Office 365 Anmeldung und Kennworte

Die Nutzung von Diensten in der Cloud erfordert natürlich eine Authentifizierung. Diese Seite beleuchtet diese Frage mit den technischen Hintergründen.

Anmeldeverfahren

Microsoft bietet für die Anmeldung an Office 365 Diensten folgende Optionen an:

  • Office 365 Identität mit Kennwort
    Dieser Weg ist für kleine Firmen oder Teststellungen interessant, wenn DirSync und ADFS nicht installiert werden. Die Authentifizierung erfolgt anhand von Anmeldedaten, die in der Cloud bereit gestellt werden. Sie melden sich also z.B. als user@kunde.onmicrosoft.com an.
  • Synchronisierte Identität mit ADFS Basics
    Größere Firmen möchten aber nicht die Benutzer doppelt pflegen und auch die Anmeldedaten sollten die gleichen wie OnPremise sein. Die Lösung hierfür besteht aus einem Verzeichnisabgleich, mit dem die Benutzerobjekte in Office 365 anhand der lokalen Objekte im Active Directory verwaltet werden und die Anmeldung über ADFS-Tokens erfolgt, die der Client von einem OnPremise ADFS-Server bezieht.
  • Synchronisierte Identität mit Kennwort (Office 365 Password Sync)
    Seit Sommer 2013 gibt es eine weitere Option, bei der der ADFS-Server entfällt und stattdessen der Verzeichnisabgleich die Hashwerte der lokalen Kennworte zu Office 365 überträgt. Damit kann sich der Anwender an Office 365 Dienste
  • Zertifikat (Lync)
    Auch wenn die erste Anmeldung weiterhin per Benutzername/Kennwort oder ADFS-Ticket erfolgt, so können nachfolgende Verbindungen eigene Verfahren nutzen. Lync macht z.B. Gebrauch davon). Aber es ist kein primäres Anmeldeverfahren, so dass es in der weiteren Betrachtung unterbleibt

Stellt man die verschiedenen Verfahren gegenüber dann ergibt sich folgendes Bild:

Durch die Synchronisation der Hashwerte im DirSync seit Mitte 2013 können mittlere und kleine Firmen nun auch ohne ADFS auskommen. Das erspart nicht nur einen Server, sondern auch einen IP-Adresse, eine Webveröffentlichung, ein öffentliches Zertifikat und die Anmeldung an der Cloud funktioniert unabhängig von der eigenen Infrastruktur. Insbesondere die Abhängigkeit von der Verfügbarkeit des ADFS ist für viele Kunden kritisch.

Zur Sicherheit der Kennwort:
Natürlich kann jemand zu einem Hashwert per "offline brute Force" Attacke ein passendes Kennwort oder sogar sehr viele passende Kennwort finden. Wenn Sie weiter lesen, dann werden Sie aber sehen dass Office 365 Anwender beim Einsatz von Outlook heute ihr Kennwort im SSL-Tunnel nur BASE64-Codiert an die Exchange CAS-Server senden. Da müsste eine privilegierte Person gar nicht lange entschlüsseln und an die Postfachinhalte ist technisch auch ein Zugriff möglich.

Auf der anderen Seite nutzen sie täglich Browser, die allesamt in den uSA entwickelt werden, (Google (Chrome), Apple (Safari) oder MS (IE). zudem erweitern "Addons" und"Toolbars" verschiedene Browser, die im gleichen Prozessraum mitlaufen. Die Software hat zwangsläufig Zugriff auf Kennworte, die sie in Formularen eingeben und niemand kann 100% sicher sein, dass diese Informationen auch sicher sind.

Anforderung an Infrastruktur

Je nachdem welche der drei Optionen sie umsetzen wollen, müssen Sie bestimmte Server und Dienste bereit stellen.

Hinweis:
Die Einstellung ist "pro Office 365 Domain" zu fällen. Es ist also durchaus möglich, mehrere Domänen zu betreiben und eine Domäne mit ADFS zu nutzen, eine andere aber als Office365 user oder DirSync.

Verfahren DirSync ADFS Kennwortspeicher

Office 365 user mit Kennwort

Entfällt

Entfällt

Hash bei Office 365

Single Sign on mit ADFS

Erforderlich

Erforderlich
Kritisch

Hash OnPremise

DirSync mit Password Hash

Erforderlich

Entfällt

Hash OnPremise und Office 365

Kritisch ist eigentlich nur die ADFS-Lösung, da hier bei einem Ausfall des ADFS-Servers niemand mehr ein Ticket bekommt und damit die Office 365-Dienste nicht weiter nutzbar sind. Das mag auch der Grund sein, warum seit Sommer 2013 die dritte Option dazu gekommen ist, die Benutzer weiter "OnPremise" zu betreiben und mit dem DirSync in der Cloud zu verwalten und mit dem gleichen Kennwort in der Cloud anmelden zu lassen.

Authentication nach Diensten

Interessant ist nun, welche der drei Verfahren für die verschiedenen Office 365 Anwendungen wie angewendet wird: Denn nicht alle Verfahren nutzen z.B. ADFS so, wie sie es erwartet hätten.

HTTPS/SSL
Alle Kommunikationen sind in der Regel per HTTPS gesichert, d.h. selbst wenn Kennworte per "BasicAuth" oder Formulare unverschlüsselt gesendet werden, sind diese durch den darunter liegenden SSL-Tunnel geschützt.

Da viele Felder der folgenden Tabelle den gleichen Inhalt haben, habe ich Varianten vorab beschrieben

  1. Anmeldung mit Benutzername und Kennwort im Formular oder per BasicAuth im Protokoll
  2. Anmeldung gegen den lokalen ADFS-Server und Durchreichen des Ticket an die Cloud
  3. Basic gegen den CAS, der dann gegen den ADFS-Server geht
    Der Client kann noch nicht selbst an den ADFS-Server gehen. Daher ist es auch erforderlich, dass der ADFS-Server ein öffentliches Zertifikat hat, damit der Office 365-Server die SSL-Verbindung aufbauen kann.

Die Varianten werden die folgt genutzt:

Dienst/Client Office 365
User
ADFS DirSync
Hash

Outlook WebApp/Browser

ActiveSync/Mobile

Kennwort geht zur Cloud

Outlook/PC

Kennwort geht zur Cloud

SharePoint/Browser

Office 365 Web Management

Lync Windows Client

+ Zertifikat für darauffolgende Prozesse

+ Zertifikat für darauffolgende Prozesse

Lync Mobile Client (Ab Version 5.2

+ Zertifikat für darauffolgende Prozesse

+ Zertifikat für darauffolgende Prozesse

+ Zertifikat für darauffolgende Prozesse

Besonders die Variante 3 ist viele Administratoren und Sicherheitsbeauftragten nicht bekannt. Sie planen mit einem ADFS-Server weil Sie erwarten, dass damit da Kennwort nie das unternehmen verlässt, sondern maximal zum ADFS-Server gelangt und das damit ausgestellte Token (Vergleichbar einem Kerberos Ticket) zur Authentifizierung an der Cloud genutzt wird.

NTLM
Meines Wissens nutzt Office 365 aktuell NICHT NTLM bei Anmeldungen innerhalb der Anwendung.

Kerberos
Kerberos-Tickets werden von DCs ausgestellt. Kerberos kann daher nur bei der Authentifizierung gegen den internen ADFS-Server per Kerberos erfolgen aber nie über das Internet.

Weitere Links