Die Cloud-Computing-Plattform Microsoft Azure ist sehr beliebt, und viele Kunden migrieren inzwischen aus verschiedensten Gründen diverse IT-Komponenten dorthin. Auch die SEPPmail-Appliance lässt sich in Azure betreiben. Azure bietet einige Möglichkeiten, den Betrieb flexibel zu gestalten, und passt besonders in Microsoft 365-Umgebungen wunderbar in das Gesamtbild einer „cloud-native“ IT. Je „nativer“ die Cloud-Umgebung gestaltet wird, desto weniger funktionieren Technologien aus klassischen On-Premises-Infrastrukturen. Ein Beispiel dafür ist das Lightweight Directory Access Protocol (LDAP), ein universal definierter Dienst für Verzeichnisabfragen, den die SEPPmail-Appliance für die Abfrage von Benutzerberechtigungen verwendet. Kunden, die das Azure Active Directory (AAD) ohne ein lokal synchronisiertes Active Directory im Einsatz haben, können LDAP nicht verwenden, da das AAD kein LDAP mehr anbietet. Für solche Fälle gibt es jedoch eine Lösung: den Betrieb von Azure Active Directory Domain Services (ADDS), die ein AD in Azure simulieren und LDAP-Zugriffe erlauben. Dieser Blogbeitrag beschreibt die Architektur eines solchen Szenarios und gibt Hinweise für die Einrichtung.

Ausgangssituation

Von einer in Azure eingerichteten SEPPmail-Appliance sollen Berechtigungsabfragen mittels LDAP durchgeführt werden, um zu steuern, welche Benutzer SEPPmail-Features verwenden dürfen. Die SEPPmail-Appliance läuft in einer Azure Subscription und ist an ein Azure Virtual Network (VNET) angebunden.

Alle Benutzer, die abgefragt werden sollen, befinden sich im Azure Active Directory dieser Subscription. Dieses AAD wird nicht von einem On-Prem Active Directory synchronisiert, sondern die Einrichtung erfolgte in der Cloud.

Im Feld „E-Mail-Adresse“ der AAD-Benutzer ist ein Wert eingetragen (anhand einer Exchange Online-Anbindung).

Zielsituation

Ein ADDS ist eingerichtet, es existiert ein Benutzer mit Leserechten auf das Verzeichnis, und es gibt Benutzergruppen (Office 365 oder AAD Security) mit Usern, die mittels LDAP abgefragt werden.

Die SEPPmail-Appliance kann via LDAP auf die Benutzergruppen zugreifen und Abfragen durchführen.

Umsetzung

Das Einrichten des ADDS ist in der Dokumentation von Microsoft sehr gut beschrieben und wird stetig aktualisiert. Daher verweisen wir an dieser Stelle auf die originalen Links:

Azure Domain Services Deployment

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance

Peer Networks

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-networking

Use Management Tools to Administer ADDS

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-management-vm

Nachdem diese Schritte umgesetzt wurden, existieren gemäß dem unten stehenden Schema folgende neue Komponenten in Azure:

  • Eingerichtetes ADDS. bestehend aus
    • zwei Domain-Controllern (10.0.0.4 und 10.0.0.5)
    • ADDS-VNET
    • automatische Synchronisierung der Benutzer aus dem AAD
  • VNET Peering zwischen dem VNET der SEPPmail-Appliance und dem ADDS-VNET
  • Auf Wunsch adaptierte Network Security Group zur Einschränkung des Zugriffs auf das ADDS

Im Abschnitt „User-Management Tools to administer ADDS“ muss unbedingt getestet werden, ob native LDAP-Zugriffe über Port 398 funktionieren. Außerdem ist von der SEPPmail-Appliance aus zu testen, ob eine Verbindung über Port 398 auf einen der Domain Controller (z.B. 10.0.0.4) funktioniert (siehe SEPPmail-Handbuch „Administrative Aufgaben > Rudimentäre Systembefehle“).

Hinweise für die Umsetzung

  • Der LDAP-Zugriff funktioniert nicht
    Bei unseren Tests haben wir versucht, die Zertifikate des ADDS in die SEPPmail einzuspielen. Dies ist jedoch gescheitert, da sie „Self-Signed“ sind. Daher erfolgt der Zugriff mittels LDAP. Die Verbindung zwischen ADDS und der SEPPmail muss dementsprechend mit Azure-Bordmitteln (Network Security Groups oder Ähnliches) gesichert werden, um den Verkehr zu schützen.
  • Benutzer für den LDAP-Zugriff
    Wir empfehlen, einen Benutzer im LDAP Reader im Azure AD anzulegen, der ausschließlich die Rolle „Directory Readers“ hat. Dieser Benutzer sollte dann für den Zugriff verwendet werden.
  • Test-VM eingerichtet lassen
    Microsoft empfiehlt für die Einrichtung eine Test-VM, die auch ADDS-Domain-Joined ist. Diese VM sollte eingerichtet werden, um später Tests durchführen zu können.
  • Kosten
    Beim Betrieb eines Azure Active Directory Domain Service fallen zusätzliche Kosten an:
    • AD Domain Service
    • VNET
    • LDAP-Test-VM

Preise für diese Ressourcen sind im Azure Pricing Calculator zu finden.

ADDS ist als Zusatz bei Azure AD zu finden.

Die VM gibt es bei Azure Compute.

VNET und VNET-Peering sind bei Networking zu finden.

  • LDAP-Abfragen auf eine IP-Adresse geben auch den Rechnernamen zurück. Dieser lässt sich ebenfalls anstatt der IP-Adresse verwenden.

Beispielabfragen

Testabfrage von der Test-VM

Um die LDAP-Funktion auszuprobieren, sollte die Abfrage unten ausreichen. Die Benutzernamen und Passwörter sowie die Domäne sind entsprechend anzupassen.

Custom Command Beispiel