Daim

Bonjour,

wichtig ist, das du die Betriebsmaster und den Globalen Katalog verschiebst:

wenn es um das Thema AD geht, gibt es kein Pardon ;) .

Zum einen: Unter Windows Server 2003 MÜSSEN nicht unbedingt die FSMO-Rollen verschoben werden.

Das passiert auch automatisch beim herunterstufen des DCs. Dieser verschiebt dann selbstständig die FSMO-Rollen auf einen bestehenden Windows Server 2003 DC.

Es ist lediglich darauf zu achten, dass je nach Umgebung der GC nicht mit dem Infrastrukturmaster zusammen auf einem DC sein sollte, es sei denn, es ist auf allen DCs dieser Domäne der GC aktiviert.

Das steht aber in dem zweiten (und weiterführenden Links), den ich oben gepostet hatte.

Zum anderen: Der globale Katalog wird nicht verschoben, sondern auf einem weiteren DC aktiviert. Der GC ist nicht zu vergleichen mit den FSMO-Rollen.

Der Link ist zwar von NT4 auf 2003... kann in diesem Abschnitt aber weiterhelfen:

Meine geposteten Links reichen völlig aus und sind aktuell.

Servus,

dazu muss zum einen die globale Richtlinie, idealerweise in der Default Domain Controllers Policy unter:

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\<Verzeichnisdienstzugriff überwachen>

aktiviert sein.

Zum anderen gilt es dann in der SACL des Containers bzw. OU die gewünschten Optionen auszuwählen.

Das ganze ist unter Windows 2000/2003 leider noch sehr spärlich gelöst.

Dieses Verhalten wurde (unter anderem) im Windows Server 2008 verfeinert.

Früher (Windows 2000/2003) wurde lediglich protokolliert, wer welches Objekt bzw. Attribut verändert hat. Die eigentlichen Werte (alter Wert/neuer Wert) blieben aber einem verborgen. Dieses Verhalten wurde im Windows Server 2008 geändert und man bekommt nun detailliert in der Ereignisanzeige die veränderten Werte zu sehen.

Trotzdem gilt auch dabei: Eine Protokollierung ist vom Betriebsrat/Datenschutzbeauftragten zu genehmigen!

Servus,

wenn der Windows Server 2003 R2 der erste R2-DC in der Windows Server 2003 Gesamtstruktur werden soll, so musst du das ADPREP von der zweiten R2-CD auf dem Schema-Master, mit dem Schalter /FORESTPREP ausführen.

Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Alles weitere, erfährst du von hier ;) :

Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Buenos tardes,

wie soll ich auf den pc zugreifen wenn mann sich nicht einloggen kann n der pc in einer niederlassung steht?!

in dem jemand diesen Client startet und du dich von deinem Arbeitplatz im Eventlog mit dem Client verbindest. Dazu startest du das Eventlog auf deiner Admin-Workstation, klickst auf AKTION und wählst die Option "Verbindung zu anderem Computer herstellen..." aus.

Das wird dir aber nichts bringen, denn den Grund wirst du nicht finden...

als admin anmelden den client in arbeitgruppe nehmen , neustarten anschliessend wieder in die domäne verschieben?!

Genau so würde ich das machen. Aber bevor du den Client erneut in die Domäne nimmst, lösche unbedingt vorher das Computerkonto-Objekt aus der Domäne.

Servus,

Kann ich solche nicht aufgelöste SIDs als Waisen betrachten, die von gelöschten Usern stammen und sie gefahrlos löschen?

ja, in den meisten Fällen ist das der Fall.

Es tauchen noch die SIDs von längst nicht mehr existierenden Benutzern auf.

Das kann aber auch bei dem bekannten Problem im Fall von: Wenn der Infrastrukturmaster und der GC auf einem DC liegt. Wenn in diesem Szenario dann nicht ALLE DCs der gleichen Domäne ebenfalls GCs sind, kann dieses Verhalten ebenfalls auftauchen.

Hätte es nicht auch gereicht das Computer Konto zurückzusetzen und ihn dann unter den gleichen Namen wieder aufzunehmen?

Doch, dass hätte auch reichen sollen.

Aber der Hinweis von zahni ist wichtig!

Das Problem war noch das ich den gleichen Computernamen nicht wieder verwenden kann denn dann wird das Computerkonto wieder deaktiviert.

Obwohl du zuerst den Client aus der Domäne genommen und anschließend das Computerkonto-Objekt aus dem AD entfernt hast? Das ist merkwürdig...

Möglicherweise hängt das mit der Anzahl meiner Standorte und den damit verbundenen DCs zusammen...

Du hättest sicherstellen müssen, dass das Computer-Objekt auch auf ALLEN DCs der Domäne entfernt wurde. Bedeutet, etwas Zeit verstreichen lassen für die Replikation.

Servus,

Wenn ich den Computer aus der Domäne nehme, das Computerkonto lösche und ein neues erstelle sollte das Problem doch gelöst sein, oder?

wenn das hier "BTM011008" also der Client ist, bei dem das Problem besteht, dann würde ich das auch so sehen.

Wie immer gute und sehr hilfreiche Antworten von Dir.

Den ersten Teil habe ich verstanden. Du weißt alles , oder?

Nee... ich weiß natürlich auch nicht alles. Vielleicht ein bisserl mehr als andere ;) .

AD ohne DNS geht nicht wirklich, richtig, aber man kann bei der Installation ja sagen "Ich kümmere mich später drum" und macht dann erstmal weiter.

Dieses "...und macht erstmal weiter" bedeutet aber in deinem konkreten Fall, dass du anfängst mit ADMT zu migrieren. Genau dabei wirst du aber dann Probleme bekommen.

MS sagt ja, dass 90% aller AD-Probelme eigentlich DNS-Probleme sind.

...wenn nicht, sogar noch höher.

ich hatte es so verstanden, dass ADMT mir nur die Nutzer migriert, aber nicht wirklich die Client(rechner), die sich dann ja - zurückgelassen - in der dann evtl. nicht mehr exitenten Domäne befinden an der sie sich dann stetig versuchen erfolglos anzumelden.

Dann wäre das Tool ja nutzlos. Denn das Benutzer-Profil, das meistens lokal auf dem Client liegt, hängt natürlich auch vom Computerkonto ab. Wenn nur die Benutzerkonten migriert werden könnten, dann könnte man x-beliebige andere Tools dazu verwenden, wie z.B. CSVDE, LDIFDE etc. Damit habe ich auch recht schnell neue Benutzer erstellt.

Nenee... das ADMT macht schon mehr. Genau das richtige Werkzeug, für eine Migration.

Also bleiben mir auch auf beiden Servern, in beiden Domänen die Nutzer erhalten?

Teste das mit einem Test-User an einem Test-PC aus. Ich "meine" der Benutzer wird aus der Quelle entfernt, bin mir aber gerade nicht sicher.

Quasi kann also dann ein Benutzer Mitglied in zwei Domänen sein, auf der alten mit seiner ursprünglichen ID und auf dem neuen mit seiner alten und neu generierten ID?

Wie gesagt, wenn ich recht der Annahme gehe, dann wird der Benutzer aus der Quelle entfernt.

In der Ziel-Domäne wird ein neues Benutzer-Objekt mit einer neuen SID erstellt und in das Attribut SID-HISTORY des neuen Benutzer-Objekts, wrd die "alte" SID (vom Benutzer-Objekt aus der Quell-Domäne) hinzugefügt. Wenn nun der Benutzer auf eine Ressource in der Quell-Domäne zugreifen wollte, zückt das neue Benutzerkonto sie "alte" SID aus der SIDHistory und erhält somit Zugriff.

Im übrigen ist diese SID-History Variante nur für den Übergang, genauer, während einer Migration gedacht und nicht für die Ewigkeit.

Nehme ich dann die alte Domäne (resp. DC) ausser Betrieb, ist das dem Client egal, weil er sich dann einfach an der (übrig gebliebenen) neuen Domain anmeldet? Habe ich das richtig verstanden?

Klar, wenn das Benutzerkonto samt Computerkonto in die neue Domäne migriert wurde,

spielt für diesen Benutzer, die alte Domäne bezgl. der Authentifizierung (Domänenanmeldung) keine Rolle mehr. Während der Migration, die ja auch in größeren Umgebungen Monate dauern kann, befindet sich nun der Benutzer in der neuen Domäne und muss aber noch auf die Freigaben in der alten Domäne zugreifen. Das erschlägt man eben durch die SID-History.

Das ist ein Thread in dem ich wiedre viel gelernt habe.

Jawollja, jeden Tag immer etwas mehr ;) .

Servus,

Der alte hat - in gruer Vorzeit mal festgelegt - die IP 172.16.1.3 der neue soll die 192.168.0.3 haben.

gib doch dem neuen Server vorübergehend, während der Migration eine IP-Adresse aus dem Bereich 172.16.x. Wenn die Migration angeschlossen ist, kannst du die IP-Adresse dann ja ändern.

03. AD ohne DNS aufsetzen, dem neuen Server kurzzeitig eine 172er IP geben und DNS nach der Migration im Nachhinein konfigurieren?

Wie willst du auf dem neuen Server das AD installieren ohne DNS?

Das DNS ist für das AD elementar.

04. Den alten Server vom Netz nehmen, die DNS und IP-Einstellungen nach 192er-IP ändern und dann die Nutzer migrieren?

Das kannst du auch machen.

Geht das irgendwie anders schneller?

Eieieiii.... dann hast du aber das Prinzip von ADMT noch nicht verstanden.

Genau das ist doch der Vorteil von ADMT. Du migrierst im ersten Schritt das Benutzer- und im zweiten das Computerkonto. Somit bleiben dir also alle Profile erhalten.

Der Benutzer schaltet dann seinen Client aus der alten Domäne aus, baut ihn in der neuen Domäne auf, fährt den Client hoch und meldet sich mit seinen Benutzerdaten an.

Alles sieht für den Benutzer dann so aus, wie vorher.

Bei der Migration mit ADMT legt das Tool einen neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SIDHistory hinzu.

Das Benutzer- sowie Computerkonto wird in der neuen Domäne während der Migration mit ADMT automatisch erstellt.

Yepp, trete mal auf die Seite. ;)

Irgendwie stehe ich immer noch drauf ;) .

Hast du zufällig was mit WSUS zu tun ?

Da gab es doch mal ein Spiel mit "Mister X" den es zu erraten gilt... cool :D .

Servus,

um welche Informationen handelt es sich denn und in welcher Dateiform liegen die Daten vor ?

Prinzipiell geht das per Skript, ADSI, CSVDE oder LDIFDE.

Nö, ich hab keine Testumgebung zur Verfügung, und zum spielen ist mir meine funktionierende Umgebung zu wertvoll. ;)

Das hätte ich dir auch sehr ans Herz gelegt, nicht deine produktive Umgebung "zu schroten" ;) .

Wir können uns ja im April persönlich drüber unterhalten. ;)

Wir können uns immer und jederzeit gerne unterhalten, aber warum im April?

War da was? Steh ich gerade auf dem Schlauch? Wo ist der nächste Arzt?

Servus,

was könnte ich tun, wenn ich von einem W2K-Server auf einen W3K-Server mit der AD umziehen muß

wenn das der erste Windows Server 2003 DC in der Gesamtstruktur ist, musst du im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus.

Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest.

Denn das ADPREP bei R2 befindet sich auf beiden CDs.

Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest.

Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig.

Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du

die DNS-Server Einstellung verändern.

Siehe:

Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ?

Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert".

Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben:

Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Zusätzlich solltest Du den neuen DC zum GC deklarieren.

Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen.

Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC)

Welche Dienste noch übernommen werden sollten bzw. was noch alles zu beachten ist, bevor der 2000er DC evtl. aus der Domäen genommen wird,

erfährst du aus diesem Artikel:

Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Und noch der Hinweis, dass wenn möglich jede Domäne zwei DCs haben sollte.

und ich habe noch 3 Win 95-PCs im Einsatz. Haben die weiterhin Zugriff auf die Domäne??

So wie Sunny61 es bereits geschrieben hat, ist das entscheidende das SMB-Signing.

Der Link mit dem Hinweis zu Dos oder 9x Clients, wäre allerdings dieser:

Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Salut,

wir haben einen 2. DC in der Domäne gehabt (keine Rollen bisher auf dem DC). Dieser ist leider gecrasht und das Backup was wir von der Kiste haben ist leider auch defekt bzw. ich kann nur ein Backup wiederherstellen als die Kiste noch nicht in der Domäne war.

so sollte natürlich ein Backup nicht aussehen.

Elementar bei einem DC, ist der Systemstatus (System State) den es zu sichern gilt.

So jetzt kann ich im Active Directory unter Domain Controllers den DC löschen und dort wählen das der DC nicht mehr DCPromo herabgestuft werden kann.

Das reicht bei weitem nicht aus. Wenn das so einfach wäre, könnte das ja jeder "schnell" mal machen ;) .

Dort erhalte ich die Meldung das das Object "xxx" ein Container ist und andere Objekte enthält.

Diese Meldung erscheint z.B. auch (unter anderem) bei einem Client, an dem ein Drucker im AD veröffentlich wurde, oder eben auch an DCs. Es gäbe da noch weitere Punkte.

Ob das Objekt, in diesem Fall der DC noch weitere Unterobjekte erhält, muss man nicht unbedingt ADSIEdit, einen LDAP-Browser oder den Active Directory Explorer verwenden. Im Snap-In Active Directory-Benutzer und -Computer einfach unter ANSICHT die Option Benutzer, Gruppen und Computer als Container aktivieren.

Danach werden die Computerobjekte als Container dargestellt und falls diese weitere Objekte enthalten, kommen diese somit zum Vorschein.

Das macht bei dir aber keinen Sinn, da der DC ohnehin gecrasht ist.

Das soll lediglich zur Erklärung diesen.

Frage ist nun was für Objekte meint diese Fehlermeldung?

Du würdest diese wie ich bereits geschrieben habe sehen.

Aber wie gesagt, macht das bei dir keinen Sinn, da der DC noch an vielen weiteren Stellen im AD steht die es zu entfernen gilt.

Ist dieser Wizard dasselbe was man händisch mit Adsiedit macht

Bei weitem nicht. Die händische Entfernung der Leiche aus dem AD muss durchgeführt werden. Erst danach ist die Leiche auch im Jenseits begraben ;) .

Hast Du Dir diesen Artikel auch genau durchgelesen:

Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung

Hier kannst Du Dir über NTDSUTIL einen Webcast anschauen:

7WTT TechNet Webcast: Active Directory - Wartung Ihres Verzeichnisdiensts mit NTDSUTIL (Level 200)

Du kannst den DC auch auf folgende Variante entfernen:

- Öffne ADSIEdit und verbinde Dich mit der Domain-Partition

- Navigiere zum Contaier "OU=Domain Controllers" und lösche dort die

Einträge des nicht mehr existierenden DCs

- Ebenfalls in der Domain-Partition, löscht Du alle Einträge des DCs auf

folgendem Pfad "CN=Domain System Volume,CN=File Replication

Service,CN=System,DC=<DeineDomäne>,DC=<TLD>

- Dann verbindest Du Dich mit der Configuration-Partition im ADSIEdit und

entfernst alle Einträge des nicht mehr existierenden DCs (z.B.

CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>)

- Entferne alle Einträge vom DC, die im DNS und WINS existieren

Es sollte aber darauf geachtet werden, zwei DCs in der Domäne zu betreiben.

Servus,

Container (CN) kannst du entweder mit CSVDE, LDIFDE oder per Skript erstellen (bitte danach mit der Suchmaschine deines Vertrauen im Internet suchen).

Mit CSVDE oder LDIFDE könnte das in etwa so aussehen (bitte die Eingabe nochmals genauer überprüfen, dies ist nur ein Ansatz):

dn: CN=Data,OU=Abteilung,DC=Domäne,DC=TLD

changetype: add

objectClass: top

objectClass: container

cn: Data

description: Data

distinguishedName: CN=Data,OU=Abteilung,DC=Domäne,DC=TLD

instanceType: 4

name: Data

Servus,

Aus diesem Grund möchte ich, dass der Mailserver die Funktion des Domänenkontrollers übernimmt.

ist das zufällig ein Exchange Server? Dann wäre das keine so gute Idee.

Denn der Server auf dem ein Exchange installiert worden ist, sollte nachträglich nicht mehr verändert werden. Was soviel bedeutet, der Serevr sollte nach der Exchange Installation weder zum DC herauf- noch heruntergestuft werden. Das wird von Microsoft nicht supportet, auch wenn man es technisch lösen kann.

Ich würde die Migration natürlich am liebsten ohne eine Neuinstallation der beiden Server durchführen.

Stufe den anderen doch zum DC und siehe zu, dass ein weiter Server zum DC gestuft wird.

Denn wenn möglich, sollte jede Domäne zwei DCs haben (und wenn der zweite lediglich eine VM wäre).

Mich interessiert vor allem was bei der Migration zu beachten und mit welchen Problemen zu rechnen ist.

Im Prinzip ist das recht einfach.

Du stufst einen anderen Server als zusätzlichen Domänencontroller deiner bereits existierenden Domäne hinzu. Anschließend aktivierst du auf diesem den GC und verschiebst die FSMO-Rollen. Das DNS muss ebenfalls dabei installiert werden und im idealfall, befindet sich deine FLZ im AD. Denn dann erledigt die AD-Replikation für dich den Rest.

Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Was noch alles zu beachten ist, wenn der erste DC ausgetauscht werden soll, erfährst du aus diesem Artikel:

Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Und dabei ist der WINS wohl sehr hilfreich. ;) Oder hab ich das immer noch nicht verstanden?

Dann beende doch mal den DNS-Dienst auf deinen DCs (bitte nur in einer Testumgebung!) und schau mal, was die AD-Replikation so macht... ;) .

Servus,

das gleiche bei mir, aber das ist bei den Charter-Zertifikaten schon immer so gewesen.

Es gibt neben den eigentlichen Zertifikaten noch zwei "besondere" Zertifikate, nämlich für die "ganz schnellen" Prüflinge.

Stand heute meine ich, bekommen die ersten 500 die eine Prüfung erfolgreich bestehen, noch ein zusätzliches Zertifikat. Das lautet "Early Archivier". Somit kann man ganz stolz behaupten, ich war einer der ersten 500 Prüflinge Welteit, die diese Prüfungen gemacht und bestanden hat. Früher waren es nicht 50 sondern mehr..

Dann gibt es noch den "Charter Member".

Dieses Zertifikat erhält man, wenn man unter den ersten 1000 (oder 2000) ist.

Früher waren es 2000, heute meine ich, sind es 1000. Microsoft hat die Werte runtergeschraubt.

Weil man eben dann einer der ersten war, die diese Prüfung bestanden hat, belohnt Microsoft einem das, mit einem extra Zertifikat.

Das ich dir das erklären muß, halte ich für ein Gerücht. ;)

Das war ja auch eher eine rhetorische Frage und um dir noch eine "Chance" zu geben, dich da sauber herauszuwinden ;) .

Die Leitungen zu den Standorten waren bzw. sind nicht die besten und stabilsten.

Die AD-Replikation braucht in der Wirklichkeit sogar weniger als eine ISDN-Leitung an Kapazität. Die Einschränkung die man aber dann damit hat, ist die Replikations-Dauer. Die Replikation dauert dann eben länger...

Nach Installation von WINS auf den DCs (1 x bei mir) und jeweils auf den DCs in den Standorten waren DNS-Probleme und damit verbundene AD-Replikationsprobleme zu 99 % gelöst. ;)

Sorry, aber das verwechselst du jetzt aber. Ein WINS-Server ist in jeder Domäne hilfreich - keine Frage. Aber nicht bei der AD-Replikation. Dort ist nunmal das DNS der elementare Dienst bei der Namensauflösung und keineswegs WINS. Was macht jeder DC von der eigentlichen AD-Replikation? Richtig, er führt ein DNS-Lookup durch und warum? Um zwei Dinge sicherzustellen. Das nämlich zum einen die DNS-Namensauflösung funktioniert und zum anderen, der Replikationspartner IP-technisch erreichbar ist.

Servus,

warum denn das ?

Du musst "lediglich" die Randbedingungen beachten, dann klappt das auch mit dem Nachbarn...

Um das mit anderen Worten zu beschreiben:

Falls Exchange 2000 auf einer Windows 2000 Maschine laufen sollte und beide Systeme aktualisiert werden sollen, dann muss zuerst Exchange 2000 auf Exchange 2003 upgedatet werden. Denn Exchange 2003 läuft unter Windows Server 2000 aber nicht umgekehrt (Exchange 2000 auf Windows Server 2003), dass geht nicht. Daher muß zuerst ein Exchange Update gemacht werden und dann das Betriebssystemupdate von Windows Server 2000 auf Windows Server 2003.

Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“.

Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der

Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren.

Der Befehl dazu lautet:

Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD".

Du musst eben die Bedingungen beachten.

Servus,

ich habe zwar deine Situation nicht klar verstanden, aber lies dir doch zuerst diesen Artikel durch und frage dann gezielter:

Yusuf`s Directory - Blog - Gruppen

Bonjour,

WINS ist sehr hilfreich für die einwandfreie Replikation.

das musst du mir jetzt aber mal genauer erklären.

Dann kann ich das so nicht nachvollziehen, da es bei mir genau so funktioniert.

Teste das doch einmal mit einem anderen Benutzer oder erstelle dir einen Test-Benutzer und führe die Objektdelegierung erneut durch.

Bonjour,

du hast in der Objektdelegierung die Option "Setzt Benutzerkennwörter zurück und erzwingt Kennwortänderung" gesetzt?

Oder wie bist du genau vorgegangen?