woiza

Falsch. Mit ntbackup bringst immer das GANZE AD auf den Stand der Sicherung, weil ja immer die ntds.dit als ganzes zurückgeschrieben wird. Was danach passiert, hängt davon ab, ob du weitere DCs in der Domäne hast. Bei einem DC ist das aut. Restore grade umsonst. Du setzst damit lediglich die Versionsnummer hoch, die zwischen den DCs verglichen wird, um das aktuellste Objekt feststellen zu können. Bei einem DC ist nicht viel mit vergleichen. Bei einem DC ist es immer so, dass der Stand des Backups wieder hergestellt wird und alle danach erfolgten Änderungen für die Katz sind. Ein Grund mehr für mind. 2 DCs ;). Wenn du ein aut. Restore mit mehreren DCs machst, wird auf dem DC auch die alte ntds.dit hergestellt, die Neuerungen seit dem Backup sind weg, werden aber nach dem Reboot wieder repliziert. Stimmt, da wird der aut. Restore auch nur im Zusammenhang mit mehreren replizierenden DCs erwähnt. Ich würde ich dir folgendes Tool ans Herz legen: .: www.kaczenski.de :. <-- Werding Damit kannst du gelöschte Objekte online wiederherstellen ohne die umständliche und zeitraubende Verzeichniswiederherstellung. Das wäre in der Tat für einen einzelnen DC das Beste und Günstigste. Quest ist toll, ich würde mein Budget dann trotzdem erstmal in einen weiteren DC installieren.

Kann es sein, dass du den bereits beim DCPromo vorhandenen Container meinst? Dieser hieße dann nicht OU=, sondern CN=

Nö, ist auch eher interessehalber. Mich würde einfach interessieren, was gerade so marktüblich ist.

Darf man fragen, wie der grobe finanzielle Rahmen der Stelle ist?

Massenänderungen mit ADModify - faq-o-matic.net Du kannst einfach eine Zahl mit angeben, also 1 für den ersten Buchstaben.

Lass beide DCs in den Clienteinstellungen auf den ersten zeigen.

Ähm, hast du die DNS-Zonen denn händisch auf der neuen Kiste angelegt? Hast du AD-integriertes DNS? Auf welchen DNS-Server zeigen die DCs?

Hi, ich habe das MUT Kompendium von Joos. Finde ich, wie das Vistabuch auch, ganz gut. Gruß woiza

Und da heißt es immer, der ÖD bezahlt schlecht :(. Wenn ich mir überlege, was das Netto ist, davon könnte ich in Stuttgart nicht überleben. Darf man fragen, was eure Firma so tut?

Brutto? :eek: :shock:

Hmm jein, habt ihr nen Single Domain Forest? Ansonsten könnte der Acount durchaus in ner anderen Domäne liegen. Das Script in der vorliegenden Form durchsucht nur die aktuelle Domäne. Versendet können die Mails auch via Telnet werden. Oder Blat, oder... Da sie ja an einen bekannten Empfänger gehen, ist es Exchange wurst, ob der Absender evtl. unbekannt ist. Schwierig zu sagen, kenne ja deine Struktur nicht. Zumindest solltest du darin sehen können, wo die Mail in deine Exchange Org gekommen ist.

Die vbs tut einwandfrei. bist du mit deiner Maschine in der richtigen Domäne?

Geht, aber wäre der Holzhammer. Verwende lieber Aspnet_regiis.exe -i. Siehe auch

Mir wiederum wäre neu, dass Win 98 nen IIS hatte ;)

IIS ist ein Webserver und verteilt eher selten IPs...

Wie viele Domänen sind es denn?

Ich will das nicht breittreten, aber es geht nicht darum, die Verschlüsselung zu knacken, sondern an den verschlüsselten PW-Hash zu kommen. Dann werden alle möglichen PWs gehasht und kontrolliert, ob ein übereinstimmender Hash gefunden wird. Schau mal unter Brute Force bei Wikipedia nach. Ist vergleichbar mit nem Fahrradschloss. Wenn du die Nr. nicht mehr weisst, dann probierst du alle durch. Jetzt kannst du dir vorstellen, dass dies bei einem vierstelligen Schloss kein Problem ist. Bei sechs Stellen sitzst du ne Weile. Das Gleiche gilt für PWs. Wenn du nur Buchstaben verwendest, gibt es pro Stelle 52 Möglichkeiten. Bei einer Länge von 5 würde der Vorgang nicht mal ne Minute dauern. Bei einer Länge von 8 wären es schon rund 20 Tage. Wenn du Zahlen dazunimmst, werden es 62 Zeichen. Bei einer Länge von 8 wären es dann schon rund 80 Tage. Da wären wir dann bei der Sinnhaftigkeit von häufigen PW Wechseln. Wenn du mal nen Security Workshop machst, werden dir die Augen übergehen, was per default im Win möglich ist. Also mit Aussagen, was definitv unmöglich ist, wäre ich vorsichtig. So, ich denke ich hab jetzt nicht gegen Boardregeln verstossen ;) Gruß woiza

Off-Topic: Geben Sie mir ein 'Ping', Vassili. Aber bitte nur ein einziges 'Ping'. :D Spass beiseite. Es gibt im AD 2 Replikationen. Und Sonar überwacht NTFRS, aber nicht NTDS.

gysinma hat Recht. In diesem Szenario wäre der DC in ner VM ungut. Auf dem Server soll ein TS laufen. Dieser wird wohl Mitglied der Domäne. Und die Domäne lebt virtuell auf diesem Server? Da hätte ich Bauchschmerzen. Wenn die VM spinnt, kann ich mich je nach Policy mit meinem Domain Account nicht mehr am Server anmelden, weil er keinen DC findet. Und den DC krieg ich nicht ans laufen, weil ich mich nicht anmelden kann. Klar gäbe es da auch noch lokale Accounts, aber mir würde es nicht gefallen.

Äh Leute, wir reden hier von 10 Usern. Da will ich doch den PC jünger als 5 Jahre sehen, der das als DC nicht verpackt, selbst wenn er alle FSMOs hat und der einzige GC ist. Mit dem DC als VM hätte ich keine Probleme, aber der SQL ist da nicht so gut aufgehoben. Wenn ein DC in der VM läuft, sollte das Hostsystem aber auf keinen Fall in dieser Domäne sein, das kann unschön enden. Wir haben bei uns für manche Zwecke nen W2k3 mit VMWare in ner eigenen Workgroup. Darauf läuft dann ein DC, ein Fileserver/DHCP, ein WSUS und ein NetInstall Server in jeweils getrennten Maschinen. Tut einwandfrei. In dem hier beschriebenen Szenario würde ich aber eher noch ne Pizzabox kaufen, da reicht ein Single P IV, da muss kein Xeon rein, und darauf würde ich den DC installieren.

Das würde ich gerne sehen, wie jemand aus einem laufenden AD Passwörter einfach "ausliest"... Natürlich kann man an die verschlüsselten Passwörter kommen, etwa mit nem Sniffer, allerdings müsste es schon ein sehr simples Passwort sein, dass dieses einfach mit Brute Force oder Dictionary Attack entschlüsselt werden kann. Daher würde ich auch empfehlen, erstmal das PW zu ändern und dabei auf die Sicherheitsregeln für Passwörter zu achten.

Intrusion Detection ist ein ziemlich fortgeschrittenes Thema und kaum jemandem zu vermitteln, der nicht sonderlich tief in der Materie ist. Ohne genauere Kenntnis der Strukturen kann man sowieso wenig sagen. Wie sehen die Angriffe aus? Wird sein Rechner angegriffen oder nur sein Account für Angriffe benutzt? usw. usf. Woher weißt du, dass dieser "Angriff", falls es denn einer war, mit seinem Account durchgeführt wurde? Gruß woiza

Dann viel Glück (bzw. mehr Glück ;) ) bei deiner neuen Arbeit. Kann ja nur besser werden. Gruß woiza

Ähm, klar kannst du dich anmelden. Schau mal hier, was die Teile wirklich tun. Wenn anmelden nur auf dem FSMO Owner ginge, bräuchte man ja nicht mehrere DCs aufstellen ;). Die FSMOs brauchst du, dass deine Domäne tut. Grob gesagt sind zwar alle DCs gleichwertig, allerdings ist es (wie im richtigen Leben) bei einigen Dingen wichtig, dass einer den Hut aufhat, sonst gibt es Chaos. Beispielsweise bekommen alle Objekte im AD eine eindeutige Kennung, die RID. Diese kann von jedem DC vergeben werden, damit auch auf jedem DC Objekte erstellt werden können, allerdings wären doppelte Nummern extrem ungeschickt. Deshalb gibt es einen RID-Master, der kleine Nummernpakete den einzelnen DCs zur Verfügung stellt. Gruß woiza

Die Fileshares haben wenig bis gar nix mit AD zu tun. Die Anmeldungen kannst du im Securitylog sehen und z.B: mit Logparser auswerten. Was wir aber immer noch nicht wissen ist, ob du ein permanentes Monitoring oder nur ab und zu nachschauen möchtest.