Multi-Faktor-Authentifizierung für SharePoint Server

In dieser Analyse werden fünf verschiedene Ansätze vorgestellt, um Multi-Faktor-Authentifizierung (MFA) für eine SharePoint Server Subscription Edition Umgebung zu implementieren. Die MFA soll dabei wahlweise nur bei externen Zugriffen (Zugriff von außerhalb des Firmennetzwerks) oder optional auch für interne Zugriffe greifen. Bisher kommt klassische Windows-Authentifizierung (NTLM/Kerberos) zum Einsatz; ein Wechsel zu ADFS (Active Directory Federation Services) ist nicht gewünscht und wird entsprechend als nachteilig bewertet.

Diese Abhandlung steht hier frei einsehbar zur Verfügung.

Wenn Sie sie in Ihrem Unternehmen oder Organisation nutzen möchten, gibt es zwei Versionen:

• Geschütztes PDF: Eine PDF-Version ohne den „Vorschau“-Schriftzug. Das PDF ist druckbar, die Entnahme von Inhalten ist nicht möglich.
• White Label-Version: Diese Variante erhalten Sie als Word-Dokument, so dass Sie das Dokument beliebig modifzieren können.

Kontaktieren Sie mich bitte, wenn Sie eine kommerzielle Fassung dieser Abhandlung möchten.

Jede der fünf Lösungen wird im Folgenden ausführlich beleuchtet hinsichtlich:

• Funktionsweise und technische Umsetzung – Wie der Ansatz technisch realisiert wird und wie er funktioniert.
• Kosten – Mögliche Lizenzkosten, Infrastrukturkosten und laufende Betriebskosten.
• Implementierungsaufwand – Einschätzung des Aufwands für Einrichtung und Integration.
• Vorteile – Die jeweiligen Pluspunkte der Lösung.
• Nachteile – Mögliche Nachteile oder Risiken der Lösung.

Lösung 1: KEMP LoadMaster (Edge Security Pack)

Funktionsweise und technische Umsetzung: Der KEMP LoadMaster ist ein Load-Balancer mit integriertem Edge Security Pack (ESP), das als Reverse Proxy vor SharePoint geschaltet wird. Der LoadMaster übernimmt die Authentifizierung der Benutzer, noch bevor die Anfragen die SharePoint-Server erreichen (Pre-Authentication). Dabei unterstützt der LoadMaster flexible Authentifizierungsmethoden: Er kann Benutzer gegen Active Directory verifizieren und zusätzlich eine zweite Faktor-Abfrage einbauen (z.B. per RADIUS-OTP, SMS-TAN, Token oder Push). Konkret präsentiert der LoadMaster dem externen Nutzer eine Anmeldeseite, auf der zunächst Benutzername/Kennwort eingegeben werden. Anschließend erfolgt eine MFA-Prüfung, z.B. durch Eingabe eines Einmalpasscodes oder Bestätigung in einer Authenticator-App. Nach erfolgreicher Zwei-Faktor-Authentifizierung leitet der LoadMaster den Anmeldeprozess an SharePoint weiter: Über Kerberos Constrained Delegation (KCD) meldet er den Benutzer nahtlos bei SharePoint an, sodass SharePoint die Anfrage als authentifizierten Windows-Benutzer akzeptiert (Single Sign-On). SharePoint selbst kann also weiterhin Windows-Authentifizierung nutzen, während der LoadMaster davor die MFA erzwingt. Dieser Ansatz erfordert keine Änderungen an SharePoint direkt – die zusätzliche Sicherheitslogik wird vollständig im vorgeschalteten Load-Balancer umgesetzt.

Ein besonderer Vorteil ist, dass der LoadMaster kontextabhängige Regeln erlauben kann. So lässt sich beispielsweise konfigurieren, dass MFA nur bei Zugriff von externen Netzwerken verlangt wird, während für interne Clients im Firmennetz keine zweite Faktor nötig ist. Dies kann entweder über getrennte Zugriffs-URLs (intern direkt, extern über den LoadMaster) oder durch netzwerkbasierte Richtlinien im LoadMaster erfolgen. Insgesamt fungiert der KEMP LoadMaster damit als Ersatz für frühere Lösungen wie Microsoft TMG/ISA Server und bietet integrierte Web-Application-Security mit moderner MFA-Unterstützung.

Kosten: Für den Einsatz des KEMP LoadMaster fallen Lizenzkosten für den Load-Balancer an. Die Kosten richten sich nach dem gewählten Modell und Durchsatz; als Anhaltspunkt liegen virtuelle LoadMaster-Instanzen je nach Leistungsklasse im Bereich von ca. 1.700–4.500 USD einmalig bzw. als Jahresabonnement. Die Edge Security Pack Funktion (ESP) ist bei aktuellen LoadMaster-Modellen in der Lizenz enthalten, sodass keine separate Lizenz für die MFA-Funktionalität anfällt. Neben den Lizenzkosten sollten Ausgaben für Hardware (bei Appliance-Lösungen) oder entsprechende VM-Ressourcen eingeplant werden, sowie Support- und Wartungsverträge je nach Bedarf. Laufende Betriebskosten sind vergleichsweise gering – abgesehen von Strom/Hostingkosten und dem Aufwand für Updates. Wichtig zu betonen: Dieser Ansatz erfordert keine pro-Benutzer-Lizenzierung der MFA. Im Gegensatz zu cloudbasierten MFA-Diensten (die oft monatliche Kosten pro Nutzer verursachen) entstehen beim LoadMaster keine direkten Kosten pro authentifiziertem Benutzer. Insbesondere wird – im Gegensatz zur Azure AD App-Proxy-Lösung – keine Azure AD Premium Lizenz pro Nutzer benötigt, um extern MFA bereitzustellen. Dies kann die Gesamtkosten deutlich reduzieren, falls viele Benutzer auf SharePoint zugreifen sollen und noch keine entsprechenden Cloud-Lizenzen vorhanden sind.

Implementierungsaufwand: Die Einführung des KEMP LoadMaster erfordert einen moderaten Projektaufwand. Zunächst muss der Load-Balancer in die vorhandene Infrastruktur integriert werden. In vielen Fällen wird der LoadMaster als virtuelle Appliance (VM) eingerichtet; alternativ stehen Hardware-Appliances zur Verfügung. Die Netzwerkkonfiguration muss so angepasst werden, dass externe SharePoint-Aufrufe zum LoadMaster geleitet werden. Die eigentliche Konfiguration umfasst:

• Anbindung an Active Directory (der LoadMaster kann Mitglied der Domäne sein oder via LDAP angebunden werden, um Benutzeranmeldungen zu prüfen).
• Einrichtung der MFA-Anbieter: Im LoadMaster ESP können RADIUS-Server für OTP/TAN hinterlegt werden oder Integrationen zu Token-Diensten wie RSA SecurID und Duo Security erfolgen. Beispielsweise lässt sich ein RADIUS-basierter OTP-Dienst oder Azure MFA NPS-Server anbinden, um den zweiten Faktor zu verifizieren.
• Kerberos-Delegierung für SSO: Es muss in AD konfiguriert werden, dass der LoadMaster für die SharePoint-Dienste (SPNs der Web-Applications) als vertrauenswürdiger Delegations-Host agieren darf. Dieser Schritt (KCD-Konfiguration) erfordert Domänen-Admin-Rechte, ist aber gut dokumentiert durch KEMP.
• SSL-Zertifikate: Der LoadMaster präsentiert die Web-Anwendung extern, daher muss ein gültiges öffentliches Zertifikat für die SharePoint-URL auf dem LoadMaster installiert werden (ähnlich wie bei jeder Reverse-Proxy-Publikation).
• Testing und Rollout: Nach Konfiguration sind Tests mit Testusern durchzuführen, um sicherzustellen, dass die MFA-Abfolge und das SSO zu SharePoint funktionieren.

Der Gesamtaufwand ist überschaubar: Erfahrungsgemäß kann die Grundimplementierung in wenigen Tagen erfolgen, vorausgesetzt es sind bereits alle Rahmenbedingungen (VM, Firewall, DNS) vorbereitet. Im Vergleich zu komplexeren Lösungen (wie ADFS) ist der Einrichtungsaufwand geringer, da keine zusätzlichen Serverrollen (wie ADFS-Farm, Proxy) installiert werden müssen. Ein erfahrener Administrator kann den LoadMaster mithilfe von Dokumentation oder KEMP-Support zügig konfigurieren. Zudem bleibt SharePoint selbst nahezu unverändert – bestehende Web-Anwendungen können bleiben, lediglich eventuell ein alternativer Zugriffsweg (URL) wird extern via LoadMaster genutzt. Bei laufendem Betrieb ist der administrative Mehraufwand gering: Der LoadMaster läuft weitgehend autonom; Einstellungen für MFA (z.B. RADIUS Secrets oder Zertifikatswechsel) müssen gelegentlich aktualisiert werden, ansonsten beschränkt sich der Aufwand auf Monitoring und Updates des LoadMaster-Firmware.

Vorteile:

• Keine Anpassung der SharePoint-Farm erforderlich: Die SharePoint-Server verwenden weiterhin Windows-Auth; der LoadMaster kapselt die MFA komplett vor und ermöglicht so eine nahtlose Integration. Benutzer bemerken lediglich den vorgeschalteten MFA-Login, die eigentliche SharePoint-Sitzung verhält sich wie gewohnt.
• Kein ADFS notwendig: Im Gegensatz zur Microsoft-Föderationslösung kommt dieser Ansatz ohne ADFS aus, was Infrastruktur und Komplexität spart. Es müssen keine zusätzlichen AD-Federation-Server betrieben werden.
• Flexible MFA-Optionen: KEMP LoadMaster (ESP) unterstützt zahlreiche Authentifizierungsquellen und -methoden. Neben AD/Kerberos werden LDAP, RADIUS, digitale Zertifikate und OIDC/OAuth als Identitätsquellen unterstützt. Dadurch können bestehende MFA-Systeme (z.B. RADIUS-basierte Tokenserver, RSA SecurID) leicht eingebunden werden. Auch moderne Verfahren wie Zertifikat-Login oder Smartcards lassen sich nutzen. Unternehmen können also ihre bevorzugte MFA-Methode wählen.
• Single Sign-On und Benutzerkomfort: Der LoadMaster ermöglicht SSO über Anwendungen hinweg. Ist ein Nutzer am LoadMaster einmal authentifiziert, kann er (bei entsprechender Konfiguration) auf weitere veröffentlichte Anwendungen im selben Domain-Kontext zugreifen, ohne sich erneut anmelden zu müssen. Dies verbessert den Benutzerkomfort beim Wechsel zwischen Anwendungen (z.B. SharePoint und Exchange Webmail), da ein einziger Anmeldedurchlauf genügt („Einmal anmelden, überall Zugriff“).
• Kontextabhängige Sicherheit: Der LoadMaster erlaubt es, Zugriffsregeln nach Kontext zu gestalten. So können unterschiedliche Sicherheitsstufen je nach Standort oder Netzwerksegment umgesetzt werden. Beispielsweise kann für interne Netzwerke auf die MFA verzichtet oder ein anderer Mechanismus (etwa Clientzertifikat) gefordert werden, während externe Zugriffe eine volle 2FA durchlaufen. Diese Granularität erhöht die Sicherheit, ohne die internen Nutzer unnötig zu belasten.
• Hohe Performance und Skalierbarkeit: Als dedizierter Load-Balancer ist der KEMP für hohe Last ausgelegt. Er verteilt Anfragen auf die SharePoint-Server und übernimmt SSL/TLS-Terminierung. Die Lösung skaliert mit entsprechender Dimensionierung der Appliance auch für große Benutzerzahlen. Durch Load-Balancing verbessert sich zudem die Verfügbarkeit der SharePoint-Farm.
• Kostenvorteil bei vielen Nutzern: Da keine nutzerbasierten MFA-Lizenzen erforderlich sind, bleiben die Kosten auch bei steigender Benutzerzahl planbar. Gerade im Vergleich zu Cloud-Lösungen, die z.B. ~5–6 € pro Nutzer/Monat verlangen, kann der LoadMaster bei mehreren hundert Nutzern wirtschaftlicher sein.
• Etablierte Lösung, Unterstützung und Updates: KEMP (inzwischen Progress) hat das ESP speziell als TMG-Nachfolger positioniert. Es handelt sich um eine erprobte Lösung mit Supportangeboten und regelmäßigen Sicherheitsupdates. Administratorschulungen und Community-Ressourcen sind verfügbar, da LoadMaster im Microsoft-Umfeld weit verbreitet ist.

Nachteile:

• Einführung einer zusätzlichen Infrastrukturkomponente: Der Betrieb eines Load-Balancers bedeutet ein weiteres System, das überwacht und gewartet werden muss. Fällt der LoadMaster aus, ist der externe Zugriff auf SharePoint unterbrochen. Deshalb muss üblicherweise eine hochverfügbare Konfiguration (z.B. zwei LoadMaster in HA-Cluster) vorgesehen werden, was den Aufwand leicht erhöht.
• Lizenz- und Anschaffungskosten: Trotz der genannten Vorteile entstehen initiale Kosten für Anschaffung/Lizenzierung des LoadMasters. Im Vergleich zu rein in Windows enthaltenen Rollen (ADFS) oder bestehenden Cloud-Abos sind dies zusätzliche Ausgaben. Allerdings relativieren sich diese, wenn man die wegfallenden Cloud-Lizenzkosten berücksichtigt (siehe oben).
• Konfigurationsaufwand für KCD und MFA-Integration: Die Einrichtung von Kerberos Constrained Delegation erfordert Kenntnisse in AD SPN/Delegations-Konfiguration. Fehler hierbei können zu anfänglichen Problemen bei der SSO-Funktion führen (z.B. „401 Unauthorized“, wenn Delegierung nicht korrekt greift). Ebenso erfordert die Integration eines MFA-Servers (z.B. RADIUS) Genauigkeit bei der Konfiguration (IP-Filter, Shared Secret, etc.). Zwar ist all das machbar und dokumentiert, jedoch komplexer als eine rein cloudgestützte Lösung, wo vieles out-of-the-box integriert ist.
• Zusätzliche Netzwerkschicht: Alle externen Zugriffe laufen durch den LoadMaster, was eine weitere Fehlerquelle (Misconfiguration, Latenz) darstellen kann. Die Netzwerkinfrastruktur (Firewall, DNS) muss entsprechend angepasst werden. In seltenen Fällen können spezielle SharePoint-Funktionen oder -URLs Anpassungen erfordern (z.B. wenn bestimmte Pfade veröffentlicht/gesperrt werden müssen). Der Betrieb eines Reverse Proxy kann so initial etwas Feintuning verlangen.
• Kein tiefes Device-Management: Der LoadMaster prüft zwar Geräte teilweise via Zertifikat oder IP, bietet aber kein vollständiges Conditional Access wie z.B. Azure AD (mit Device Compliance, Benutzer risikobasiert etc.). Solche Funktionen sind nur begrenzt im LoadMaster umsetzbar. Für viele Szenarien reicht die Gruppen-/Netzwerk-basierten Steuerung aus, doch gegenüber z.B. Azure Conditional Access ist es simpler gestrickt.

Lösung 2: ADFS + Azure MFA (föderierte Authentifizierung)

Funktionsweise und technische Umsetzung: Dieser klassische Ansatz nutzt Active Directory Federation Services (ADFS) als Föderationsdienst, um SharePoint die MFA-Funktionalität bereitzustellen. SharePoint wird hierzu im Claims-Modus konfiguriert und vertraut auf ADFS als Identity Provider. Technisch bedeutet das: Ein externer Benutzer, der auf SharePoint zugreifen will, wird zur Anmeldung an den ADFS-Server umgeleitet. ADFS wiederum authentifiziert den Benutzer gegen Active Directory (erster Faktor, z.B. durch Eingabe von AD-Benutzername und Kennwort). Anschließend führt ADFS eine MFA-Prüfung durch. In vielen Fällen wird hier Azure Multi-Factor Authentication eingebunden, indem Azure MFA als zusätzlicher Authentifizierungsanbieter in ADFS registriert ist. Microsoft hat die eigenständige lokale MFA-Server-Lösung inzwischen eingestellt, so dass die Integration des Cloud-basierten Azure MFA Dienstes der empfohlene Weg ist. Beispielsweise sendet Azure MFA einen Push an die Authenticator-App oder eine SMS an den Benutzer und meldet das Ergebnis zurück an ADFS. Ist die Zwei-Faktor-Authentifizierung erfolgreich, erstellt ADFS ein SAML/WS-Federation Token mit den Benutzeransprüchen und gibt es an SharePoint weiter. SharePoint vertraut diesem Token (die SharePoint Webanwendung ist als „vertrauende Anwendung“ in ADFS hinterlegt) und gewährt Zugriff.

Für interne Benutzer kann ADFS so konfiguriert werden, dass sie nahtlos (Single Sign-On via integrierter Windows-Auth) angemeldet werden und ggf. keine MFA benötigen. ADFS unterscheidet Anfragen aus dem internen Netz vs. Extranet anhand der Anmeldedatenquelle (direkter ADFS vs. ADFS über Web Application Proxy). Es lassen sich Richtlinien definieren, die z.B. MFA nur für Zugriffe von extern verlangen. Interne Anfragen (von Domänenrechnern im LAN) könnten ohne zweiten Faktor durchgelassen werden, während externe zwingend MFA erfordern – diese Differenzierung ist ein Feature von ADFS/Azure MFA Conditional Access. Somit kann die Vorgabe „MFA nur extern“ erfüllt werden. Alternativ ist es auch möglich, interne Nutzer weiterhin über Windows Auth direkt auf SharePoint zugreifen zu lassen (per separater Zone), während externe über eine andere URL via ADFS laufen – dies erhöht jedoch die Komplexität und wurde hier nicht primär vorgesehen.

Um ADFS extern erreichbar zu machen, setzt man meist einen Web Application Proxy (WAP) in der Perimeterzone ein. Der WAP nimmt externe HTTPS-Verbindungen entgegen und leitet sie an die internen ADFS-Server weiter, sodass die ADFS-Farm selbst nicht direkt exponiert wird. Der WAP kann die gleiche URL wie ADFS bereitstellen und steuert den Anmeldefluss von extern.

Kosten: ADFS ist eine Serverrolle von Windows Server und an sich lizenzkostenfrei nutzbar (sofern Windows-Server-Lizenzen vorhanden sind). Die Hauptkostenpunkte liegen hier in der Infrastruktur und dem Betriebsaufwand sowie in ggf. benötigten MFA-Lizenzen:

• Es werden mindestens zwei ADFS-Server (für Hochverfügbarkeit) und ggf. zwei Web Application Proxy-Server benötigt. Diese können als VMs betrieben werden. Jede Instanz benötigt Ressourcen (CPU, RAM, Storage) und Wartung. Die Windows-Server-Lizenz ist meist durch vorhandene Volumenlizenzen oder Datacenter-Hosts abgedeckt, so dass direkte Lizenzkosten für ADFS-Server oft nicht extra anfallen. Dennoch entstehen Aufwände für Einrichtung, Konfiguration und regelmäßige Updates (ADFS erhält Security Updates über Windows Update).
• Azure MFA Kosten: Wenn Azure AD als MFA-Dienst genutzt wird, benötigt man entsprechende Azure AD Lizenzen. In vielen Fällen erfordert dies Azure AD Premium Plan 1 für alle Benutzer, die MFA nutzen sollen. Azure AD Premium P1 ist oft in Microsoft 365 E3/E5 enthalten; falls nicht, kostet es einzeln ca. 5–6 € pro Benutzer/Monat. Für 100 Benutzer wären das rund 600 € monatlich laufend. Alternativ, wenn man die kostenfreie Azure MFA (pro User) nutzt, entstehen keine Lizenzkosten, jedoch ist diese Variante weniger flexibel (manuelles Enable pro Nutzer, keine Conditional Access Policies). In Unternehmensszenarien wird in der Regel P1 lizenziert für sauberes Conditional Access Management.
• Alternativer MFA-Anbieter: Anstelle von Azure MFA könnte ADFS auch mit Drittanbietern erweitert werden (z.B. Duo Security ADFS-Adapter, RSA Authentication Agent für ADFS etc.). Diese Drittanbieter haben eigene Lizenzmodelle, meist ebenfalls pro Nutzer (z.B. Duo ca. 3–9 \$ pro User/Monat je nach Plan). Das müsste als Alternative kalkuliert werden, bringt aber ähnliche laufende Kosten mit sich.
• SSL-Zertifikate: Für die ADFS-Service-URL und die WAP-Publikation sind öffentliche Zertifikate notwendig. Pro Domain fallen hier ggf. jährliche Zertifikatskosten an, falls keine bestehende CA-Infrastruktur dies abdeckt (mittlerweile oft durch bereits vorhandene Zertifikate für andere Dienste vorhanden).
• Arbeitsaufwand als Kostenfaktor: Nicht zu vernachlässigen sind die Implementierungs- und Betriebskosten durch Administratoren. ADFS + MFA einzurichten und zu betreiben, ist komplexer als andere Lösungen, was sich in höherem Zeitaufwand niederschlägt (siehe unten). Dies kann als indirekter Kostenpunkt betrachtet werden (Adminstunden, Schulungen etc.).

Implementierungsaufwand: Die Implementierung einer ADFS-basierten MFA-Lösung ist aufwändig und erfordert sorgfältige Planung. Die Schritte umfassen:

• ADFS-Farm einrichten: Installation der ADFS-Rolle auf mindestens zwei Servern, Konfiguration eines Farm-Verbunds (benötigt z.B. ein dediziertes Dienstkonto, eine SQL-DB oder Windows Internal Database, etc.). Auswahl eines Federation Service Names (z.B. sts.firma.de) und Einbindung ins AD. Ausstellen und Binden des SSL-Zertifikats für ADFS.
• Web Application Proxy einrichten: Im DMZ/Perimeter werden WAP-Server installiert und mit der ADFS-Farm verbunden. Der WAP veröffentlicht dann die ADFS-Anmeldung nach extern. Auch hier Zertifikatskonfiguration und Name (gleich wie ADFS).
• SharePoint an ADFS anbinden: In SharePoint muss eine Vertrauensstellung für ADFS als Identity Provider konfiguriert werden (PowerShell: New-SPTrustedIdentityTokenIssuer etc.). Man importiert das ADFS-Token-Signing-Zertifikat und definiert die Claim-Mappings (welche Claim z.B. als Benutzeridentität dient, üblicherweise UPN oder SIP). Evtl. wird eine neue Web Application oder eine Extended Zone erstellt, die statt Windows nun ADFS-Auth verwendet.
• Azure MFA Integration: Auf den ADFS-Servern wird das Azure MFA Adapter registriert. Dies erfordert die Installation der Azure MFA Erweiterung und die Konfiguration der Verbindung zum Azure AD Tenant. Dazu muss man den Azure Tenant vorbereiten (mind. einen Global Admin Zugriff, Azure AD MFA provider aktivieren). Nach Installation kann in ADFS eine MFA-Zugriffssteuerungsrichtlinie erstellt werden, die bspw. „MFA erforderlich für Extranet“ vorschreibt. ADFS bietet hier GUI-basierte Policies oder man nutzt Azure AD Conditional Access (bei B2B-Szenarien).
• Betrieb und Tests: Nach Einrichtung muss die Lösung gründlich getestet werden (intern vs. extern, verschiedene Browser, Office-Integration). ADFS-Protokolle müssen überwacht werden, um mögliche Claim-Issues oder Fehlschläge bei MFA zu erkennen. Im laufenden Betrieb müssen sowohl ADFS als auch WAP regelmäßig gepatcht werden. Auch das Azure AD Connect (für Benutzerabgleich) und der Azure AD Tenant selbst müssen administriert werden (z.B. neue Benutzer auch im Azure AD, MFA-Geräte registrieren usw.).
• Migration/Benutzerakzeptanz: Falls man vom bisherigen reinen Windows-Login umsteigt, müssen Benutzer informiert und geschult werden, da sich der Anmeldeablauf ändert (Weiterleitung zur ADFS-Seite, MFA-Eingabe). Bei gutem Design (ADFS im Forms-SSO zu Windows) bleibt der Unterschied gering, aber visuell wird es eine andere Anmeldemaske (ADFS-Loginseite) sein.

Insgesamt ist der Implementierungsaufwand hoch. Microsoft selbst weist darauf hin, dass für MFA in SharePoint on-premises eine ADFS-Föderation nötig ist. Dieser Ansatz bedingt eine Vielzahl an Komponenten, was Implementierungstage durch erfahrene AD/ADFS-Spezialisten erfordert. Auch im Betrieb ist die Lösung wartungsintensiver (Patch-Management für mehrere Server, Monitoring der ADFS-Farm, Zertifikatserneuerungen etc.).

Vorteile:

• Offizielle Microsoft-Lösung: Der ADFS-Weg ist von Microsoft als Standard vorgesehen, um On-Premises-Anwendungen um MFA zu erweitern. Dadurch ist die Kompatibilität mit SharePoint gewährleistet und es gibt umfangreiche Dokumentation und Support seitens Microsoft für dieses Vorgehen.
• Hohe Flexibilität und Sicherheitsfeatures: ADFS in Kombination mit Azure MFA erlaubt sehr feingranulare Zugriffsregeln. Über Conditional Access Policies können Bedingungen definiert werden (z.B. MFA nur extern, Blockieren unsicherer Altsysteme, Gerät muss Hybrid-AD-joined sein etc.). Auch zukünftige Azure AD Features (z.B. risk-based MFA, Passwortlos-Login via FIDO2) können genutzt werden, sobald sie ADFS/Azure AD integriert sind. Damit erhält man ein State-of-the-Art Policymanagement für Authentifizierung.
• Integration mit weiteren Anwendungen: Hat man ADFS erst einmal im Einsatz, kann man darüber auch andere On-Premises Applikationen (z.B. Outlook Web App, andere Websites mit Claims-Unterstützung) einbinden. Ebenso können (via Azure AD B2B) sogar Cloud-Anwendungen darüber föderiert werden. ADFS fungiert als zentrales Authentifizierungs-Hub. Für Unternehmen, die viele Apps unter einem Login vereinen wollen, kann dies vorteilhaft sein (SSO über viele Systeme).
• Bewährte Sicherheit: ADFS ist ein ausgereiftes Produkt mit hohen Sicherheitsstandards. Es unterstützt moderne Protokolle (SAML, WS-Fed, OIDC) und starke Verschlüsselung. Durch die MFA-Integration (sei es Azure MFA oder Drittanbieter) können alle gängigen zweiten Faktoren (Push, OTP, Telefonanruf, Hard Token) genutzt werden. Azure MFA bietet dabei eine sehr zuverlässige Infrastruktur, welche global verteilt und skalierbar ist – Ausfälle sind selten und die Lösung ist vielfach erprobt.
• Transparenz für Benutzer (bei interner Nutzung): Domain-angebundenen Clients kann ADFS Single Sign-On bieten. Das heißt, im Intranet merken die Nutzer kaum etwas von ADFS – sie werden automatisch angemeldet, solange sie am AD angemeldet sind. Nur extern erscheint dann die zusätzliche MFA-Abfrage. Diese nahtlose Integration erhöht die Akzeptanz: intern ändert sich nichts, extern gibt es mehr Sicherheit.
• Keine Änderungen am SharePoint-Code: Wie auch beim LoadMaster werden keine Code-Änderungen an SharePoint nötig, lediglich Konfiguration. SharePoint unterstützt das Claims-Federation-Login nativ, sodass Updates oder Upgrades von SharePoint unbeeinflusst bleiben.

Nachteile:

• Sehr hoher Einführungsaufwand und komplexe Architektur: Die Zahl der benötigten Server (ADFS/WAP-Farmen), die Konfigurationsschritte und Abhängigkeiten (AD, Azure AD Connect, Zertifikate, Firewallregeln) ist erheblich. Die Lösung erfordert Spezialwissen in mehreren Bereichen. Damit einher geht auch ein erhöhtes Fehlerpotential – von Token-Fehlern bis zu Netzwerkproblemen. Für viele mittelständische Umgebungen ist dieser Overhead unverhältnismäßig groß, wenn es nur darum geht, einem einzelnen Dienst (SharePoint) MFA hinzuzufügen.
• Abhängigkeit von Azure MFA/Cloud: Da der eigenständige Microsoft MFA-Server nicht mehr verfügbar ist, ist man auf einen Cloud-Dienst angewiesen. Das bedeutet, dass die Verfügbarkeit der MFA auch von der Internetanbindung und Azure-Diensten abhängt. Ein Ausfall der Azure MFA Service (oder falls die Verbindung dorthin gestört ist) würde die Anmeldung für externe Nutzer verhindern, selbst wenn die lokale ADFS-Farm läuft. Für manche sicherheitsbewusste Organisationen ist außerdem die Einbindung der Cloud (Benutzer müssen in Azure AD registriert sein) ein Kritikpunkt.
• Hoher Wartungsaufwand: ADFS erfordert ständige Pflege: Sicherheitsupdates, Zertifikatmanagement (Token Signing/Decrypting Zertifikate alle paar Jahre erneuern, SSL-Zertifikate jährlich erneuern), Überwachung der Event-Logs, etc. Troubleshooting kann komplex sein – z.B. wenn Token nicht akzeptiert werden, muss man Claims-Diagnosen durchführen. Der Betrieb einer ADFS-Infrastruktur ist daher aufwändiger als z.B. eine Cloud-Lösung, wo vieles vom Anbieter gemanagt wird.
• Performance und Benutzererlebnis: Ein kleiner Latenz-Nachteil entsteht dadurch, dass jeder Login einen Umweg über den ADFS-Server macht. Gerade bei externen Zugriffen (WAP->ADFS->AD) kann das Anmelde-Fenster etwas länger dauern als ein direkter Login. Zwar sind die Zeiten meist kurz, aber es ist ein zusätzlicher Hop. Auch ist die Benutzerführung fragmentiert: Der Nutzer sieht zunächst die ADFS-Formularseite, danach ggf. den Azure MFA Prompt, dann SharePoint – dieser Medienbruch kann als weniger „smooth“ empfunden werden, verglichen mit integrierten Lösungen.
• Kein unmittelbarer SSO zu Windows-Client-Anwendungen: Ein Sonderfall in gemischten Umgebungen: Wenn man SharePoint via ADFS absichert, kann es bei Office-Apps (Word/Excel auf dem Desktop) zu zusätzlichen Prompts kommen, da diese die ADFS-Föderation ggf. nicht ohne weiteres nutzen können (je nach Office-Version muss Modern Auth aktiviert sein). Das heißt, die Anwender könnten bei Öffnen von SharePoint-Dokumenten in Office erneut einen ADFS/MFA-Login sehen, was Schulungsbedarf erzeugt.
• ADFS wird von Microsoft perspektivisch weniger fokussiert: Mit dem Schwenk zu cloudbasierten Authentifizierungsdiensten (Entra ID) investiert Microsoft weniger in On-Prem ADFS-Weiterentwicklungen. Für neue Features (z.B. Passwordless mit FIDO2) muss man selbst Workarounds bauen oder auf neuere Windows Server-Versionen upgraden. Auch das Client-Betriebssystem (z.B. Windows 11) und Office 365 sind primär auf Cloud-Auth ausgerichtet. Dies bedeutet nicht, dass ADFS bald abgeschafft wird, aber es könnte auf lange Sicht zu einem „Legacy“-Status führen, der erhöhten Wartungsaufwand mit sich bringt.

Lösung 3: Azure AD Application Proxy (Cloud-Proxy mit Azure MFA)

Funktionsweise und technische Umsetzung: Der Azure AD Application Proxy ist ein Cloud-basierter Reverse-Proxy-Dienst von Microsoft Entra (Azure AD). Er ermöglicht es, eine interne Webanwendung wie SharePoint extern verfügbar zu machen, ohne selbst einen publizierenden Server in der DMZ betreiben zu müssen. Die Architektur ist wie folgt: Auf einem internen Server (oder mehreren) wird der App-Proxy Connector installiert. Dieser stellt eine ausgehende Verbindung zu Azure her und wartet auf Steuerbefehle. In Azure AD legt man eine Application Proxy App für SharePoint an, die auf eine interne URL verweist. Ein externer Benutzer greift dann über eine von Microsoft gehostete Proxy-URL (z.B. https\://.msappproxy.net/…) auf SharePoint zu. Azure AD übernimmt an diesem Endpunkt die Authentifizierung des Benutzers – dieser meldet sich mit seinen Azure AD Zugangsdaten an (meist identisch mit AD durch Synchronisierung) und muss gemäß Richtlinie eine MFA durchführen. Nach erfolgreicher Authentifizierung leitet der Application Proxy die Anfrage an den Connector weiter, der im internen Netzwerk eine Verbindung zum SharePoint aufbaut (zur internen SharePoint-URL) und dem SharePoint-Server einen Impersonierungstoken präsentiert. Hierfür kann der Connector entweder den Nutzer per Kerberos im AD delegiert anmelden (KCD) oder – in neueren Varianten – OAuth2-Tokens im Namen des Benutzers verwenden. In der Praxis wird häufig KCD genutzt: Der Connector meldet sich beim SharePoint an, indem er dessen Dienstprinzipal nutzt und mit einem Computerkonto die Kerberos-Delegierung ausführt. Dadurch sieht SharePoint den Zugriff als internen Windows-Login des jeweiligen Nutzers (ähnlich wie beim KEMP-Ansatz).

Für interne Zugriffe ändert sich nichts: Die Mitarbeiter können weiterhin die direkte interne URL von SharePoint nutzen (z.B. https://sharepoint.intern) und werden per Windows-Auth angemeldet, ohne MFA. Nur externe Benutzer, die über den App Proxy Pfad kommen, müssen via Azure AD Authentifizierung + MFA durch. Damit wird die Forderung „MFA nur extern“ automatisch erfüllt – interne Nutzer gehen gar nicht über den Proxy. (Soll auch intern MFA erzwungen werden, könnte man interne Zugriffe ebenfalls über die externe Proxy-URL leiten oder eine Conditional Access Policy auf interne Logins anwenden – beides eher unüblich).

Die Azure AD Authentifizierung bietet verschiedene MFA-Mechanismen (je nach Azure AD Lizenz und Konfiguration): Standardmäßig können Benutzer die kostenlose Azure MFA per App, SMS oder Anruf nutzen. Über Conditional Access lassen sich auch Regeln definieren, wann MFA erforderlich ist (z.B. nur bei ungewohnten Standorten). In vielen Fällen wird man einfach MFA für alle externen Zugriffe auf diese Anwendung verlangen.

Kosten: Die Nutzung des Azure AD Application Proxy erfordert eine entsprechende Azure AD Lizenz. Laut Microsoft ist der App-Proxy ein Feature, das mindestens Azure AD Premium P1 benötigt. In der Praxis bedeutet das: Alle Benutzer, die diese Proxy-Anwendung nutzen (also alle extern zugreifenden SharePoint-Nutzer), sollten mit Azure AD P1 lizenziert sein. Viele Unternehmen haben dies bereits über Microsoft 365 E3/E5 Lizenzen abgedeckt. Falls nicht, kostet eine Einzel-P1-Lizenz ca. 5–6 € pro Benutzer/Monat. Technisch gesehen reicht zum Aktivieren oft eine Lizenz im Tenant, aber lizenzrechtlich ist pro Nutzer gefordert. Zusätzlich zu App-Proxy ist für bedingte MFA-Regeln meist ebenfalls P1 nötig – einfache MFA pro User kann auch ohne P1 genutzt werden, doch Conditional Access (z.B. standortbasiert) erfordert P1. Angenommen, 100 Mitarbeiter sollen extern auf SharePoint mit MFA zugreifen, wären also ~100 * 6 € = 600 € monatlich für P1 einzuplanen, sofern nicht ohnehin vorhanden.

Weitere Kostenfaktoren:

• Azure AD Connect: meist bereits vorhanden für O365. Falls nicht, die Synchronisierung von AD zu Azure AD ist aber kostenlos als Dienst nutzbar (Azure AD Connect Tool).
• Infrastructure: Der Application Proxy Connector läuft als Dienst auf einem oder mehreren bestehenden Servern (kann ein Mitgliedserver oder gar ein SharePoint-Server sein). Hier fallen keine Lizenzkosten an, außer man möchte dedizierte VM dafür (dann deren Windows-Lizenz falls nötig). In vielen Fällen kann ein vorhandener Server genutzt werden, da der Connector recht leichtgewichtig ist.
• Netzwerkbandbreite: Das Datenvolumen, das durch den App Proxy fließt, verursacht in Azure keine direkten Kosten (App Proxy ist Teil des AAD-Dienstes, kein separater Azure Service Metering). Allerdings belastet es natürlich die eigene Internetleitung und minimal den Tenant (die Anzahl der Authentifizierungen ist aber in AAD flat, es gibt keine Begrenzung die Kosten verursacht außer man hat extreme Last).
• Betrieb: Die Kosten für Betrieb sind gering – Azure betreibt den Proxy-Service, die eigenen Connectoren updaten sich automatisch. Admin-Aufwand entsteht für die Einrichtung von Conditional Access Policies und die Überwachung der Nutzung (Protokolle in Azure AD). Diese Tätigkeiten sind aber Teil der allgemeinen Azure AD Administration.

Implementierungsaufwand: Der Einführungsaufwand für den Azure AD Application Proxy ist mittel und deutlich geringer als der ADFS-Ansatz. Wichtige Schritte:

• Azure AD Vorbereitung: Sicherstellen, dass ein Azure AD Tenant vorhanden ist und die on-premises Benutzer synchronisiert sind (via Azure AD Connect), damit dieselben Anmeldedaten genutzt werden können. Falls noch nicht erfolgt, Azure AD Connect installieren und konfigurieren (User Sync, Passwort-Hash oder Pass-Through Auth).
• Application Proxy aktivieren: In Azure AD das Feature aktivieren (das geht per Portal, falls P1-Lizenz vorliegt).
• Connector Installation: Auf einem Domänenserver (idealerweise kein DC, aber ein Server mit Zugang zum SharePoint) den App Proxy Connector installieren. Der Connector verbindet sich beim Einrichten mit dem Azure AD (erfordert Admin-Anmeldung) und registriert sich. Für Hochverfügbarkeit kann man mehrere Connectoren installieren (in eine Connector-Gruppe).
• App erstellen: Im Azure AD Portal unter Enterprise Applications eine neue Application Proxy App anlegen. Dort die interne URL der SharePoint-Seite angeben (z.B. https://sharepoint.intern) und eine externe URL definieren (standardmäßig *.msappproxy.net Domäne, optional custom Domain mit CNAME). Die Pre-Auth-Methode auf „Azure Active Directory“ setzen, damit AAD-Login erzwungen wird.
• SSO konfigurieren: Für integriertes SSO auf SharePoint wählt man Kerberos Constrained Delegation in den App Proxy Einstellungen. Man muss hier den SPN der SharePoint-Dienstanwendung angeben (z.B. HTTP/sharepoint.intern) und ein Servicekonto definieren, unter dem der Connector delegieren darf. Dieses Konto sollte in AD so konfiguriert sein, dass Trust for Delegation zum SPN erlaubt ist. Alternativ kann man den Computeraccount des Connector-Servers entsprechend berechtigen. Microsoft-Dokumentation führt durch diesen Schritt.
• Conditional Access/MFA Policy: Erstellen einer Azure AD Conditional Access Policy, welche für diese Enterprise App (SharePoint App Proxy) gilt und MFA erzwingt. Man kann auch einstellen „Zugriff nur für Hybrid AAD-joined Geräte“ etc., je nach Sicherheitsbedarf. Typischerweise reicht MFA-Pflicht für alle User dieser App.
• Testing: Extern die neue URL aufrufen – man sollte die Microsoft Azure AD Anmeldeseite sehen, sich authentifizieren, dann je nach Policy eine MFA-Eingabe leisten, und schließlich sollte die SharePoint-Seite erscheinen. Interne Benutzer sollten weiterhin direkt per alte URL ohne Umleitung zugreifen können.
• Benutzer-Schulung: Die externe URL (falls anders als intern) muss den Nutzern kommuniziert werden. Ggf. kann man DNS so einstellen, dass externe und interne Namen gleich sind – dann nutzen interne aber trotzdem indirekt den Proxy (was evtl. nicht gewollt ist, man könnte mit Split DNS arbeiten). Manche Unternehmen geben bewusst unterschiedliche URLs (z.B. sharepoint.ext-firma.de für extern via Proxy), um intern nicht über die Cloud zu gehen.

Der Implementierungsaufwand ist insgesamt überschaubar, vor allem wenn Azure AD im Unternehmen bereits im Einsatz ist. Oft kann innerhalb 1-2 Tagen ein erfahrener Cloud-Admin den Proxy einrichten. Schwieriger sind evtl. Sonderfälle: KCD muss korrekt klappen – hier passieren häufig Konfigurationsfehler (SPN falsch, Delegation nicht richtig gesetzt). Aber mit Standardwerten funktioniert es meist. Ein weiterer Aufwandspunkt: Office-Integration testen – neuere Office-Versionen erkennen, dass die URL extern via AAD abgesichert ist, und fordern entsprechend einen AAD-Login (was dank SSO mit dem Office-Account oft automatisch passiert). Hier kann es zu Fragen kommen, was man durch Dokumentation klären sollte.

Vorteile:

• Keine eigene DMZ-Infrastruktur notwendig: Man benötigt weder einen Reverse-Proxy-Server noch Load-Balancer on-premises, um SharePoint sicher zu veröffentlichen. Der Dienst in Azure übernimmt das Frontend. Das vereinfacht die Architektur deutlich – weniger Server, weniger Angriffsfläche im eigenen Netzwerk.
• Schnelle, cloud-basierte Skalierung und Verfügbarkeit: Azure AD Application Proxy ist ein Cloud-Dienst mit hoher Verfügbarkeit. Microsoft stellt sicher, dass genügend Kapazität und Redundanz vorhanden ist. Lastspitzen werden in der Cloud abgefangen. Für das eigene Rechenzentrum fällt nur der Connector an, der wenig State hält und notfalls schnell ersetzbar ist. Damit erreicht man ohne viel Eigenaufwand eine professionelle externe Anbindung.
• Integration in Azure AD Ökosystem: Die Authentifizierung erfolgt via Azure AD – Nutzer profitieren von einem einheitlichen Login, den sie ggf. schon von Office 365 kennen. Single Sign-On ist möglich, wenn Benutzer z.B. bereits an Teams/Outlook angemeldet sind (Azure AD erkennt vorhandene Session). Außerdem stehen alle Azure AD Features zur Verfügung: Conditional Access, Geoblocking, Gerätestatus-Prüfung, Passwortlos-Optionen, MFA-Methodewahl etc. Die Sicherheitsrichtlinien sind damit sehr fein steuerbar und zukunftssicher (neue MFA-Methoden oder Policies können sofort genutzt werden).
• Sehr gute Unterstützung mobiler und externer Szenarien: Azure AD ist auf moderne Authentifizierung optimiert. Die Lösung harmoniert gut mit Mobilgeräten, verschiedenen Browsern, etc. Es gibt keine Abhängigkeit von Domänenmitgliedschaft für externe Geräte. Auch Gastbenutzer (Externe Identitäten) lassen sich via Azure B2B einbinden, falls z.B. Partner zugreifen sollen – diese könnte man ebenfalls per MFA erzwingen.
• Geringerer Verwaltungsaufwand: Da wenige eigene Komponenten im Spiel sind, reduziert sich die Wartung. Kein dedizierter Server, der gepatcht werden muss (nur der Connector, der automatisch Updates erhält). Azure AD Policies sind meist schon im Einsatz; man fügt nur eine weitere Anwendung hinzu. Monitoring ist über Azure AD Logging zentral möglich (Anmeldeprotokolle).
• Sicherheitsvorteile durch Microsoft-Cloud: Microsoft investiert stark in die Sicherheit von Azure AD. Features wie Identity Protection (risikobasierte MFA) oder laufende Verbesserungen (Smart Lockout, Passwortschutz etc.) kommen direkt der Anmeldung zugute. Zudem kommunizieren die Connectoren ausschließlich ausgehend (Outbound) zu Azure, d.h. keine eingehenden Ports müssen ins eigene Netz geöffnet werden – die Verbindung wird von innen initiiert. Das minimiert das Risiko eines direkten Angriffs auf die Infrastruktur.
• Kein ADFS notwendig: Im Gegensatz zu Lösung 2 benötigt dieser Ansatz kein ADFS. Damit entfallen die komplizierte Föderationsserver-Infrastruktur und deren Pflege. Wer bereits Azure AD für O365 nutzt, kann denselben Identity-Service nun auch für SharePoint verwenden – konsolidiertes Identity Management.
• Keine zusätzlichen Kosten, falls Lizenzen vorhanden: Sollte die Organisation bereits Azure AD Premium für ihre Mitarbeiter lizenziert haben (etwa durch Microsoft 365 E3/E5), entstehen für den App-Proxy keine neuen Lizenzkosten. Dann ist diese Lösung kosteneffizient, da die vorhandenen Cloud-Abos mitgenutzt werden.

Nachteile:

• Abhängigkeit von Cloud und Internet: Die Verfügbarkeit der SharePoint-Anmeldung hängt von Azure AD ab. Bei einem Ausfall des Azure-Services oder bei Internetproblemen ist kein externer Zugriff möglich. Während Microsoft sehr zuverlässige Dienste bietet, ist man doch von deren Infrastruktur abhängig. Für Unternehmen mit strikter On-Prem-Philosophie kann dies ein Hinderungsgrund sein.
• Azure AD Premium Lizenz erforderlich: Ohne vorhandene P1-Lizenzen muss für alle betreffenden Nutzer ein Premium-Plan erworben werden, da der App-Proxy ein P1-Feature ist. Dies kann teuer werden, insbesondere wenn nur für diesen Anwendungsfall die Lizenzen angeschafft würden. Zwar gibt es oft einen Business Case, Azure AD auch anderweitig zu nutzen – dennoch sind es laufende Kosten pro Nutzer, die beim On-Premises-LoadBalancer-Ansatz nicht in dieser Form anfallen.
• Komplexität bei bestimmten Anwendungen: Der App-Proxy eignet sich sehr gut für Standard-Webanwendungen. Jedoch bei komplexen oder sehr latenzsensiblen Anwendungen kann es Einschränkungen geben. Microsoft selbst weist darauf hin, dass für einige Multi-Geo oder sehr komplex verteilte Anwendungen ein traditioneller Load-Balancer eventuell weiter nötig ist. In Bezug auf SharePoint kann das relevant werden, wenn z.B. große Datei-Uploads, spezielle Integrationen oder hohe Performance-Ansprüche bestehen. Der Proxy leitet Traffic zwar effizient weiter, aber er fügt eine gewisse Latenz hinzu (Daten gehen über Azure). In Praxis sind diese Verzögerungen gering, doch bei großen Dateien oder vielen kleinen Requests kann es spürbar sein.
• KCD-Konfiguration und Einschränkungen: Die Einrichtung der Kerberos-Delegierung erfordert wie beim KEMP-Ansatz einiges an Feintuning. Fehler führen dazu, dass evtl. keine automatische Anmeldung erfolgt. Außerdem muss der Connector die Anwendung unter einem festen SPN ansprechen – bei komplexen SharePoint-Farmen mit mehreren URLs oder Nicht-Windows-Services könnte das problematisch sein. Der App-Proxy unterstützt zudem WebSockets und NTLM in neueren Versionen, aber früher gab es hier Limitationen. Man sollte prüfen, ob alle benötigten SharePoint-Funktionen über den Proxy laufen (z.B. Event-Empfänger, die von SharePoint zurück ins Internet callen, funktionieren nicht, da Proxy nur eingehende Verbindungen abdeckt).
• Benutzer- und Supportaufwand: Benutzer müssen ggf. eine neue URL verwenden und sich mit Azure AD anmelden. Das ist zwar ähnlich wie bei Office 365, aber es erfordert eine gewisse Kommunikation und Schulung (z.B. Nutzung der Authenticator-App). Der IT-Helpdesk muss auf MFA-bezogene Anfragen eingestellt sein (z.B. Hilfe bei Gerätwechsel für MFA, Entsperren bei falschen MFA-Eingaben etc.). Dieser Aufwand ist nicht riesig, aber vorhanden.
• Feature-Parität zu ADFS (falls relevant): Sollte das Unternehmen sehr spezifische ADFS-Funktionen genutzt haben (z.B. benutzerdefinierte Claim Rules, spezielle Token-Layouts), lassen sich diese nicht 1:1 auf Azure AD abbilden. Azure AD bietet weniger Möglichkeiten zur Anpassung der Token für SharePoint. Allerdings sind solche speziellen Anforderungen im SharePoint-Kontext selten.

Lösung 4: Externer Identity Provider (z.B. Okta, Ping Identity) mit MFA

Funktionsweise und technische Umsetzung: Bei diesem Ansatz wird anstelle von Microsoft-Lösungen ein externer Identity-Provider (IdP) eingesetzt – typischerweise ein cloudbasierter Dienst wie Okta, Ping Identity, OneLogin, miniOrange oder ähnliches. Diese Dienste bieten Single Sign-On (SSO) und MFA für verschiedenste Anwendungen an. Die Idee ist, SharePoint Server als vertrauende Anwendung (Service Provider) zu konfigurieren, die die Authentifizierung an den externen IdP delegiert. Technisch läuft es über SAML 2.0 oder WS-Federation: Wenn ein Benutzer auf SharePoint zugreift, wird er zur Anmeldeseite des externen IdP umgeleitet. Dort meldet er sich mit seinen Zugangsdaten an (meistens ebenfalls AD-Konto, aber über den IdP vermittelt) und muss eine definierte MFA-Prozedur durchlaufen. Nach erfolgreicher Authentifizierung stellt der IdP ein SAML-Token aus, das an SharePoint zurückgesendet wird. SharePoint prüft das Token (über den in SharePoint konfigurierten Vertrauensstellungs-Zertifikatsfingerabdruck) und loggt den Benutzer mit den im Token enthaltenen Claims ein.

Damit das funktioniert, muss der IdP Zugang zu den Benutzerkonten haben. Meistens werden die AD-Konten ins IdP-System synchronisiert (z.B. mittels eines Okta AD Agents oder via LDAP-Abfrage). Alternativ können die Benutzer im IdP separat angelegt werden, was aber aufwändiger in der Pflege wäre. In der Regel nutzt man also die bestehende AD-Identität, aber die Authentifizierung geschieht über den IdP. Der IdP kann selbst wiederum AD-Passwort prüfen (via Agent) oder man integriert einen AD-Login als ersten Faktor. In jedem Fall hat der IdP die Kontrolle über die MFA: Er bietet meist zahlreiche zweite Faktoren an (TOTP-Apps, Push-Benachrichtigungen, U2F-Keys, SMS, E-Mail OTP, etc.), je nach Produkt.

Für externe vs. interne Zugriffe gibt es zwei mögliche Herangehensweisen:

1. SharePoint mit gemischten Zonen: Man könnte SharePoint so konfigurieren, dass externe Nutzer über eine Erweiterte Zone mit SAML-Auth (IdP) kommen, während interne Nutzer weiterhin die Standardzone mit Windows-Auth nutzen. So würden intern keine Änderungen passieren, extern jedoch die IdP-Anmeldung greifen. Diese Trennung ist möglich, erfordert aber doppelte Konfiguration der Webapp-Zugriffsregeln und kann verwirrend sein, wenn ein interner Nutzer versehentlich die externe URL nutzt (dann SAML-Login).
2. Einheitliche Authentifizierung für alle, mit IdP-Policy: Man kann alle Zugriffe auf den IdP lenken und dort über Netzwerkstandort-Regeln steuern, ob MFA erzwungen wird. Viele IdPs (z.B. Okta) unterstützen Policies ala „wenn IP aus Firmenrange, dann kein MFA, ansonsten MFA erforderlich“. So hätte man eine einzige Login-Methode: interne Benutzer werden beim IdP via IWA (Integrated Windows) oder schlichtem Login ohne MFA authentifiziert, externe zusätzlich mit MFA. Allerdings müssen dafür interne Benutzer auch die IdP-Schiene durchlaufen – was bedeutet, sie sehen ggf. einen anderen Login-Screen als gewohnt und es muss Single Sign-On intern klappen, sonst wäre es lästig.
   In der Praxis würde man vermutlich den ersten Ansatz wählen: internes Arbeiten wie bisher (AD direkt), extern via IdP. Daher liegt der Fokus der IdP-Lösung vor allem auf dem externen Zugang mit MFA.

Um SharePoint an einen IdP anzubinden, sind folgende Schritte nötig:

• Trusted Identity Provider in SharePoint einrichten: Ähnlich wie bei ADFS muss in SharePoint per PowerShell ein neuer TrustedIdentityTokenIssuer angelegt werden, mit dem Zertifikat des IdP und den Endpunkten (SAML Redirect URL, Logout URL etc.). SharePoint 2019/Subscription Edition unterstützt SAML 2.0 IdPs im SP-Lite Profil, was gängige IdPs wie Okta kompatibel macht. Man muss definieren, welcher Claim den Benutzer repräsentiert (z.B. UPN oder E-Mail).
• IdP-seitig SharePoint App konfigurieren: Im IdP wird eine neue SAML-App angelegt. Man trägt die Assertion Consumer URL (SharePoint Vertrauensstellungs-Endpunkt) ein und konfiguriert die Claims, die SharePoint erwartet (z.B. UPN als NameID, vielleicht zusätzlich Gruppen in einem Claim falls benötigt). Okta & Co haben oft vordefinierte Konfigurationen für SharePoint On-Prem. Teilweise muss ein People Picker Plugin installiert werden (z.B. stellt Okta ein Plugin bereit, damit SharePoint-People-Picker auch Okta-Benutzer auflösen kann).
• Synchronisation/Provisionierung: Ein IdP wie Okta wird in der Regel mit AD verbunden, um die Benutzer (und Gruppen) zu importieren. Diese müssen im IdP vorhanden sein, sonst können sie sich nicht anmelden. Der Abgleich kann regelmäßig erfolgen (Okta-Agent synchronisiert alle 15 min z.B.), oder man belässt es beim Just-in-Time Provisioning bei Erstanmeldung (dann taucht der User im IdP auf).
• MFA im IdP konfigurieren: Festlegen, welche Methoden erlaubt sind (z.B. TOTP-App, SMS) und ob es zwangsweise aktiviert ist. Meist lassen sich Policies erstellen, wann MFA gefordert wird (z.B. immer bei dieser Anwendung für externe Zugriffe).
• Test: Anmeldeablauf mit einem Testuser durchführen und prüfen, ob die Token von IdP -> SP korrekt akzeptiert werden und der Benutzer die erwarteten Berechtigungen hat. Ggf. muss man in SharePoint die Benutzerprofile und Berechtigungen an die neuen Claims-Benutzer anpassen. Falls bisher AD-Konten direkt Berechtigungen hatten, erscheinen dieselben Personen nun u.U. als neue Nutzer mit dem Identity-Provider-Claim (z.B. i:0#.w|okta\). Man kann bestehende Berechtigungen migrieren durch STS-Convert, oder man vergibt neu.

Kosten: Die Kosten hängen stark vom gewählten Anbieter ab:

• Okta als Beispiel hat Lizenzgebühren pro Nutzer, typischerweise im Bereich ~ 6 \$ pro User/Monat für die MFA+SSO Funktionen. Oftmals verkaufen die IdPs Pakete (z.B. Okta MFA einzeln etwas günstiger, Okta Identity Cloud mit allem etwas teurer). Bei 100 Nutzern wären grob 600 \$ pro Monat fällig. Ping Identity und andere haben ähnliche Preismodelle, teils gestaffelt nach Benutzerzahl. Einige Anbieter (miniOrange, Rublon etc.) werben mit günstigeren Tarifen (z.B. ab ~2–3 \$ pro Nutzer), was aber oft bei höheren Nutzerzahlen oder eingeschränktem Funktionsumfang der Fall ist.
• Infrastruktur: Wenn der IdP rein cloudbasiert ist (Okta, OneLogin SaaS), braucht man kaum eigene Infrastruktur. Lediglich ggf. ein Sync-Agent auf einem AD-Server (der minimalen Ressourcenverbrauch hat) ist nötig. Sollte man einen selbst gehosteten IdP (wie Keycloak oder PingFederate On-Prem) einsetzen, entstehen wieder Server- und Betriebskosten analog zu ADFS, was den Vorteil mindert. Meistens nutzt man daher die SaaS-Variante.
• Betriebskosten: Die IdP-Lösung ist in der Regel ein Abonnement (jährlich oder monatlich zahlbar) – also laufende Kosten. Positiv: der Anbieter kümmert sich um Updates, Sicherheitspatches usw. Intern fallen dafür weniger Administrationsstunden für Pflege an, außer für die Integration mit AD und das Zuweisen neuer Benutzer/Rollen.
• Implementierungskosten: Je nach Komplexität der Umgebung könnten Dienstleisterkosten anfallen, um die IdP-Integration sauber einzurichten, vor allem wenn man selbst wenig Erfahrung damit hat. Einige IdP-Anbieter bieten aber relativ intuitive Admin-Oberflächen, sodass es auch intern gestemmt werden kann. Trotzdem sollte man Schulung/Know-how aufbauen, was indirekt auch ein Kostenfaktor (zeitlich) ist.

Implementierungsaufwand: Der Aufwand ist mittel bis hoch, abhängig von vorhandener IAM-Infrastruktur:

• Wenn das Unternehmen bereits einen IdP wie Okta/Ping im Einsatz hat (z.B. für andere Anwendungen), dann ist der Mehraufwand für SharePoint gering – es ist nur eine weitere App-Integration. In dem Fall würde man in 1-2 Tagen alles konfigurieren und testen können.
• Wenn noch kein externer IdP genutzt wird, muss zunächst der IdP selbst eingeführt werden. Das bedeutet: Administratorkonten einrichten, AD-Anbindung konfigurieren, Policies definieren, eventuell Benutzer schulen für neue Authenticator-Apps etc. Das skaliert zum Projekt, das über SharePoint hinausgeht (Stichwort SSO-Initiative).
• Speziell für SharePoint: Die Konfiguration von SAML in SharePoint ist nicht extrem kompliziert, aber Fehler wirken sich sofort auf die Zugriffsmöglichkeit aus. Ein häufiger Stolperstein ist das Benutzeridentitäten-Mapping. SharePoint behandelt Claims-Benutzer als separate Identitäten. Das heißt, ein AD-User domäne\user ist für SharePoint ein anderer Principal als user@firma.com über SAML, selbst wenn es dieselbe Person ist. Ohne Zusatzmaßnahmen hat dieser nach Umstellung auf SAML z.B. keine Berechtigungen, bis man ihn hinzufügt. Um das zu vermeiden, kann man versuchen, den SAML-Claim so zu gestalten, dass er dem AD-Account entspricht (z.B. exact UPN match). In SharePoint Subscription Edition gibt es Optionen für Alternate ID (z.B. man könnte den ImmutableID nutzen). Solche Feinheiten erhöhen den Konfigurationsaufwand und verlangen Tests.
• People Picker und Benutzerprofile: Damit Administratoren und Site Owner weiterhin Nutzer einfach berechtigen können, sollte der People Picker idealerweise IdP-Benutzer auflösen können. Okta stellt z.B. ein People Picker Tool zur Verfügung, welches man installieren muss. Ohne dieses sieht man nur den Claim-Wert und kann nicht komfortabel nach Namen suchen. Dieser zusätzliche Installations-/Konfigurationsschritt muss eingeplant werden.
• Anpassung der Login-Seite (optional): SharePoint’s Standard-FBA-Auswahlseite lässt sich anpassen, z.B. um dem Benutzer das IdP-Login freundlich zu benennen (statt „Vertrauensstellungsanbieter 1“ anzuzeigen). Dazu können Änderungen in der web.config oder via Powershell (Set-SPAuthenticationProvider) vorgenommen werden. Ist kein Muss, aber für Usability ratsam.
• Testing und Pilot: Gerade weil es ein nicht-Microsoft IdP ist, sollte umfangreich getestet werden: Authentifizierung, Abmeldung, Zeitüberschreitungen, Funktion in Office-Clients, Mobilzugriff, etc. Exotische Dinge wie Office Web Apps Integration oder Such-Crawler (der evtl. auch Auth braucht) müssen geprüft werden. Möglicherweise benötigt der Search Crawler weiterhin NTLM-Zugang, weshalb man die Defaultzone evtl. auf NTLM belässt und nur extern die SAML-Zone nutzt.
• Betrieb: Nach Inbetriebnahme muss die IT die Benutzerverwaltung im IdP handhaben (wobei vieles durch AD-Sync automatisiert sein kann). Wenn Mitarbeiter ausscheiden, muss sichergestellt sein, dass sie im IdP keine Zugriffsrechte mehr haben (idR durch AD-Deaktivierung, die IdP Sync erkennt). Zudem sollte MFA-Policy regelmäßig überprüft werden (z.B. neue MFA-Geräte registrieren, verlorene Geräte entfernen).

Zusammengefasst ist der Implementierungsaufwand höher, wenn der IdP neu eingeführt wird. Bei bestehendem IdP mittelhoch, da SharePoint-Integration einige besondere Schritte erfordert, aber machbar ist.

Vorteile:

• Umfangreiche MFA-Methoden und Usability: Externe IdPs bieten oft eine breite Palette an MFA-Optionen out-of-the-box (OTP-App, Push, SMS, Telefonanruf, E-Mail-Code, Sicherheitsfragen, biometrisch via App etc.). Dies ermöglicht es, die für die Benutzer bequemste und zugleich sichere Methode zu wählen. Einige IdPs unterstützen auch Adaptive MFA – z.B. nur bei riskanten Logins wird MFA verlangt. Die Benutzeroberflächen sind meist modern und benutzerfreundlich gestaltet, was die Akzeptanz erhöhen kann.
• Zentrale Identity-Lösung für viele Anwendungen: Hat ein Unternehmen mehrere Anwendungen (on-prem und Cloud), die MFA/SSO benötigen, kann ein dedizierter IdP eine konsolidierte Lösung darstellen. Benutzer hätten einen zentralen Login-Portal für alles. Für die IT ergibt sich eine einheitliche Verwaltung von Zugriffsrechten und Policies über alle angebundenen Apps.
• Plattformunabhängigkeit und offene Standards: Lösungen wie Okta & Co unterstützen neben Microsoft AD auch viele andere Verzeichnisse und Standards. Falls irgendwann SharePoint Online oder andere Cloudservices integriert werden sollen, kann der IdP diese ebenfalls einbinden. Auch Nicht-Microsoft-Systeme (z.B. Linux-basierte Webapps) lassen sich so ins SSO holen. Der IdP fungiert als universelle Authentifizierungsinstanz.
• Entlastung interner Ressourcen: Da der IdP meist als Cloud-Service läuft, übernimmt der Anbieter das Skalieren, Updaten, Absichern der Auth-Infrastruktur. Die internen IT-Ressourcen können sich auf die Konfiguration beschränken, während Verfügbarkeit und Security-Monitoring weitgehend vom Anbieter garantiert werden. Im Idealfall erhöht das die Gesamtsicherheit (professionell gewarteter Dienst).
• Policy-Rich und zukunftssicher: Viele IdPs haben Features wie Conditional Access, Geolokation-Checks, Device Posture im Angebot, ähnlich Azure AD. Manche bieten innovative Funktionen schneller an als traditionelle Systeme – z.B. Okta FastPass (eine Art Passwordless via Device Trust) oder Integration mit Kontextinformationen. Für Unternehmen mit hohen Sicherheitsanforderungen kann das attraktiv sein.
• Keine lokale Hardware nötig: Abgesehen vom evtl. Sync-Agent benötigt man keine zusätzliche Hardware oder VMs vor Ort. Der Start ist relativ schlank möglich – Registrieren beim IdP-Dienst, konfigurieren, fertig. Gerade für kleinere Unternehmen ohne große IT-Infrastruktur kann das ein einfacher Weg sein, MFA einzuführen.
• Umgehung von ADFS-Limitierungen: Externe IdPs können ADFS komplett ersetzen. Falls ADFS nicht gewünscht ist (wie hier), liefert ein IdP dennoch die benötigte Föderationsfunktion. In manchen Fällen sind IdPs auch flexibler als ADFS beim Benutzerstore – z.B. können sie externe Identitäten oder soziale Logins einbeziehen, falls das je relevant wird (z.B. Partnerlogin über Google/Facebook Accounts, eher unwichtig für internen SharePoint, aber möglich).

Nachteile:

• Laufende Lizenzkosten pro Benutzer: Die IdP-Lösungen sind kostspielig, wenn man sie rein für einen einzigen Anwendungsfall betrachtet. Jeden Monat summieren sich die Gebühren, was über Jahre deutlich teurer als ein einmaliger Kauf eines Appliances sein kann. Beispielsweise ~6 \$/Benutzer/Monat für Okta ergibt auf 3 Jahre für 100 Nutzer über 20.000 \$ – dafür könnte man auch Hardware und eigene Lösungen betreiben. Ohne vorhandenes breiteres Nutzungsszenario sind diese Kosten schwer zu rechtfertigen.
• Integration in vorhandene Systeme komplex: Die SharePoint-Integration ist nicht trivial, wie oben beschrieben. Aber auch die AD-Integration und eventuell weitere Legacy-Systeme erfordern Aufwand. Oft müssen zusätzliche Softwarekomponenten installiert werden (Sync-Agents, Plugins). Gerade in reinen Microsoft-Umgebungen stellt ein Fremd-IdP ein Stück Fremdtechnologie dar, die man beherrschen muss. Probleme können auftreten, die außerhalb der üblichen MS-Support-Domäne liegen.
• Externe Abhängigkeit und Datenschutz: Man gibt die Benutzerauthentifizierung in die Hände eines Drittanbieters. Das bedeutet, dass im Falle von Cloud-IdPs die Anmeldeinformationen (Benutzernamen, evtl. Passwort-Hashes oder Cloud-Passwörter) und die zweiten Faktoren bei einem externen Dienst liegen. Dies kann ein Sicherheits- und Compliance-Risiko darstellen (Stichwort DSGVO, wo liegen die Daten? Ist der Anbieter vertrauenswürdig?). Zudem vergrößert es die Angriffsfläche – ein kompromittierter IdP würde alle angeschlossenen Dienste betreffen.
• Zusätzliche Login-Ebene für interne Nutzer: Sofern man alle Zugriffe via IdP laufen lässt, müssen sich auch interne Benutzer ggf. an einem neuen System anmelden. Das könnte zu Gewöhnungsproblemen führen. Zwar lässt sich SSO z.B. via IWA-Integration lösen (Okta Access Gateway kann z.B. interne Logins transparent machen), aber das ist wiederum ein On-Premises-Komponente mehr. Alternativ, wie erwähnt, kann man intern bei Windows-Auth bleiben, aber dann hat man zwei separate Authentifizierungssysteme parallel im SharePoint (AD und SAML), was administrativ herausfordernd sein kann.
• Benutzerverwaltung doppelt: Trotz AD-Synchronisation hat man faktisch zwei Benutzerverzeichnisse – AD und IdP. Sollte es mal zu Abweichungen kommen (User nicht synchronisiert, Gruppe nicht korrekt übernommen), kann es Authentifizierungsprobleme geben. Das Management von Gruppen für Berechtigungen könnte sich aufspalten: Man kann zwar in SAML-Token AD-Gruppen übergeben, aber in vielen IdPs muss man das explizit mappen. Ohne saubere Prozesse besteht hier Fehlerrisiko.
• Support und Know-how: Nicht jeder IT-Administrator ist mit den externen IdPs vertraut. Die internen Helpdesk-Mitarbeiter müssen geschult werden, um Probleme bei der Anmeldung über diesen Drittanbieter zu unterstützen. Bei Störungen ist man auf den Support des IdP angewiesen – man hat weniger „Eigenkontrolle“ als bei einer on-prem Lösung. Gerade bei kleineren Anbietern könnte der Support und die langfristige Verlässlichkeit ein Unsicherheitsfaktor sein.
• Vendor Lock-in: Hat man einmal alle Apps in einem IdP integriert, wird man abhängig von diesem Anbieter. Ein späterer Wechsel (z.B. zu einem anderen IdP oder zurück zu einer MS-Lösung) kann sehr aufwändig sein, da man alle Anwendungen und Benutzer umziehen muss. Dieses Risiko sollte bedacht werden.

Lösung 5: On-Premises MFA-Plugin (Beispiel: UserLock)

Funktionsweise und technische Umsetzung: Bei dieser Lösung wird keine vorgeschaltete Proxy-Instanz und kein externer Dienst genutzt, sondern die MFA wird direkt auf den SharePoint Webservern durch ein lokales Sicherheitsmodul erzwungen. Ein Beispiel dafür ist UserLock der Firma IS Decisions (stellvertretend für Ansätze wie auch RSA Web-Agents oder DUO-Integrationen für IIS). Die Funktionsweise von UserLock: Man installiert auf jedem SharePoint Web-Frontserver einen Agenten, der sich in den IIS-Authentifizierungsprozess einklinkt. Wenn nun ein Benutzer sich an SharePoint anmeldet (sei es per integrierter Windows-Auth oder Forms-Auth, je nach Setup), interceptiert der UserLock-Agent diesen Vorgang. Konkret bedeutet das: Bei der ersten Authentifizierung prüft der Agent die eingegebenen AD-Anmeldeinformationen gegenüber dem Active Directory – das geschieht lokal, sodass der erste Faktor wie gewohnt das AD-Kennwort bleibt. Ist das Passwort korrekt, stoppt der Agent den Loginfluss und fordert einen zweiten Faktor an. UserLock unterstützt verschiedene MFA-Methoden: z.B. TOTP-Codes via Authenticator-App, Push-Benachrichtigungen an eine mobile App, U2F/FIDO2-Token (YubiKey), SMS oder E-Mail OTP, usw.. Diese Methoden können dem Benutzer zur Auswahl gestellt werden oder durch die Richtlinie vorgegeben sein. Der Benutzer muss dann z.B. den in seiner Authenticator-App generierten Code eintippen oder eine Push-Anfrage bestätigen. Der Agent kommuniziert dabei mit einem zentralen UserLock-Server, der die Gültigkeit des zweiten Faktors überprüft und den Status der Anmeldung protokolliert. Wenn die MFA-Prüfung erfolgreich ist, lässt der UserLock-Agent den Loginvorgang passieren und der Benutzer erhält Zugriff auf SharePoint. Aus Sicht von SharePoint ist es nach wie vor eine „normale“ Windows-Authentifizierung, weil der Agent diese ja initial durchgeführt hat, bevor er den zweiten Faktor abfragte.

Im Ergebnis hat man also MFA auf der SharePoint-Website selbst, ohne Änderung der Anmelde-URL oder Umleitung zu externen Diensten. Wichtig ist, dass der UserLock-Agent natürlich nur jene Anmeldungen abfängt, die über IIS laufen. Für direkte Datenbank-Zugriffe oder andere Kanäle (was bei SharePoint aber selten relevant ist) würde er nicht greifen. Die Lösung sichert also genau die Web-Logons ab. Für externe vs. interne Zugriffe kann man mit UserLock Richtlinien definieren, z.B. basierend auf Benutzergruppen, Tageszeiten oder auch IP-Bereichen. So lässt sich einstellen, dass Benutzer, die sich von außerhalb des Firmennetzes anmelden, stets einen zweiten Faktor brauchen, während bei LAN-internen Logons ggf. kein MFA erzwungen wird (oder eine einfachere Methode). Diese Feinsteuerung muss man in der UserLock-Policy hinterlegen. Damit kann auch hier das Szenario „MFA nur extern“ abgebildet werden, indem interne Subnets als vertrauenswürdig markiert werden.

UserLock ist exemplarisch; andere Produkte funktionieren ähnlich: RSA SecurID hatte z.B. ein Web-Agent, der bei IIS eine RSA MFA einfädelte. Duo Security bietet ein Web SDK, das man in IIS-Seiten integrieren kann. Allerdings gibt es kein offizielles Duo-Plugin für SharePoint on-prem, soweit bekannt – man müsste es selbst implementieren. Daher ist UserLock ein gut dokumentiertes Beispiel für Agent-basierte MFA.

Kosten: UserLock wird als kommerzielles Softwareprodukt lizenziert, typischerweise auf Abonnement-Basis pro Benutzer. Laut Hersteller beginnt die Preisgestaltung bei etwa \$2 pro Benutzer/Monat (bei jährlicher Abrechnung). Je nach Volumen kann der Preis sinken. Beispielsweise gibt es Einstiegspakete ab ~\$595 jährlich für kleinere Umgebungen. Verglichen mit Cloud-IdPs oder Azure AD ist das preislich relativ günstig – es ist auf das Nötige fokussiert (MFA für AD-Logins). Selbst inklusive verschiedener Add-ons bleibt der Preis pro Nutzer oft unter dem der großen Cloudanbieter.

Weitere Kostenpunkte:

• Server-Infrastruktur: Es wird ein zentraler UserLock-Server benötigt, der die Anfragen der Agents koordiniert und die Management-Oberfläche bereitstellt. Dieser kann auf einer vorhandenen Windows-VM laufen. Seine Anforderungen sind nicht hoch (ein paar vCPU/RAM, je nach Anzahl Logins). Dennoch muss man dafür eine VM + Windows-OS bereitstellen, falls nicht ohnehin vorhanden. Der Server kann aber auf einer bestehenden Maschine mitlaufen, sofern die Performance es zulässt.
• Agents auf SharePoint-Servern: Die Installation der Agents ist im Lizenzpreis inbegriffen, aber zu bedenken: auf jedem WFE-Server muss der Agent-Service laufen. Ressourcenverbrauch ist gering, jedoch ist sicherzustellen, dass Agent-Updates ausgerollt werden usw. Diese Verteilung ist aber in der Admin-Konsole steuerbar.
• Betriebskosten: Da es on-prem Software ist, fallen Wartungsaufwände an: Updates einspielen (UserLock bringt regelmäßig Verbesserungen heraus, z.B. Unterstützung neuer MFA-Methoden), Überwachung der Server-Verfügbarkeit, etc. Technischer Support ist bei aktiver Lizenz inbegriffen. Ein großer laufender Aufwand entsteht nicht, aber man sollte die Software pflegen wie jede Security-Lösung.
• SMS/Telefon Gebühren: Falls man MFA-Methoden wie SMS-Tokens nutzen will, könnten Gebühren für den SMS-Versand entstehen (UserLock selbst versendet glaube ich via E-Mail/SMS-Gateway des Kunden). In der Regel setzt man aber lieber App-basiertes OTP ein, was keine variablen Kosten verursacht.

Implementierungsaufwand:

• Installation des UserLock-Servers: Zunächst wird der zentrale Server installiert. Das geht relativ schnell über einen Setup-Assistenten. Man bindet ihn an die AD-Domäne an (die Software nutzt AD als Backend, was ja der Vorteil ist) und konfiguriert die Basis (z.B. welche OUs/Benutzer überwacht werden sollen). Der Server beinhaltet auch die Verwaltungskonsole.
• Deployment der Agents: Auf jedem SharePoint-IIS-Server wird der UserLock Agent installiert. Das kann remote von der Konsole aus angestoßen werden oder manuell via MSI. Der Agent registriert sich dann beim Server.
• Konfiguration der Richtlinien: In der UserLock-Konsole definiert man die MFA-Policy: Welche Benutzer/Gruppen müssen MFA machen, welche Methoden sind erlaubt, gilt es ständig oder nur extern etc. Hier kann man auch festlegen, ob MFA bei jeder Anmeldung gefordert wird oder z.B. pro Gerät einmal und dann X Stunden remembered (Gerätezufriedenheit gibt es vielleicht in gewissem Umfang).
• Benutzereinrichtung: Benutzer müssen für die MFA vorbereitet werden. Z.B. wenn man TOTP-Apps nutzt, muss jeder Benutzer einmal einen QR-Code scannen (den kann UserLock generieren) und einen initialen Code eingeben. Alternativ bei Push muss der Benutzer mit der App des Herstellers verknüpft sein. UserLock bietet administratives Hinzufügen von Token an, oder Self-Enrollment-Portale. Dieser Prozess muss begleitet werden, damit alle Benutzer ihre MFA-Option haben. Zumindest Kommunikation der Anleitung ist nötig.
• Testing: Mit einem Test-User die Anmeldung durchspielen: Auf SharePoint zugreifen -> AD-Passwort eingeben -> sollte MFA-Feld erscheinen -> Code eingeben -> Zugriff erhalten. Auch Fehlversuche testen, um zu sehen wie Sperren gehandhabt werden. Ebenso testen, dass interne Logins (wenn exempted) ohne MFA durchgehen.
• Rollout: Die Software kann schrittweise ausgerollt werden, z.B. erst eine kleine Pilot-Gruppe in die MFA-Pflicht nehmen, dann ausweiten. Da es AD-integriert ist, kann man z.B. gruppenbasiert steuern.
• Betrieb: Laufend sind Logs zu prüfen (UserLock bietet Monitoring wer angemeldet hat, wo evtl. MFA fehlgeschlagen ist – praktisch für Audits). Agents und Server sollten aktuell gehalten werden. Anpassungen der Policy evtl. bei neuen Anforderungen.

Der Implementierungsaufwand ist insgesamt geringer als bei ADFS und auch leichter zu fassen als der externe IdP, weil alles in bekannter Windows-Umgebung bleibt. Dennoch ist es kein Null-Aufwand: Gerade die Benutzerregistrierung für MFA und das Ausrollen auf mehreren Servern erfordert sorgfältiges Vorgehen. Für eine mittelgroße Organisation kann man aber in wenigen Wochen das System produktiv haben, inklusive Schulung der Anwender.

Vorteile:

• Keine externe Abhängigkeit: Die gesamte Lösung läuft on-premises. Es werden keine Daten in eine externe Cloud übertragen und man ist unabhängig von Internet oder Dritten. Dies ist für datensensible Unternehmen ein großer Pluspunkt. Selbst bei Ausfall der Internetverbindung funktioniert die MFA für interne Zugriffe weiter (externe natürlich nicht, weil kein Internet, aber das läge dann nicht an der MFA).
• Nutzt bestehende AD-Infrastruktur: UserLock und ähnliche Systeme integrieren sich direkt ins vorhandene Active Directory. Es ist kein zweites Identitätsverzeichnis nötig, keine Synchronisation in Cloud erforderlich. Die Lösung arbeitet mit den bereits vorhandenen Benutzerkonten und Gruppen. Das hält die Komplexität niedrig und vermeidet Widersprüche zwischen mehreren Identity Stores.
• Einfacher Rollout für mehrere Systeme: UserLock ist nicht nur für SharePoint gedacht – es kann zahlreiche Anmelde-Szenarien absichern: z.B. Windows-Anmeldungen am PC, VPN-Einwahlen, Outlook Web App, RD Web Access, etc. Wenn gewünscht, kann man mit der gleichen Lösung all diese Punkte nach und nach mit MFA versehen, ohne für jeden Dienst separate MFA-Produkte anzuschaffen. Diese Multipurpose-Fähigkeit steigert den ROI der Lösung.
• Geringe Kosten pro Benutzer: Mit ~2 \$/Nutzer/Monat liegt diese Lösung preislich im unteren Bereich, deutlich günstiger als Okta/Azure AD P1 etc. Gerade für viele Nutzer kann das sehr wirtschaftlich sein. Zudem sind im Preis bereits Support und Updates enthalten, es kommen keine überraschenden Zusatzkosten.
• Schnelle Login-Abläufe: Da alles lokal geschieht, ist der MFA-Prozess recht zügig (abhängig von der Methode natürlich). Keine Umleitung auf externe Seiten, kein Warten auf Cloud-Response – insbesondere bei Token-Apps ist es ein schneller Zweitschritt. Das Benutzererlebnis bleibt zusammenhängend, da die MFA-Eingabe direkt im SharePoint-Kontext erscheint (z.B. als zusätzliche Eingabemaske) und nicht auf eine völlig andere Seite führt.
• Flexible MFA-Optionen mit Offline-Fähigkeit: UserLock bietet viele gängige zweite Faktoren. Besonders hervorzuheben: Der Hersteller betont auch, dass MFA selbst für Laptop-Anmeldungen außerhalb des Netzwerks möglich ist – d.h. der Agent kann so konfiguriert werden, dass z.B. auch bei Offline-Logon ein OTP verlangt wird (dafür muss natürlich eine Zeitbasierte OTP-Methode zum Einsatz kommen, die ohne Online-Verifizierung funktioniert). Das ist ein spezialisiertes Feature für Workstation Logons, zeigt aber die Durchdachtheit des Produkts. Für SharePoint bedeutet dies, dass auch wenn mal der zentrale UserLock-Server kurz nicht verfügbar wäre, evtl. zwischengespeicherte Mechanismen greifen könnten (die genaue Funktionsweise müsste man in Doku prüfen).
• Keine Änderung der SharePoint-URL/Struktur: Ähnlich wie bei KEMP muss man die SharePoint-Farm selbst kaum ändern. Die Authentifizierung bleibt Windows-basiert, und der Agent „ergänzt“ nur den zweiten Faktor. Benutzer verwenden dieselbe URL, dieselben Accounts. Aus Admin-Sicht bleibt SharePoint-Konfiguration (Zonen, AAM etc.) unberührt. Das reduziert Risiko bei der Implementierung.
• Transparenz und Logging: Das System loggt alle Anmeldeversuche, erfolgreiche und abgelehnte MFA, etc., zentral mit. Dadurch erhält man einen guten Überblick über Sicherheitsvorfälle (z.B. wenn jemand wiederholt falsche Codes eingibt – möglicher BruteForce) und kann Compliance-Anforderungen erfüllen (Protokollierung von Zugriffen). Die Logs bleiben im Haus und können bei Bedarf in SIEMs integriert werden.
• Benutzerfreundlichkeit anpassbar: Da man selbst Herr des Systems ist, kann man z.B. die Texte der MFA-Aufforderung anpassen (in Landessprache, mit eigenen Hinweisen) – das ist bei Cloud-Services oft nur begrenzt möglich. Außerdem kann der Helpdesk direkt in das System eingreifen, um z.B. einen Benutzer temporär vom MFA auszunehmen (bei Problemen), ohne komplexe Azure/Okta Policies ändern zu müssen.

Nachteile:

• Drittanbieter-Software auf kritischem System: Die Installation eines Agents auf den SharePoint-Servern birgt immer ein gewisses Risiko. In Kompatibilitätsfragen muss man darauf vertrauen, dass der Hersteller das mit getestethat. Ein schlecht programmiertes ISS-Plugin könnte theoretisch die Stabilität beeinträchtigen oder Performance kosten. Man fügt also eine neue Komponente in die SharePoint-Umgebung ein, was bei Upgrades/Updates beachtet werden muss (z.B. muss der Agent kompatibel bleiben mit künftigen Patches).
• Abhängigkeit vom UserLock-Server: Fällt der zentrale UserLock-Dienst aus, können sich Benutzer u.U. nicht mehr anmelden (je nach Failover-Mechanismus). Man sollte also Hochverfügbarkeit bedenken – evtl. einen zweiten Server als Standby. Das erhöht den Infrastrukturaufwand leicht. Auch regelmäßige Backups der Konfig (Benutzer-MFA-Registrierungen) sind nötig, damit im Desasterfall die Anmeldung weiterhin klappt.
• Begrenzte Verbreitung und Community: Im Gegensatz zu ADFS oder Azure MFA ist UserLock ein Nischenprodukt. Die Anzahl der Community-Beiträge, Forenlösungen etc. ist kleiner. Man ist stärker auf den Hersteller-Support angewiesen. Sollte der Hersteller den Support einstellen oder die Geschäftstätigkeit aufgeben, stünde man vor der Aufgabe, relativ kurzfristig eine Alternative finden zu müssen. Dieses Risiko ist gering, aber vorhanden, wie bei jeder proprietären Lösung.
• Skalierungspotential begrenzt: Für die meisten Szenarien (bis einige tausend Nutzer) ist die Lösung ausgelegt. In wirklich großen Enterprise-Umgebungen mit zig Tausend Usern oder sehr komplexen Authentifizierungsflüssen könnte die auf AD-Login fokussierte Lösung an Grenzen stoßen, wo ein Cloud-IdP flexibler wäre. Beispielsweise Integration mit modernen Auth Standards (OAuth/OIDC) ist so nicht gegeben – es sichert nur traditionelle AD-Logins ab. Falls SharePoint irgendwann auf eine andere Authentifizierungs-Methode wechseln würde (z.B. reines OIDC), müsste man auch hier umsteigen.
• Kein vollständiges Identity-Management: UserLock bietet MFA und Sessionkontrolle, aber kein Self-Service-Password-Reset, keine eigenen Identity Governance Funktionen etc. Es ist also „nur“ eine Security-Overlay auf AD. Für viele passt das, aber Unternehmen die eine umfassende IAM Lösung anstreben, werden damit nicht alle Anforderungen abdecken (dann bräuchte es zusätzliche Tools).
• Clientseitige Anforderungen: Für manche MFA-Methoden brauchen die User Smartphones mit Authenticator-App oder Hardwaretoken. Das ist generell bei MFA so, aber hier muss die Verteilung/Installation solcher Apps teils intern gemanagt werden, da kein cloudbasiertes Registrierungsportal existiert. Der Benutzer registriert z.B. seinen Token in Absprache mit IT. Das erfordert ein gewisses Handling, ist aber vergleichbar mit anderen Lösungen, nur ohne glamouröse Web-Portale.

Zum Abschluss der Analyse bietet die folgende Tabelle eine strukturierte Gegenüberstellung der fünf Ansätze.

Vergleichstabelle der MFA-Ansätze

Fazit

Alle betrachteten Ansätze ermöglichen grundsätzlich die Umsetzung von Multi-Faktor-Authentifizierung für SharePoint Server Subscription Edition – allerdings unterscheiden sie sich erheblich in Aufwand, Kosten und Komplexität. Insbesondere die Möglichkeit, MFA nur für externe Zugriffe zu erzwingen (und interne Logons optional auszunehmen), lässt sich mit jeder Lösung realisieren, jedoch mit unterschiedlichem technischen Ansatz.

Der KEMP LoadMaster mit Edge Security Pack hat sich in diesem Vergleich als die bevorzugte Lösung herauskristallisiert. Er bietet eine praktikable Balance aus Sicherheit, Benutzerfreundlichkeit und Administrierbarkeit. Im Gegensatz zur ADFS-Föderationslösung benötigt der LoadMaster keine zusätzliche föderierte Identity-Infrastruktur, was den Implementierungsaufwand deutlich reduziert. Die MFA wird elegant vorgeschaltet, ohne Änderungen an SharePoint selbst – ein großer Vorteil, da bestehende Abläufe und Berechtigungen unberührt bleiben. Die Flexibilität des LoadMaster, verschiedenste Authentifizierungsquellen (AD, LDAP, RADIUS, OAuth) und mehrere MFA-Methoden einzubinden, sorgt dafür, dass die Lösung an die individuellen Anforderungen angepasst werden kann (z.B. Weiterverwendung eines bereits vorhandenen OTP-Servers). Zudem kann der LoadMaster dank kontextabhängiger Regeln exakt steuern, wann MFA greift – etwa nur bei externen Netzwerken.

Auch wirtschaftlich punktet der LoadMaster: Es fallen zwar initial Lizenzkosten an, doch diese sind einmalig bzw. fest kalkulierbar und nicht nutzerbezogen gestaffelt. Gerade bei einer wachsenden Nutzerzahl oder vielen externen Projektmitarbeitern vermeidet man so hohe laufende Gebühren für Cloud-Abonnements. Darüber hinaus übernimmt der LoadMaster zugleich die Rolle des Load-Balancers für SharePoint, was Performance und Hochverfügbarkeit der Farm verbessert – ein Mehrfachnutzen, der die Investition weiter rechtfertigt.

Natürlich erfordert auch der KEMP LoadMaster fachgerechte Einrichtung. Aspekte wie Kerberos Delegation und SSL-Konfiguration müssen sauber umgesetzt werden. Doch im Vergleich zu ADFS ist dies deutlich überschaubarer und mit KEMP-Unterstützung oder vorhandener Expertise gut zu bewältigen. Im Betrieb ist die Lösung robust und benötigt wenig Pflege. Die Benutzer erleben eine einheitliche Anmeldeseite (die sogar im Corporate Design anpassbar ist) und profitieren von Single Sign-On über Anwendungen hinweg – Sicherheit wird erhöht, ohne die User Experience unnötig zu verschlechtern.

Zusammenfassend überwiegen bei der KEMP LoadMaster-Lösung klar die Vorteile: geringerer Implementierungsaufwand als ADFS, umfangreiche MFA-Funktionen, moderate Kosten und die Möglichkeit, interne und externe Zugriffe differenziert zu behandeln. Sie integriert sich nahtlos in die bestehende Windows-Auth-Welt und vermeidet die Komplexität externer Identity-Systeme. Damit stellt der KEMP LoadMaster aus Sicht dieser Analyse die empfohlene Option dar, um SharePoint Server Subscription Edition zuverlässig und benutzerfreundlich mit Multi-Faktor-Authentifizierung abzusichern.

Weitere Beiträge zum Thema SharePoint