Office 365 Password Sync

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 OnPremise 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 OnPremise 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.

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".

Applikationen die ADFS erfordern

Ehe Sie nun ADFS gleich verwerfen, sollten Sie genau prüfen, welche Applikationen vielleicht nur mit ADFS korrekt arbeiten. Hier eine Liste, die ggfls. aber schon veraltet ist:

Applikation Status

CRM Mobile

Der Mobile Client für "Microsoft CRM" erzwingt ADFS

Lync Client

Aktuell unterstützt Lync nur die Anmeldung per ADFS oder Kennworte, die in der Cloud gepflegt werden. Die Nutzung eines synchronisierten Kontos ist noch nicht möglich

 

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 OnPremise 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 OnPremise 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.

Monitoring und Troubleshooting

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 "OnPremise" 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 "OnPremise" ä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 OnPremise 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

657

Ergebnis-Meldung je Benutzer

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 funktionier.

  • 2855271 How to troubleshoot password synchronization when using the Azure Active Directory Sync tool
  • 2962509 Password hash synchronization stops working after you Update Azure Active Directory credentials in FIM
  • 2643629 One or more objects don't sync when using the Azure Active Directory Sync tool

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

Set-MsolDomainAuthentication
https://msdn.microsoft.com/en-us/library/azure/dn194112.aspx

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