P.Foeckeler

Hmmm, außer dem "Only encrypted connection are allowed" das ihr schon probiert habt fällt mir eigentlich keine Server-Einstellung ein mit der Simple LDAP Binds verboten werden. Hast du das gleiche Ergebnis auch mit anderen LDAP-Browsern (LDP.EXE von Microsoft oder LEX - The LDAP Explorer ) ?? Außerdem: Bei einem LDAP Bind kommt auch dann die Fehlermeldung "Invalid Credentials", wenn in Wirklichkeit der Benutzer nur disabled ist, oder sein Passwort abgelaufen ist, oder er bei der nächsten Anmeldung das Passwort ändern muss.....ist es vielleicht das? Gruß, Philipp

Probier mal bei LDAP Simple Binds an AD als Credential das gute alte "Domain\Username" Sei dir bitte aber bewußt dass du mit Simple Bind dein Passwort unverschlüsselt über's Netz schickst - also wenn das ganze nicht in einer LDAP-SSL-Session abläuft ist das eigentlich nicht sehr toll. Was stört euch den so an GSS Negotiate.....das wäre nämlich dann in diesem Fall eine schöne Kerberos-Anmeldung. Warum nicht? Gruß, Philipp

Hallo, Sorry wenn ich da widersprechen muss. Keine Ahnung was du da angeschaut hast mit dem ADSIEdit, aber: Es gibt kein Recht "Gruppenmitgliedschaften lesen", es gibt Rechte auf das gesamte Objekt, oder dessen Attribute, oder ein paar spezielle Rechte wie z.B. "Passwort setzen". Standardeintrag für "Authenticated Users" ist auf alle Objekte in einer Domäne der folgende: "List Content" für Container + OUs "Read all Propertiers" <- hier ist das Auslesen der Gruppenmitliedschaft drin "Read permissions" In der Schnellübersicht der Rechte siehst du das bei den Authenticated Users schlicht als Häckchen bei "READ", für die Einzelheiten mußt du die "Advanced Settings" aufmachen.... Andernfalls wurden die Standardrechte in Deinem AD verändert, was aber sehr exotisch wäre.... Kannst ja mal einen DSACL Output des betreffenden Objektes posten, da wären die Einzelheiten auch zu sehen.... Gruß, Philipp

Du kannst mit diesem kostenlosen Tool hier nachprüfen, dass der Eintrag "Authentifizierte Benutzer" auf alle OUs das Leserecht bereits hat: LIZA - Active Directory Security, Permission and ACL Analysis Gruß, PHilipp

Hallo, die Gruppenzugehörigkeit ist bei AD-Usern im Attribut "memberOf", das ist ein gewöhnliches Attribut, auf das im AD _JEDER_ angemeldete User Leserechte hat. Du brauchst also keine speziellen Rechte zu vergeben :) Liste der User-Attribute: SelfADSI : Attribute für AD User (Windows 2008) Gruß, Philipp

Hallo, warum klappt denn der Aufruf des externen DSACL-Kommandos bei Dir aus der Powershell heraus nicht? Kannst du direkt auf der Kommandozeile heraus die Rechte ändern? Welche Fehlermeldung kommt da? Außerdem hätte ich hier eine Alternative, wie du in VBSCript die Berechtigung ändern kannst: Const ADS_SD_CONTROL_SE_OWNER_DEFAULTED = &H1 Const ADS_SD_CONTROL_SE_GROUP_DEFAULTED = &H2 Const ADS_SD_CONTROL_SE_DACL_PRESENT = &H4 Const ADS_SD_CONTROL_SE_SACL_PRESENT = &H10 Const ADS_SD_CONTROL_SE_SACL_DEFAULTED = &H20 Const ADS_SD_REVISION_DS = 4 Const ADS_ACETYPE_ACCESS_ALLOWED = &H0 Const ADS_ACETYPE_ACCESS_DENIED = &H1 Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5 Const ADS_ACETYPE_ACCESS_DENIED_OBJECT = &H6 Const ADS_FLAG_OBJECT_TYPE_PRESENT = &H1 Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2 Const ADS_ACEFLAG_CONTAINER_INHERIT_ACE = &H2 Const ADS_ACEFLAG_INHERITED_ACE = &H10 Const ADS_RIGHT_DS_CONTROL_ACCESS = &H100 Const USER_CHANGE_PASSWORD = "{AB721A53-1E2F-11D0-9819-00AA0040529B}" Const WKSID_SELF_SDDL = "S-1-5-10" Const WKSID_SELF = "NT AUTHORITY\SELF" Const WKSID_EVERYONE_SDDL = "S-1-1-0" Const WKSID_EVERYONE = "EVERYONE" '__________________________________________________________________________________________________ 'get existing user permission data Set dso = GetObject("LDAP:") Set user = dso.OpenDSObject("LDAP://yourserver/CN=test,OU=test,DC=EXAMPLE,DC=COM", "EXAMPLE\administrator", "Pa$$w0rd", 1) Set userACL = user.get("nTSecurityDescriptor") Set userDACL = userACL.DiscretionaryAcl WScript.Echo user.distinguishedname & vbCrLf 'prepare new DACL to write for this user Set newDAcl = CreateObject("AccessControlList") newDAcl.AclRevision = ADS_SD_REVISION_DS newDAcl.AceCount = 0 'check all existing dacl entries... Set userAce = CreateObject("AccessControlEntry") For Each userAce In userDACL 'Debug: Output DACL entries 'WScript.Echo userAce.Trustee & ", " & userAce.AccessMask & ", " & userAce.AceType & ", " & userAce.AceFlags & ", " & userAce.Flags & ", " & userAce.ObjectType & ", " & userAce.InheritedObjectType 'build a new DACL with all the entries which are NOT related to "Change Password" (for Self / EveryOne) If Not ((UCase(CStr(userAce.ObjectType)) = USER_CHANGE_PASSWORD) And ((UCase(CStr(userAce.Trustee)) = WKSID_SELF) Or ((UCase(CStr(userAce.Trustee)) = WKSID_EVERYONE)))) Then 'only entries which are NOT inherited If ((userAce.AceFlags And ADS_ACEFLAG_INHERITED_ACE) = 0) Then newDAcl.AddAce userAce End If End If Next 'create new entry => deny "Change Password" for Everyone Set newAce = CreateObject("AccessControlEntry") newAce.Trustee = WKSID_EVERYONE newAce.AccessMask = ADS_RIGHT_DS_CONTROL_ACCESS newAce.AceFlags = 0 newAce.AceType = ADS_ACETYPE_ACCESS_DENIED_OBJECT newAce.Flags = ADS_FLAG_OBJECT_TYPE_PRESENT newAce.ObjectType = USER_CHANGE_PASSWORD newDAcl.AddAce newAce 'build new ACL to write for this user Set newAcl = CreateObject("SecurityDescriptor") newAcl.OwnerDefaulted = True newAcl.GroupDefaulted = True newAcl.SaclDefaulted = True newAcl.DaclDefaulted = False newAcl.Revision = 1 newAcl.Control = ADS_SD_CONTROL_SE_DACL_PRESENT Or ADS_SD_CONTROL_SE_SACL_PRESENT Or ADS_SD_CONTROL_SE_SACL_DEFAULTED Or ADS_SD_CONTROL_SE_OWNER_DEFAULTED Or ADS_SD_CONTROL_SE_GROUP_DEFAULTED newAcl.DiscretionaryAcl = newDAcl 'write the ACL back to the user: user.Put "ntSecurityDescriptor", newAcl user.SetInfo Sieht komplizierter aus als es ist :) Gruß, Philipp

Hallo, du kannst so genannte "Query-based Distribution Groups" erzeugen, deren Mitgliedschaft stets aufgrund eines LDAP-Filters bestimmt wird. Der Nachteil: - Diese Gruppen existieren nur in Umgebungen mit einer Exchange 2003 (und höher) Installation - bzw. mit installiertem E2K3-Schema. - Diese Gruppen sind KEINE Security Principals, sie können also nicht für Vergabe von Berechtigungen verwendet werden, deswegen auch die Bezeichnung "Verteilergruppen" - denn Mailempfänger können diese Gruppen werden.... Links: Für die Gruppen selbst: Query-based Distribution Groups Für die LDAP-Filter, die Du dazu brauchst: SelfADSI : LDAP Filter Gruß, Philipp

Hmmm, das hängt sehr von dem konkreten Programm ab würde ich sagen. Viele Setups laufen ja auf Basis von MSI ab, vielleicht hilft Dir die Doku der Aufrufoptionen für MSI-Installationen ein wenig weiter: Msiexec (command-line options) Für andere Setups gilt: Beim jeweiligen Hersteller der Software nachfragen ! Gruß, Philipp

Gruppenrichtlinien haben ja gerade den Sinn, dass sie stets diejenige Konfiguration herstellen, die von der Administration festgelegt wird, und dem Benutzer selbst keinerlei Spielraum zur eigenen Entscheidung geben. Dementsprechend gibt es auf dem Client selbst keinen "Trick", der die Ababeitung von GPOs (die aus der Domäne kommen) verhindert... Also über Berechtigungen lösen oder getrennte OUs für die Entwickler.... Gruß, Philipp

Hallo, also grundsätzlich wäre es nicht ratsam, Verzeichnis-Informationen in der DMZ zu halten - auch wenn es sich dabei nicht um "die Passwörter" handelt, sondern "nur" um AD LDS Proxy-Accounts. Besser (wenn auch nicht so richtig toll) wäre hier ein niedrig privilegierter Account für den Postfix, der über LDAP aufs interne AD lesend zugreifen darf und dort die Infos ausliest... Für den Webservice müßte dann auch eine entsprechende Verzeichins-Authentifizierung von der DMZ in Richtung internes AD "aufgemacht" werden. In beiden Fällen wären also keine Verzeichnis-Daten in der DMZ. Sehr wohl ist jedoch die Öffnung von z.B. LDAP-Ports von der DMZ in Richtung internes Netz notwendig, und das ist nicht so schön... Für den Web-Service evtl. sogar Kerberos, d.h. also noch zusätzliche Ports. Aber AD LDS mit Proxy-Accounts in der DMZ ist noch schlimmer, denn da wäre ja auch eine Authentifizierung zwischen AD LDS und interme Ad notwendig, d.h. wieder: offene Ports in der Firewall von aussen nach innen. Ginge es nur um Postfix, so würde ich einfach per Script regelmäßig eine Text-Datei raushauen, in der alle existierenden User-Mailadressen aufgeführt werden. Diese Datei ladet Ihr dan per SCP auf den Postfix-Hobel, dort wird sie dann als Virtual Table ins Postfix-System eingebunden, ist übrigens auch viel performanter als dauernde LDAP-Abfragen während der Postfix-Queue-Verarbeitung.... Und: Man braucht nur Ports von innen nach aussen in die DMZ zu öffnen! :) Was die Web-Anwendung angeht: Wenn man die offenen Ports partout vermeiden will, müßte man sich vielleicht AD Federation Services anschauen.... das ist eigentlich genau dafür gedacht. Gruß, Philipp

Hallo, also, hier habe ich wenigstens mal ein paar Grundinfos zu den betreffenden LDAP-Attributen für Dich: SelfADSI : Active Directory Attribute für Service for Unix 3.5 Was den Standardwert der UIDs/GUIDs betrifft, so dachte ich immer, das AUC-Tool selbst merkt sich irgendwie, welchen Wert man als letztes eingetragen hat, und zählt dann jeweils eins dazu. D.h. wenn du einmal von Hand 50000 als UID wählst, macht er dann bei 50001 weiter (falls du auf der gleichen Maschine das Tool weiter benutzt...) Würde ja dafür sprechen, dass es irgendwo in der lokalen Registry steht..... Meiner Erfahrung nach kannst du aber nicht auf "kleinere" Werte gehen, d.h. wenn Du 500 von Hand einträgst, dann macht er eben nicht bei 501 weiter... :( Sehr mysteriös. Eine allgemeine MaxUID + 1 Regel scheint es auch nicht zu geben.... Naja, zu allgemeinen Check stehen natürlich DSGET und Powershell mit Get-AD.... Kommandos zur Auswahl, oder als GUI-Tool z.B. LEX - The LDAP Explorer: LEX Manual : Object Attribute Columns Hier kannst du wengistens für alle User-Objekte gleich in einer Spalte die UID / GUIDs mit anzeigen lassen.... Oder der Wechsel auf "/bin/bash" für viele User-Objekte auf einmal: LEX Manual : Editing Mulitple Directory Objects Gruß, Philipp

Was den AD Recycle Bin unter W2K8 R2 und den Umgang mit Tombstone-Reanimation vs. echter Objekt-Recovery angeht, möchte ich noch auf das kostenlose GUI-Tool dazu verweisen: LAZARUS - Active Directory Deleted Objects Recovery Gruß, Philipp

Hallo. noch ein allgemeiner Hinweis: Wenn du den "alltäglichen" LDAP-Verkehr z.B. zwischen Client und DC/GC beobachten willst oder z.B. was bei einem DCDIAG-Durchlauf geschieht, dann wirst du auch mit NetMon/Wirshark Tools wenig sehen, denn hier wird eigentlich immer ein LDAP-Bind mit GSSAPI/SPNego durchgeführt, d.h. die Daten innerhalb der LDAP-Pakete sind verschlüsselt (selbst wenn kein "LDAPS" verwendet wird). Wenn du in Deinem Plug-in bei den LDAP-Bind-Einstellungen irgendwo "Basic Auth" oder "Simple Bind" einstellen kannst, dann mach das mal, dann siehst Du vielleicht die LDAP Rohdaten im Monitor-Tool. Gruß, Philipp

Hallo Zahni, ich weiß dass er Computer meinte, aber Lumax kann eben auch Computer-Accounts auswerten und nicht nur User :) Auch Rechner-Accounts haben das lastLogon-Attribut bzw. das lastLogonTimestamp-Attribut... Gruß, Philipp

Schau mal den Tutorial-Artikel in SelfADSI über deas userAccountControl-Attribut an: Das Häckchen "Kann Passwort nicht ändern" kann nur über die Berechtigung geändert werden. SelfADSI : Attribute für AD User - userAccountControl Gruß, Philipp

Hallo, das kostenloses Tool Lumax kann auch diejenigen Rechner anzeigen, die sich seit x Tagen nicht mehr angemeldet haben, oder deren Account Passwort sich seit x Tagen nicht geändert hat: LUMAX - Active Directory User Maintenance Das Ergebnis läßt sich dann Excel oder Textfile exportieren... Gruß, Philipp

Hallo, hier ein paar kurze Hinweise, wie man es unter VBScript lösen kann: 1. Problem: Mit dem eigenen User-Obekt verbinden: Schau mal hier nach: SelfADSI : Name Translation - Wie man den LDAP Pfad eines Benutzers ermittelt unter dem Punkt "Auf einen Benutzer zugreifen, dessen NT Anmeldename bekannt ist", den Anmeldenamen hast du ja im Environment. 2. Problem: Attribut thumbnailphoto auslesen. Ist etwas schwieriger, da es sich hierbei um ein Binär-Attribut mit der Syntax "OctetString" handelt. Vielleicht bringt das dich weiter: SelfADSI : Objekt-Attribute des Typs "Octet String" Vielleicht kannst du die ausgelesenen Attribut-Daten dann gleich ohne Umwandlung in eine Datei schreiben. Hier scheibe ich solche Binärdaten in in eine Temp-Datei. In var_hex sind die ausgelesenen Attribut-Daten: Set fso = CreateObject ("Scripting.Filesystemobject") Set ts = fso.createtextfile("c:\temp\photo.jpg") For n = 1 To (Len(var_hex) - 1) Step 2 ts.write Chr("&H" & Mid(var_hex, n, 2)) Next Nicht vom "createtextfile" verwirren lassen, es sind trotzdem Binärdaten im File.... :) Gruß, Philipp

Allerdings: Du kommst mit ADSI-Scripting nicht an gelöschte Objekte heran...Versuchs mal mit dem Lazarus, einem kostenlosen Tool für den Zugriff/die Wiederherstellung gelöschter AD-Objekte: LAZARUS - Active Directory Deleted Objects Recovery Ob du dann wirklich die Verteiler plus Mitgliedern wiederherstellen kannst, hängt davon ab, ob du den so genannten AD Recycle Bin in Deinem AD Forest aktiviert hast. Steht aber alles auf der Seite vom Lazarus ganz gut erklärt.... Gruß, Philipp

Hallo, ganz einfach: Du musst gar nicht nach einem Objekt mit einer bestimmten SID suchen, sondern du kannst dich per ADSI-Scripting auch direkt mit einem Objekt verbinden, dass eine bestimmte SID hat :D. Danach hast du ja direkt Zugriff auf alle Eigenschaften wie z.B. Objektname, Anmeldename, Gruppenmitgliedschaften etc... Ich zitiere mal aus dem betreffenden SelfADSI-Artikel plus angefügtem Beispiel: SelfADSI : Microsoft Security Descriptor (SID) Attribute : LDAP Bind zu Objekten mit SIDs anstatt mit dem Distinguished Name Eine interessante Variation der Suche nach Objekten mit einer vorgegebenen SID: Man kann beim Verbinden mit Objekten (LDAP Bind) auch einfach deren SID verwenden, wenn man folgende Syntax einhält <SID=S-1-5-21-34672221-56910222-80333210-57321189-511> (Beispiel) Sogar die puren HexStrings der SIDs lassen sich hier zum BIND benutzen: <SID=0105000000000005150000001b0e683dbf16479eb5a59ec158040000> (Beispiel) Diese Technik können wir verwenden, um die Liste der direkten und indirekten Gruppenmitgliedschaften viel eleganter als im letzten Beispiel zu erhalten: 'Sie müssen hier andere Namen und Anmeldedaten aus Ihrer eigene Umgebung angeben! Set obj = GetObject("LDAP://cn=Foeckeler,cn=Users,dc=cerrotorre,dc=de") obj.GetInfoEx Array("tokenGroups"), 0 'tokenGroups ist ein Operational Attribut und muß extra angefordert werden groupListRaw = obj.GetEx("tokenGroups") WScript.Echo obj.cn For i = 0 To UBound(groupListRaw) sidHex = OctetToHexStr(groupListRaw(i)) Set obj = GetObject("LDAP://<SID=" & sidHex & ">") WScript.Echo "---> " & obj.distinguishedName Next Function OctetToHexStr(var_octet) 'wandelt reine Binärdaten (Byte-Array) in einen String mit den Hexadezimalwerten um. Dim n OctetToHexStr = "" For n = 1 To lenb(var_octet) OctetToHexStr = OctetToHexStr & Right("0" & hex(ascb(midb(var_octet, n, 1))), 2) Next End Function Gruss, Philipp

Hallo, ein guter Kandidat als Grund für die ausgeschaltete Vererbung ist die (auch ehemalige) Mitgliedschaft in hoch privilegierten Gruppen (Admins, Kontenoperatoren, Server-Operatoren, Sicherungs-Operatoren). Daraufhin wirkt dann auf einmal die ACL vom adminSDHolder Objekt und die Vererbung ist ausgeschaltet... Gleichzeitig wird das Attribut "adminCount" auf 1 gesetzt, du könntest also einen Schnelltest starten, indem du User suchst mit folgendem LDAP-Filter: (&(objectClass=user)(objectCategory=person)(adminCount=1)) Eine genaue Prüfung nach solchen USerm mit einem schnellen LDAP-Filter geht leider nicht, denn das Häckchen für die Vererbung ist tief versteckt im Attribut nTSecurityDescriptor... Mit dem kostenlosen Tool LIZA kannst du relativ schnell die Rechte für Benutzerobjekte anschauen, aber eine automatische Suche nach "nicht vererbten" gibt es leider noch nicht. Wäre mal einen Idee für eine neue LIZA-Version (ich bin der Author dieses Tools): LIZA - Active Directory Analyse für Security, Berechtigungen und ACLs Gruß, Philipp

Hallo, 1) zuerst mal zu Deinem DNS-Problem: Der ADMT läuft ja auf einer Maschine in der neuen Domäne xyz.de, stimmt's? Evtl sogar auf dem DC dort. Also zuerst brauchst du mal eine NAmensauflösung für "abc.de" NAmen von dieser MAschine aus. Das notwendige Forwarding richtest du nicht in den TCPIP-Einstellungen ein, sondern in der Konfiguration des DNS-Serverdienstes auf dem DC von xyz.de Dort bitte "Conditional Forwarding" eintragen mit "Alle Anfragen für abc.de an den DNS-Server von abc.de schicken". Es ist mir allerdings unklar, wie Du ohne funktionierende Namensauflösung den Trust einrichten konntest... 2) dann zur eigentlichen Fehlermeldung: Du willst mit ADMT auch die Passwörter der alten User migrieren. Das geht nur, wenn du zusätzlich zu ADMT auch die so genannten PAssword Export Services auf einem DC der alten Domäne abc.de einrichtest. Download details: Password Export Server version 3.1 (x86) Hast Du das schon gemacht? Bitte lies Dir nochmal genau die Anleitungen im Word-Dokument nach, dass mit dem ADMT mitgeliefert wird. Da steht eigentlich alles drin Schritt für Schritt. Gruß, Philipp

Hmmm, kann vielleicht an zwei Dingen liegen: jpegPhoto ist per Schema-Definition kein Single-Attribut und hat auch keine Größenbeschränkung.... Microsoft ist dann wohl irgendwann aufgefallen, dass das sich vielleicht nicht so gut eignet für kleine Mitarbeiter-Icons, die eine gewisse Größe nicht überschreiten sollen.... und solche Schema-Definitionen werden dann auch bei Neueinführung einer neuen Windows-Version dann nicht mehr geändert => also mußte eine neue Attribut-Syntax-Definition her: thumbnailPhoto ist als Single-Attribut gekennzeichnet (es kann also nur ein einziges Foto im AD gespeichert werden), außerdem gibt es Range-Beschränkung von 102400 Byte.... Picture Attribute (Windows) Gruß, Philipp

...und jetzt gebe ich auch mal meinen Senf dazu ;), was den Gebrauch vos thumbnailPhoto-Attributs anbelangt: Im Microsoft-eigenen AD der Mitarbeiter-Accounts ist dieses Attribut fast immer mit dem Ausweisfoto befüllt. Bleibt die Frage, ob Microsoft hier die Referenz für Best-Practice ist.... ?? Gruß, Philipp

Hallo, also einen einfachen "Schalter" zum Erweitern der Extension Attribute gibt es leider nicht, falls du zusätzliche Attribute brauchst, kannst Du jedoch eine eigene Schema-Erweiterung durchführen....mit den üblichen Warnhinweisen natürlich: Das Schema wird global auf alle DCs des Forests verteilt, Fehler im Schema werden ebenfalls global verteilt => Sorgfältige Planung + Durchführung bitte! Schemaerweiterungen lassen sich nicht zurücknehmen (man kann Attribute / Klassen höchstens "deaktivieren") Für Schemaerweiterungen benötigt man eigene OIDs, die man offiziell beantragen sollte, um nicht in Konflikt mit einer anderen Schema-Erweiterung zu kommen. Dieser link sollte Dir weiterhelfen: Extending the schema: Active Directory Gruß, Philipp

Hallo, Dein großes Problem: Du hast (lediglich) zwei DCs, die länger als die TombstoneLiftime (bei Dir 60 Tage) nicht mehr repliziert haben. Man kann jetzt nicht so genau sagen, dass einer der "gute" und der andere der "schlechte" DC ist....es sei denn einer von beiden war wirklich so lange vom Netz oder sonstwie offline... Aber das hört sich ja eigentlich ncht so an - irgendein anderer Grund hat die beiden die lange Zeit über nicht replizieren lassen. Die Links mit den Heilungsmethoden, die Du genannt hast, beziehen sich alle auf ein Szenario, in denen ein einziger DC von mehreren aus der Replikation rausgefallen ist und wie man diesen identifiziert und das dann wieder geradebiegt. Bei Dir jedoch könnte folgende Situation vorherrschen: Die User werden (falls die DCs in der selben AD-Site sind) per Zufall an einen von beiden DCs angemeldet. Bei Änderungen an Objekten (z.B. Passwörter) wird das jeweils an einem DC gemacht, aber nicht zum anderen repliziert. So geraten die internen Datenbanken der beiden DCs so langsam "auseinander"...Welchen DC kannst Du jetzt als "gut" bezeichnen? Keinen irgendwie...hmmm. Man würde hier tatsächlich mal versuchen, die so genannten "Lingering Objects" zu entfernen (LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)) und schauen, ob die Replikation danach wieder in Gang kommt. Falls das nicht funktioniert, dann muß einer der beiden mt DCPROMO /forceremoval herauntergestuft werden (die Änderungen in dessen DB sind dann halt verloren...), der andere verbleibende DC muß dann aber auch funktionieren! => Vorher durch temporäres Offline-Setzen testen und Systemstate BAckups bitte! Dann ein Metadata Cleanup, um die reste des rausgehauenen DCs zu entfernen und mit DCPROMO die rausgenommene MAschine wieder als DC hinzufügen... Alles in allem kein trivialer Vorgang. Ich kann mich dem Ratschlag von zahni hier egentlich nur anschließen: Falls das ein produktives System ist, überleg Dir gut ob Du Dir da evtl. Hilfe dazuholst... Viele Grüße, Philipp