Active Directory LDAP Verbindung über Port 636 funktioniert nicht - AD LDAP connection via port 636 not possible

Hallo zusammen,

ich möchte gerne eine Apptec Installation (EMM System) mit Active Directory LDAP verbinden.
Dabei bin ich auf das Problem gestoßen, dass ich mich über Port 636 nicht mit dem LDAP verbinden kann.

Das Programm “Active Directory-kompatibler Domänencontroller” ist installiert.
Das Active Directory scheint grundsätzlich zu funktionieren, jedenfalls kann ich erfolgreich:
- mit Windows Geräten der Domäne beitreten
- Mich mit den Nutzern an den Geräten anmelden
- GPOs definieren und nutzen

Der Domain-Controller ist auf die neueste Version aktualisiert (5.0-4 errata779).
Ich habe entsprechend der Anleitung einen LDAP Nutzer “Einfaches Authentifizierungskonto” eingerichtet. (Das Problem besteht aber auch mit dem Administrator Account)

Mittels ldapsearch habe ich die Verbindung sowohl auf dem Domain-Controller (UCS) als auch auf einem Lunux-Client, der nicht Teil der Domäne ist, getestet. (Das UCS root Zertifikat ist auf diesem Rechner, wie auch auf der Apptec-Appliance, installiert)

In beiden Fällen ist die Verbindung über Port 7636 erfolgreich.
Über Port 636 erhalte ich folgende Fehlermeldung:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

Hier der verwendete Befehl:
ldapsearch -x -H ldaps://[host].[domain].[tld]:636 -D "uid=[username],cn=users,dc=[domain],dc=[tld]" -b "dc=[domain],dc=[tld]" -w [password]

Bei der Verbindung in Apptec erhalte ich bei Port 7636 folgende Fehlermeldung:

Connection successfully established. Remote Host is no Active Directory Server. Failed to Fetch ‘objectguid’ Attribute for BaseNode.

Der Fehler ist zu erwarten, da Apptec ein Active Directory und nicht OpenLDAP erwartet.

Bei der Verbindung in Apptec über Port 636 erhalte ich folgende Fehlermeldung:

0x31 (Invalid credentials; 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1)

Diese Meldung ist Deckungsgleich zur Fehlermeldung beim Testen mittels ldapsearch.

in /var/log/auth.log erhalte ich folgenden Eintrag:

Aug 15 16:28:34 [host] ldapsearch: DIGEST-MD5 common mech free

Bei der Suche danach stoße ich jedoch nur auf Probleme, bei denen baseDN oder Nutzer nicht richtig konfiguriert waren.


Muss hier grundsätzlich die Abfrage über Active Directory anders erfolgen?
Oder sollten eigentlich die gleichen Daten wie bei der Verbindung über Port 7636 funktionieren? (Das erwarte ich nämlich aktuell)
Wo kann ich die Fehlersuche fortsetzen?


– ENGLISH VERSION –

Hello all,

I would like to connect an Apptec installation (EMM system) with Active Directory LDAP.
In doing so, I have encountered the problem that I cannot connect to the LDAP via port 636.

The program “Active Directory-compatible domain controller” is installed.
The Active Directory seems to work, at least I can successfully:
- join the domain with Windows devices
- Log on to these devices with the domain users
- Define and use GPOs

The domain controller is updated to the latest version (5.0-4 errata779).
I have set up an LDAP user “Einfaches Authentifizierungskonto” according to the instructions. (However, the problem also exists with the administrator account).

Using ldapsearch, I tested the connection both on the domain controller (UCS) and on a Lunux client that is not part of the domain. (The UCS root certificate is installed on this machine, as well as on the Apptec appliance).

In both cases, the connection via port 7636 is successful.
Via port 636 I receive the following error message:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

Here is the command used:
ldapsearch -x -H ldaps://[host].[domain].[tld]:636 -D "uid=[username],cn=users,dc=[domain],dc=[tld]" -b "dc=[domain],dc=[tld]" -w [password]

When connecting within Apptec, I get the following error message at port 7636:

Connection successfully established. Remote Host is no Active Directory Server. Failed to Fetch ‘objectguid’ Attribute for BaseNode.

The error is to be expected as Apptec expects an Active Directory and not OpenLDAP.

When connecting within Apptec via port 636, I get the following error message:

0x31 (Invalid credentials; 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1)

This message is identical to the error message when testing with ldapsearch.

In /var/log/auth.log I get the following entry:

Aug 15 16:28:34 [host] ldapsearch: DIGEST-MD5 common mech free

However, when searching for this, I only come across problems where baseDN or users were not configured correctly.


Does the query via Active Directory have to be done differently here?
Or should the same data actually work as with the connection via port 7636? (which is what I currently expect)
Where can I continue with troubleshooting?

if you want ad search then you should use cn=username instead of uid infront of the user
uid is only for ldap not ad afaik

rg
Christian

Hi Christian,
thank you very much for pointing that out. Unfortunately that did not solve the problem, but maybe it is a piece of the puzzle…

I have also had some cases , with external systems not being abler to connect to the LDAP when used in AD mode.
636…

they just will not connect , I spoke with one manufacturer and they were saying that the systems are programmed too tightly as regards to the AD requirements… , the will only deal with MS ad’s since the code in many cases is hand crafted to specific responses and fall backs.

you might try “wire shark” for both original & SAMBA systems , to try & spot it that way.

Thank you very much for your help, I managed to solve the issue, at least sort of…

First of all the solution:
Using “CN=” instead of “UID=” was part of the issue, the other part was that the user type “Einfaches Authentifizierungskonto” did not work for the AD connection.
I had to add a real user who is part of the “Schema Admins” Group. With that user, authentication works now.

This leads to a new question:
Is there a way to give only “schema read” permissions for a regular user?
The expected outcome would be, that this user could read the LDAP schema but not change it.

Mastodon