Einrichten von Office 365 – Teil 2

Office365 einrichten-Teil2

Dieser Artikel ist Teil meiner Migration von meinem alten Office 365 zu meinem neuen Microsoft 365 Tennant. In diesem Artikel geht es um das Thema Einrichten von Office 365. Die weiteren Microsoft 365 Themen werden später folgen. Dieser Artikel ist bewusst so verfasst, dass er auch außerhalb eines Migrationsszenario zur Einrichtung verwendet werden kann. In Teil 1 ging es um die Auswahl der richtigen Edition, die Einrichtung des Kontos und die Konfiguration der Domänen und des DNS.

Das Einrichten der Azure AD Synchronisation und Authentifizierung

Um nicht alles mehrfach zu pflegen und den Benutzern verschiedene Konten zu zumuten, führt eigentlich kein Weg an einer Synchronisierung mit dem Active Directory vorbei. Wenn Sie sich noch nicht mit Azure AD befasst haben, empfehle ich einen Blick in den Artikel „Microsoft Azure AD – wofür braucht man das?„.


Dabei gibt es verschiedene Varianten der Synchronisation. Sie haben die Wahl zwischen einer Vollständigen und einer Eingeschränkten Synchronisation. Eingeschränkt bedeutet, dass zum Beispiel nur eine bestimmte Organisationseinheit oder Mitglieder einer Bestimmten Gruppe synchronisiert werden. Auch ist es möglich die Synchronisierten Attribute einzuschränken. Natürlich erhöht so etwas die Komplexität, wenn im Fehlerfall analysiert werden muss. Ich empfehle immer den meisten Kunden eine Vollständige Synchronisierung.

Bei der Authentifizierung gibt es verschiedene Ansätze:

Password Hash Authentifizierung / Synchronisierung (PHS)

Bei der Password Hash Synchronisierung wird ein Hash des Passwords im AzureAD gespeichert. Dadurch kann das Kennwort überprüft werden. Technisch gesehen ist das nicht der Gleiche Hash wie er im Active Directory gesichert ist. Es ist also auch nicht möglich, sollte man diesen Hash stehlen können, in im On-Premise AD zu missbrauchen. Wie das genau gesichert ist, erfahren Sie bei den einzelnen Schritten. Der große Vorteil des Verfahrens ist, dass die Authentifizierung am Azure AD erfolgt. Das bedeutet eine Verbindung zu Ihrer Umgebung ist nicht notwendig. Auch wenn der Bagger das RZ vom Netz getrennt hat, können Ihre Mitarbeiter sich im nächsten Café mit WLAN an Office 365 / Azure AD anmelden.

Doch wie ist der Ablauf genau:

Password Hash Synchronisierung (PHS)
1. Bevor sich ein Benutzer anmeldet geht es schon beim Synchronisieren der Objekte los. Hier fragt der AD Connect Server beim Domänen Controller unter anderem das Passwort über eine spezielle Schnittstelle an
2. Der Domänen Controller übermittelt das Passwort als MD4 Hash
3. Der Azure AD Connect Server verschlüsselt den MD4 Hash mit MD5. Der 8 Byte binär Hash wird in einen 64 Byte binär Hash umgewandelt. Dann mit einen Benutzerspezifischen 10 Byte Salt gehärtet. Dann wird das Ganze noch in SHA256 umgewandelt.
4. Der SHA256 für den Benutzer wird übermittelt und im Azure AD gespeichert.
5. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet.
6. Der Benutzer meldet sich mit seiner Benutzer ID am Azure AD.
7. Das AzureAD erkennt PHS und fordert die Eingabe des Kennwortes. AzureAD bildet einen entsprechenden Hash und vergleicht dem mit dem gespeicherten Hash. Stimmt er überein wird ein Azure Authentifizierungstoken ausgestellt.
8. Der Benutzer meldet sich mit diesem Token an Office 365 an.
Password Hash Synchronisierung (PHS)
  1. Bevor sich ein Benutzer anmeldet geht es schon beim Synchronisieren der Objekte los. Hier fragt der AD Connect Server beim Domänen Controller unter anderem das Passwort über eine spezielle Schnittstelle an
  2. Der Domänen Controller übermittelt das Passwort als MD4 Hash
  3. Der Azure AD Connect Server verschlüsselt den MD4 Hash mit MD5. Der 8 Byte binär Hash wird in einen 64 Byte binär Hash umgewandelt. Dann mit einen Benutzerspezifischen 10 Byte Salt gehärtet. Dann wird das Ganze noch in SHA256 umgewandelt.
  4. Der SHA256 für den Benutzer wird übermittelt und im Azure AD gespeichert.
  5. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet.
  6. Der Benutzer meldet sich mit seiner Benutzer ID am Azure AD.
  7. Das AzureAD erkennt PHS und fordert die Eingabe des Kennwortes. AzureAD bildet einen entsprechenden Hash und vergleicht dem mit dem gespeicherten Hash. Stimmt er überein wird ein Azure Authentifizierungstoken ausgestellt.
  8. Der Benutzer meldet sich mit diesem Token an Office 365 an.

Auf Grund des Verfahrens und der vielfältigen Hashen des Kennwortes sollte es nicht möglich sein dies zu entschlüsseln.

Ich bevorzuge diese Methode, wenn keine sehr guten Gründe für eine der anderen Methoden vorliegen. Eine Anleitung wie PHS eingerichtet wird, finden sie in dem Artikel „Azure Active Directory mit Single-Sign On mit Passwort Hash Synchronisierung„. PHS kann übrigens auch als Fallback-Lösung für die beiden anderen eingerichtet werden. So dass eine Anmeldung ohne Verbindung zwischen dem eigenen und den Azure Active Directory möglich ist.

Pass-Through Authentifizierung (PTA)

Bei der Pass-Through Authentifizierung ist ein zusätzlicher Dienst bei Ihnen im Rechenzentrum erforderlich. Dieser holt sich die Verschlüsselten Anmeldeinformationen aus einer Warteschlange beim AzureAD ab, und überprüft diese gegen den eigenen Domänen Controller. Der Vorteil, die Hashes des Kennworthash werden nicht im Azure AD gespeichert. Der Nachteil, wenn die Internetleitung Ihres Rechenzentrums gestört ist, kann sich keiner mehr anmelden. Diese Lösung setzt also gewisse Redundanzen und Vorbereitungen voraus. Sie können aber auch die Hashes der Passwort Hashes mit übertragen und im Notfall auf die Password Hash Authentifizierung umschalten.

Wie funktioniert das ganze?

Pass-Through Authentifizierung (PTA)
1. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet.
2. Der Benutzer meldet sich mit seiner Benutzer ID am Azure AD.
3. Das AzureAD erkennt PTA und fordert die Eingabe des Kennwortes.
4. Das AzureAD verschlüsselt die Informationen mit dem öffentlichen Schlüssel des Pass-Through Agenten und legt es in die Warteschlange
5. Der Pass-Through Agent holt sich die Pakete aus der Warteschlange (Es besteht eine dauerhafte Verbindung, über die er benachrichtigt wird, wenn es was Neuen gibt)
6. Der PT-Authentifizierungsagent Agent entschlüsselt mit seinem privaten Schlüssel das Paket
7. Die entschlüsselten Daten werden zur Überprüfung an den Domänen Controller übermittelt
8. Der Domain Controller antwortet entsprechend (Erfolgreich, Fehlgeschlagen, Benutzer gesperrt oder Passwort abgelaufen)
9. Der PT-Authentifizierungsagent leitet die Rückmeldung an das Azure Active Directory weiter
10. Das Azure Active Directory stellt einen Authentifizierungstoken aus
11. Der Benutzer meldet sich mit diesem Token an Office 365 an.
Pass-Through Authentifizierung (PTA)
  1. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet.
  2. Der Benutzer meldet sich mit seiner Benutzer ID am Azure AD.
  3. Das AzureAD erkennt PTA und fordert die Eingabe des Kennwortes.
  4. Das AzureAD verschlüsselt die Informationen mit dem öffentlichen Schlüssel des Pass-Through Agenten und legt es in die Warteschlange
  5. Der Pass-Through Agent holt sich die Pakete aus der Warteschlange (Es besteht eine dauerhafte Verbindung, über die er benachrichtigt wird, wenn es was Neuen gibt)
  6. Der PT-Authentifizierungsagent Agent entschlüsselt mit seinem privaten Schlüssel das Paket
  7. Die entschlüsselten Daten werden zur Überprüfung an den Domänen Controller übermittelt
  8. Der Domain Controller antwortet entsprechend (Erfolgreich, Fehlgeschlagen, Benutzer gesperrt oder Passwort abgelaufen)
  9. Der PT-Authentifizierungsagent leitet die Rückmeldung an das Azure Active Directory weiter
  10. Das Azure Active Directory stellt einen Authentifizierungstoken aus
  11. Der Benutzer meldet sich mit diesem Token an Office 365 an.

Durch die Offengehaltenen Verbindung, die von PTA Agenten aufgebaut wird, ist keine merkbare Verzögerung bei dieser Methode. Da der PTA Agent die Verbindung aufbaut sind keine Anpassungen oder Weiterleitung an Ihrer Firewall notwendig. Den Azure AD Connect Server benötigen Sie auch bei dieser Lösung, er ist nur nicht an der Authentifizierung beteiligt, muss aber die Benutzer und die passenden Attribute replizieren.

Active Directory Federation Service

Active Directory Federation Service, kurz AD-FS, ist das Urgestein der Azure AD Anmeldung. Es war die erste Anmeldemethode die für einheitliche Anmeldung mit On-Premise Zugangsdaten an der Cloud möglich war.

Da mein Artikel von 2013 „Was sind Microsoft Active Directory Federation Services (ADFS)„, erschienen im CONET Blog (Zu diesem Zeitpunkt habe ich dort gearbeitet) etwas veraltet ist, erkläre ich es hier noch einmal.

Eine Besonderheit dieser Lösung ist das Sie eine eingehende Freischaltung in die DMZ und von der DMZ in die Interne Infrastruktur benötigt. Dies mag auf den ersten Blick nach einem Sicherheitsproblem klingen, aber AD-FS ist die Lösung, die ich am besten auf meine Sicherheit anpassen kann. Und auch insofern die sicherste, da hier gar keine Zugangsdaten bei AzureAD eingegeben werden, sondern direkt auf Server des eigenen Unternehmens umgeleitet wird. Somit ist es die Sicherste Lösung, wenn man Microsoft nicht die Authentifizierung überlassen möchte.

Aber AD-FS hat noch weitere Vorteile, zum Beispiel können auch Drittanbieter Lösungen für Multi-Faktor Authentifizierung wie RSA eingebunden werden. Auch kann ich sehr granular steuern welche Authentifizierungen und Faktoren erforderlich sind. Das klingt jetzt nach dem Feature „Bedingtem Zugriff“ (Conditional Access), dieser wurde auch mit dem einen oder anderen Blick auf ADFS konzipiert. Der Gedanke war auch für andere Authentifizierungsarten dieselbe Sicherheit bei deutlich weniger Aufwand zu ermöglichen. Weitere Vorteile von AD-FS sind das ich auch deutlich mehr Dienste als Azure AD anbinden kann, da AD-FS SAML, OAUTH und WS-Fed spricht und umwandeln kann.

Wo soviel Licht ist, muss auch Schatten sein. Der AD-FS benötigt mehr Systeme und ist deutlich komplexe in der Einrichtung und Wartung. Ähnlich wie die Push-Through Authentifizierung ist ein Anmelden an den Ressourcen ohne Zugriff auf die eigene Umgebung nicht möglich. Ich persönlich empfehle ADFS immer nur in sehr komplexen Umgebungen mit besonderen Sicherheitsauflagen, oder wenn ein nicht AD Verzeichnisdienst als Identität Provider noch mit im Spiel ist.

Wie funktioniert hier die Anmeldung:

Active Directory Federation Service (ADFS)
1. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365
2. Office365 leitet den Benutzer zu Azure AD zur Anmeldung um.
3. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet. Nach der Abfrage der Benutzerkennung wird erkannt das es ein Föderierter Benutzer (Federation User) ist.
4. Azure AD leitet den Benutzer zu seinem Federation Server weiter, in diesem Fall ein Web Application Proxy in der DMZ der als Reverse Proxy dient.
5. Der Benutzer authentifiziert sich am Reverse Proxy mit seinem Kennwort, der Benutzername wir mitübergeben.
6. Der Reversproxy leitet die Anfrage an den AD-FS Server oder die AD-FS Farm weiter.
7. Das AD-FS authentifiziert den Benutzer am Active Directory und stellt einen ADFS-Token aus.
8. Das Token wird an den Reverse Proxy weitergeleitet.
9. Dieser sendet das ADFS-Token an den Benutzer zurück.
10. Jetzt wird wieder das Azure AD kontaktiert, und dort das ADFS-Token geprüft.
11. Nach erfolgreicher Prüfung wird ein Azure AD Token ausgestellt.
12. Der Benutzer meldet sich mit dem AAD-Token an Office 365 an.
Active Directory Federation Service (ADFS)
  1. Der Benutzer greift auf eine Ressource zu, zum Beispiel Office 365
  2. Office365 leitet den Benutzer zu Azure AD zur Anmeldung um.
  3. Wenn er nicht angemeldet ist, wird er zur Anmeldung an die AzureAD Anmeldeseite weitergeleitet. Nach der Abfrage der Benutzerkennung wird erkannt das es ein Föderierter Benutzer (Federation User) ist.
  4. Azure AD leitet den Benutzer zu seinem Federation Server weiter, in diesem Fall ein Web Application Proxy in der DMZ der als Reverse Proxy dient.
  5. Der Benutzer authentifiziert sich am Reverse Proxy mit seinem Kennwort, der Benutzername wir mitübergeben.
  6. Der Reversproxy leitet die Anfrage an den AD-FS Server oder die AD-FS Farm weiter.
  7. Das AD-FS authentifiziert den Benutzer am Active Directory und stellt einen ADFS-Token aus.
  8. Das Token wird an den Reverse Proxy weitergeleitet.
  9. Dieser sendet das ADFS-Token an den Benutzer zurück.
  10. Jetzt wird wieder das Azure AD kontaktiert, und dort das ADFS-Token geprüft.
  11. Nach erfolgreicher Prüfung wird ein Azure AD Token ausgestellt.
  12. Der Benutzer meldet sich mit dem AAD-Token an Office 365 an.

Eigentlich ganz einfach, oder? Vor allem wenn man bedenkt das der Web Application Proxy am besten mindestens zwei Systeme mit einem Load Balancer bestehen sollte. Und der AD-FS auch am besten eine Farm sein sollte.

Und ja, einen Azure AD Connect Server benötigen Sie auch bei dieser Lösung, er ist nur nicht an der Authentifizierung beteiligt, muss aber die Benutzer und die passenden Attribute replizieren.

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

Diese Form von Single-Sign-On ist nur mit PHS oder PTA möglich. Für AD-FS gibt es eigene Wege. Da für die meisten aber AD-FS zu Komplex sein dürfte, werde ich das Thema hier nicht behandeln.

Damit Azure AD Seamless SSO funktioniert müssen die Geräte Mitglied der AD Domäne sein. Sie müssen nicht Mitglied im Azure Active Directory sein.

Was funktioniert mit SSO?

Die Webseiten für Office 365, wenn Sie mit dem Domänen Hinweis aufgerufen werden. Zum Beispiel:

  • https://login.microsoftonline.com/<tenant_ID>/<..>
  • https://myapps.microsoft.com/<tenant_ID>
  • https://<tenant_id>.sharepoint.com

Allerdings nur mit den folgenden Browsern (Und das muss noch teilweise per Gruppenrichtline vorbereitet sein, später mehr) auf Microsoft Windows 7, Windows 8.1 und Windows 10

  • IE 10
  • Microsoft Edge (Classic)
  • Microsoft Edge (Chromium)
  • Google Chrome
  • Mozilla Firefox

Unter MacOS X sollte es mit zusätzlichen Aufwand auch für Google Chrome, Mozilla Firefox, Edge Chromium und Safari funktionieren. Weiterhin funktioniert das SSO auch mit dem Microsoft Office 365 ProPlus (ab 16.0.8730). Nur bei OneDrive sind zusätzliche Schritte erforderlich, mehr dazu in diesem Microsoft Blog Artikel.

Was muss in den Gruppenrichtlinien konfiguriert werden?

Damit das auch funktioniert muss die URL „https://autologon.microsoftazuread-sso.com“ zu den Intranet-Zonen hinzugefügt werden. Dafür gibt es verschiedene Wege, je nach Browser und ja nach Management Strategie.

Der Google Chrome folgt, wenn er entsprechend konfiguriert ist, den IE / Edge Vorgaben.

Microsoft Internet Explorer über Gruppenrichtlinie

Bei der Einstellung als Gruppenrichtlinie können Benutzer die Einstellung im Browser nicht ändern. Dies ist sehr restriktiv, kann aber je nach Sicherheitsanforderungen der bessere Weg sein.

Navigieren Sie in der Gruppenrichtlinie wie folgt: Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Internet Explorer > Internetsystemsteuerung > Sicherheitsseite und wählen die Einstellung und wähle Sie die Einstellung „Liste der Site zu Zonenzuweisung“.

Tragen Sie hier die URL mit dem Wert „1“ ein, dies steht für Intranet Seiten.

Screenshot: Gruppenrichtlinienverwaltung-Editor, "Liste der Site zu Zonenzuweisung"
Screenshot: Gruppenrichtlinienverwaltung-Editor, „Liste der Site zu Zonenzuweisung“

Zusätzlich wird noch eine weitere Einstellung benötigt. Diese finden Sie unter Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Internet Explorer > Internetsystemsteuerung > Sicherheitsseite und wählen die Einstellung. Die Einstellung, die Sie bearbeiten müssen, ist „Aktualisierung der Statusleiste per Skript zulassen“.

Diese Richtlinie muss aktiviert werden und die Option muss ebenfalls aktiviert werden.

Screenshot: Gruppenrichtlinienverwaltung-Editor, "Einstellung Aktualisierung der Statusleiste per Skript zulassen"
Screenshot: Gruppenrichtlinienverwaltung-Editor, „Einstellung Aktualisierung der Statusleiste per Skript zulassen“
Microsoft Internet Explorer über Gruppenrichtlinien Vorgaben

Wenn Sie die Benutzer nicht zu sehr einschränken möchten, empfiehlt sich die Einstellung als Gruppenrichtlinien Vorgabe zu machen. Das bedeutet, dass der Anwender diese Einstellungen ändern kann.

Realisiert wird das über einen Schlüssel in der Registry. Diesen können sie unter Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung vornehmen. Legen Sie dazu ein neues Registrierungselement mit den folgenden Werten an:

Schlüsselpfad: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
Name: https
Werttype: REG_DWORD
Wertdaten (Dez): 1
Screenshot: Gruppenrichtlinienverwaltungskonsole, Registrierungseinstellung
Screenshot: Gruppenrichtlinienverwaltung-Editor, Registrierungseinstellung
Mozilla Firefox

Für den Mozilla Firefox können Sie die Administrativen Vorlagen verwenden. Mehr zu den Vorlagen finden Sie im Artikel „Liste verschiedener Gruppenrichtlinien Vorlagen„. Die Benötigte Einstellung „SPNEGO“ finden Sie unter Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Mozilla > Firefox > Authentifizierung.

Screenshot: Gruppenrichtlinienverwaltungskonsole, Mozilla Firefox Richtlinie
Screenshot: Gruppenrichtlinienverwaltung-Editor, Mozilla Firefox Richtlinie

Installation von Azure AD Connect

Die Installation ist sehr einfach und Agenten gestützt. Die aktuelle Version können Sie aus dem AzureAD Portal herunterladen. Die einzelnen Schritte sind selbsterklärend, sobald Sie wissen welche Authentifizierung sie nutzen möchten. In dem Artikel „Azure Active Directory mit Single-Sign On mit Passwort Hash Synchronisierung“ führe ich Sie durch die einzelnen Schritte der Installation.

Azure Multi-Factor Authentication (MFA) einrichten

Da wir schon mal von Authentifizierung gesprochen haben, und bei AD-FS schon mal der Begriff Multifaktor Authentifizierung gefallen ist, schauen wir uns das mal an. Wie schon in den vorigen Kapiteln lasse ich AD-FS außen vor.

Die Azure MFA ist auch eine der Voraussetzungen für Bedingte Zugriffe (Conditional Access) oder Authentifizierungsszenarien wie Passwortlose-Authentifizierung (Password less-Authentication). Dabei gibt es ein paar Dinge zu beachten:

  • Legacy Anwendungen, die damit geschützt werden sollen, benötigen den Azure AD Applikation Proxy oder andere Methoden, um eingebunden zu werden. Eine direkte Integration beziehungsweise Erweiterung in die On-Premise AD Authentifizierung ist nicht vorgesehen.
  • Microsoft Office 2010 und Apple Mail für iOS 11 unterstützen keine Moderne Authentifizierung.
  • Da sich die Art der Anmeldung ändert, sollten die Anwender einbezogen und geschult werden. Microsoft bietet dafür auch Unterlagen in Englisch an.
  • Azure MFA kann auch mit Radius und AD-FS integriert werden. Mehr dazu im Microsoft Docs. Dadurch kann ich Azure MFA mit fast jeder Authentifizierung, die ich über ein AD laufen lassen kann, integrieren. Es ist nur eine Frage des Aufwandes und der Komplexität.

Authentifizierungsfaktoren mit Azure MFA

Der wichtigste Faktor ist der Microsoft Authenticator, eine App von Microsoft für Mobiltelefone. Die App bildet den Kern für viele Authentifizierungsmöglichkeiten und ist für den Benutzer die bequemste Art.

Microsoft Authenticator Push Authentifizierung

Die Standartmethode ist die Push-Benachrichtigung in die App. Der Benutzer wird gefragt ob er die Authentifizierung genehmigen möchte oder nicht. Das funktioniert bei mir sogar über die Smartwatch, kein Grund das Smartphone aus der Hosentasche zu hohlen.

Microsoft Authenticator Verification Code

Als Fallback für Regionen mit schlechten Mobilnetz oder erschöpften Datenvolumen generiert der Authenticator auch ein Einmalpasswort (One-Time-Passwort abgekürzt OTP). Dieses hat 6 Stellen und das Ganze funktioniert ähnlich wie bei normalen Hardwaretoken, Nummer eingeben und gut.

Dies kann die App übrigens auch für viele andere Anwendungen durch die Verwendung von offenen Standards. Zum Beispiel für:

  • Amazon
  • Facebook
  • Twitter
  • Instagram
  • IFTTT
  • Google
  • Ubiquiti
  • Plesk Server
  • WordPress Blogs mit Plug-Ins
  • Microsoft Live ID (Live.com / Outlook.com)
  • Xing

Und viele andere die den entsprechenden Standard unterstützen

Screenshot aus der Microsoft Authenticator App mit Konten von Amazon, Facebook, Twitter, IFTTT, Ubiquiti und AzureAD
Screenshot aus der Microsoft Authenticator App

Telefonische Authentifizierung

Der Benutzer erhält einen Anruf auf einer vorher hinterlegten und verifizierten Telefonnummer. Er bestätigt die Authentifizierung mit dem Drücken der Taste „#“ auf dem Telefon. Hierfür eignet sich zum Beispiel das Bürotelefon oder das private Mobiltelefon.

SMS-Authentifizierung

Hier wird der Code per SMS an eine vorher festgelegte Telefonnummer geschickt. Also eine gute Möglichkeit für Mitarbeiter ohne Smartphone oder Fans des Nokia 8110. Wesentlich wahrscheinlicher wäre aber der Fall, das der Mitarbeiter Spezielle Mobiltelefone, zum Beispiel Explosionsgeschützte, verwendet.

Einrichten von Azure MFA

Um die Multifaktor Authentifizierung einzurichten, gehen Sie bitte in das AzureAD Portal und dort in die Benutzerübersicht. Dort finden Sie in der Navigationsleiste den Punkt „Multi-Factor Authentication“. Wenn Sie diesen anklicken öffnet sich ein neuer Tab.

Azure Active Directory admin center
Screenshot aus der Microsoft Authenticator App

In diesem Tab wählen Sie zuerst den Punkt „service settings“ um Azure MFA zu konfigurieren.

Azure Multi-factor authentification
Azure Multi-factor authentification

Bei diesen Einstellungen gibt es ein paar die Relevant sind und die ich erklären möchte.

Azure Multi-factor authentification service settings
Azure Multi-factor authentification service settings

Anwendungspasswörter (App Passwords)

Für Anwendungen, die keine Moderne Authentifizierung können, gibt es zur Kompatibilität die sogenannten Anwendungspasswörter. Diese werden von Azure erstellt und dann als Kennwort in die Anwendung eingetragen. Dadurch wird die Moderne Authentifizierung mit MFA und Conditional Access umgangen. Sie sollten sich also überlegen ob Sie diese Funktion aktivieren. Ich würde Sie deaktivieren, bis sie benötigt wird. Mehr dazu bei Microsoft Docs.

Vertrauenswürdige IP-Adressbereiche (Trusted IPs)

Hier können Sie Ihre IP-Adressbereiche definieren. Diese erfordern dann keine MFA Authentifizierung. Mehr dazu wieder bei Microsoft Docs.

Überprüfungsoptionen (Verification options)

Hier können die bereits erklärten Überprüfungsoptionen ausgewählt werden. Zum Beispiel können Sie hier der telefonische oder SMS-Überprüfung deaktivieren.

MFA Authentifizierung Merken (Remember multi-factor authentication)

Damit hat der Anwender die Möglichkeit bei einer Anmeldung für bis zu 60 Tage auf die Multifaktor Anmeldung für diesen Dienst von dem aktuellen Gerät zu verzichten. Das kann gerade bei häufig genutzten Webseiten angenehm sein. Allerdings nur wenn es kein PC in der Hotellobby ist. Der Anwender und der Administrator können alle bestehenden gespeicherten MFA über das AzureAD verwerfen.

Aktivieren der ersten Anwender

Wenn Sie wieder zurück in die Benutzerübersicht der MFA Seite wechseln, können Sie die Benutzer aktivieren. Natürlich sollten Sie die Benutzer vorher darüber informieren. Zum Einrichten muss der Anwender dann die Seite https://aka.ms/MFASetup aufrufen, nach dem Sie ihn aktiviert haben.

Azure Multi-factor authentification Enable multiple User
Azure Multi-factor authentification Enable multiple User

Über die Schaltfläche „Bulk Update“ können Sie auch eine Liste hochladen. Beim aktiveren der MFA für die Benutzer kommt nochmal ein Hinweis mit dem Link zur Einrichtung.

About enable Multi-factor auth
Azure Multi-factor authentification Enable multiple User

Sobald der Benutzer freigeschaltet ist, wird er ans „Aktiviert“ (Enabled) angezeigt. Sobald MFA eingerichtet ist, wird „Erzwungen“ (Enforced) angezeigt. So können Sie auch kontrollieren wer schon MFA eingerichtet hat.

Enabled and Enforced User in MFA
Azure Multi-factor authentification Enable multiple User

So einfach ist das Aktivieren der MFA für Azure AD. Komplex wird es, wenn andere Systeme eingebunden werden sollen. Deshalb ist es wichtig die MFA Einführung zu planen. Vor allem wenn Sie nicht Microsoft Cloud-Dienste über AzureAD authentifizieren möchten.

Unternehmens-Branding einrichten

Natürlich ist es gut, wenn sich Benutzer direkt heimisch fühlen. Deshalb sollte die Anmeldung auch angepasst werden. So sehen die Benutzer nicht den Standard von Microsoft, sondern den für Ihr Unternehmen angepasste Anmeldung. Auch hier wieder der Hinweis, die gilt nicht für AD-FS. Trotzdem sollten Sie das auch Konfigurieren. Für bestimmte Dienste, zum Beispiel Microsoft Autopilot ist die Voraussetzung.

Gehen Sie zum Einrichten bitte in das Azure AD Portal, dort finden Sie im Bereich „Manage“ den Punkt „Company branding“.

Azure Active Directory admin center
Dashboard > Company branding
Configure the text and graphics your users see when they sign in to Azure Active Directory.
Azure Active Directory admin center Dashboard > Company branding

Dann wählen sie „Configure“ zum Einrichten des Unternehmensbranding.

Azure Active Directory admin center
Dashboard > Configure company branding
Language
Sign-in page background image
Image size: 1920x1080px
File size: <300KB
File type: PNG, JPG, or JPEG 0
Banner logo
Image size: 280x60px
File size: 10
File type: Transparent PNG, JPG, or JPEG
username hint O
Sign-in page text O
Advanced settings
Sign-in page background color O
Square logo image
Image size: 240x240x (resizable)
Max file size: 50KB
Default
Select a file
Select a file
Azure Active Directory admin center Dashboard > Configure company branding

Was kann / muss alles konfiguriert werden. Optimalerweise bereiten Sie die Grafiken vorher vor.

  • Hintergrund für die Anmeldeseite (1920x1080px, max. 300KB, PNG, JPG oder JPEG)
  • Banner Logo (280x60px, max. 10KB, transparentes PNG, JPG oder JPEG)
  • Viereckiges Logo (240x240px, max. 50KB, PNG – bevorzugt, JPG oder JPEG)
  • Viereckiges Logo für dunkele Anmeldungen (240x240px, max. 50KB, PNG – bevorzugt, JPG oder JPEG)

Auch gibt es einige Texte, die dem Benutzer angezeigt werden können. Natürlich gibt es die Möglichkeit verschiedene Einstellungen für verschiedene Sprachen vornehmen.

  • Tipp für den Benutzernamen
  • Text für die Anmeldeseite

Zusätzlich kann noch eine Hintergrundfarbe als RGB-Code hinterlegt werden. Angepasst werden kann auch, ob die Option angemeldet zu bleiben angezeigt wird.

Im Anschluss ist die Default Sprache angelegt und weitere können konfiguriert werden.

Anzeige

Azure Active Directory admin center
Dashboard > Company Branding
Azure Active Directory admin center Dashboard > Company Branding

Der Anwender sieht nach Eingabe der Benutzer ID die Eingabemaske für das Kennwort entsprechend angepasst.

Corporate Branding - Password field for the User
Corporate Branding – Password field for the User


Autor: Fabian Niesen

Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs. Hier schreibt er privat und unabhängig von seinem Arbeitgeber. Unter anderem ist er Zertifiziert als MCSA Windows Server 2008 / 2012, MCSA Office 365, MCSA Windows 10, MCSE Messaging, MCT und Novell Certified Linux Administrator. Seit 2016 ist er auch MCT Regional Lead für Deutschland. Seine Hobby’s sind Social Media, Bloggen, Mittelaltermärkte, Historische Lieder und der Hausbau. Zu finden ist er auch auf folgenden Plattformen: -

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.