Re: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)

[Buchan Milne <bgmilne [at] mandriva.org>]

On Thursday 25 June 2009 11:11:35 Guillaume Rousse wrote:
> Aaron Hicks a écrit :
> > Hope someone here can help.
>
> You'd better test nss first, and pam second. As long as 'getent
> password' doesn't list you all known users, that's no use to try to
> autenticate them.
>
> Various hints:
> - use 'debug 1' in your nss_ldap configuration file.
> - check if there is any difference using anonymous or authenticated binding
> - check if there any difference between tls (port 389), ssl (port 636),
> and unencrypted connection (warning, unspecified configuration values in
> nss_ldap configuration, such as tls_checkpeer, will usually use nss_ldap
> default values, not use openldap library values, such as TLS_REQCERT
> never in your case)
> - check your ldap server logs
>
> I have no clue what eDirectory is, but if it is just a branding name
> over openldap, you can perfectly tune its access policy as needed. I
> doubt it really enforce the use of encryption for connection, rather for
> autentication only.

eDirectory is Novell's directory server (historically, NDS), which later 
(after the bindery days) got an LDAP interface.

The error message provided however looks very much like MS Active Directory.

> Also, take care than ubuntu (Debian, actually) doesn't use a unique
> configuration file for nss_ldap and pam_ldap (/etc/ldap.conf), but two
> distinct ones (/etc/libnss_ldap and /etc/libpam_ldap, from memory).
> [..]

AFAIR, modern releases of Ubuntu have reverted to a single /etc/ldap.conf.

>
> > ===========Config files from here on========
> >
> > My /etc/ldap.conf looks like (omitting sections left as default):
> >
> > <defaults omitted>
> > # The distinguished name of the search base.
> > base
>
> An empty base will not help. maybe nss_ldap use openldap default
> configuration in this case, but I would not rely on it.

I would also prefer to see the entire ldap.conf without comments (but, 
including any "defaults"), rather than missing some potentially important 
values that are maybe at incorrect defaults. Also, please do consistent (e.g. 
perl -pe 's/dc=myrealdomain,dc=com/dc=example,dc=com') mangling of your 
configuration file, as this looks suspect:

binddn "cn=User 
Name,ou=internal,ou=users,ou=accounts,cn=,dc=our,dc=long,dc=domain,dc=co,dc=nz"

(this is not a valid DN, as there is an attribute without a value)

Now, I am unsure if your original value is correct or not.

Regardless, if there is not some simple mistake like the above, running 
'getent passwd user_in_ldap' (where user_in_ldap is the samAccount value of a 
user in AD) with debugging enabled in nss_ldap would be more enlightening.

Regards,
Buchan