Granikos Technology Blog

Identitätsmodelle

Office 365 unterstützt grundsätzlich drei unterschiedliche Modelle von Benutzeridentitäten, kurz Identitäten, für die Authentifizierung. Ohne eine erfolgreiche Authentifizierung ist eine Nutzung der zugewiesen Produkte und Dienste nicht möglich. Sie müssen sich für mindestens eine der drei Indentitätsmodelle entscheiden.

Die drei unterstützten Formen der Identität sind

• Cloud-Identität
  Bei dieser Identität gibt es keine Verbindung zu einem möglicherweise vorhanden Benutzerkonto im lokalen Active Directory. Die Verwaltung erfolgt vollständig in Office 365. Ebenso erfolgt die Authentifizierung durch Azue Active Directory (Azure AD) in der Cloud.
   
• Synchronisierte Identität
  Bei dieser Identität erfolgt eine Synchronisierung von Active Directory Benutzerobjekten und dem jeweiligen Kennwort-Hash. Auf Basis des synchronisierten Kennwort-Hashes erfolgt eine Authentifizierung durch Azure AD. 
  Synchronisierte Identitäten existieren in Azure AD parallel zu vorhandenen Cloud-Identitäten.
   
• Föderierte Identität - auch als Verbundidentität bezeichnet
  Diese Form der Identität ist eine Sonderform der synchronisierten Identität. Es erfolgt keine Synchronisierung der Kennwort-Hashes. Die Authentifizierung erfolgt durch Komponenten, die zusätzlich in der lokalen IT-Infrastruktur bereitgestellt werden müssen.
  Föderierte Identitäten existieren in Azure parallel zu vorhanden synchronisierten und Cloud-Identitäten.

Das folgende Schaubild verdeutlicht die Unterschiede der drei Identitätsmodelle.

Authentifizierung

Die Authentifizierung von synchronisierten Benutzerkonten aus dem lokalen Active Directory mit Azure AD sind drei unterschiedliche Authentifizierungsmethoden möglich.

Die drei Methoden sind:

• Kennwortsynchronisierung
  • Hierbei werden Kennwort-Hashes über AAD Connect zu Azure AD synchronisiert
  • Mit Self-Password-Reset können Benutzer ihr Kennwort in Azure AD ändern und mit aktiviertem Password-WriteBack wird die Änderung ins lokale AD zurückgeschrieben
  • Neben einem System, auf dem AAD Connect installiert ist, sind keine weiteren Systeme in der lokalen IT-Infrastruktur -Premises erforderlich

• Federation Services
  • Hierbei werden in der IT-Infrastruktur sog. Federation Server und, für den Zugriff aus dem Internet, Reverse Proxy Systeme im Perimeter-Netzwerk installiert
  • Mögliche Federation Software-Lösungen:
    • ADFS, Ping Federate, Shibboleth, u.a.
  • Neben einem System für AAD Connect werden zusätzliche Serversysteme benötigt
    Beispiel für ADFS
    • Minimum: 1x ADFS im LAN, 1x ADFS-Proxy im Perimeter-Netzwerk
    • Redundanz: 2x ADFS im LAN, 2x ADFS-Proxy im Perimeter-Netzwerk
  • Mit einer Federation-Implementierung können weitere Applikationen, zusätzlich zu Office 365, mit einer föderierten SSO-Anmeldung angebunden werden
    • Intern: z.B. Jira, Intranet, u.a.
    • Extern: z.B. Hosted SAP, u.a. 
  • Zusätzlich wird mindestens eine öffentliche IP-Adresse und eingehende HTTPS-Verbindungen benötigt
  • Hinweis:
    • Normalerweise werden Federation Services eingeführt, um KEINE Kennwort-Hashes mit Azure AD zu synchronisieren
    • MIT synchronisierten Kennwort-Hashes, ist ein längerer Ausfall der Federation Server leicht kompensierbar, da die UPN-Domäne in Office 365 nur von "federated" auf "standard" umgestellt werden muss

• Azure AD Connect Pass-through
  • Hierbei wird auf mindestens einem internem System (Domain Member) der Azure AD Connect Pass-through-Agent installiert
  • Der Agent baut eine ausgehende Verbindung zu Azure AD auf
  • Ein höhere Verfügbarkeit wird durch die Installation mehrerer Azure AD Connect Pass-through-Agenten erreicht
  • Der Agent kann auf bestehenden Systemen installiert werden
  • Eine SSO-Anbindungen ist für interne Applikation nur u.U. möglich. 

Hinsichtlich der Vor- und Nachteile dieser drei Optionen müssen Sie Ihre Anwendungsszenarien kennen. Alle drei Methoden haben ganz unterschiedliche Anforderungen. Gerade im Hinblick auf gewünschte SSO-Anbindungen von Lösungen jenseits von Office 365 (Azure AD) fallen eventuell einzelne Optionen weg.

Es dürfen aber nicht nur die Authentifizierungsart und die Applikationen betrachtet werden. Die verwendeten Clients (Desktop OS, Mobile OS, Applikationen) müssen für die ausgewählte Authentifizierungsart geeignet sein. Idealerweise sind natürlich Windows 10 und Office 2016/2019 oder Office 365 ProPlus im Einsatz. Ältere Softwarekomponenten müssen Sie separat evaluieren.

Links

• What is password hash synchronization with Azure AD?
• What is Azure Active Directory Pass-through Authentication?
• What is federation with Azure AD?

Viel Spaß mit Microsoft 365 und Azure AD.

Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist. 

Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.

Problem

Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema. 

Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.

Grund

Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:

Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?

Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.

Lösung

Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..

Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.

Hinweis

Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.

Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.

Links

• Configuring Kerberos authentication for load-balanced Client Access services (Exchange 2016), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.160).aspx
• Configuring Kerberos authentication for load-balanced Client Access servers (Exchange 2013), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.150).aspx

Weiterhin viel Spaß mit Exchange Server