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.

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 Authentifiierung an Daten zu kommen.

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.

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.

Unsicheres Kennwort

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.

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.

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 dan 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

652/653

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

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

Konvertierung von ADFS zu DirSync

Natürlich ist es möglich, eine Domäne und die Benutzer mit der SIP-Adresse vom ADFS Betrieb wieder auf DirSync-Password umzustellen. Dies ist sogar als Desaster-Option interessant, wenn ihre ADFS-Umgebung für längere Zeit ausfällt und daher sich die Anwender nicht mehr anmelden können. Folgende Schritte sind für das "Retour" in der Office 365 PowerShell auszuführen

convert-msoldomaintostandard `
   -domainname msxfaq.de `
   -skipUserconversion $false

Optional kann auch eine Kennwortliste mit übergeben werden, in der pro UPN ein Kennwort steht. Das ist aber nicht gewünscht, wenn Sie mit dem DirSync das Kennwort schon gesetzt haben oder setzen wollen.

Allerdings erfordert diese Befehlszeile den Zugriff auf dem ADFS-Server. Aber genau das wird nicht so einfach sein, wenn der ADFS-Service nicht mehr da ist. Dann hilft ein anderer Weg:

Set-MsolDomainAuthentication `
   -DomainName msxfaq.de `
   -Authentication Managed

Dieses Commandlet aktualisiert aber nur die Einstellungen in Office 365. Die Federation-Trust-Einstellungen auf dem lokalen ADFS-Server bleiben erhalten. Wenn der Server aber eh nicht mehr da ist und ein Neuaufbau ansteht, dann ist das das kleinste Problem.

Weitere Links