Guten Tag allerseits,

aktuell bin ich auf der Suche nach weiteren Anbietern, welche eine in AD FS integrierbare MFA Lösung für Windows Hello for Business anbieten. Ich bin mir der Möglichkeit einer Hybrid Lösung mit Azure AD bewusst, das wollen wir aber wenn irgend möglich vermeiden und auf eine On-Premises Lösung setzen.

Ich bin die von Microsoft bereitgestellte Liste [1] schon durchgegangen, jedoch bietet von diesen Anbietern nur SafeNet eine On-Premises Version an. Gibt es zu diesem Thema Erfahrungen mit anderen Anbietern?

Grüße,

ma_fl

[1] https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs

Hallo.

Habe mehrere Sysvols migriert und es läuft nun mit den DC-2019 einwandfrei. Aber, das dicke Ende kommt zum Schluß. Es gibt Probleme mit dem administrativen Vorlagen. In Verzeichnis "PolicyDefinitions" liegen die Administrativen Vorlagen für Office 2010. Wenn die dort sind, werden die Standard Administrativen Vorlagen in Gruppenrichtlinienverwaltungs-Editor unterdrück oder überlagert. Man sieht nur noch die Office Vorlagen. Wenn ich den Ordner "PolicyDefinitions" lösche, erscheinen die Standardvorlagen wieder. Konnte dies an mehreren Domänen nachvollziehen, die ich migriert habe. Bei Domänen die ich noch nicht migriert habe, also FRS, gibt es diese Probleme nicht. Dort werden die Office 2010 Vorlagen ganz einfach in den Baum integriert und alles ist da, wo es hingehört. Leider keine Idee, was dies sein kann.

Müssen die ADMX-Dateien beim neuen DFS woanders platziert werden? Bin leider schon wieder ratlos. 

Hallo,

nach meinem Verständnis, ist es ja so, dass bei einem Domainjoined-Computer und Active Directory based Benutzern, dass Passwort vom Domain Controller verwaltet wird. Was bedeutet, nehme ich mein Gerät auf dem ich angemeldet bin und trenne seine Verbindung von der Domain, wechsele dann mein Passwort in der Domain, wird mein Gerät es erst kennen, wenn es wieder eine Verbindung zu dem Domain Controller hat.

So zumindest kannte ich es und war es auch lange für mich. Nun habe ich ein neues Gerät (gleiches Betriebssystem Windows 10 und auch am Domaincontroller Server 2016 hat sich außer Updates nichts am Betriebssystem geändert), und jetzt ist es so, wenn ich von Zuhause aus arbeite und mein Passwort ändere, kann ich mich auch an dem Gerät mit meinem neuen Passwort einloggen. Es stört mich eigentlich nicht, ich finde es sogar sehr angenehm, würde aber gerne verstehen, woher das kommt, da ich das auch gerne bei einem Kunden implementieren würde, die ein nach meinem dafürhalten fast identisches Setup haben.

Ich kann sogar das Kennwort ablaufen lassen bzw. eine Änderungsaufforderung hinterlegen und das Kennwort an meinem Gerät ändern und das neue Passwort kommt bei dem Domain Controller an. Es liegt keinerlei VPN-Verbindung vor. Die einzigen Verbindungen die ich in unsere Domain aufbaue, sind Mail über auto-discover und RDP über ein Gatewayserver zu unserem Terminalserver, aber nicht zu unserem Domain Controller.

Kann mir jemand dieses Phänomen erklären?

Sollte mehr Hintergrundwissen benötigt werden, liefere ich dieses gerne.

Danke im Voraus.

Hallo zusammen,

in einem Netz mit mehreren DCs (srv201x) kommen neuen DCs (201x) dazu, die bisherigen werden dauerhaft abschaltet.
Auf den alten DCs laufen die üblichen Dienste, wie ADDS, DNS, DHCP sowie auch weitere Drittanbieterdienste.

Das Ziel ist nun, alle Dienste entsprechend zu übernehmen und die alten Server abzuschalten, möglichst ohne dass es die Benutzer mitgekommen (durch unschöne Fehlermeldungen etc.)

Die neuen DCs haben bereits die ADDS Rolle erhalten, DNS wird brav ausgeführt, DHCP ist umgezogen, FSMO Rollen werden umgezogen; die Drittanbieterdienste wurden auch umgezogen, DNS Verweise auf die alten DCs entfernt bzw. auf die neuen DCs verwiesen.
Die alten DCs wurden von der Last als GC befreit.

Um nun sicher stellen zu können, dass die DCs nicht noch "versteckte" Anfragen von Clients mit irgendwo/irgendwann fest eingetragenen IPs zu diesen DCs erhalten (Zeitserver, DNS Anfragen, Anfragen an die Drittanbeiter-Dienste...), wollen wir den eingehenden Netzwerktraffic mitloggen (lokal oder Portspiegelung...); damit sehen wir, von wo ev. noch Anfragen rein kommen und können dies anpassen, bevor wir abschalten und dann jemand schreit.
Um die Logs möglichst übersichtlich zu halten, hatten wir vor, die DNS SRV der alten DC raus zu nehmen, so dass diese von den Clients bzw. anfragenden Diensten nicht mehr verwendet werden. Ich glaube mich zu erinnern, dass der LogonDienst die SRV Einträge des DCs  regelmässig prüft und ggf. neu erstellt, wenn die nicht da sind - ist dem so?

Weiterhin wollten wir die ein/ausgehende Replikation deaktivieren, um unnötige, immer wieder kehrende Meldungen auf den anderen DCs zu vermeiden und auch diesen Traffic im Log nicht durchstöbern müssen.

Wir erwarten doch einiges an Traffic und würden uns leichter tun, wenn wir die obigen Punkte deaktivieren könnten.

Was meint Ihr dazu?

Hallo an Alle!

Ich habe hier eine Infrastruktur mit 4 Domänen (firma1,2,3,4 .intern) bestehend aus je 2 Domain Controllern (2008r2 u 2012r2), 1 Terminalservern (2008r2 u 2012r2) und 1 Exchangeservern (2010 u 2013 ebenfalls auf entweder 2008r2 bzw 2012r2)

Nun sollen alle 4 Domänen mit den bestehenden Usern in eine neue AD (ad.firma.org) gebracht werden. Parallel dazu ist die Einführung von Office 365 geplant.

Pro Exchange sind ca 80 Mailboxen; Alle Server laufen auf je einem VMWare ESXi Host.

Alle User auf den 4 Exchange Servern haben die gleiche offizelle Domain. Mails kommen über den Provider, werden dort auf einem Gateway Server auf SPam, AV usw gescannt und dann intern auf den jeweiligen Exchange weitergeleitet (eigene Subdomain-Email Adresse zb. userx@firma1.firma.org)

Der UPN Name für die Office365 Migration ist bereits bei allen Usern hinzugefügt (firma.org).

Mein Plan dazu wäre nun pro Domain:

Update Exchange auf jeweils aktuellste Version

Einrichten Ad-Connect für AD Sync zu Azue AD mit Passwortsync;

Migration der Exchange Postfächer

Aufheben der ADSync

->>>>User arbeiten weiterhin am alten Terminalserver (login via Netbios Namen)

Dekomissionierung des lokalen Exchange,

ADMT 3.2 installieren; AD-Sync in die neue Domain OHNE SID History

Installierern, Konfigurieren und Datenübernahme auf den neuen Terminalserver unter Server 2019; Test RDP-Server

Mit ADMT SID-History übernehmen, Test Outlook Verbindung zu Office 365;

Mit der Übernahme der SIDs in die neue Domain und vorher mit ADConnect in Azure AD sollte die Verbindung funktionieren.

Meine Frage wäre nun: Habe ich hier einen Denkfehler, was sagt ihr dazu ? Würdet ihr was anderes machen ?

Danke im vorhinein für alle Anregungen und Tips!

Herzliche Grüße

Reinhold

Guten Morgen Kollegen,

ich versuche gerade einen (alten) DC aus Domäne herunterzustufen

Facts:

-         DC alt Windows 2008 R2 Foundation

-         DC neu Windows 2019 std

-         Die 4 FSMO Rollen habe ich erfolgreich auf den neuen Übertragen

-         Hat ohne Fehlermeldungen einwandfrei geklappt

-         Beim herunterstufen des alten DC kommt die Meldung „Es konnte kein anderer DC erreicht werden…

Dir Replikation mit repadmin /showrepl zwischen den DCs geht in beide Richtungen

-         Namensauflösung in beide Richtungen geht prima

Eine Überprüfung mit dcdiag bringt „test DFSREvent“ einen Fehler

Starting test: DFSREvent 

Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.

    ......................... Der Test DFSREvent für DC-alt ist fehlgeschlagen.

Und der primäre DC wird nicht gefunden!-)

-         Unternehmenstests werden ausgeführt auf: domain.local Starting test: LocatorCheck Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Domänencontroller ist nicht verfügbar.

......................... Der Test LocatorCheck für domain.local ist fehlgeschlagen.

-         DNS sehen sich gegenseitig und die Namensauflösung auf beiden für beide geht

-         Trotzdem ist der neue DC vom alten via DCdiag offensichtlich nicht erreichbar

-         

-         Dann stelle ich fest, dass es auf dem neuen DC KEIN SYSVOL Verzeichnis gibt Hat das eventuell mit dem oben genannten Fehler zu tun?

Es wäre klasse, wenn ich dazu ein paar Tipps zur Lösungsfindung bekommen könnte!

Guten Start in die Woche.-}

Jörg

Hallo Kollegen,

wir haben eine (einzige) meinefirma.local domain. In Azure benötigen wir diese domain als meinefirma.com. Die Hintergründe erspare ich euch, es geht letztendlich um einen single sign on bzgl eingebundes Mailpostfach. 

Kann ich nachträglich problemlos einen Forest erstellen mit meinefirma.com? Das Problem ist, dass wir Exchange 2010 verwenden und es hier massive Probleme geben würden wenn wir die .local Domäne umbenennen würde in meinefirma.com. D.h. wir sind auf die .local angewiesen. Wenn wir es aber schaffen würden, die user der .local in einem Forest zu moven, sodass die Anmeldung meinefirma\meinname weiterhin funktioniert, hätten wir das Ziel erreicht. Ob das jetzt meinefirma.local.meinefirma.com ist, oder Ähnliches, ist dabei egal.

Würde mich über einen Input freuen.

VG
Rainer

Hallo,

um LDAPS zu verwenden benötigen meine DCs ja ein Computer-Zertifikat.

Da wir keine CA besitzen stellt sich mir nun die Frage, ob die Domänencontroller von Hause aus schon so ein Zertifikat besitzen, damit Applikationen LDADS nutzen können?

Kann ich mich mit Benutzer Name länger als 20 Zeichen an Domäne anmelden? Windows 2012 R2

Wenn ja wie?

Hallo zusammen.

Folgendes Szenario:

AD LDS installiert und eine Instanz mit dem Setup Assistenten erstellt. Ich habe während der Erstellung der Instanz hierbei nur inetorgPeroson verwendet,  da dieses Schema alles beinhaltet, was benötigt wird.

DN sieht so aus: OU=Kontakte,DC=IKHLDAP,DC=COM

Einfach war, Daten mit einem beliebigen Tool manuell zu erfassen. Nach einigem probieren haben ich dann auch Daten importieren können. Soweit so gut. Diese Daten kann ich mit ADSIEDIT oder auch jedem anderen beliebigen Tool sehen

Nun möchte im nächsten Schritt diese Daten auch den "Umsystemen" zur Verfügung stellen wie z.B. unserer Telefonanlage. Jedoch wollte ich als ersten Test das AD LDS in Outlook einbinden, in der Annahme, wenn es da funktioniert, werden die Daten wohl auch in anderen Systemen ansprechbar sein.

Die Einbindung hat eigentlich einwandfrei funktioniert, jedoch musste ich hierbei feststellen, dass die Suche in dem AD LDS immer endet mit:

Bei einfacher Suche: "Keine Ergebnisse für den Suchvorgang"

Bei erweiterter Suche: "Es wurden keine Einträge gefunden".

Nun ganz offensichtlich habe ich hier noch irgendwo einen Fehler in der Config, aber wo beginne ich zu suchen?

Ich habe verschiedenes ausprobiert, wie z.B. die Angabe der DN in der Config im Outlook, aber das wirft schon beim Speichern Fehler auf.

Any help is welcome.... :-)

Vielen Dank schon mal!

Klaus

Ich möchte die Rufnummern von den Benutzern in eine Spalte anzeigen lassen.

Ich bitte um Hilfe

Guten Morgen,

ich informiere mich momentan über das Zusammenspiel von NTFS- und Freigabeberechtigungen. Eine Sache habe ich jedoch noch nicht verstanden.

Warum ist es best-practice, dass man bei jeder Freigabe auf Freigabeebene die Berechtigung für Jeden auf "Vollzugriff" stellt und dann in den NTFS-Berechtigungen diese gleich wieder einschränkt?

Warum lässt man die Freigabeberechtigungen nicht einfach frei und regelt die Berechtigungen direkt und ausschließlich in den NTFS-Berechtigungen? Die NTFS-Berechtigungen gelten doch schließlich sowohl für den lokalen, als auch für den Netzwerk-Zugriff

Hallo liebes Technet-Support-Team,

ich hab vor kurzem in einer Windows Server 2012R Umgebung als IT-Verantwortlicher angefangen und habe leider ohne richtige Übergabe mich eingearbeitet. In naher Zukunft stehen einige Projekte an, um die ganze Umgebung up to date zu bringen. Wir betreiben hier ein Server-Client Active Directory, dass im ursprünglichen Design mit festen Windows 7 Arbeitsplatzrechnern lief. Um die Daten zentral auf dem Server zu sichern wurden die AD Profile so eingerichtet, dass sie einen Basisordner haben, der auf dem Storage ist, in diesem Beispiel unter Profil -> Verbinden von O: Mit: \\server\Benutzer\MitarbeiterX und einen Profilpfad, sprich Roaming-Profil eingerichtet haben 

Der lokale Ordner Dokumente hat in dem Fall auch nicht den eigentlichen Pfad "Dieser PC -> Dokumente" sondern: \\server\Benutzer\MitarbeiterX\Documents

Nun hat ein Mitarbeiter einen Windows 10 Laptop mit Docking Station bekommen, den er gerne auch mobil nutzen möchte. Entfernt er nun das Notebook im laufenden Betrieb wird der Rechner langsam und Microsoft Office Produkte bleiben während des Öffnens im Logo-Ladebildschirm hängen. Vermutlich weil das Notebook versucht Dateien aus dem absoluten Pfad \\server\Benutzer\MitarbeiterX\Documents zu beziehen. Mit dem vorherigen Laptop unter Windows 7 sei das alles kein Problem gewesen.

Im AD unter Profil -> Benutzerprofil -> Profilpfad habe ich bei Ihm schon heraus genommen, aber das hat an dem Problem wohl nichts geändert lauter Mitarbeiter. Verbinden von O: Mit: \\server\Benutzer\MitarbeiterX ist weiterhin aktiv.

In naher Zukunft wird wie gesagt das ganze Server-System auf Windows Server 2019 migriert samt neuer Hardware, ich würde aber für diesen Mitarbeiter kurzfristig eine Lösung anbieten bei der dieses Problem nicht mehr auftaucht, er auf die Netzlaufwerke weiterhin zugreifen kann, wenn das Gerät im Intranet ist (gerne auch per VPN) oder er es irgendwie umgehen kann. Backups, die auf den Server kommen, sollten dennoch irgendwie erfolgen.

Ich hoffe ich konnte das Problem in etwa formulieren, ich bedanke mich für eure Unterstützung im voraus und wenn ihr noch fragen habt, meldet euch!

Hallo zusammen, 

aktuell gibt es im meiner Umgebung 2x AD-Controller, beides Server 2008R2. Das Funktionslevel ist noch auf Windows2003. 

Ich möchte auf 2016 upgraden.

Ich habe mir einige Tutorials angeschaut.

1. Es gibt noch ein paar alte XP und Server 2003 Clients. Es gibt auch noch einige 2008R2 Clients
--> Sind die Clients noch kompatibel?

2. Die beiden DCs sind für DNS und einer der beiden für DHCP zuständig. Soweit ich mich informieren konnte, muss ich den DHCP jedenfalls manuell verschieben. Der DNS wird automatisch migriert? 

3. Wie ist das mit dem Zertifikatmanager? Ich habe hier gesehen, es sind noch Fehler vom Vorgänger Admin vorhanden. Muss man hier Hand anlegen? Soweit ich es weiß wird ein Zertifikat für den Terminalserver verwendet. Sonst geht da glaub nicht viel.

4. Muss ich den Umweg über 2012R2 zwingend gehen?

5. Gibt es noch weitere Stolpersteine wo ich aktuell gar nicht auf dem Schirm haben kann?

6. Ich habe noch irgendwie im Kopf, wenn die Domäne von Windows2000 auf Windows 2008 migriert wurde, muss ich noch etwas am sysvol (FRS auf DFSR) anpassen. Leider finde ich die Information nicht mehr. 

PS: Ich habe einen Testserver auf dem ich das Backup des DCs einspielen kann, sodass ich auch einiges ausprobieren kann. 

Vielen Dank,
Grüße
Leon

Hallo,

ich möchte gerne das Verhalten der Downloads eines Windows Clients steuern, dass er die Updates automatisch runterlädt und dem User die Möglichkeit gibt, es selbst zu bestimmen, ob er updatet. Updates direkt von Microsoft, also ohne WSUS.

Zusätzlich sollen die Updates nur zu einer bestimmten Zeit runtergeladen werden, was ich durch starten und stoppen des Update Services mit geplanten Tasks mache.

Ich hab' nun per GPO folgendes eingestellt und sonst nichts:

Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows Komponenten > Windows Updates > Automatische Updates konfigurieren > 3. Automatisch runterladen, aber vor Installation benachrichtigen.

Der Client bekommt nun die GPO, lädt aber nicht die Updates, ohne betätigen des Buttons "Nach Updates suchen".

Darunter steht auch: Updates werden automatisch heruntergeladen, außer bei getakteten Verbindungen...

Teste das Ganze in einer VM. Weiß jemand, warum das nicht klappt? Müsste es so klappen? Könnte es an der Nutzungszeit liegen?

Hi,
weiß jemand, wie man ein AD LDS einrichten muss, damit darüber die Authentifizierung mit AD-Konten funktioniert, z.B. von einer vSphere Appliance (VCSA)? Oder anderen Linux-basierten Systemen?

Kurz zum Setup und Problem (siehe auch u.g. Grafik)

• AD mit Windows Server 2016, alle Funktionsebenen auf 2016
• ein Forest mit mehreren Domänen
• wir haben intern mehrere Systeme (z.B. solche o.g. VCSA), welche im internen Netz sind und im SSO das AD als Identitätsquelle eingerichtet haben - keine Probleme damit

Jetzt soll ein externer Dienstleister einen Web-Anwendung für uns hosten und betreiben. Es ist gewollt, dass sich von unseren Anwendern dann ausgwählte über ihre AD-Konten dort anmelden können. Dafür muss eine Anbindung an unser AD eingerichtet werden. Aus Datenschutzgründen können wir aber keine direkte Anbindung an unser AD einrichten, weil sonst der externe Dienstleister die Informationen aller Anwender aus dem gesamten AD auslesen kann, auch solcher, welche mit dieser genannten Web-Anwendung gar nichts zu tun haben. Das technisch einzuschränken (Lese-Zugriff verweigern) wäre extrem aufwändig bzw. ohne komplette Umstrukturierung unserer AD-Strukturen überhaupt nicht machbar. Deshalb die Idee, dass über einen AD LDS zu erledigen.

Wir haben also ein AD mit mehreren Domänen hinter einer Firewall. Vor der Firewall steht ein Windows Server 2016 mit AD LDS (im weiteren "LDAP-Proxy" genannt). Der LDAP-Proxy ist Mitglied einer der internen Domänen. Diese Domänenmitgliedschaft ist voll funktionstüchtig, die entsprechenden Regeln in der FW dafür eingerichtet. Soweit kein Problem.

Der AD-Proxy synchronisiert ausgewählte AD-Konten aus den verschiedenen Domänen und legt dafür in seinem LDAP userProxy-Objekte an. Soweit auch gut, kein Problem.

Was nicht funktioniert, ist die Anbindung als Identitätsquelle z.B. in einer VCSA, welche sich ebenfalls vor der FW im selben Subnetz wie der LDAP-Proxy befindet.

Beim Versuch, die Identitätsquelle auf der VCSA einzurichten wird auf dem LDAP-Proxy im Sicherheits-Ereignislog protokolliert:

Der Fehlercode variiert.
Verwenden wir zur Einrichtung der Identitätsquelle den NT Anmeldnamen wie "domain\samaccountname", dann kommt als Fehlercode

Bedeutung: Benutzeranmeldung mit falsch geschriebenem oder fehlerhaftem Benutzerkonto
Das scheint logisch, weil im userProxy-Objekt zwar der sAMAccountName steht, aber nicht der NetBIOS-Name der Domäne.

Verwenden wir zur Einrichtung der Identitätsquelle dagegen den UPN wie "name@domain.tld", dann kommt als Fehlercode

Bedeutung: Dies liegt entweder an einem fehlerhaften Benutzernamen oder an Authentifizierungsinformationen.
Der UPN steht im userProxy-Objekt und in der Ereignislog-Meldung steht dann auch der korrekt erkannte DistinguishedName.

(Quelle für Fehlercodes: https://docs.microsoft.com/de-de/windows/security/threat-protection/audi ...)

Ich habe die Einrichtung der Identitätsquelle sowohl mit einem Konto versucht, welches auf den LDAP-Proxy synchronisiert wird, als auch mit einem AD-Konto, welches nicht synchronisiert wird, als auch mit einem lokalen Konto des LDAP-Proxy. (alle 3 sind jeweils Mitglied der Rolle "Readers" im AD LDS)

Was ich ausschließen kann:

• falscher Benutzername -- mehrere versucht
• falsches Passwort -- mehrere versucht
• fehlende offene TCP/UDP-Ports -- Die lokale Firewall des LDAP-Proxy habe ich zum Test deaktiviert und zwiwschen VCSA und LDAP-Proxy ist keine weitere FW.

Irgendwas mache ich also falsch. Hat jemand ne Idee?

E.

Hallo zusammen,

wir haben in der Firma 2 Zeritfizierungsstellen. Eine auf einem 2008 R2 laufen und die neuere auf einem Windows Server 2016. Beide sind in der AD registriert. Es ist jetzt an der Zeit die alte zu deinstallieren, da es sich nebenbei noch um den alten PDC handelt, der aber bereits schon die FSMO Rollen abgegeben hat. Kann ich hier die Zertifizierungsstelle einfach sauber über die Server Rollen deinstallieren und die andere übernimmt den Dienst, oder muss ich hier noch etwas zusätzliches umziehen?

Vielen Dank schon im Voraus!

Horst Schwarz

Hallo,

wir haben folgendes Problem. Unsere Kunde mit mehreren Standorten und DFS Replikation kommt manchmal nicht auf DFS Freigaben, weil das Ziel für den Client nicht erreichbar ist.

Wenn man über Nslookup dann die Domäne prüft, liefert der DNS Manchmal eine IP Adresse aus dem Adresspool, die für den Client nicht erreichbar ist.

Bsp

Domäne Test.local

Standort 1 DC/DNS 192.168.0.1

Standort 2 DC/DNS 192.168.1.1

Standort 3 DC/DNS 192.168.2.1

Alle 3 Standorte sind über VPN vernetzt und Die DCs können untereinanden replizieren.

Die Clients kommen nur an ihre Standort DCs dran.

Alle Domänen Kontroller und Subnetzte sind auch in Active Directry Standorte und Dienste eingerichtet und

Standort 1 Client kann sich nicht an test.local verbinden, weil er vom DNS die IP vom Standort 3 bekommt.

Pingen lässt sich die Domäne auch nicht mehr. Macht man auf dem Client ein ipconfig /flusdns ein paar mal, bekommt man vom DNS irgendwann eine IP, die erreichbar ist.

Hallo,

einige meiner Maschinen haben leider aus irgendeinem Grund den falschen Zeitserver. Sie nutzen leider nicht den PDC sondern einen anderen DC.

In der Registry ist korrekt der Type "NT5DS" eingestellt. Der richtige DC mit dem PDC hat auch die Rolle 5 (0x5)  Primary Domain Controller korrekt und die anderen DCs die Rolle 4 (0x4)  Backup Domain Controller.

Jedoch verbindet sich laut

w32tm /query /source z.B. ein DC mit einem Backup Domain Controller und nicht mit dem Primary Domain Controller.