Password Hash Sync (PHS)

Wer Dienst in der Office 365 Cloud nutzt, muss dort nicht nur einen Benutzer haben, sondern sich auch anmelden können. Seit Sommer 2013 gibt es neben einem manuell in der Cloud gepflegten Kennwort und der Anmeldung per ADFS Basics auch die Möglichkeit, dass On-Prem Kennwort mittels DirSync auch in die Cloud zu bringen. Diese Seite beschreibt dieses Verfahren.

Siehe dazu auch: ADFS zu PHS/SSO - Irgendwann macht es jeder. von ADFS zu PHS mit Conditional Access.

Migrate from federation to cloud authentication
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/migrate-from-federation-to-cloud-authentication
Microsoft hat mittlerweile ein richtig gutes Video samt Beschreibung veröffentlicht

Sicherheit

Die allererste Frage, die sich stellt, ist die Betrachtung der Sicherheit. Ist es nicht generell unsicher, ein Kennwort in der Cloud zu pflegen, was mit dem lokalen Kennwort identisch ist? Wenn dem so wäre, dann wäre es natürlich sehr kritisch zu betrachten aber der DirSync überträgt aus der Quelle nicht das Kennwort selbst sondern den Hashwert. Das Klartext-Kennwort kann nicht aus dem Active Directory exportiert werden und ist auch gar nicht möglich.

Auch das Active Directory speichert das Kennwort nur als Hashwert. Wenn der Anwender sich anmeldet, wird das Kennwort mit der gleichen Hash-Funktion verarbeitet und nur das Ergebnis verglichen. Es gibt keinen schnellen Weg zurück, um aus einem Hashwert wird das Kennwort zu ermitteln. Man müsste schon sehr viele Kennwort durchprobieren um irgendwann einen Hashwert zu erhalten, der übereinstimmt. Aber selbst dann hat man ein Kennwort, welches den gleichen Hashwert ergibt. Das muss aber nicht das richtige Kennwort sein, auch wenn es auch für eine Anmeldung geeignet sein könnte.

Laut Microsoft wird aber nicht mal der Hashwert aus dem AD-Forest übertragen sondern der wird noch einmal mit SHA256 verhashed und erst dann in die Cloud übertragen. Wenn sich ein Anwender nun an der Cloud mit seinem Benutzernamen (UPN) und dem Kennwort anmeldet, dann muss das Office 365-System zweimal einen Hash ausführen. Wer diesen Hashwert aus der Cloud irgendwie erhalten hat, hat es doppelt schwer ein gültiges Kennwort dazu zu finden.

Man kann aber geteilter Meinung sein, ob das Kennwort für einen Benutzer überhaupt erforderlich ist, wenn z.B. eine Ermittlungsbehörde oder ein Geheimdienst es auf die Daten in der Cloud abgesehen hat. Es gibt auch hier immer einen "Super-Admin", der letztlich unter Umgehung der Benutzerberechtigungen an die Daten kommt und diese extrahieren kann. Wer dies verhindern will, könnte die Daten zusätzlich, z.B. durch Rights Management Server verschlüsseln oder Mail per SMime oder PGP verschlüsselt senden und mit etwas Hilfe der externen Absender auch verschlüsselt empfangen.

Das einzige Risiko ist also, dass jemand mit dem doppelten Hashwert aus der Cloud, an den er erst einmal kommen muss, über eine Brute-Force-Funktion irgendwann ein Kennwort in Erfahrung bringt, welches den gleichen Hashwert ergibt und damit ein Zugriff auf die On-Prem Umgebung möglich wird. Ich denke dass es einfachere Wege gibt, um einen Zugang zu einem Firmennetzwerk zu erhalten, z.B. durch Trojaner, Zielgerichtete Mails mit entsprechenden Anlagen oder Links auf präparierte Webseiten, Einbruch in das Haus, Diebstahl des Notebooks. Firmen sind generell gut beraten, dass Personen wirklich nur die erforderlichen Berechtigungen haben, dass Zugänge vielleicht zusätzlich gesichert sind und Anmeldungen überwacht werden.

Die Replikation eines per SHA265 gehashten Hashwerts in die Cloud sehen ich als tolerierbar an. Da finde ich es deutlich bedenklicher, wenn Benutzer das Firmenkennwort vielleicht noch an anderen Stellen ebenfalls verwenden. Hier sollten sie über Schulungsmaßnahmen die Sensibilität erhöhen, dass Anwender zumindest das Kennwort für das Firmenkonto "besonders" schützen.

Identity Architecture: Password Hash Synchronization | Azure Active Directory
https://www.youtube.com/watch?v=s2-RmScMfm4
Gut gut gemaches Erklär-Video

Laut dem Video scannt Microsoft das Internet nach Kennwortlisten (Leaked credentials) und prüft diese gegen hinterlegte Hash-Werte um den Anwender zu warnen. Es kann also sinnvoll sein, PHS zu nutzen, obwohl die Domain "Federated" ist.

Auch das britische National Cyber Security Center empfiehlt Password Hash Sync:

We now recommend that hybrid environments – i.e. those that use Active Directory as well as Azure AD – should prefer native authentication against Azure AD rather than ADFS.
Quelle Securing Office 365 with better configuration https://www.ncsc.gov.uk/blog-post/securing-office-365-better-configuration

Man muss natürlich dazu sagen, dass das NCSC Teil des Geheimdiensts GCHQ ist. Aber staatliche Stellen haben eh andere Wege unter Umgehung der Authentifizierung an Daten zu kommen.

Wie liest ADSync das Kennwort?

Es gibt im Active Directory natürlich das Feld "Password", welches aber nicht per LDAP ausgelesen werden kann. Selbst als Domain-Administrator kann ich das Feld nicht einfach lesen. Das wäre aber auch nicht hilfreich, denn meines Wissens speichert das AD das Kennwort nicht im Klartet oder als reversible Verschlüsselung ab, sondern sowieso nur die Hashwerte der Kennworte. Bei einer Anmeldung durch einen Anwender wird ein eventuell im Klartext übertragenes Kennwort direkt zu einem Hashwert verrechnet und die Hashwerte werden verglichen.

Insofern kann ADSync auch keine Klartext-Kennworte in die Cloud replizieren. Aber ADSync muss natürlich die Hashwerte lesen können und dies ist erschwert, damit Angreifer nicht einfach "offline" ein zum Hashwert passendes Kennwort suchen oder aus Rainbow-Tabellen ermitteln.

ADSync bedient sich der API (Siehe DirSync-API im Detail) über die sich auch Domain Controller replizieren. Es muss ja auch für einen neu installierten Domaincontroller möglich sein, eine komplette Kopie der Active Directory Partitionen zu erhalten. Auch bei einer Änderung des Kennworts durch den Anwender erfolgt die ja auf einem DC und die anderen DCs bekommen dies über die Replikation.

Dazu bekommt das ADSync-Konto einfach die Berechtigungen auf der Domäne:

Das ADSync Dienstkonto kann sich damit als "Replikationspartner" ausgeben und über die Dirsync-API die Änderungen z.B. der Hashwerte der Kennworte erhalten.

Die Herausforderungen von ADFS

Warum hat Microsoft aber den Schritt getan, Hashwerte mit dem DirSync zu übertragen, wenn es für mittlere und größere Firmen doch mit ADFS eine etablierte und zuverlässige Technik gibt? Ein Grund wird natürlich sein, dass der Einsatz von ADFS wieder zusätzliche Server und Dienste bedeuten, die installiert und betrieben werden müssen. für ADFS sind DNS-Namen und Zertifikate erforderlich und letztlich publiziert die Firma einen Webservice, der entsprechend gesichert werden muss. Sie dazu auch:

Wer ADFS nutzt, muss wissen, dass die Anmeldung an Dienste der Cloud nur möglich ist, wenn der ADFS-Service auch verfügbar und das interne Konto nicht gesperrt ist

Die Existenz eines ADFS-Service kann nicht wirklich verborgen werden. Es reicht einmal auf https://portal.microsoftonline.com einen UPN eine "interessanten" Firma einzugeben und wenn die Domäne für ADFS aktiviert ist, dann wird man schon alleine auf den ADFS-Service der Firma umgeleitet. Sehr schnell wird dann sichtbar, welche Firmen ADFS nutzen. Ich habe auf der Anmeldeseite ca. 20 Domains bekannter Welt-Firmen mit test@.... eingegeben und ein paar Treffer erzielt (Stand 20. Aug 2014). Ich habe natürlich keine Anmeldung versucht und die Domainauswahl ist willkürlich, nicht repräsentativ und sagt nichts über die Office 365 Aktivitäten der Firmen:

Domain ADFS-Server Version Schutz

siemens.com

https://sts-online.siemens.com

ADFS 3.0

Form Based

basf.com

https://federation.basf.com

?

Clientzertifikate / RSA Token

sixt.com

https://fedservice.sixt.de

ADFS 2.0

Form Based

henkel.com

https://toto.henkelgroup.net

ADFS 2.0

Form Based

Bis auf BASF, die den Zugang durch Zertifikate zusätzlich absichern, könnte man bei den anderen Systemen eventuell interne Konten auch sperren. (Siehe auch DoS mit Account Lockout). Wobei ADFS durchaus entsprechende Schutzfunkionen hat, um zu viele Fehlversuche zu blocken und so das interne Konto nicht zu sperren. Das muss aber explizit konfiguriert werden. Zudem unterstützt ADFS auch Zwei-Faktor-Authentifizierungen.

Eine andere Einschränkung ist natürlich, dass es ein Webservice ist, der meist hinter der WAN-Anbindung der Firma steht und damit ein Angreifer einfach durch sehr viele Request z.B. den Service oder die Verbindung dorthin überlasten kann. Ein klassischer DDoS kann damit die Anmeldefunktion zumindest behindern. Das kann man z.B. abmildern, indem man mehrere ADFS-Server hinter eine dicken Leitung hat oder das eigene AD z.B. mit einem DC und dem ADFS-Server in die Cloud (Stichwort Azure) ausdehnt und damit den Firmenzugang dahingehend aus der Schusslinie nimmt.

Die dritte Problemstelle liegt natürlich bei der Funktionsfähigkeit des ADFS-Servers. Wenn kleine Firmen hier mit einem Server starten und dieser durch Windows Updates mal einige Zeit "geplant Offline" ist, können in der Zeit dennoch die Anwender sich nicht neu an Cloud-Diensten anmelden. Natürlich kann man mehrere ADFS-Server als Farm installieren und einen Loadbalancer davor schalten und auch die WAN-Anbindung und Firewalls doppelt auslegen aber letztlich bleibt es eine Abhängigkeit. Je mehr und intensiver die Cloud-Dienste genutzt werden, desto kritischer wird dieser "Single Point".

Die Probleme mit Password Sync in die Cloud

Abgesehen von den Fragen der Sicherheit, gibt es eine weitere Problematik mit dem Kennwort statt ADFS. Ein Anwender kann beim Zugriff auf einen Dienst in der Cloud seinen bekannten Benutzernamen (UPN) eingeben und das Kennwort, welches er auch On-Prem zur Anmeldung verwendet. Damit ist ein Single-Account und ein Single-Password  erfüllt aber noch kein Single-SingOn. Der Benutzer muss sein Kennwort erneut eingeben, kann es aber je nach Anwendung im "Windows Tresor" speichern. Solange die Cloud-Seiten aber nicht als "Intranet" gekennzeichnet sind, wird zumindest ein Internet Explorer keine automatische Anmeldung durchführen.

Da es für den Dienst kein Konto im lokalen Active Directory gibt, kann der Client auch kein Kerberos-Ticket erhalten. Wobei der Cloud-Dienst vermutlich sowieso kein Kerberos als Anmeldeverfahren anbietet. Auch ist die Nutzung von NTLM z.B. mit Exchange Online und Outlook RPC/HTTP nicht möglich.

Auch wenn es das gleiche Kennwort wie On-Prem ist, so muss der Benutzer es erneut eingeben. Beim Einsatz mit ADFS ist dies besser möglich. Zumindest ein interner Client könnte sich intern am ADFS-Server per "Integrierter Authentifizierung" anmelden um ein Ticket zu bekommen. Wer als intern auf einen Cloud-Dienst zugreift und z.B. den Benutzernamen hinterlegt hat, sieht nur kurz "aufblitzen", dass der Client auf den ADFS-Server umgeleitet wird, ein Ticket bekommt und dann wieder zum eigentlichen Dienstserver zurück springt.

Microsoft entspannt dieses Problem mit dem "Microsoft Online Services Sign-In Assistant".

Zitat: The MOS SIA can also provide an improved sign-in experience, such that end Users can access Microsoft Online Services without having to re-enter their credentials (such as a User name or password).
http://www.microsoft.com/en-us/download/details.aspx?id=28177

Auch gibt es eine Verzögerung, wenn ein Konto deaktiviert wird. Während bei ADFS der Anwender sich nicht mehr anmelden kann, kann es beim DirSync einige Stunden (per Default startet der Abgleich alle 3h) dauern, bis das Konto auch in der Cloud gesperrt wurde. Auch Änderungen des Kennworts werden verzögert in die Cloud übertragen.

ADFS unterstützt zudem stärkere Anmeldeverfahren und beachtet auch die "Login Zeiten", die beim Benutzer hinterlegt werden können.

Insofern kann die Lösung mit der Synchronisierung des Kennworts in die Cloud für viele mittlere und kleinere Firmen unterm Strich die optimale Lösung sein, um sich den Betrieb einer ADFS-Plattform komplett zu sparen.

Passwordhash und ADFS kombinieren?

Aber auch Firmen mit ADFS können von der Synchronisation des Kennworts profitieren. Denn auch wenn eine Domäne für ADFS aktiviert ist, so kann das Kennwort dennoch mittels synchronisiert werden. Der Anwender nutzt es nur nicht, weil Office 365 die Anmeldung immer zum ADFS-Server umleitet.

Wenn dann aber z.B. die ADFS-Plattform längere Zeit ausfallen sollte, z.B.: weil ein Großschaden (Feuer, Sturm, Hochwasser), dann ist es relativ einfach und schnell möglich, die ADFS-Anmeldung für die Domäne zu deaktivieren. Die Anwender können dann sich weiter mit dem Kennwort anmelden, welches bislang durch den DirSync in die Cloud übertragen wurde.

So kann z.B. ein "Notbetrieb" aufrecht erhalten werden, wenn die ADFS-Umgebung temporär oder längere Zeit ausgefallen ist. Es ist aus meiner Sicht aber eine Option für ein Desaster Recovery aber sicher kein Prozess, zum während der Installation von Windows Updates auf dem ADFS-Server den Betrieb weiter aufrecht zu erhalten. Hier sollten Sie dann doch eher über eine ADFS-Farm nachdenken oder ein Wartungsfenster ankündigen.

Diese Schritte sind natürlich auch passend um eine ADFS-Installation wieder zurück zu bauen und vorher alle Benutzer auf das synchronisierte Kennwort umzustellen.

PHS und "Kennwort ändern"

Vorsicht, wenn ein Benutzer sein Kennwort vergisst und der Helpdesk das Kennwort im lokalen Active Directory zurücksetzt. In der Regel wird dann auch der Haken bei "Muss Kennwort beim ersten Anmelden ändern" gesetzt:

Was vielen Administratoren aber nicht bekannt ist, ist die Bedeutung dieser Einstellung für ADSync und die Kennwortsynchronisation, die damit blockiert wird. Das können Sie auch im Eventlog nachvollziehen:

Log Name:      Application
Source:        Directory Synchronization
Date:          23.01.2020 15:36:15
Event ID:      2207
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      dc01.msxfaq.net
Description:

FilteredByTarget - Temporary password is filtered by target. 
AD Connector - msxfaq.net, 
DN - CN=user1,OU=demo,DC=msxfaq,DC=net, 
DateTime - 01/23/2020 13:27:24 UTC

Wenn Sie also möchte, dass der Anwender sich direkt wieder in der Cloud auch mit dem Kennwort anmelden kann, welches der Helpdesk im gegeben hat, dann sollten Sie die Checkbox nicht setzen oder nachträglich wieder beim Benutzer entfernen.

Kurz darauf sollten Sie dann das Update im Eventlog sehen:

Log Name:      Application
Source:        Directory Synchronization
Date:          23.01.2020 16:07:39
Event ID:      657
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      dc01.msxfaq.net
Description:
Password Change Result - 
Anchor : xxxxxx==, 
Dn : CN=user1,OU=demo,DC=msxfaq,DC=net, 
PwdChangeOnLogon=False, 
Result : Success.

Es ist natürlich ein ganz schlechter Stiel, wenn das Kennwort eines Benutzers dann nicht geändert werden würde. Der Anwender sollte also deutlich darauf hingewiesen werden, dass er bitte dennoch sein Kennwort ändert, auch wenn Windows dies nicht erzwingt. Wenn aber ein Anwender "unterwegs" ist und von draußen gar keine Möglichkeit hat sein Kennwort zu ändern, dann ist dies ein Zwischenschritt. Der Anwender kann sich dann erst einmal per Terminal Dienste, VPN o.ä. anmelden und dann immer noch sein Kennwort ändern.

Ansonsten ist es ja letztlich das Risiko des Anwenders, wenn er sein Kennwort nicht ändert. Es versteht sich ja von selbst, dass jeder Anwender beim Zurücksetzen ein individuelles Kennwort bekommt. Bitte tragen Sie hier nicht bei allen Personen "Kennwort123" oder "Start123" oder so etwas ein.

ADSync und LastPasswordChangeTimestamp

Wenn ein Benutzer sein Kennwort im lokalen AD ändert, dann ändert sich natürlich auch das Feld "pwdLastSet", indem das Datum der Änderung festgehalten wird. Diese Feld wird durch ADSync in das AzureAD übertragen.

So können Sie auch im AzureAD einfach sehen, wann das Kennwort geändert wurde. Sie sehen aber in dieser ADSync-Ansicht nicht die eigentliche Replikation des Kennworts. Allein diese Information bedeutet nicht, dass das Kennwort auch erfolgreich repliziert wurde.

Kennwort Policies

Ein weiterer Aspekt von PHS ist die Prüfung der Hashwerte in der Cloud gegen Listen von unsicheren Kennworten. Sie kennen vielleicht die Seite "https://haveibeenpwned.com/" oder https://sec.hpi.de/ilc/, mit der Sie die Sicherheit ihres Kennworts prüfen können. Beide Dienste sammeln Kennwortlisten und speichern die Hashwerte und verbundene Mailadresse. Die gleiche Technik nutzt Microsoft, um Kennwort auf ihre "Tauglichkeit" zu prüfen.

Allerdings schreibt Microsoft dazu auch:

Password complexity policy:
... the password complexity policies in your On-Premises Active Directory instance override complexity policies in the cloud for synchronized users ...
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization

Wenn das Kennwort eines Anwenders im lokalen Active Directory abgelaufen ist, dann kann er sich weiter an der Cloud anmelden. Ein Zwang zur Aktualisierung ihres Kennwort kann die Cloud nicht anwenden. Das passiert bei der nächsten Anmeldung im lokalen Active Directory.

Wenn sich also ein Anwender trotz neu gesetztem lokalen Kennwort weiterhin nicht in der Cloud anmelden kann, dann sollten Sie die Komplexität prüfen oder ein weniger offensichtliches Kennwort verwenden.

Kennwortsicherheit

Damit Benutzer keine allzu leicht zu erratenden Kennworte verwenden, können Sie sowohl im lokale Active Directory (Siehe Fine-grained Password Policy) als auch im AzureAD entsprechende Kennwortrichtlinien vorgeben.

In der Cloud ist standardmäßig nur ein "Audit" aktiv und ich würde immer dazu raten, die Einstellung auf "Enforced" zu ändern. Das habe ich auch schon auf Checkliste Tenant Einrichtung empfohlen.

Zusätzlich gibt es noch eine ADSync-Option, die ebenfalls im Standard auf "False" steht:

Connect-MSOLService
Get-MsolDirSyncFeatures -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers | fl

DirSyncFeature : EnforceCloudPasswordPolicyForPasswordSyncedUsers
Enabled        : False

When EnforceCloudPasswordPolicyForPasswordSyncedUsers is disabled (which is the default setting), Azure AD Connect sets the PasswordPolicies attribute of synchronized users to "DisablePasswordExpiration". This is done every time a user's password is synchronized and instructs Azure AD to ignore the cloud password expiration policy for that user.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#enforcecloudpasswordpolicyforpasswordsyncedusers

Solange diese Einstellung noch aktiv ist, kann ADSync auch "unsichere lokale Kennworte" in die Cloud replizieren und damit den Schutz in der Cloud umgehen. Sie können das beim Benutzer auch sehen, weil die "passwordpolicies" auf "none" stehen.

PS C:\WINDOWS\system32> (Get-AzureADUser -SearchString msxfaqdevu1).passwordpolicies
none

Wenn Sie die Kennwortrichtlinien der Cloud erzwingen wollen, dann müssen Sie die Option "EnforceCloudPasswordPolicyForPasswordSyncedUser" noch aktivieren.

Set-MsolDirSyncFeature `
   -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers `
   -Enable $true

Diese Funktion ist natürlich nicht für föderierte Domains verfügbar.

Ich würde mich nicht darauf verlassen, dass ADSync ein unsicheres Kennwort nicht in die Cloud überträgt und ihr Support dann die Probleme sucht und schwer findet. Sorgen Sie einfach dafür, dass die Kennwort-Richtlinien im lokalen AD und in der Cloud identisch sind, dann kommt PHS nicht in die Verlegenheit ein Kennwort zu blockieren.

Fehlersuche mit Invoke-ADSyncDiagnostics

Neben dem "Synchronization Service Manager" und dem Eventlog sollten Sie auch einen Blick in die PowerShell werfen. Das Commandlet "Invoke-ADSyncDiagnostics" liefert durchaus interessant werde. Sie können es ohne Parameter starten und dann durch das Menü z.B. "Troubleshoot Password Hash Synchronization" gehen:

Sie können aber auch direkt die Aufgabe mit angeben, damit alle Tests auf einmal ausgeführt werden.

Invoke-ADSyncDiagnostics -PasswordSync

Damit sollten sich eigentlich alle Probleme finden und lösen lassen.

Monitoring

Der Einsatz des Kennwort-Sync ist natürlich abhängig von einer möglichst schnellen Synchronisation von lokalen Kennwort Änderungen . Daher werden diese Änderungen nicht über den "normalen" DirSync-Job durchgeführt, der nur alle 3 Stunden läuft. In der Regel funktioniert der Sync problemlos, aber einige Dinge verträgt die Cloud nicht, z.B.

  • Benutzer muss Kennwort bei der Anmeldung ändern
    Wenn diese Checkbox On-Premises aktiv, ist dann kann dies in der Cloud nicht wirken. Setzen Sie die Einstellung wieder zurück. Es dauert bis zu 2 Minuten, bis dies in der Cloud aktiv ist.
  • Kennwort ist nicht Synchron
    Bitten Sie den Anwender das Kennwort einmal zu ändern, um einen neuen Abgleich zu erreichen
  • Kennwort wurde in der Cloud geändert
    Mit Azure AD Premium kann ein Anwender auch in der Cloud das Kennwort ändern. Wenn Sie "Password Writeback" nicht aktiviert habe, dann sind die Kennworte dann nicht synchron. Der Anwender sollte das Kennwort On-Premises ändern. Die Snychronisation sollte die Daten dann wieder in die Cloud übertragen

Ob ihr DirSync arbeitet oder nicht, sehen Sie am besten im Application Eventlog:

EventID Bedeutung

650/651

Start und Ende-Meldung des Prozess, welcher die geänderten Kennwort aus dem On-Prem AD einsammelt. 650 ist der "Start" und 651 das "Ende" des Jobs

Log Name:      Application
Source:        Directory Synchronization
Event ID:      651
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Description:
Provision credentials batch end. Count: 1, TrackingID : c073a828-b127-4960-99f4-55de5d71fc26
<forest-info>
  <partition-name>UCLABOR.DE</partition-name>
  <connector-id>04dddde8-352d-40f8-b6d4-f63c10ed8d66</connector-id>
</forest-info>

Das Ausbleiben einer solchen Meldung ist ein deutliches Zeichen, dass der Dienst nicht funktioniert

652/653

Start und Ende-Meldung des Prozess, der dem Azure AD alle 30 Minuten mitteilt, dass keine Updates anliegen.

Log Name:      Application
Source:        Directory Synchronization
Event ID:      653
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Description:
Provision credentials ping start.  TrackingID : ae220af9-23f9-4183-b1cd-a78c609817dd
<forest-info>
  <partition-name>UCLABOR.DE</partition-name>
  <connector-id>04dddde8-352d-40f8-b6d4-f63c10ed8d66</connector-id>
</forest-info>

Das Ausbleiben einer solchen Meldung ist ein deutliches Zeichen, dass der Dienst nicht funktioniert

656

Start-Meldung von anstehende Update von bis zu 50 Usern als Batch

Log Name:      Application
Source:        Directory Synchronization
Event ID:      656
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Description:
Password Change Request - Anchor : xxx==, CloudAnchor: False, Dn : CN=Demo 1,OU=Abteilung,DC=uclabor,DC=de, Change Date : 08/06/2019 15:57:16
Password Change Request - Anchor : xxx==, CloudAnchor: False, Dn : CN=Demo 3,OU=Abteilung,DC=uclabor,DC=de, Change Date : 08/06/2019 15:57:07
Password Change Request - Anchor : xxx==, CloudAnchor: False, Dn : CN=Demo 2,OU=Abteilung,DC=uclabor,DC=de, Change Date : 08/06/2019 15:57:35
Password Change Request - Anchor : xxx==, CloudAnchor: False, Dn : CN=Demo 4,OU=Abteilung,DC=uclabor,DC=de, Change Date : 08/06/2019 15:57:26

657

Ergebnis-Meldung wenn das Update in der Cloud erfolgt ist

Log Name:      Application
Source:        Directory Synchronization
Event ID:      657
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Description:
Password Change Result - Anchor : xxx==, Dn : CN=Demo 1,OU=Demo,DC=uclabor,DC=de, PwdChangeOnLogon=False, Result : Success.
Password Change Result - Anchor : xxx==, Dn : CN=Demo 3,OU=Demo,DC=uclabor,DC=de, PwdChangeOnLogon=False, Result : Success.
Password Change Result - Anchor : xxx==, Dn : CN=Demo 2,OU=Demo,DC=uclabor,DC=de, PwdChangeOnLogon=False, Result : Success.
Password Change Result - Anchor : xxx==, Dn : CN=Demo 4,OU=Demo,DC=uclabor,DC=de, PwdChangeOnLogon=False, Result : Success.

Dies sind alles "Information"-Meldungen und können sehr einfach als "Watchdog" genutzt werden, ob der Kennwort Sync noch läuft. Wenn Sie hingegen "Error"-Events bekommen dann sollten sie aktiv werden, da etwas dann nicht korrekt funktioniert.

Troubleshooting mit ADSyncDiagnostics

Mittlerweile hat Microsoft eine sehr ausführliche Beschreibung und sogar PowerShell-Tools, um bei Problemen mit Password HashSync den Fehler zu suchen. Sofern die PowerShell die Module noch nicht selbst importiert hat, können Sie folgendes auf dem ADSync Server machen:

Import-Module ADSyncDiagnostics

Das Modul befindet sich auf dem ADSync Server an folgendem Ort.

C:\Program Files\Microsoft Azure AD Sync\Bin\ADSyncDiagnostics\ADSyncDiagnostics.psm1

In dem Modul sind einige CMDLets enthalten, die aber nicht alle dem Namensschema "Verb-Befehl" folgen

PS C:\> Get-Command -Module ADSyncDiagnostics

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Function        ConvertAADContactObjectToHashTable                 ADSyncDiagnostics
Function        ConvertAADGroupObjectToHashTable                   ADSyncDiagnostics
Function        ConvertAADUserObjectToHashTable                    ADSyncDiagnostics
Function        ConvertADObjectToHashTable                         ADSyncDiagnostics
Function        ConvertCSObjectToHashTable                         ADSyncDiagnostics
Function        ConvertMVObjectToHashTable                         ADSyncDiagnostics
Function        GetAADConnector                                    ADSyncDiagnostics
Function        GetAADTenantName                                   ADSyncDiagnostics
Function        GetADConnectorByName                               ADSyncDiagnostics
Function        GetADConnectors                                    ADSyncDiagnostics
Function        GetCSObject                                        ADSyncDiagnostics
Function        GetCSObjectByIdentifier                            ADSyncDiagnostics
Function        GetDateTimeLocaleEnUs                              ADSyncDiagnostics
Function        GetMVObjectByIdentifier                            ADSyncDiagnostics
Function        GetTargetCSObjectId                                ADSyncDiagnostics
Function        Invoke-ADSyncDiagnostics                           ADSyncDiagnostics
Function        IsStagingModeEnabled                               ADSyncDiagnostics
Function        WriteEventLog                                      ADSyncDiagnostics

Sie können das Modul also einfach öffnen und anschauen, was Microsoft hier tut. Ein einfacher Aufruf startet ein Auswahlmenü

Sie können das Commandlet auch direkt mit der Vorauswahl starten

Invoke-ADSyncDiagnostics -PasswordSync

Technisch wird das Eventlog auf Fehler und den Heartbeat untersucht. Bei einer allgemeinen Analyse ohne Eingabe des DN eines Users erhalten sie auch nur eine allgemeine Ausgabe:

Wer genau hinschaut, findet hier aber auch ein paar Mal die Ausgabe "False". Diese Checks könnte man durchaus auch in eine Überwachung mit einbauen. Um gewisse Dinge in ADSync zu sehen, müssen Sie aber gar kein lokale Administrator oder sogar Domain Admin sein. ADSync legt entsprechende lokale Sicherheitsgruppen an, über die Sie z.B. "Leserechte auf die Konfiguration und den Status gewähren können.

Die Gruppe "ADSyncBrowse" ist eine solche "ReadOnly"-Gruppe.

Denkbar ist auch ein Skript, welche z.B. eine Liste der Objekte mit ihrem Status ermittelt, so dass ein 1st Level Helpdesk zumindest den Status eines Objekts lesen könnte. Oder sie vergleichen z.B. die Exchange Adressbücher mit z.B. Compare-GAL

PHS und Staging Server

Für eine höhere Verfügbarkeit installieren insbesondere größere Firmen auch mal zwei oder mehr ADSync-Server. Dabei ist darauf zu achten, dass nur ein Server "Aktiv" sein darf und der andere Server nur als "Staging Server" agiert. Nur der aktive Server führt die Funktion PHS aus:

Suppose you have a Microsoft Entra Connect with Password Hash Synchronization feature enabled. When you enable staging mode, the server stops synchronizing password changes from on-premises AD. When you disable staging mode, the server resumes synchronizing password changes from where it last left off. If the server is left in staging mode for an extended period of time, it can take a while for the server to synchronize all password changes that had occurred during the time period.
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server#staging-mode

Ein Staging Mode Server bekommt weiterhin alle Kennwort-Änderungen mit aber exportiert diese zu Microsoft 365. Das bedeutet aber auch, dass nur der aktive ADSync-Server die Kennworte synchronisiert. Sollte der primäre Server ausfallen, dann werden geänderte Kennworte erst zu Microsoft 365 repliziert, wenn der aktive Server wieder online ist oder sie einen Staging Server zu aktiven Server konfigurieren.

Der parallele Betrieb von zwei aktiven ADSync-Servern ist meines Wissens nicht supportet

Konvertierung von ADFS zu PHS

Siehe dazu die Seite ADFS zu PHS/SSO

PHS und andere Verzeichnisdienste

Nicht immer ist ein Active Directory ihr lokales Verzeichnis. Es gibt durchaus andere Dienste wie OpenLDAP, SAMBA etc., die als primäre Identity-Plattform dienen und als Quelle für einen Verzeichnisabgleich mit Microsoft 365 genutzt werden sollen.

Während der COVID19-Zeit habe ich für eine Schule eine Lösung mit PowerShell entwickelt, bei der ich die im LDAP-Server als Klartext(!) gespeicherten Kennworte ausgelesen und per Graph die Kennworte in Microsoft 365 gesetzt habe. Das ist natürlich streng genommen kein "Password Hash Sync". In einem anderen Projekt wurde eine Webseite (Apache/PHP) genutzt, über welche die Anwender ihr Kennwort ändern mussten, so dass der PHP-Code dann das Kennwort in allen verbundenen Systemen mit aktualisiert hat. Aus meiner Sicht ist das alles unprofessionell und unsicher und ich frage mich bis heute, warum damals nicht schon lange ein Kerberos-Service aufgebaut wurde.

Aber es gibt tatsächlich auch andere Connectoren, die Hashwerte aus lokalen Anmelddatenbanken in einen Microsoft 365 Tenant replizieren können:

Weitere Links