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
