Multi Factor Authentication in Azure und SharePoint

Microsoft führt mit der Multi Faktor Authentisierung (MFA) ein neues Feature in Office 365 hinzu, das kostenlos zur Verfügung steht. Es ist eine weitere Authentifizierungsebene und ermöglicht einen sicheren Zugriff für Kunden, Partner und Mitarbeiter. Die MFA kann für lokale und Cloud-Anwendungen genutzt werden.

Wofür steht denn eigentlich “Multi Faktor Authentisierung”?

“Multi Faktor Authentisierung” bedeutet, dass der Benutzer sich mehrfach authentifizieren muss, bevor er auf eine Office 365 Seite Zugriff bekommt. Das heißt, dass neben dem Benutzername und dem Passwort noch eine zusätzliche Authentisierung notwendig ist. Hierzu muss etwas verwendet werden, das eindeutig nicht duplizierbar ist – wie zum Beispiel ein Fingerabdruck oder eine Telefonnummer. Dieser Mechanismus ist mit einem VPN Token vergleichbar.

Die MFA funktioniert also nach der Regel „Something you know + something you have”.

Wichtig: MFA funktoiniert nur, wenn eine WebApplikation (in SharePoint) EXTENDED ist.

Wo werden die Benutzer gepflegt?

Ein großer Vorteil der MFA ist, dass kein eigenes Active Diretory benötigt wird. In Azure ist die Benutzer- und Gruppenverwaltung bereits integriert. MFA wird über eben diese Verwaltung zu-/ oder abgeschalten. Damit die MFA funktioniert, muss darauf geachtet werden, das für jeden angelegten Benutzer die MFA Funktion eingeschaltet ist.

Admin und Test User sind Benutzer, die im Azure Active Directory (AAD) angelegt wurden.

Admin und Test User können müssen sich nun mehrfach authentisieren.

Zusätzlich muss der Benutzer sich zum ersten mal auf eine Office 365 Seite anmelden. Dort bekommt er die Möglichkeit, sein Passwort zu ändern. Außerdem muss noch eine Telefonnummer hinterlegt werden, damit die Mehrfachauthentifizierung stattfinden kann.

Was hat eigentlich die Telefonnummer mit dem ganzen zu tun?

Angenommen der SharePoint Server verwendet den AAD. Nun möchte das Unternehmen sicherstellen, dass der Benutzer, der auf unsere SharePoint Seite zugreifen möchte, auch wirklich der autorisierte User ist. Der Benutzer gibt sein Benutzername inkl. Passwort ein. Anschließend wird der Benutzer auf der hinterlegten Telefonnummer angerufen. Erst nachdem er durch das Telefon eine Bestätigung abgibt, wird er auf unsere SharePoint Seite weitergeleitet. Die Authentifizierung gewinnt hierdurch an zusätzlicher Sicherheit.

Anstelle des Anrufs kann auch eine SMS erfolgen. Man erhält darin einen Bestätigungscode, welcher dann eingegeben werden muss.

Kommunikation zwischen Azure und SharePoint

Damit SharePoint den Azure versteht, muss ein Access Control Service (ACS) eingerichtet werden. Das ist notwendig, da zwischen beiden Systemen unterschiedliche Protokoll Versionen „SAML 1.1″ und “SAML 2.0” existieren. SharePoint versteht nur SAML 1.1, Azure hingegen SAML2.0. Damit die Authentifizierung gegen Azure stattfinden kann, wird der ACS eingerichtet, da dieser beide Protokolle versteht und die Informationen weiterleitet.

Einrichtung des ACS Dienstes auf Azure – Step by Step

Nun muss ein AAD Tenant angelegt werden (Domain Name kann frei gewählt werden):

Ein Service Principal muss per Powershell angelegt werden. Vorher aber ist es zwingend notwendig, das PS Cmdlet für AD zu installieren. Folgende Schritte sind notwendig:

1. ConnectPS
   Connect-MsolService​Login Dialog erscheint: Anmelden mit dem Primary Administrator Account „*protected email*”
2.  Service Principal anlegenPS
   Import-Module MSOnlineExtended -ForcePS > $replyUrl = New-MsolServicePrincipalAddresses -Address “https://sp2aad.accesscontrol.windows.net/”PS > New-MsolServicePrincipal –ServicePrincipalNames @(“https://sp2aad.accesscontrol.windows.net/”) -DisplayName “ACS Namespace” -Addresses $replyUrl​

Nun AAD Tenant als Identity Provider (IdP) im ACS anlegen

https://accounts.accesscontrol.windows.net/spusers.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml

Windows Live Id ist standardmäßig als Identity Provider aktiv. Man kann das Häckchen allerdings bedenkenlos deaktivieren, da es hier keine Verwendung findet.

Nun muss ein Trust (Token signing) zwichen SharePoint und ACS aufgebaut werden. Dazu benötigt man einen X.509 Zertifikat. Man hat zwei Möglichkeiten dies zu tun:

1.  Man erstellt ein neues (selfsigned) Zertifikat
2. Man benutzt das Zertifikat, welches im ACS bereits existiert und importiert dieses in SharePoint siehe „Relying Party” Config.

In diesem Fall wird das Zertifikat vom ACS genutzt:

Die angezeigt URL muss in den Browser kopiert werden. Anschließend bekommt man den Key angezeigt

Dieser Key muss dann in NotePad kopiert werden und als ANSI Format gespeichert werden. Anschließend die Datei mit der Endung .cer umbenennen.

Doch damit ist es noch nicht getan. Auf dem SharePoint Server muss der AAD noch als Trusted Identity Provider eingerichtet werden.  Dazu ist es nötig, folgende PS-Skripte auf dem Server auszuführen:​

1. ​$c​ert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“Lokaler Pfad des Zertifikats”
2. $signinurl = https://sp2aad.accesscontrol.windows.net:443/v2/wsfederation?wa=wsignin1.0&wtrealm=https://webapp.cloudapp.net
3. $realm = “https://deinewebapp.cloudapp.net/”
4. New-SPTrustedRootAuthority -Name “ACS SharePoint Token Signing Certificate” -Certificate $cert
5. $map1 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -IncomingClaimTypeDisplayName “UPN” –SameAsIncoming
6. $map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname” -IncomingClaimTypeDisplayName “GivenName” –SameAsIncoming
7. $map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname” -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming
8. $ap = New-SPTrustedIdentityTokenIssuer -Name “AAD” -Description “ACS Using Azure Active Directory Identity Provider” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2,$map3 -SignInUrl $signinurl -IdentifierClaim “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”

Nachdem die PS-Skripte ausgeführt wurden, kann man in der WebApplication den Identity Provider auswählen:

Ab diesem Zeitpunkt können die AAD Benutzer in SharePoint gefunden und Berechtigungen verteilt werden:

Vorteile & Nachteile

​Viel Spaß beim Einrichten.