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

[Aaron Hicks <HicksA [at] landcareresearch.co.nz>]

Thanks Buchan.

The bits I've snipped out of ldap.conf were all commented out, and the errors 
pointed out were due to me manually mangling the parts that violate our 
policies for submitting to public lists. I'll be more careful.

I've made a couple of changes which deal with the exessive delays on failed 
connections in ldap.conf:

debug 1
bind_policy soft
tls_checkpeer no
nss_connect_policy oneshot

Looking at the debug messages it looks a lot like nss_ldap is failing to bind 
to LDAP on the AD server. I've requested a user account for searching the 
domain which doesn't have a space in its name.

And here's the debugging info from getent

[root@centos ~]# getent passwd user
ldap_create
ldap_url_parse_ext(ldap://ldap.our.long.domain.co.nz)
ldap_create
ldap_url_parse_ext(ldap://ldap.our.long.domain.co.nz)
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.our.long.domain.co.nz:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying x.x.x.x:389
ldap_connect_timeout: fd: 3 tm: 10 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush: 121 bytes to sd 3
ldap_result ld 0x49d1310 msgid 1
ldap_chkResponseList ld 0x49d1310 msgid 1 all 0
ldap_chkResponseList returns ld 0x49d1310 NULL
wait4msg ld 0x49d1310 msgid 1 (timeout 10000000 usec)
wait4msg continue ld 0x49d1310 msgid 1 all 0
** ld 0x49d1310 Connections:
* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Jun 26 10:11:04 2009

** ld 0x49d1310 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x49d1310 Response Queue:
   Empty
ldap_chkResponseList ld 0x49d1310 msgid 1 all 0
ldap_chkResponseList returns ld 0x49d1310 NULL
ldap_int_select
read1msg: ld 0x49d1310 msgid 1 all 0
ber_get_next
ber_get_next: tag 0x30 len 103 contents:
read1msg: ld 0x49d1310 msgid 1 message type bind
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
ldap_chase_referrals
read1msg:  V2 referral chased, mark request completed, id = 1
new result:  res_errno: 49, res_error: <80090308: LdapErr: DSID-0C090334, 
comment: AcceptSecurityContext error, data 525, vece>, res_matched: <>
read1msg: ld 0x49d1310 0 new referrals
read1msg:  mark request completed, ld 0x49d1310 msgid 1
request done: ld 0x49d1310 msgid 1
res_errno: 49, res_error: <80090308: LdapErr: DSID-0C090334, comment: 
AcceptSecurityContext error, data 525, vece>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_err2string
ldap_unbind
ldap_free_connection 1 1
ldap_send_unbind
ber_flush: 7 bytes to sd 3
ldap_free_connection: actually freed
ldap_err2string


> -----Original Message-----
> From: owner-nssldap@padl.com [owner-nssldap [at] padl.com] On Behalf
> Of Buchan Milne
> Sent: Friday, 26 June 2009 1:30 a.m.
> To: Guillaume Rousse
> Cc: pamldap@padl.com; nssldap@padl.com
> Subject: Re: [nssldap] pam_ldap and nss_ldap can't connect to LDAP
> server(s)
>
> 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=c
> o,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

Please consider the environment before printing this email
Warning:  This electronic message together with any attachments is 
confidential. If you receive it in error: (i) you must not read, use, disclose, 
copy or retain it; (ii) please contact the sender immediately by reply email 
and then delete the emails.
The views expressed in this email may not be those of Landcare Research New 
Zealand Limited. http://www.landcareresearch.co.nz