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

[Howard Chu <hyc [at] highlandsun.com>]

Aaron Hicks wrote:
> debug 7 provides some interesting results. In particular it looks like the
LDAP server is sending _responses_ to the search request that nss_ldap is
discarding. It's also clear that it's asking for attributes that aren't stored
in the AD, some I don't want to set (e.g. home directory, we have some servers
where it should be /home/user and others where it should be /export/home/user)
so I hope if nss is unable to set them, then the system defaults are used.

nss_ldap requires a uidNumber and gidNumber to be returned. Since your LDAP 
server isn't providing these attributes, it cannot generate a proper passwd 
entry for this user. By the way, you seem to have something else misconfigured 
since it is requesting displayName twice. But at least you know the problem is 
not in the authentication config of nss_ldap any more.

> Hmm, can't really mangle this one :P, this is a dump of the debug responses
>
> ldap_search
> put_filter: "(&(objectClass=user)(sAMAccountName=hicksa))"
> put_filter: AND
> put_filter_list "(objectClass=user)(sAMAccountName=hicksa)"
> put_filter: "(objectClass=user)"
> put_filter: simple
> put_simple_filter: "objectClass=user"
> put_filter: "(sAMAccountName=hicksa)"
> put_filter: simple
> put_simple_filter: "sAMAccountName=hicksa"
> ldap_build_search_req ATTRS:
>      sAMAccountName
>      userPassword
>      uidNumber
>      gidNumber
>      cn
>      unixHomeDirectory
>      loginShell
>      displayName
>      displayName
>      objectClass
> ldap_send_initial_request
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({) ber:
> ber_flush: 252 bytes to sd 3
>    0000:  30 81 f9 02 01 02 63 81  f3 04 31 64 63 3d 6c 61   0.ù...c.ó.1dc=la
>    0010:  6e 64 63 61 72 65 2c 64  63 3d 61 64 2c 64 63 3d   ndcare,dc=ad,dc=
>    0020:  6c 61 6e 64 63 61 72 65  72 65 73 65 61 72 63 68   landcareresearch
>    0030:  2c 64 63 3d 63 6f 2c 64  63 3d 6e 7a 0a 01 02 0a   ,dc=co,dc=nz....
>    0040:  01 00 02 01 01 02 01 1e  01 01 00 a0 2f a3 13 04   ........... /£..
>    0050:  0b 6f 62 6a 65 63 74 43  6c 61 73 73 04 04 75 73   .objectClass..us
>    0060:  65 72 a3 18 04 0e 73 41  4d 41 63 63 6f 75 6e 74   er£...sAMAccount
>    0070:  4e 61 6d 65 04 06 68 69  63 6b 73 61 30 7e 04 0e   Name..hicksa0~..
>    0080:  73 41 4d 41 63 63 6f 75  6e 74 4e 61 6d 65 04 0c   sAMAccountName..
>    0090:  75 73 65 72 50 61 73 73  77 6f 72 64 04 09 75 69   userPassword..ui
>    00a0:  64 4e 75 6d 62 65 72 04  09 67 69 64 4e 75 6d 62   dNumber..gidNumb
>    00b0:  65 72 04 02 63 6e 04 11  75 6e 69 78 48 6f 6d 65   er..cn..unixHome
>    00c0:  44 69 72 65 63 74 6f 72  79 04 0a 6c 6f 67 69 6e   Directory..login
>    00d0:  53 68 65 6c 6c 04 0b 64  69 73 70 6c 61 79 4e 61   Shell..displayNa
>    00e0:  6d 65 04 0b 64 69 73 70  6c 61 79 4e 61 6d 65 04   me..displayName.
>    00f0:  0b 6f 62 6a 65 63 74 43  6c 61 73 73               .objectClass
> ldap_write: want=252, written=252
>    0000:  30 81 f9 02 01 02 63 81  f3 04 31 64 63 3d 6c 61   0.ù...c.ó.1dc=la
>    0010:  6e 64 63 61 72 65 2c 64  63 3d 61 64 2c 64 63 3d   ndcare,dc=ad,dc=
>    0020:  6c 61 6e 64 63 61 72 65  72 65 73 65 61 72 63 68   landcareresearch
>    0030:  2c 64 63 3d 63 6f 2c 64  63 3d 6e 7a 0a 01 02 0a   ,dc=co,dc=nz....
>    0040:  01 00 02 01 01 02 01 1e  01 01 00 a0 2f a3 13 04   ........... /£..
>    0050:  0b 6f 62 6a 65 63 74 43  6c 61 73 73 04 04 75 73   .objectClass..us
>    0060:  65 72 a3 18 04 0e 73 41  4d 41 63 63 6f 75 6e 74   er£...sAMAccount
>    0070:  4e 61 6d 65 04 06 68 69  63 6b 73 61 30 7e 04 0e   Name..hicksa0~..
>    0080:  73 41 4d 41 63 63 6f 75  6e 74 4e 61 6d 65 04 0c   sAMAccountName..
>    0090:  75 73 65 72 50 61 73 73  77 6f 72 64 04 09 75 69   userPassword..ui
>    00a0:  64 4e 75 6d 62 65 72 04  09 67 69 64 4e 75 6d 62   dNumber..gidNumb
>    00b0:  65 72 04 02 63 6e 04 11  75 6e 69 78 48 6f 6d 65   er..cn..unixHome
>    00c0:  44 69 72 65 63 74 6f 72  79 04 0a 6c 6f 67 69 6e   Directory..login
>    00d0:  53 68 65 6c 6c 04 0b 64  69 73 70 6c 61 79 4e 61   Shell..displayNa
>    00e0:  6d 65 04 0b 64 69 73 70  6c 61 79 4e 61 6d 65 04   me..displayName.
>    00f0:  0b 6f 62 6a 65 63 74 43  6c 61 73 73               .objectClass
> ldap_result ld 0x1488d380 msgid 2
> ldap_chkResponseList ld 0x1488d380 msgid 2 all 1
> ldap_chkResponseList returns ld 0x1488d380 NULL
> wait4msg ld 0x1488d380 msgid 2 (timeout 30000000 usec)
> wait4msg continue ld 0x1488d380 msgid 2 all 1
> ** ld 0x1488d380 Connections:
> * host: markshaw.landcare.ad.landcareresearch.co.nz  port: 389  (default)
>    refcnt: 2  status: Connected
>    last used: Fri Jun 26 15:52:38 2009
>
> ** ld 0x1488d380 Outstanding Requests:
>   * msgid 2,  origid 2, status InProgress
>     outstanding referrals 0, parent count 0
> ** ld 0x1488d380 Response Queue:
>     Empty
> ldap_chkResponseList ld 0x1488d380 msgid 2 all 1
> ldap_chkResponseList returns ld 0x1488d380 NULL
> ldap_int_select
> read1msg: ld 0x1488d380 msgid 2 all 1
> ber_get_next
> ldap_read: want=8, got=8
>    0000:  30 84 00 00 01 1b 02 01                            0.......
> ldap_read: want=281, got=281
>    0000:  02 64 84 00 00 01 12 04  61 43 4e 3d 41 61 72 6f   .d......aCN=Aaro
>    0010:  6e 20 48 69 63 6b 73 2c  4f 55 3d 49 6e 74 65 72   n Hicks,OU=Inter
>    0020:  6e 61 6c 2c 4f 55 3d 55  73 65 72 73 2c 4f 55 3d   nal,OU=Users,OU=
>    0030:  41 63 63 6f 75 6e 74 73  2c 44 43 3d 6c 61 6e 64   Accounts,DC=land
>    0040:  63 61 72 65 2c 44 43 3d  61 64 2c 44 43 3d 6c 61   care,DC=ad,DC=la
>    0050:  6e 64 63 61 72 65 72 65  73 65 61 72 63 68 2c 44   ndcareresearch,D
>    0060:  43 3d 63 6f 2c 44 43 3d  6e 7a 30 84 00 00 00 a9   C=co,DC=nz0....©
>    0070:  30 84 00 00 00 3c 04 0b  6f 62 6a 65 63 74 43 6c   0....<..objectCl
>    0080:  61 73 73 31 84 00 00 00  29 04 03 74 6f 70 04 06   ass1....)..top..
>    0090:  70 65 72 73 6f 6e 04 14  6f 72 67 61 6e 69 7a 61   person..organiza
>    00a0:  74 69 6f 6e 61 6c 50 65  72 73 6f 6e 04 04 75 73   tionalPerson..us
>    00b0:  65 72 30 84 00 00 00 17  04 02 63 6e 31 84 00 00   er0.......cn1...
>    00c0:  00 0d 04 0b 41 61 72 6f  6e 20 48 69 63 6b 73 30   ....Aaron Hicks0
>    00d0:  84 00 00 00 20 04 0b 64  69 73 70 6c 61 79 4e 61   .... ..displayNa
>    00e0:  6d 65 31 84 00 00 00 0d  04 0b 41 61 72 6f 6e 20   me1.......Aaron
>    00f0:  48 69 63 6b 73 30 84 00  00 00 1e 04 0e 73 41 4d   Hicks0.......sAM
>    0100:  41 63 63 6f 75 6e 74 4e  61 6d 65 31 84 00 00 00   AccountName1....
>    0110:  08 04 06 48 69 63 6b 73  41                        ...HicksA
> ber_get_next: tag 0x30 len 283 contents:
> read1msg: ld 0x1488d380 msgid 2 message type search-entry
> wait4msg ld 0x1488d380 30 secs to go
> wait4msg continue ld 0x1488d380 msgid 2 all 1

> > For situations like this I prefer to use debug 7 to see the actual
> > network
> > data. It looks like an entry was actually received, from the previous
> > output.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/