LDAP-Server identifizieren
Immer wieder ist es erforderlich per LDAP-Abfrage zu ermitteln mit welcher Software ein fremder LDAP-Server betrieben bzw. welche LDAP-Server-Implementation genau eingesetzt wird. Doch leider gibt es dafür keinen standardisierten Weg, da die LDAP-Spezifikation selbst dies nicht zwingend oder eindeutig vorgibt – nachfolgend daher Hinweise und Beispiele:
Bei LDAP in der heutzutage üblicherweise eingesetzten Version handelt es sich um LDAPv3 welches in RFC 2251 spezifiziert ist. Im Abschnitt 3.4 wird festgelegt welche Informationen ein LDAP-Server in der sogenannten „root DSE“ über sich selbst mitteilen muss. Das Problem hierbei ist, dass zwar u.a. mitgeteilt werden müssen welche Fähigkeiten, Erweiterungen und Protokollversionen unterstützt werden, nicht jedoch der Produktname bzw. die eingesetzte Version des LDAP-Servers selbst. Immerhin wurden als Teil von RFC 3045 die Attribute vendorName und vendorVersion nachträglich noch hinzugefügt, allerdings müssen diese Attribute leider nicht verpflichtend gesetzt sein.
Trotzdem können die gängigen Server-Implementationen verhältnismäßig einfach unterschieden werden; ein OpenLDAP-Server kann als solcher zumindest sehr zuverlässig identifiziert werden, wenn gleich die Version unklar bleibt:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
objectClass: top
objectClass: OpenLDAProotDSE
robert@tux:~ >
Der 389 Directory Server, früher „Fedora Directory Server“, ist eine Weiterentwicklung des „Netscape Directory Servers“ und identifiziert sich erfreulicherweise mit den Attributen vendorName und vendorVersion:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
vendorName: 389 Project
vendorVersion: 389-Directory/1.3.7.5 B2018.178.1311
objectClass: top
robert@tux:~ >
Samba 4 liefert eine eigene LDAP-Server-Implementation mit aus, die sich ebenfalls mit den Attributen vendorName und vendorVersion zuverlässig identifizieren lässt:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
vendorName: Samba Team (http://samba.org)
vendorVersion: 4.6.16-SerNet-RedHat-16.el7
isGlobalCatalogReady: TRUE
robert@tux:~ >
Das Original hingegen, der proprietäre Microsoft Active Directory Server (ADS), gibt sich eher schweigsam und kann nur mittels des Attributs isGlobalCatalogReady in Verbindung mit den fehlenden Attributen vendorName bzw. vendorVersion von Samba 4 unterschieden werden:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
isGlobalCatalogReady: TRUE
robert@tux:~ >
Der ebenfalls proprietäre Oracle Directory Server, früher „Sun Java System Directory Server“, davor „Sun ONE Directory Server“, davor „iPlanet Directory Server“ ist auch eine Weiterentwicklung des „Netscape Directory Servers“, weshalb vermutlich die Attribute vendorName und vendorVersion zur Identifikation herangezogen werden können:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
vendorName: Oracle Corporation
vendorVersion: Sun-Directory-Server/11.1.1.7.2
objectClass: top
robert@tux:~ >
Eine weitere proprietäre LDAP-Server-Implementation ist „Atos DirX Directory“, früher „Siemens DirX“, welche inzwischen auch als „Evidian DirX Directory“ vermarktet wird. Zwar wirkt objectClass: subEntry seltsam, dennoch sind die Attribute vendorName und vendorVersion vorhanden:
robert@tux:~ > ldapsearch -x -LLL -b '' -s base '(objectClass=*)' vendorName vendorVersion objectClass isGlobalCatalogReady
dn:
objectClass: ldapRootDSE
objectClass: subEntry
objectClass: top
vendorName: Atos IT Solutions and Services GmbH
vendorVersion: DirX Directory V8.6 9.2.278 2018:05:07 01:10 64-Bit
robert@tux:~ >
Selbstverständlich gibt es noch diverse weitere LDAP-Server, welche die obenstehende Liste vervollständigen könnten, jedoch hatte ich bei diesen bislang nicht die Möglichkeit für eine entsprechende LDAP-Abfrage. Das wiederum ist mindestens teilweise dem Umstand geschuldet, dass eben diese Server-Implementationen entweder proprietär sind oder kaum relevante Marktanteile haben.