grizzly999

Wenn du da Probleme mit dem Esel hast , Dein Problem. Lies dir die Boardregeln durch.

Support endet hier.

grizzly999

Keine Ahnung, was das Problem in dem Script ist, habe auch nicht geschaut, weil ich mache das immer mit forfiles.exe aus dem Resource Kit ;)

grizzly999

Also denn, per Mail oder PN, oder Telefon, oder ....

Closed

grizzly999

Bis auf in der sub.contoso.de muss man keine contoso.de ad integriert anlegen.

Nein, muss man nicht, habe ich auch nie gesagt, dass man das so tun soll ;)

Na dann viel Spaß noch :)

grizzly999

Willkommen hier

Du brauchst in jedem Rechner eine Netzwerkkarte, ein Crossover-kabel oder einen Switch, ein gemeinsames Transportprokoll, wenn es ein adressierbares ist auch eine Art Netz-ID und Host-ID, evtl. Freigaben, fertig.

Du wolltest mehr hören? Dann lies dir doch bitte deinen eigenen Thread nochmals durch, und zähle mal die Informationen, die uns gegeben hast ;)

grizzly999

Wenn der Tunnel steht solltest du ja schon den Zugriff haben, vorausgesetzt, die Clients haben den RAS-Server als Router eingetragen und die Namensauflösung steht.

Auf dem RAS-Server solltest du noch in der RAS-Verwaltung üner den Punkt "Statische Routen" das jeweils andere Netz mit der VPN-Schnittstelle asl Gateway eintragen, damit der Router die Pakete über das VPN weiterleiten kann.

grizzly999

Du solltest keine Overtakes machen und jetzt in dem Fall, wo deine Probleme weitergehen, sowieso nicht.

Mache einen eigenen Beitrag zu DEINEM Problem auf und verzichte dabei auf solche Formeln wie "bei mir klappt das nicht".

Keiner, aber wirklich keiner, weiß, was und wie du was du gemacht hast, eingerichet hast, usw. keine Fehlermeldungen, schlichtweg nichts.

Und dann erwartetst du fachmännische Hilfe hier :rolleyes:

grizzly999

Alle im selben IP-Netz? Dann nimm doch irgenein IP-Scanner wie angry IP Scanner oder GFI-Languard oder ... oder ...

grizzly999

Wäre ich danach MCSA 2000

Mitnichten, aber wie wäre es, wenn du da einfach mal auf die Hompeage von MIcrosoft schaust, das sollte ein angehender MCSA schon hinbekommen :rolleyes:

http://www.microsoft.com/learning/mcp/mcsa/requirements.asp

grizzly999

psexec von http://www.sysinternals.com könnte hier wertvolle Dienste leisten.

Alternativ wäre per Gruppenrichtlinie ein Computerstart-Skript eine Lösung.

grizzly999

Ich empfehle das hauseigene forfiles.exe aus dem Resource Kit. Mit dem klappt das bei mir wunderbar

grizzly999

naja, aber es muss ja einen geben, der der "POWER-User" ist und alles darf, oder?

Die Mitglieder der Organisations-Admins haben Forest-Wide administrative Berechtigungen, bzw. da, wo sie diese nicht haben können sie sich diese holen.

Aber eine Hierarchie kann man aus dieser Tatsache nicht - und für die o.g. Gruppen schon gar nicht - ableiten, und das wäre auch Nonsens. Nochmals,e s geht hier nicht um Hierarchien, die gab's im alten Rom :D , sondern um Aufgaben und Zuständigkeiten.

grizzly999

Closed

Völk, Föckeler usw. Benutze mal die Boardsuche

grizzly999

Da braucht man antürlich einige Konfiguration mehr. Schau mal hier rein: http://www.mcseboard.de/showthread.php?t=86179

grizzly999

Die Reverse Lookup Zonen würde ich so anlegen, dass die Server an ihrem Standort die als AD-integrierte Zonen bekommen, und die Server am anderen Standort bekommen die jeweils andere Zone (vom anderen Standort) als Sekundäre

grizzly999

Es sind die Ports 500 UDP, bei NAT-T 4500 UDP und die Protokollkennung 50 (ESP), NICHT Port 50 !!

Ist da ein NAT-gerät im Spiel?

grizzly999

Aber VPN mit Zertifikaten, das klingt nach IPSec, da sind ganz andere Ports gefragt.

grizzly999

Das ist korrekt, aber ein dickes ABER: Man macht damit einen Split-Tunnel, bei dem ich schwerste Sicherheitsbedenken habe.

Wenn der Rechner im Internet sich irgndwas einfängt, am besten irgend einen Exploit nach dem Motto "The attacker can take the control over the computer" o.ä., dann hat der liebe Hacker oder die Malware jetzt direkten Zugriff aus dem Internet über den VPN-Client ins interne Netz. Sogar schön verschlüsselt und getunnelt :eek:

Ich würde jedem der Benutzer den Mars*** blasen, der das macht (weil er es einstellen kann, z.B. lokale Admins).

Just my 2 cents

grizzly999

Nein, die Reihenfolge stimmt nicht, denn es gibt keine Reihenfolge.

Die verschiedenen Gruppen haben verschiedene Reche und Berechtigungen und damit bestimmte Funktionen. Eine Reihenfolge is nich und wäre ein Miss-Interpretation dessen.

grizzly999

Das ist alles etwas unscharf, z.B.:

der linux server ist nicht mal zur überwachung definiert jedoch blockt mir der isa server jeglichen traffic keine ahnung warum

was heißt "Nicht zur Überwachung definiert"

Dann, was willst du im Einzelnen genau erreichen, man kann aus deinen Angaben nur Mutmaßen (will ich aber nicht).

Und was heißt das hier:

das client netzwerk mit der externen ip: 80.78.252.19 sowie intern mit 192.168.1.1 - 192.168.255.255

client-Netz, externe IP

Der ISA hat normal eine externe IP.

Wie sieht den dein Netz genau aus?

Gute Anleitungen findest du übrigens hier: http://www.msisafaq.de

grizzly999

Das muss ja bei jeder Anmeldnug erneut als Anmeldeskript des Benutzers laufen (üAnmeldeskript über die Konoteigenschaft oder per GPO), da würde sich der Befehl reg.exe hervorragend anbieten. Andere ähnlich eBefehle sind auch möglich.

Schau mal in diesen Thread, da sind so ziemlich alle Möglichkleiten auch mit Beispielen behandelt, einen ReKey per Batch zu setzen: http://www.mcseboard.de/showthread.php?s=&threadid=10263

grizzly999

Es würde auf den betreffenden DC, also in den anderen Sites genügen, ich würde den Key auf allen DCs setzen.

Ein Reboot ist nicht nötig, ein Neustarten des Netlogon-Dienstes reicht aus.

grizzly999

Also, um das eindeutig zu klären:

Die Einstellung MUSS in der Default Deomain Controllers Policy gesetzt werden.

Theoreitsch könnet sie in der Default Domain Policy gesetzt werden, würde aber von einer Richtlinie in der Default Domain Controllres Policy überschrieben werden.

Und dort ist standardmäßig bei 2003 bereits eine Policy gesetzt, die die Überwachung für Erfolgreiche Anmeldeversuche setzt. Damit wird jede Policy der Domäne überschrieben.

Eine Alternative wäre es, die Default Domain Policy auf "Erzwungen (Kein Vorrang)" zu setzen, davon rate ich aber ab. Besser auf OU-Ebene die Richtlinie setzen.

Anm.: Das beste dabei wäre es sogar, eine eigene Richtlinie auf der OU zu definieren, dort die ganzen Überwachungsrichtlinieneinstellungen der Default Domain Controllers Policy zu übernehmen und zu erweitern. Never change a default Policy ;)

grizzly999

Das ist egal. Die Inter-Site-Replication macht der Bridghead-Server. Dieser wird nach einem bestimmten Algorithmus vom ISTG (InterSite Toplogie Genrator) , der auf einem der DCs läuft, für jede Domäe und Standort bestimmt

grizzly999