LDAP Connection Issue

Hi there,

I just installed UCS with Active Directory-compatible Domain Controller module only.

I also just installed OpenMediaVault with its Directory Service plugin.

I wish to integrate OpenMediaVault with UCS Domain Controller but it seems not working.


Details:

IP: 10.20.30.40
domain: dc.mydomain.com
Port: 389
User: Administrator (UCS default)
Enabled the Simple Authentication
DN: DC=mydomain,DC=com


but it returned an error too…

With LDAPAdmin, anonymous test connection was successful.


May I know what am I missing here? Thanks so much in advance.

Hello,

the DN of Administrator is normally cn=Administrator,cn=users,dc=mydomain,dc=com

But for joining OpenMediaVault to UCS should create a host account from type Linux for it with the UMC. You also must set the password manually.

Hi there,

I was able to connect LDAP Admin to my UCS Domain but only with GSS-API or GSS Negotiate…

Is there a way to set the connection type to GSS? Thanks

Hello, I have exactly the same problem.

  • installed UCS with Active Directory-compatible Domain Controller module only.
  • installed OpenMediaVault with its Directory Service plugin.
  • created host account from type Linux in UMC
  • set the password for the UCS User " Administrator" (overwritten, ignored PW history)

But OpenMediaVault cant find the LDAP Server. I tryed Port 389 without SSL, 7389, 638 wit SSL.

Does someone has experience with this setup?

Hey,

on a UCS server there are actually two LDAP servers listening:

[ul][li]Samba on ports 389 (unencrypted or with StartTLS) and 636 (SSL encrypted)[/li]
[li]OpenLDAP on ports 7389 (unencrypted or with StartTLS) and 7636 (SSL encrypted)[/li][/ul]

Both contain roughly the same data; the Univention S4 Connector service is used for synchronizing that. However, the schemas used are similar but slightly different. For example, the DN for the user “administrator” is “uid=Administrator,cn=users,$base_dn” in the OpenLDAP variant and “cn=Administrator,cn=users,$base_dn” in the Samba variant.

The most important difference between the two is how group membership is handled. In OpenLDAP group membership is usually only noted in the group’s object but not in the user’s object (this is similar to how local accounts are handled; group membership is listed in “/etc/group” but not in “/etc/passwd”). In Samba the group membership is part of the user object.

This means that whenever you want to filter user objects by their group membership (e.g. in order to grant access to certain groups only) you’re much better off using the Samba LDAP server.

Other important differences include how login is handled. In OpenLDAP you have to bind with a full DN, e.g. “uid=Administrator,cn=users,$base_dn”. In Samba you can also use the syntax “domainusername” or “username@fqdn”, e.g. “linetadministrator” or "administrator@bs.linet-services.de" for our internal domain.

Another thing that can fail is encryption. Recent UCS versions only allow binds to both of the LDAP directories if they’re done over an encrypted connection. This means that the client has to use StartTLS when connecting on ports 389 or 7389 and SSL when connecting on ports 636 or 7636. Now the usual restraint of “the certificate’s common name must match the server name used to connect” comes into play (similar to how web browsers will throw a warning when you use google.com/).

Based on this information there are several things that I can see are wrong:

[ul][li]raleigh uses port 389 (the Samba LDAP) but no encryption; binds won’t be allowed in such a configuration.[/li]
[li]raleigh uses an IP address as the host name. This will likely break encryption even if it is turned on.[/li]
[li]raleigh uses “ou=Users” and “ou=groups” as the contains for users and groups, but they’re actually called “cn=users” and “cn=groups” in the Samba LDAP. Use “univention-s4search” to search through the Samba LDAP and look such things up.[/li]
[li]lex uses an IP address as the host name. This will likely break encryption.[/li][/ul]

In both cases I highly suggest that you actually test these settings with the “ldapsearch” command line tool. For example, lex could try the following command with his/her current settings:

ldapsearch -x -H ldaps://192.168.10.100:636/ -b dc=meine,dc=domain -D cn=administrator,cn=users,dc=meine,dc=domain -W

You should then getter a better picture of what’s wrong. For example, “invalid credentials” means that the bind DN and/or password is wrong. “Can’t contact LDAP server” can mean that the address is wrong or that the TLS/SSL certificate validation failed (agian, use a host name mentioned in the certificate’s common name, not an IP address).

Kind regards,
mosu

hi i have the same problem:
My stand Alone Nextcloud server has no problem to connect to ldap

ldap nextcloud

The same settings in Openmediavault
omv ldap settings
And the log
omv ldap log

When i disable the SSL/TLS Option in OMV the log is empty but i cant see any ldap users

Can someone help me
Do you have now a working configuration between OMV and UCS ??

Sorry for my bad English :slight_smile:

Did someone resolve this issue?

Have you done this setup ? Please confirm. I am also facing same issue and willing to fix asap.

echo “TLS_REQCERT allow” >> /etc/ldap/ldap.conf
echo “ssl start_tls” >> /etc/libnss-ldap.conf
echo “ssl start_tls” >> /etc/pam_ldap.conf

thanks to https://forum.openmediavault.org/index.php/Thread/14041-LDAP-Connection-Issue/

Mastodon