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

VorteileNachteile
Erhöhte Sicherheit, da eine mehrstufige Authentifizierung notwendig istKeine komplexe Gruppenstruktur möglich
Kein eigenes Active Directory notwendigSchlechte Dokumentation, da es noch sehr neu ist
Kompatibel mit on-premise und Cloud Anwendungen 
Kein eigener MFA Server notwendig und keine Sorgen bzgl. Ausfallsicherheit 

 

​Viel Spaß beim Einrichten.

Erfahren Sie mehr

Valo ist neuer Partner der novaCapta für Intranets
News
News

Valo ist neuer Partner der novaCapta für Intranets

Durch die Partnerschaft mit Valo, dem Ready-2-Go Intranet-Baukasten aus Finnland baut die novaCapta ihr Angebot bei der Umsetzung von schnellen und funktionalen...

novaCapta auf der Fachtagung für Interne Revision
Event
Event

novaCapta auf der Fachtagung für Interne Revision

Das Expertenteam der novaCapta präsentiert am 15. und 16. November ihre innovative Audit Management Lösung auf dem DIIR-Kongress in Dresden. Besuchen Sie unsere...

Jan
25
Webcast mit Microsoft: Fit für die digitale Arbeitswelt
Webinar
Webinar

Webcast mit Microsoft: Fit für die digitale Arbeitswelt

Die digitale Transformation und die Veränderung der Arbeitswelt ist längst in vielen Unternehmen und in den öffentlichen Einrichtungen angekommen. Dennoch stell...

Office 365 Groups als Evolution von SharePoint?
Blog
Blog

Office 365 Groups als Evolution von SharePoint?

Zusätzlich zu SharePoint erlauben die Office 365 Groups es mir als Anwender, schnell und einfach neue Gruppen anzulegen und selbständig Benutzer hinzuzufügen.

Strukturen lernen und leben – Praxis Informationsarchitektur
Blog
Blog

Strukturen lernen und leben – Praxis Informationsarchitektur

Teil 1 – Strukturen lernen – Informationsarchitektur erfolgreich vertreten

Farben zur Optimierung des SharePoint-Kalender
Blog
Blog

Farben zur Optimierung des SharePoint-Kalender

Auch in SharePoint kann man Kategorien für Teamkalender-Einträge farblich abheben und damit die Lesbarkeit erhöhen. Wir zeigen Ihnen, wie das geht.

Die Micro-Info-Architektur
Blog
Blog

Die Micro-Info-Architektur

Vertiefung zum Thema Informationsarchitektur moderner Intranets mit SharePoint: Das Micro-Management.

SharePoint Framework Client-Side Webparts mit React
Blog
Blog

SharePoint Framework Client-Side Webparts mit React

React ist ein Framework zur Erstellen von Benutzeroberflächen. In der SharePoint Online Entwicklung bietet es sich für die Entwicklung von Client-Side Webparts...

Jan
17
Webinar Azure DevOps und Docker Machine
Webinar
Webinar

Webinar Azure DevOps und Docker Machine

DevOps ist in aller Munde, doch was genau verbirgt sich eigentlich hinter dem so viel beschworenen Konzept der IT-Zusammenarbeit? Im Webinar am 17.01.2019 erfah...

Referenz: Heidelberger Druckmaschinen AG

Referenz: Heidelberger Druckmaschinen AG

Ziel der Heidelberger Druckmaschinen AG war es eine neue innovative Arbeitsumgebung zu schaffen.

Das neuste Mitglied der Office 365 Familie: Delve
Blog
Blog

Das neuste Mitglied der Office 365 Familie: Delve

Microsoft legt nach: Mit Delve startet eine neue Form des Suchens und des Auffinden von Dokumenten und Informationen.

Nov
07
Webcast mit Microsoft: Das Intranet zu Ende gedacht
Webinar
Webinar

Webcast mit Microsoft: Das Intranet zu Ende gedacht

Am 07. November findet erneut eines unserer Webinare gemeinsam mit Mircosoft statt. Das Thema dieses Mal: Das Intranet zu Ende gedacht – Die Informationszentral...