Office 365 Übersicht der Anmeldeoptionen

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

Anmeldeverfahren

Jeder Anwender, der Daten in der Cloud verwenden will, muss als Office 365 Identität in der Cloud natürlich angelegt und berechtigt worden sind. Das allein reicht aber nicht. Der Anwender muss natürlich auch beweisen, dass er die angegebene Identität ist. er muss sich also authentifizieren. Bei der Installation von ADSync fragt der Assistent schon einige Optionen an:

Die häufigsten Optionen sind:

  • Office 365 Identität mit "Cloud 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 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
  • Anmeldung per ADFS
    Größere Firmen möchten aber nicht die Benutzer doppelt pflegen und auch die Anmeldedaten sollten die gleichen wie On-Prem sein. Sie können daher ihre UPN-Domain über ADFS "federieren". Die Identitäten haben dann einen entsprechenden Anmeldenamen und ein ADFS-Service übernimmt die Authentifizierung. ADFS Dienste können Sie selbst On-Premises hosten oder in der Cloud als AzureVM aufbauen oder direkt von Microsoft (Azure AD Premium) beziehen. Dann kommt aber wieder das Cloud Kennwort zum Tragen.
  • Pass-Through Authentifizierung
    Wenn ein ADFS zu aufwändig ist und der Kennwort-Sync das Single SignOn verhindert, ist PTA vielleicht ein Mittelweg

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

Thema Cloud Login Password Hash Sync (PHS) Pass Through Authentifizierung (PTA) ADFS AD Premium

Lokale Server/Dienste

Kein
  • 1x AADConnect
    mit KennwortSync
  • 1x AADConnect
  • ggfls. zusätzliche Agenten
  • 1-mehrere ADFS-Server
  • Public IP
  • ReverseProxy/ADFSProxy
  • Zertifikat
  • AAD Premium Lizenz
  • AADConnect
    mit KennwortSync

Verfügbarkeit

Hoch

Hoch

Hoch einfach möglich

Hoch teuer möglich

Hoch

Kosten

Niedrig

Niedrig

Niedrig

Mittel bis Hoch

Mittel *

Single SignOn

Nein

Same SignOn

Ja (Intern)

Ja (Intern)

Same SignOn

MFA

Ja

Ja

Ja

Ja (über ADFS On-Premises )

Ja

Meine Zielgruppe

1-10 User

1-x User mit lokalem AD

1-x User mit lokalem AD und SSO Anspruch intern

1-x User mit lokalem AD und SSO Anspruch intern und ADFS Nutzung mit anderen Apps

Wie ADFS nur eben PaaS

Multi Forest

Ja

Ja

Ja, mit Trust zwischen Forests

Ja, mit Trust zwischen Forests
Ja, mit eigenen ADFS je UPN-Domain

Ja

Es ist gar nicht so einfach zu unterscheiden.

BRK3015 Deep-dive: Azure Active Directory Authentication and Single-Sign-On
https://www.youtube.com/watch?v=6RHbDriZRVc
Sehr guter Vortrag von John Craddock

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 "Add-ons" 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 Benutzer mit Kennwort

Entfällt

Entfällt

Hash bei Office 365

Single Sign on mit ADFS

Erforderlich

Erforderlich
Kritisch

Hash On-Prem

DirSync mit Password Hash

Erforderlich

Entfällt

Hash On-Prem und Office 365

Pass Through Auth

Ratsam

Entfällt

Hash On-Prem

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 On-Premises 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.
  4. Integrierte Anmeldung mit Kerberos
    Der Client bekommt von der Cloud auch "Negotiate" angeboten und wenn er lokal ein passendes Computerkonto mit dem SPN findet und die URL zum "Intranet" gehört, dann meldet sich der Client ohne weitere Kennworteingabe an.

Die Varianten werden die folgt genutzt:

Dienst/Client Office 365
User		 ADFS DirSync
Hash		 Pass Through

Outlook WebApp/Browser

ActiveSync/Mobile

Kennwort geht zur Cloud

EAs kann kein Kerberos

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

+ 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

+ 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. Mit PassThroughAuth ist aber Negotiate möglich.

Kerberos
Kerberos-Tickets werden von DCs ausgestellt. Kerberos kann daher nur bei der Authentifizierung gegen den internen ADFS-Server per Kerberos erfolgen.

Weitere Links