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

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.

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...

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow
Blog
Blog

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow

Die Power Platform wird aktuell von Microsoft sehr stark gepusht. Zeit, sich mit dem Potenzial der einzelnen Komponenten zu beschäftigen. Heute: Flow.

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest
Blog
Blog

Sprechen Sie LUIS? – Der intelligente Chat-Bot im Praxistest

Mit LUIS, der Sprach- und Texterkennungssoftware von Microsoft, und dem Bot Framework von Azure haben wir eine Lösung für den IT-Support entwickelt.

Auf Goldkurs in der Cloud
News
News

Auf Goldkurs in der Cloud

Die novaCapta hat ihren Partnerstatus bei Microsoft zusätzlich vergoldet: Auch in der Sparte Cloud Productivity haben wir jetzt den Goldstatus.

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...

Azure Functions: Der Webservice ohne Webserver
Blog
Blog

Azure Functions: Der Webservice ohne Webserver

Azure Functions als Authentifizierungs-Helfer für clientseitige Lösungen mit 3rd Party APIs

Mit der HoloLens ein Stück Berlin nach Köln holen
News
News

Mit der HoloLens ein Stück Berlin nach Köln holen

Im Rahmen eines zweitägigen Hackathons haben sich einige Mitarbeiter der novaCapta der Microsoft HoloLens und dem Thema Mixed Reality gewidmet. Dabei haben wir...

Paket Dependency Manager für .NET
Blog
Blog

Paket Dependency Manager für .NET

Paket ist ein Dependency Manager für .NET, welcher es sich zum Ziel gesetzt hat einige Probleme von NuGet zu beheben.

Oct
12
PCDE #3 Event am 12.10. in Stuttgart
Event
Event

PCDE #3 Event am 12.10. in Stuttgart

Developer und IT-Professionals aufgepasst! Das novaCapta-Team nimmt am 12. Oktober am Pitch Club Developer Edition (PCDE) in Stuttgart teil. Dort stellen wir Ih...