In vielen Systemen werden LDAP Abfragen verwendet, um im Directory Informationen abzufragen. Sei es, um die User Zugehörigkeit einer Gruppe abzufragen oder weil die Appliance wissen muss, ob der User überhaupt existiert. Der Einsatz von LDAP ist weit verbreitet und mit LDAPS bietet das Protokoll auch eine Verschlüsselung an, um die Abfragen und Informationen auf dem Transportweg zu sichern.
Nutzt man das Azure AD (AAD), gibt es diese Option generell nicht. Sie kann jedoch im AAD Domain Service eingerichtet werden. Dies ist ein Service, welcher es erlaubt via LDAPS Anfragen zu stellen bzw. Informationen vom Azure AD abzufragen.
In diesem Artikel möchte ich kurz die «Installation» und Konfiguration des Domain Services (DS) aufzeigen und zeigen, wie dieser getestet und möglicherweise eingesetzt werden kann. Wichtig ist, durch die Installation werden zusätzliche Ressourcen installiert / konfiguriert, welche Kosten auf Seiten Azure verursachen können (azure.microsoft.com/en-gb/pricing/details/active-directory-ds/).
Nun zur Installation / Konfiguration
Bevor wir loslegen, muss sichergestellt werden, dass die folgenden Punkte erfüllt sind:
-
- Azure Portal Benutzer mit den «Application Administrator», «Domain Services Contributor” und «Groups Administrator» Rollen
- Aktive Azure Subscription
- Azure Active Directory Tenant
- Virtuelles Netzwerk mit DNS Server, welches die notwendigen Ziele auflösen kann
Kann bei diesen Punkten überall einen Haken gesetzt werden, kann mit der Erstellung des AAD DS begonnen werden.
- Im Azure Portal eine neue “Resource” erstellen mittels „Create a resource“.
- Im neuen Fenster dann nach „Azure AD Domain Services“ suchen und auswählen.
- Danach noch mit „Create“ bestätigen.
- Nun folgt die Konfiguration des Domain Services. Hierbei müssen verschiedene Informationen angegeben werden und vor allem die Domäne, welche verwaltet werden soll. Mit „Next“ zur nächsten Seite.
- Der Wizard erstellt automatisch neue Netze. Falls ein bereits bestehendes oder ein anderes Netz verwendet werden soll, kann dies hier angepasst werden.
- Automatisch werden alle Globalen Admins vom Azure AD auch in die neu erstellte AAD DC Administrators Gruppe aufgenommen. Wenn dies nicht gewünscht ist, kann dies angepasst werden.
- Im nächsten Schritt kann angepasst werden, was überhaupt in den Domain Service übertragen werden soll.
- Sicherheitseinstellungen – hier müssen wenn nötig die Default Einstellungen angepasst werden z.B. das nur TLS 1.2 verwendet werden soll.
- Für die Abrechnung kann noch ein Tag gesetzt werden:
- Zum Schluss gibt es noch eine Übersicht. Wenn alles okay ist, mit „Create“ fortfahren.
- Es wird nochmals darauf hingewiesen, dass diese Einstellungen nicht angepasst werden können!
- Nun startet Azure mit dem Deployen. Dies kann je nach Azure Subscription über eine Stunde dauern!
- Azure gibt dann an, wenn das Deployment beendet worden ist.
Konfigurieren von LDAPS
- Wechsle zur erstellten «Resource» und dort unter Settings ⇒ Secure LDAP. Hier kann das LDAPS eingeschaltet werden.
- Nun muss man ein Zertifikat hinterlegen und es kann auch aktiviert werden, dass von Extern zugegriffen werden darf – hierfür braucht es dann noch eine Firewall Regel (kurze Anleitung zur Erstellung eines Zertifikates mit Powershell: docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps).
- Unter Properties findet man dann die externe IP Adresse und auch die Sicherheitsgruppe, in welcher der Zugriff erlaubt werden muss. Es kann direkt auf den Namen geklickt werden und man gelangt somit zu den Sicherheitsregeln.
- Auf der linken Seite „Inbound security rules“ auswählen und mit „Add“ eine neue Rule erstellen:
Bei uns ist unsere Labor IP hinterlegt.
LDAB Bind User
Es empfiehlt sich, für die LDAP-Abfragen einen eigenen User im Azure AD anzulegen. Bei den Gruppen und Rollen genügt die „Directory readers“ Rolle.
Testen der Verbindung
Um die Konfiguration zu testen, kann man versuchen, sich mit einem LDAP Browser zu verbinden. Die IP findet man unter den Properties des Azure AD Domain Services und Port ist der TCP/636.
Der Distinguished Name für den LDAB Bind User sieht ca. so aus: CN=ldapbind,OU=AADDC Users,DC=test,DC=lab,DC=ch
Ist der Test erfolgreich, findet man die eigenen User in der OU AADDC Users.
SEPPmail – Custom Command
Beim Custom Command braucht es eine wichtige Anpassung, da bei Azure AD im Feld „sAMAccountName“ nicht die Mailadresse hinterlegt ist, muss hier der „userPrincipalName“ verwendet werden. Sonst wird der User nicht korrekt erstellt auf der SEPPmail.
Anbei ein Beispiel für einen LDAP Bind im Custom Command auf der SEPPmail:
setvar('ldap_bind','ldaps://IPADDRESSE:636;CN=ldapuser,OU=AADDC Users,DC=test,DC=lab,DC=ch;LDAPUSERPASSWORT;OU=AADDC Users,DC=test,DC=lab,DC=ch;(mail=$header_from)');
IronPort – LDAP Anbindung
Bei der IronPort gibt es keinen grossen Unterschied. Bei den Tests konnte ich jedoch die externe Authentisierung für die SPAM Quarantäne etc. nicht erfolgreich testen für andere User.
Auf der ESA selber konnte ich die SPAM Quarantäne Anmeldung für alle User noch nicht erfolgreich testen. Deshalb habe ich diese in diesem Artikel nicht abgebildet. Sobald ich dies auch mit Azure AD durchführen bzw. konfigurieren konnte, werde ich diesen Artikel udpaten.
Falls zu dieser Thematik oder bei der Umsetzung Unterstützung benötigt wird, stehen wir euch gerne zur Verfügung.
Bender
Bender ist Security Engineer bei AVANTEC. Er hat grosses Interesse an der Welt der E-Mails und den verschiedenen Produkten wie IronPort, SEPPmail und Symantec.cloud. Weiter ist er ein stolzer Serienjunkie und Gamer.