MFA für SharePoint Server SE mit Kemp LoadMaster 

1. MFA-Integration mit Kemp LoadMaster für veröffentlichte Ressourcen

Kemp LoadMaster bietet mit dem Edge Security Pack (ESP) eine integrierte Lösung, um Webanwendungen abgesichert im Internet bereitzustellen. Das ESP ermöglicht Pre-Authentication (Vorab-Authentifizierung) und unterstützt erweiterte Authentifizierungsmethoden, darunter Mehrfaktor-Authentifizierung (MFA) und Single Sign-On. Dabei fungiert der LoadMaster als vorgelagerte Instanz (Reverse Proxy), die den Zugriff auf interne veröffentlichte Ressourcen kontrolliert. Benutzer müssen sich zunächst am LoadMaster anmelden, bevor Anfragen an die eigentlichen Anwendungssysteme – z. B. SharePoint – weitergeleitet werden.

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.

Für die MFA-Integration nutzt Kemp LoadMaster gängige Mechanismen: So können LDAP/Active Directory für die erste Faktor-Validierung (Benutzername/Passwort) und RADIUS für die Zweitfaktor-Authentifizierung kombiniert werden. Beispielsweise lässt sich ein RADIUS-basierter OTP-Dienst (One-Time Password) einbinden, wie RSA SecurID oder ein anderer Token-Server. Der LoadMaster bietet dafür eine spezielle Dual-Factor-Authentifizierungsformular-Vorlage an, in der der Benutzer beide Faktoren eingibt (z. B. Passwort und Einmalcode). Intern prüft der LoadMaster diese Angaben gegen die hinterlegten Authentifizierungsserver: zunächst die Primär-Authentifizierung (z. B. AD Login), gefolgt von der Sekundär-Authentifizierung via RADIUS-Server. Erst wenn beide erfolgreich sind, erhält der Benutzer Zugriff auf die geschützte Anwendung.

Technisch realisiert der LoadMaster dies durch Session-Cookies und Weiterleitungsmechanismen: Nach erfolgreicher MFA stellt er ein Session-Cookie aus (gebunden an eine definierte SSO-Domain), damit der Benutzer für die Dauer der Session nicht erneut alle Anmeldedaten eingeben muss. Mehrere veröffentlichte Dienste unter derselben Domain können so mit Single Sign-On abgedeckt werden. Das ESP erlaubt zudem, den Zugriff feingranular zu steuern – z. B. über Zugriff nur für bestimmte Hostnamen oder URL-Pfade sowie AD-Gruppenmitgliedschaften als Voraussetzung für den Zugriff.

Für die Zweitfaktor-Authentifizierung unterstützt Kemp neben RADIUS/OTP auch Zertifikatsprüfungen (Client-Zertifikate als zweiter Faktor) sowie die Einbindung externer Identity Provider über SAML 2.0. In letzterem Fall kann der LoadMaster selbst als SAML-Service-Provider agieren und die MFA an einen externen IdP (etwa Azure AD, Okta etc.) auslagern, der die Benutzer z. B. per Push-App authentisiert. Typischer ist jedoch die direkte Integration eines RADIUS-basierten MFA-Dienstes, da dies eine konsistente Login-Erfahrung über das LoadMaster-Webformular ermöglicht. Zusammengefasst erweitert der LoadMaster also die klassische Load-Balancing-Funktion um eine Sicherheits-Gateway-Funktion, die vor den veröffentlichten Webanwendungen sitzt und dort MFA erzwingt, bevor irgendeine Anfrage an die internen Server gelangt. Dies schützt die Ressourcen vor unautorisiertem Zugriff selbst dann, wenn diese Anwendungen selbst keine MFA unterstützen.

2. Absicherung und Lastverteilung von SharePoint Server SE mittels LoadMaster (unter Berücksichtigung von MFA)

Für SharePoint Server Subscription Edition (SE), eine On-Premises-Version von SharePoint, übernimmt Kemp LoadMaster sowohl das Load-Balancing der Web-Frontends (WFE) als auch die Absicherung der Zugriffe durch Voranstellen einer MFA-Authentifizierung. In einer typischen Umgebung werden mehrere SharePoint-Webserver in einer Farm betrieben, um Hochverfügbarkeit und Lastverteilung zu gewährleisten. Der LoadMaster bietet hierfür einen virtuellen Service (VIP) an, der unter der externen SharePoint-URL erreichbar ist (z. B. sharepoint.meinefirma.de). Alle Clientanfragen laufen zuerst an diese VIP-Adresse und werden vom LoadMaster gemäß definierter Regeln an die gesunden SharePoint-Server weitergeleitet.

Lastverteilung: Der LoadMaster unterstützt verschiedene Verteilungsalgorithmen (Round-Robin, Least Connections, adaptives Scheduling etc.), um eingehende Anfragen gleichmäßig auf die SharePoint-WFEs zu verteilen. Wichtig ist dabei oft eine Sitzungspersistenz, da SharePoint (insbesondere bei Windows-Authentifizierung oder komplexen Workflows) von einer fortlaufenden Session pro Nutzer profitiert. Häufig wird eine Cookie-basierte Persistenz oder Source-IP-Persistenz konfiguriert, damit ein Benutzer während einer Sitzung immer zum gleichen Backend-Server geleitet wird. Dies verhindert Probleme bei NTLM-Authentifizierung (mehrstufiger Handshake) und kann die Performance verbessern, weil SharePoint ggf. serverseitig Session-Daten hält. Alternativ kann SharePoint jedoch auch zustandslos mit Claims-Authentifizierung arbeiten, wo Persistenz weniger kritisch ist – hier reicht es aus, dass der LoadMaster HTTP(S)-Anfragen terminieren und weiterreichen kann, da SharePoint den Benutzerzustand in eigenen Cookies (wie FedAuth) verwaltet.

Absicherung mit MFA: Sobald MFA am LoadMaster aktiviert ist (mittels ESP Pre-Auth), schaltet der LoadMaster einen Authentifizierungsdialog vor die SharePoint-Site. Technisch bedeutet dies, dass der LoadMaster zunächst jede eingehende HTTPS-Verbindung abfängt und den Benutzer auf eine Anmeldeseite umleitet. Dort werden Benutzername, Passwort und ggf. ein Zweitfaktor (z. B. Einmalcode) abgefragt. Bei korrekter Eingabe prüft der LoadMaster die AD-Anmeldung und danach den zweiten Faktor via konfiguriertem RADIUS-Server. Nur bei Erfolg leitet der LoadMaster die ursprüngliche Anfrage an SharePoint weiter.

Damit SharePoint die Anfrage akzeptiert, muss der LoadMaster die Authentifizierungsinformation intern weiterreichen. Hierfür bietet Kemp zwei gängige Ansätze:

• Basic/NTLM-Weiterleitung: SharePoint könnte so konfiguriert sein, dass es Basic Auth über HTTPS annimmt (z. B. auf einer eigenen Zone). Der LoadMaster kann die vom Benutzer eingegebenen Anmeldeinformationen nutzen, um im Hintergrund eine Basic-Authentifizierung gegenüber dem SharePoint-Server durchzuführen. Diese Variante ist einfach, hat aber Nachteile in Bezug auf Sicherheit (Basic über internes Netz, wenn auch verschlüsselt) und unter Umständen Nutzererlebnis (Popups, falls SharePoint doch noch eine Authentifizierung verlangt).
• Kerberos-Weiterleitung (Constrained Delegation): Besser ist die Integration via Kerberos. Der LoadMaster selbst kann dem Active Directory beitreten und für die veröffentlichte SharePoint-SPN (Service Principal Name) eine Kerberos Constrained Delegation (KCD) durchführen. Das heißt, der LoadMaster meldet den Benutzer nach erfolgreicher Pre-Auth im eigenen Namen per Kerberos beim SharePoint an. SharePoint erhält so ein gültiges Kerberos-Ticket und erkennt den Benutzer als authentifiziert, ohne dass dieser an SharePoint selbst nochmal Anmeldedaten übermitteln muss. Dies erfordert einige Konfiguration: SharePoint-Webanwendungen sollten auf Kerberos-Authentifizierung stehen, der LoadMaster-Host bekommt im AD das Recht, Tickets zum SPN des SharePoint-Dienstes anzufordern. Kemp unterstützt dieses Szenario nativ – NTLM passt hingegen nicht für SSO, da der LoadMaster keinen NTLM-Handshake führen kann. Entsprechend gilt KCD als Best Practice, um SharePoint mit vorgelagertem Pre-Auth zu betreiben. So wird erreicht, dass die SharePoint-Farm selbst nur Domänen-Tickets akzeptiert und aus Sicht von SharePoint jeder Request bereits von einem berechtigten Domänenbenutzer kommt (der vom LoadMaster geprüft wurde).

Konfiguration in SharePoint: Wichtig ist, dass die externe URL, unter der der LoadMaster die Site anbietet, in SharePoint bekannt ist. In SharePoint wird dies über Alternate Access Mappings (AAM) oder Zonen konfiguriert. Beispielsweise kann die externe URL https://sharepoint.meinefirma.de als Internet-Zone der Webanwendung registriert sein. Der LoadMaster leitet die Host-Header typischerweise unverändert an SharePoint weiter, sodass SharePoint seine Seiten und Links korrekt mit der externen Adresse ausliefert. Zudem muss auf SharePoint-Seite die gewählte Authentifizierungsmethode (Kerberos oder Basic) aktiviert sein. Häufig richtet man für externe Zugriffe eine eigene Webanwendungszone mit Claims/Windows-Authentifizierung ein, die Kerberos unterstützt, während interne Zugriffe evtl. weiterhin NTLM nutzen könnten – durch die KCD-Konfiguration auf dem LoadMaster kann extern trotzdem Kerberos genutzt werden.

Sicherheit durch MFA und ESP: Durch die vorgelagerte MFA-Schicht wird SharePoint effektiv geschützt, als läge es hinter einer Firewall mit integrierter Authentifizierung. Unautorisierte Zugriffsversuche werden vom LoadMaster blockiert, bevor sie SharePoint erreichen. Zusätzlich kann der LoadMaster optional einen Web Application Firewall (WAF)-Filter vorschalten, um Angriffe auf bekannte SharePoint-Schwachstellen oder allgemeine Web-Angriffe (SQL-Injection, XSS etc.) zu verhindern. Damit bildet der LoadMaster eine umfassende Sicherheitsfront: Er terminiert die SSL-Verbindung (entschlüsselt TLS), prüft Benutzeridentität mit MFA, setzt ggf. Sicherheitsrichtlinien durch und eröffnet dann eine neue, sichere Verbindung zum SharePoint-Server im internen Netz (SSL-Bridging). Dieses Konzept entspricht dem früher oft genutzten Microsoft TMG (Threat Management Gateway), welches ebenfalls für Exchange/SharePoint als Publishing Firewall diente – Kemp LoadMaster übernimmt diese Rolle mit aktueller Technologie.

Aus Sicht des Benutzers bleibt der Zugriff komfortabel: Nach einmaliger MFA-Anmeldung am LoadMaster kann er die SharePoint-Funktionalität nutzen, ohne nochmals aufgefordert zu werden. Greift er parallel auf weitere veröffentlichte Dienste (z. B. eine SharePoint-MySite auf anderer URL oder Exchange OWA) zu, kann dank SSO die Anmeldung domänenweit gelten, sofern die Dienste im LoadMaster unter derselben SSO-Domain konfiguriert wurden. Gleichzeitig sind alle Verbindungen durchgehend verschlüsselt (TLS), und vertrauliche Daten in SharePoint werden nun durch die zusätzliche MFA-Schicht vor unbefugtem Zugriff geschützt.

3. Vergleich verschiedener MFA-Methoden (mit Vor- und Nachteilen)

In der folgenden Tabelle sind gängige MFA-Methoden aufgeführt – exemplarisch SMS-TAN, App-basiert (Authenticator-App oder Push) und Hardware-Token – jeweils mit ihren Vorteilen und Nachteilen:

(Hinweis: Weitere MFA-Methoden wie E-Mail-basierte Codes oder biometrische Verfahren/FIDO2 existieren ebenfalls. Diese sind jedoch in Unternehmensumgebungen weniger gebräuchlich oder dienen oft nur als Ergänzung. Die obigen drei Kategorien decken die häufigsten Ansätze ab.)

In Kontext von Kemp LoadMaster werden typischerweise App- oder Token-basierte OTP-Lösungen via RADIUS integriert. SMS könnte ebenfalls über einen RADIUS-Provider (z. B. integrierter SMS-OTP-Service) realisiert werden, ist aber wegen der genannten Sicherheitsbedenken und Abhängigkeiten weniger empfohlen. Am sichersten und benutzerfreundlichsten sind heute oft App-basierte MFA (z. B. Microsoft Authenticator, Google Authenticator, Duo Mobile), da sie eine gute Balance zwischen Sicherheit und Bedienbarkeit bieten.

4. Technische Anforderungen an Hochverfügbarkeit für LoadMaster im SharePoint-Umfeld

Da der LoadMaster im SharePoint-Szenario als kritischer Knotenpunkt (Single Point of Entry) fungiert, ist dessen Hochverfügbarkeit (High Availability, HA) essenziell. Folgende technische Anforderungen und Aspekte sind dabei zu beachten:

• LoadMaster-Cluster (HA-Paar): Es sollten mindestens zwei LoadMaster-Appliances im Verbund betrieben werden (HA-Paar im Active/Standby-Modus). Kemp LoadMaster verwendet ein eigenes HA-Protokoll auf Basis von CARP/VRRP (Common Address Redundancy Protocol), um den Ausfall eines Knotens zu erkennen und nahtlos an den zweiten zu übergeben. Beide Einheiten teilen sich dabei eine virtuelle IP-Adresse (Service-VIP) für die Dienste. Fällt der Active-Knoten aus, übernimmt der Standby-Knoten automatisch diese IP und damit den Traffic (Failover). Dieser Mechanismus arbeitet mit Heartbeat-Nachrichten über ein direktes Verbindungsnetz oder über dedizierte Interfaces zwischen den Knoten. (CARP nutzt z. B. Multicast 224.0.0.18 für Heartbeats.) Die Umschaltung erfolgt innerhalb von Sekundenbruchteilen, sodass Benutzerverbindungen erhalten bleiben.
• Synchronisation und Zustandsübernahme: Die beiden LoadMaster in HA-Konfiguration halten ihre Konfiguration synchron (virtuelle Dienste, ESP-Einstellungen etc.). Änderungen werden vom aktiven Gerät aufs Backup repliziert. Optionale Features wie persistente Sitzungen können so eingestellt werden, dass sie bei Failover nicht verloren gehen (Stateful Failover). Allerdings ist zu prüfen, welche Daten tatsächlich übernommen werden – in manchen Fällen müssen Benutzer sich nach einem Failover neu anmelden, insbesondere wenn der Session-Cookie an den Knotel gebunden war. Best Practices empfehlen, die Idle-Timeouts so zu setzen, dass ein Re-Login notfalls nur geringe Auswirkung hat.
• Geografische Redundanz (DR/Geo-Cluster): Für sehr hohe Ausfallsicherheit kann zusätzlich ein zweiter Standort mit weiterer LoadMaster-Instanz und SharePoint-Farm im Standby betrieben werden. Kemp bietet hierfür das GEO-Feature (Global Server Load Balancing) an, um DNS-basiert auf einen Ausweichstandort umzuschalten. Im lokalen Kontext genügt jedoch meist ein HA-Paar im selben Rechenzentrum.
• Netzwerk und Infrastruktur: Beide LoadMaster-Knoten sollten in Bezug auf Netzwerk redundant angebunden sein (mehrere Switches oder Bonding von Interfaces). In virtuellen Umgebungen ist darauf zu achten, dass Promiscuous Mode auf den vSwitches aktiviert ist (erforderlich für das Sharing der VIP zwischen zwei VMs im HA-Verbund). Außerdem sollten die Knoten auf getrennten Hosts laufen, damit ein Hardwareausfall nicht beide betrifft. Auch beim Einsatz von Cloud-VMs müssen Verfügbarkeitszonen berücksichtigt werden.
• Lizenzierung und Support: Für HA ist i. d. R. pro LoadMaster eine Lizenz nötig; Kemp erlaubt einen HA-Cluster oft ohne zusätzliche Kosten, sofern beide Knoten identisch lizenziert sind. Sicherzustellen ist, dass das ESP/MFA-Feature auf beiden aktiv ist. Außerdem sollten beide Appliances auf dem gleichen Firmwarestand laufen, um Kompatibilität zu gewährleisten.
• Monitoring und Health-Checks: Innerhalb des LoadBalancers werden kontinuierlich Health-Checks auf die SharePoint-Server durchgeführt (z. B. HTTPS-GET auf eine bestimmte Seite oder einen speziellen Health-Endpoint von SharePoint). Wenn ein SharePoint-Server nicht mehr reagiert oder Fehler liefert, wird er automatisch aus dem Pool genommen. Dies stellt sicher, dass bei Teilausfällen (einzelner WFE down) der Traffic auf die verbleibenden Server geht. Für HA der LoadMaster selbst sollte ein externes Monitoring vorhanden sein, das Alarm schlägt, falls ein Knoten ausfällt oder ungewöhnliche Load/Netzwerkprobleme auftreten.

Zusammengefasst muss die gesamte Architektur ohne Single Point of Failure gestaltet sein: Mehrere SharePoint-WFEs hinter einem hochverfügbaren LoadMaster-Cluster. So erreicht man End-to-End-Hochverfügbarkeit. Im Fehlerfall (sei es eine SharePoint-Instanz oder ein LoadBalancer-Knoten) bleibt der Dienst erreichbar. Wichtig ist, Failover-Szenarien auch praktisch zu testen (siehe Tests weiter unten), um sicherzustellen, dass keine Konfigurationslücken bestehen.

5. Aktionsplan zur Einführung von Kemp LoadMaster als MFA-Lösung für SharePoint SE

Zum Abschluss folgt ein detaillierter Aktionsplan, der die Einführung von Kemp LoadMaster zur MFA-Absicherung von SharePoint Server Subscription Edition Schritt für Schritt beschreibt. Dieser Plan umfasst die Planung, konkrete Konfigurationsschritte, Testverfahren sowie Sicherheitsüberlegungen und Best Practices.

5.1 Planung und Vorbereitung

1. Anforderungen und Zieldefinition: Zunächst sind die genauen Anforderungen festzulegen. Welche SharePoint-Webanwendungen sollen extern verfügbar sein? Welche Benutzer(gruppen) erhalten Zugriff? Welches MFA-Verfahren soll eingesetzt werden (z. B. bestehende RSA SecurID-Infrastruktur, Azure MFA via RADIUS, Duo Push etc.)? Definieren Sie auch die Sicherheitsrichtlinien (z. B. Sperrung nach X Fehlversuchen via ESP „Soft Lockout“ Feature). Legen Sie fest, ob ein WAF-Schutz aktiviert werden soll und ob SSO für mehrere Dienste nötig ist.
2. Architektur entwerfen: Planen Sie die physische/virtuelle Bereitstellung des LoadMasters. Idealerweise setzen Sie zwei LoadMaster in HA (siehe Abschnitt 4). Skizzieren Sie das Netzwerk: der LoadMaster benötigt eine Schnittstelle in das DMZ/Extranet (für eingehende Clientverbindungen) und eine in das interne LAN (für die Verbindung zu SharePoint und AD/RADIUS). Planen Sie IP-Adressen, DNS-Einträge (externer Name der SharePoint-Site), und beschaffen Sie ein gültiges TLS-Zertifikat für die externe URL (vom Unternehmen oder öffentlichen CA). Ebenfalls in der Planung: Falls Kerberos-Delegation genutzt werden soll, klären Sie die notwendigen AD-Einstellungen (Domain-Join des LoadMasters, SPN für SharePoint-Webdienste, Delegationsrechte für den LoadMaster-Computeraccount).
3. MFA-Backendlösung vorbereiten: Richten Sie den RADIUS-Server oder anderen MFA-Dienst ein. Beispielsweise könnte dies ein Microsoft NPS mit Azure MFA Extension sein, ein Duo Authentication Proxy oder ein RSA Authentication Manager. Konfigurieren Sie die zu nutzenden MFA-Methoden dort (z. B. OTP via App oder SMS, je nach System). Testen Sie zunächst standalone, ob Benutzer am RADIUS mit Zweitfaktor authentifiziert werden können.
4. SharePoint-Konfiguration überprüfen: Stellen Sie sicher, dass SharePoint für die Zusammenarbeit mit dem LoadMaster vorbereitet ist. Dazu gehört:
   • Die Webanwendung(en), die veröffentlicht werden, sollten eine passende Alternate Access Mapping für die externe URL haben.
   • Aktivieren Sie in der Webanwendung die Authentifizierungsmethode, die der LoadMaster intern verwenden wird. Für KCD: integrierte Windows-Auth (Kerberos) aktiv und SPN gesetzt. Alternativ für Basic: Basic-Auth aktivieren (idealerweise auf einer separaten AAM Zone „Extranet“ mit HTTPS erforderlich).
   • Prüfen Sie die SharePoint-Farm auf aktuelle Updates und Sicherheitspatches, bevor sie dem Internet zugänglich gemacht wird.
5. Betriebs- und Sicherheitsrichtlinien definieren: Legen Sie fest, wer den LoadMaster administriert und wie Änderungen kontrolliert werden (Change Management). Definieren Sie Monitoring-Anforderungen (wird es in ein bestehendes Monitoring/SIEM integriert?) sowie Backup-Strategien für die LoadMaster-Konfig. Sicherheitsrichtlinie: Welche Cipher-Suites und TLS-Versionen sollen erlaubt sein? Kemp erlaubt das Abschalten unsicherer Protokolle – entscheiden Sie z. B., TLS 1.2/1.3 zu erzwingen und ältere abzuschalten, um Compliance-Anforderungen zu erfüllen.

5.2 Installation und Konfiguration des LoadMaster (MFA für SharePoint)

1. Bereitstellung des LoadMaster: Installieren Sie die LoadMaster-Appliances gemäß Kemp-Anleitung (entweder als Hardware, virtuelle Maschine oder in der Cloud, je nach Planung). Verbinden Sie die Netzwerkschnittstellen entsprechend (DMZ, LAN). Weisen Sie IP-Adressen zu und stellen Sie sicher, dass beide Appliances (bei HA-Zwei) sich erreichen. Führen Sie die Grundkonfiguration durch (Hostname, Default-Gateway, DNS, Admin-Zugang, Lizenzaktivierung). Bei einem HA-Paar: Richten Sie die HA-Konfiguration ein (eine Einheit aktiv, die zweite Standby; Synchronisation aktivieren).
2. SSL/TLS einrichten: Importieren Sie das SSL-Zertifikat für die externe SharePoint-URL in den LoadMaster. Dies umfasst in der WUI (Web User Interface) das Hochladen des Zertifikats und Schlüssels, ggf. Zwischenzertifikate der CA. Weisen Sie das Zertifikat dem neuen virtuellen Service zu, bevor Sie ihn aktiv schalten, sodass eingehende Anfragen per HTTPS bedient werden können.
3. Virtual Service für SharePoint anlegen: Erstellen Sie im LoadMaster einen Virtual Service (VS) auf der externen IP/Port 443 für SharePoint. Tragen Sie die internen SharePoint-WFE-Server als Real Servers (mit deren IP und Port 443 oder 80, je nach Verschlüsselungsentscheidung) ein. Empfehlenswert ist SSL-Bridging: VIP empfängt HTTPS und leitet als HTTPS an die Real-Server weiter, um Ende-zu-Ende-Verschlüsselung zu behalten. Alternativ kann man terminieren (HTTPS auf VIP, Weiterleitung als HTTP intern), falls interne Netz als vertrauenswürdig gilt; jedoch muss dann SharePoint denken, es laufe unter HTTPS – in dem Fall „SSL Offloading“ aktivieren und eventuell im HTTP-Header den X-Forwarded-Proto: https setzen, damit SharePoint keine Mixed-Content-Warnungen produziert.
4. Health Check konfigurieren: Im VS einstellen, wie die Gesundheitsprüfung der SharePoint-Server erfolgen soll. Z. B. HTTP/HTTPS GET auf / oder eine dedizierte Seite (/_layouts/15/healthcheck.aspx falls vorhanden) mit erwarteter Status 200. Frequenz und Timeout der Checks so wählen, dass Ausfall schnell erkannt wird, aber Server nicht überlastet werden.
5. Persistenz und weitere L7-Einstellungen: Aktivieren Sie bei Bedarf Session Persistence. Für SharePoint eignet sich SSL SessionID oder Client-IP-Persistenz, oder Cookie Insert (Kemp kann ein eigenes Cookie setzen). Beachten: Bei SSL SessionID Persistenz funktioniert es automatisch bei SSL-Offloading; bei SSL-Bridging lieber IP-basierte Persistenz wählen, falls keine speziellen Anforderungen vorliegen. Zusätzlich können in den L7-Optionen Größenlimits, Kompression oder Caching aktiviert werden, um Performance zu optimieren – dies ist optional.
6. ESP aktivieren (MFA-Auth einrichten): Im Virtual Service aktivieren Sie nun das Edge Security Pack. Wählen Sie als Authentication Method „Form Based“. Als Server Authentication zuerst LDAP/Active Directory einrichten: Geben Sie die Domänendaten ein (AD-Server, Bind-Konto, Base-DN etc.). Testen Sie die Verbindung und ggf. Benutzerauthentifizierung. Dann Second Factor hinzufügen: Wählen Sie RADIUS als zusätzliches Auth-System. Konfigurieren Sie den RADIUS-Server (IP, Port, Shared Secret). Legen Sie fest, ob der Login-Bildschirm als Dual-Factor-Formular angezeigt wird (vier Eingabefelder: typischerweise Benutzername, Passwort, + zweites Passwort/OTP und ggf. Domain). Kemp bietet hier ein Standard-Template „Dual Factor“ an, das passend ist, wenn man LDAP + RADIUS nutzt. Passen Sie die Login-Seite ggf. mit eigenem Text oder Logo an (ESP erlaubt HTML-Customization für z. B. Firmenlogo). Setzen Sie eine SSO Domain (z. B. .meinefirma.de), damit der Cookie für alle entsprechenden Anwendungen gilt. Wenn nur eine einzelne Anwendung geschützt wird, kann man auch den spezifischen Hostnamen nehmen.
7. SSO und Delegation einrichten: In den Single Sign-On Einstellungen des ESP konfigurieren Sie, wie der LoadMaster nach erfolgreicher Auth den Request an SharePoint weitergibt. Für SharePoint mit Windows-Auth sollte Kerberos Constrained Delegation konfiguriert werden:
   • Joinen Sie den LoadMaster zunächst zur AD-Domäne (über die WUI unter System Configuration > Domain Joined).
   • Hinterlegen Sie unter ESP > SSO Kerberos als Methode und tragen den Service Principal Name (SPN) des SharePoint-Dienstes ein, etwa HTTP/sharepoint.meinefirma.de@AD-DOMAIN (bzw. das entsprechende SPN, das auf das App-Pool-Konto der Webapp gesetzt wurde). Alternativ kann Kemp oft das SPN aus dem eingehenden Host-Header automatisch ableiten.
   • Im AD-Userkonto (Computerobjekt) des LoadMasters müssen Sie die Delegation für den Service HTTP/sharepoint.meinefirma.de erlauben (Vertrauensstellung für Delegierung -> „nur für angegebene Dienste“).
   • Testen Sie die Kerberos-SSO-Funktion mit einem Benutzer: Der LoadMaster sollte im Log anzeigen, ob KCD-Tickets geholt werden konnten. Falls Kerberos nicht klappt, fällt Kemp automatisch auf NTLM nicht zurück (unterstützt er nicht für SSO), daher muss Kerberos funktionieren. Bei Problemen SPN und Delegationseinstellungen prüfen.

   Falls Basic-Auth als Fallback genutzt werden soll (nicht ideal, aber möglich): Statt Kerberos würden Sie Basic als SSO-Methode wählen und vermutlich dem LoadMaster-Formular erlauben, das Passwort zu speichern. Der LoadMaster würde dann einen Authorization-Header mit Base64-Credentials an SharePoint senden. Dieses Vorgehen ist einfacher einzurichten, aber weniger sicher, daher nur nutzen, wenn Kerberos absolut nicht umsetzbar ist.

8. Zugriffskontrolle und Feintuning: Nutzen Sie weitere ESP-Optionen nach Bedarf:
   • Permitted Groups: Sie könnten angeben, dass nur Benutzer einer bestimmten AD-Gruppe sich anmelden dürfen (z. B. Extern_MFA_Authorized). So wird selbst ein gültiger AD-Login abgelehnt, falls der Benutzer nicht berechtigt ist.
   • Allowed Virtual Hosts / URLs: Beschränken Sie optional, auf welche Hostnames und Pfade der Benutzer nach Login zugreifen darf. Für eine einzelne SharePoint-Site meist nicht nötig, kann aber hilfreich sein, um sicherzustellen, dass der LoadMaster nur die vorgesehenen Sites bedient (z. B. MySite-Pfade ausschließen, etc.).
   • Logon Attempt Settings: Aktivieren Sie Soft Lockout, um Brute-Force zu verhindern (z. B. nach 5 Fehlversuchen wird Login für 5 Minuten gesperrt).
   • WAF aktivieren: Wenn lizenziert, fügen Sie eine WAF-Regel hinzu, spezifisch gibt es Kemp-Regelsätze für SharePoint. Dies kann gängige Exploits blocken. Achten Sie aber darauf, die WAF zunächst im Lern- oder Reporting-Modus zu testen, um False Positives auszuschließen.
9. DNS und Firewall: Weisen Sie dem externen DNS die öffentliche IP des LoadMaster (bzw. der Firewall davor) für den SharePoint-Hostnamen zu. Konfigurieren Sie Firewalls so, dass HTTPS-Verkehr von extern an den LoadMaster weitergeleitet wird. Ausgehend benötigt der LoadMaster selbst Zugriff auf: die SharePoint-Server (HTTPS intern), den AD-Server (LDAP/Kerberos), den RADIUS-Server (UDP 1812/1813), ggf. OCSP/CRL-URLs falls Zertifikatsprüfung in MFA oder Clientzertifikaten genutzt wird.
10. Abschluss der Grundkonfiguration: Stellen Sie sicher, dass alle Änderungen gespeichert sind. Dokumentieren Sie die Konfiguration (Export der LoadMaster-Einstellungen als Backup-Datei). Führen Sie ein Failover-Test innerhalb des LoadMaster-HA-Paares durch (manuell den Active wechseln), um zu sehen ob die Konfiguration sauber synchronisiert und übernommen wird.

5.3 Testplan und Testszenarien

Nach der Einrichtung ist ein umfangreiches Testen unerlässlich:

• Funktionstest Anmeldung: Versuchen Sie sich mit einem gültigen Benutzer anzumelden. Erwartung: Login-Seite erscheint, nach Eingabe von Benutzer/Passwort und gültigem Zweitfaktor gelangt man auf die SharePoint-Homepage. Überprüfen Sie, dass alle Inhalte geladen werden (CSS, Bilder – falls nicht, evtl. noch an Allowed URLs anpassen) und dass die URL in der Adresszeile korrekt die externe ist. Navigieren Sie durch verschiedene SharePoint-Seiten, um zu verifizieren, dass Persistenz klappt und keine erneute Authentifizierung gefordert wird.
• Negativtests: Geben Sie falsche Anmeldedaten ein:
  • Falsches Passwort, richtiger OTP → Zugriff verweigert (Meldung sollte erscheinen, kein Zugang).
  • Richtiges Passwort, falscher oder kein OTP → Zugriff verweigert.
  • Benutzer nicht in zulässiger Gruppe (falls Group-Filter aktiv) → Zugriff verweigert.
  • Überprüfen Sie, ob Fehlermeldungen ausreichend aber nicht zu detailliert sind (keine Interna preisgeben).
• MFA-Spezialtests: Testen Sie das Verhalten bei Timeouts: Lassen Sie die Session idle, bis sie abläuft (konfigurierbar, z. B. 15 Minuten). Zugriff auf nächste Seite sollte wieder die Login-Seite bringen. Testen Sie zudem „Abmelden“: SharePoint-Logout sollte idealerweise auch die LoadMaster-Session beenden (hier ggf. Logoff-String konfigurieren, z. B. /logout.aspx falls vorhanden, damit Kemp die Session invalidiert).
• Mehrgeräte- und SSO-Test: Melden Sie sich von zwei verschiedenen Browsern oder Geräten an, um sicherzustellen, dass parallele Sessions erlaubt sind (oder bewusst nicht, je nach Richtlinie). Greifen Sie falls zutreffend auf andere durch denselben LoadMaster geschützte Dienste zu, um SSO zu prüfen (sollte keinen zweiten Login verlangen, wenn Cookie gültig und SSO Domain passt).
• Leistungstest: Führen Sie rudimentäre Lasttests durch, z. B. mehrere gleichzeitige Anmeldungen, um zu sehen, wie der LoadMaster und der RADIUS darauf reagieren. Beobachten Sie CPU-/RAM-Auslastung des LoadMasters bei Spitzen. Kemp-Appliances haben je nach Modell bestimmte Throughput- und SSL-Handshake-Kapazitäten – stellen Sie sicher, dass diese ausreichend dimensioniert sind.
• Failover-Test: Simulieren Sie den Ausfall eines SharePoint-WFE: Stoppen Sie den IIS auf einem Server und prüfen, ob der LoadMaster den Server als down markiert und Traffic zum anderen umleitet, ohne dass der Benutzer es merkt. Ebenso simulieren Sie einen LoadMaster-Failover: Setzen Sie im Webinterface den aktiven Node in den Standby-Modus, sodass der andere übernimmt. Die bestehende Session des Benutzers sollte idealerweise weiter funktionieren. Falls ein erneutes Login notwendig war, notieren und prüfen Sie die Einstellungen (Session State sync).
• Security-Test (Penetration Light): Falls möglich, lassen Sie einen Sicherheitsscan laufen (z. B. OWASP ZAP oder Nessus) gegen die externe URL. Schauen Sie, ob der LoadMaster konfiguriert ist, gängige Dinge abzuschirmen: z. B. keine HTTP->HTTPS-Redirect-Lücke (so konfigurieren, dass HTTP auf 443 weiterleitet oder dicht ist), TLS-Einstellungen korrekt, keine Offenlegung von internen IPs oder Versionen, WAF filtert gängige Attack-Muster. Überprüfen Sie auch die Logs: Fehlanmeldungen sollten geloggt sein (Kemp kann an Syslog senden).

5.4 Sicherheitsüberlegungen und Best Practices

Abschließend einige Best Practices und Hinweise für den produktiven Betrieb:

• Prinzip der minimalen Öffnung: Stellen Sie sicher, dass der LoadMaster der einzige Weg von extern zu SharePoint ist. Direkte Zugriffe auf SharePoint (z. B. über andere Ports oder alte Publishing-Regeln) sollten deaktiviert werden. In der Firewall nur den LoadMaster in die DMZ exponieren.
• Härtung des LoadMasters: Deaktivieren Sie unbenötigte Dienste auf dem LoadMaster. Z. B. Management-Zugriff auf den LoadMaster (WUI/SSH) nur aus dem internen Netz erlauben, nicht aus dem Internet. Ändern Sie die Standard-Adminpasswörter. Spielen Sie regelmäßige Updates der LoadMaster-Firmware ein, um Sicherheitslücken zu schließen.
• Starke Verschlüsselung erzwingen: Nutzen Sie aktuelle TLS-Versionen und schränken Sie unsichere Ciphers ein. Kemp erlaubt eigene Cipher-Sets – verwenden Sie z. B. nur AES-GCM und disable 3DES, wenn nicht schon Standard. Aktivieren Sie HTTP Strict Transport Security (HSTS) im LoadMaster Header-Settings, um Man-in-the-Middle-Risiken zu senken.
• Logging und Monitoring: Aktivieren Sie ausführliches Logging für ESP-Events. In den Logs sollte ersichtlich sein, wer sich wann (un-)erfolgreich angemeldet hat. Diese Logs können ins SIEM geleitet werden, um verdächtige Muster (z. B. viele Fehlversuche = Passwort-Spray-Angriff) zu erkennen. Überwachen Sie auch die Systemmetriken des LoadMasters, um frühzeitig Engpässe zu erkennen. Kemp 360 Central (falls vorhanden) kann ein zentrales Monitoring für Kemp-Geräte liefern.
• Notfall-Bypass planen: Überlegen Sie einen Plan, falls der LoadMaster oder MFA-Dienst ausfällt. Z. B. könnte man einen temporären Direktzugang inszenieren (nicht ideal, aber als Backup). Besser: Setzen Sie auf HA (wie beschrieben) und halten Sie MFA-Backend redundant (z. B. zwei RADIUS-Server). Testen Sie die Fallbacks – Kemp kann mehrere RADIUS-Server in Prioritätsreihenfolge anlegen.
• Schulung und Dokumentation: Schulen Sie Administratoren auf der LoadMaster-Oberfläche, damit im Fehlerfall schnell reagiert werden kann. Dokumentieren Sie die Konfiguration gründlich (inkl. Screenshots der Einstellungen). Gerade MFA-Integrationen haben mehrere Komponenten – halten Sie fest, welche Versionen von RADIUS/IDP, AD etc. im Einsatz sind.
• Zukunftssicherheit: Evaluieren Sie gelegentlich neue Features. Z. B. bietet Kemp/Progress inzwischen Lösungen sm Richtung Zero Trust Access Gateway an, die vielleicht noch feinere Zugriffssteuerung ermöglichen. Auch Integration mit modernen Cloud-IdPs via SAML/OIDC könnte interessant sein, falls die Unternehmensstrategie sich ändert. Die hier implementierte Lösung ist flexibel – sie kann z. B. leicht angepasst werden, um statt eines RADIUS-OTP künftig Azure AD OAuth zu nutzen (durch Wechsel der ESP Auth-Methode auf SAML mit Azure IdP).

Mit diesem Vorgehensplan und den berücksichtigten Aspekten wird die Einführung des Kemp LoadMasters als MFA-Sicherheitslösung für SharePoint SE erfolgreich gelingen. Die SharePoint-Umgebung profitiert von erhöhter Sicherheit durch MFA und stabilerer Verfügbarkeit durch professionelles Load Balancing und hohe Ausfallsicherheit. Wichtig ist, kontinuierlich die Umgebung zu überwachen und die getroffenen Maßnahmen regelmäßig zu überprüfen, um sowohl Sicherheit als auch Performance auf Dauer zu gewährleisten.

Quellen: Die verwendeten Informationen stammen aus der offiziellen Kemp-Dokumentation und Erfahrung mit vergleichbaren Projekten, u. a. Kemp-Datenblätter, Whitepaper zu SharePoint-Architektur sowie Best-Practice-Berichten aus der Community (z. B. Reddit) zur Kerberos-Integration.

Weitere Beiträge zum Thema SharePoint