pam_ldap and nss_ldap can't connect to LDAP server(s)

[Aaron Hicks]

Hello the list,

I've been trying to authenticate linux logins with Ubuntu and CentOS using LDAP against our Novell eDirectory or our Active Directory. CentOS is more important to us as it's distribution used in some of our pre-packaged server installs.

The packages openldap_clients and nss-ldap (for CentOS) are installed and up to date (using yum).

The configuration on /etc/openldap/ldap.conf works and I can use ldapsearch to bind and search our directories freely from the command line.

/etc/openldap/ldap.conf
URI ldap://ldap.our.long.domain.co.nz
BASE dc=our,dc=long,dc=domain,dc=co,dc=nz
TLS_REQCERT never

When you do:

ldapsearch -x ""

The LDAP server (A Windows Server 2003 Domain Controller) responds with:

# extended LDIF
#
# LDAPv3
# base <dc=our,dc=long,dc=domain,dc=co,dc=nz> (default) with scope subtree
# filter: (objectclass=*)
# requesting:
#

# search result
search: 2
result: 1 Operations error
text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope
 ration a successful bind must be completed on the connection., data 0, vece

# numResponses: 1

Binding ldapsearch with an appropriate username and password allows 'proper' searches, and gives meaningful responses.

So, that was the bits that work.

What's not working is login authentication. I ignore the GUI interface on Gnome and use the command line to edit the config files.

When I set up LDAP authentication and restart the server, non-local logins take a very long time (while nss_ldap tries to connect to the server and fails) before failing. There are no messages in /var/log/auth, but /var/log/messages is full of:

Jun 25 15:24:46 vmcluster gdm[5986]: nss_ldap: could not search LDAP server - Se
rver is unavailable
Jun 25 15:30:28 vmcluster gdm[5969]: nss_ldap: could not search LDAP server - Se
rver is unavailable
Jun 25 15:33:29 vmcluster gdm[5969]: nss_ldap: could not search LDAP server - Se
rver is unavailable
Jun 25 15:33:29 vmcluster gdm[5969]: pam_unix(gdm:auth): check pass; user unknow
n
Jun 25 15:35:33 vmcluster gdm[5969]: nss_ldap: could not search LDAP server - Se
rver is unavailable
Jun 25 15:35:33 vmcluster gdm[5969]: pam_succeed_if(gdm:auth): error retrieving
information about user ldapuser
Jun 25 15:37:39 vmcluster gdm[5969]: nss_ldap: could not search LDAP server - Se
rver is unavailable
Jun 25 15:37:40 vmcluster gdm[5969]: Couldn't authenticate user

I've tweaked many of the settings, tried using SSL and TLS (which the eDirectory requires, and the Active Directory doesn't do) and the bindings for searching (different users, or anonymous binding), still the general trend of ldapsearch just works, but login authentication with the pam modules (pam_ldap and nss_ldap) fails to even connect to the server.

I've tried comparible setups on Ubuntu, and get similar results.

Hope someone here can help.

Regards.

Aaron Hicks

===========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

# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
uri ldap://ldap.our.long.domain.co.nz

# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
# Note: We have users with spaces in their cn!
binddn "cn=User Name,ou=internal,ou=users,ou=accounts,cn=,dc=our,dc=long,dc=domain,dc=co,dc=nz"

# The credentials to bind with.
# Optional: default is no credential.
bindpw secret

<defaults omitted>
# Search timelimit
#timelimit 30
timelimit 10

# Bind/connect timelimit
#bind_timelimit 30
bind_timelimit 10

<more defaults omitted>

# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad

<no more changes>

Since they seem important here's my /etc/nsswitch.conf

passwd:     files ldap
shadow:     files ldap
group:      files ldap

And finally /etc/pam.d/sustem-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so



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

[guillomovitch]

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.

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).
[..]
> ===========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.

--
BOFH excuse #390:

Increased sunspot activity.

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

[tkoeller]

Am Donnerstag, 25. Juni 2009 06:35:22 schrieb Aaron Hicks:

> When I set up LDAP authentication and restart the server, non-local logins
> take a very long time (while nss_ldap tries to connect to the server and
> fails) before failing. There are no messages in /var/log/auth, but
> /var/log/messages is full of:
>
> Jun 25 15:24:46 vmcluster gdm[5986]: nss_ldap: could not search LDAP server
> - Se rver is unavailable
> Jun 25 15:30:28 vmcluster gdm[5969]: nss_ldap: could not search LDAP server
> - Se rver is unavailable
> Jun 25 15:33:29 vmcluster gdm[5969]: nss_ldap: could not search LDAP server
> - Se rver is unavailable

Hi Aaron,

I had a problem very similar to the one you are describing: although querying
the LDAP server using the ldapsearch command appeared to work just well, there
were many error messages about the server being unavailable in my log file.
Since in my case the server was running on the local machine, and both
pam_ldap and nss_ldap were configured to communicate with it through a unix
domain socket (ldapi:/// uri), I really could not understand why the server
would be unavailable only sporadically. Analyzing the problem I found that at
times there were lots of open connections to the server, exhausting its
configured limit, and causing it to reject further connection requests. All
those connections had been left behind by requests that had already completed,
and remained open until the server's connection timeout had been reached.

I changed the 'nss_connect_policy' in the nss_ldap config file from its
default value 'persist' to 'oneshot', instructing the client to close its
connection after every request, and the problem went away. Using nscd, as has
been suggested, tends to alleviate the problem by causing nss_ldap to be
invoked less frequently, but is not a real solution.

I think that 'persist' has been made the default value for
'nss_connect_policy' based on the assumption that the client is re-using open
connections, but obviously nss_ldap (and pam_ldap?) does not do this and
always opens a new connection for every request (I am just guessing, not being
involved in ldap development).

Hope this helps,
Thomas
--
Thomas Köller

[Aaron Hicks]

Thanks Andreas,

Yes, searching with ldapsearch works on AD when I bind with "-D cn=valid,cd=distinguished,cn=name -W", generally ldapsearch (and other command line tools and Softerra LDAP Administrator) works. pam_ldap isn't connecting.

Regards,

Aaron Hicks

> -----Original Message-----
> From: Andreas Moroder [mailto:andreas.moroder@...]
> Sent: Thursday, 25 June 2009 6:03 p.m.
> To: Aaron Hicks
> Subject: Re: [nssldap] pam_ldap and nss_ldap can't connect to LDAP
> server(s)
>
> Aaron Hicks schrieb:
> > Hello the list,
> >
> > I've been trying to authenticate linux logins with Ubuntu and CentOS
> using LDAP against our Novell eDirectory or our Active Directory.
> CentOS is more important to us as it's distribution used in some of our
> pre-packaged server installs.
> >
> > The packages openldap_clients and nss-ldap (for CentOS) are installed
> and up to date (using yum).
> >
> > The configuration on /etc/openldap/ldap.conf works and I can use
> ldapsearch to bind and search our directories freely from the command
> line.
> >
> > /etc/openldap/ldap.conf
> > URI ldap://ldap.our.long.domain.co.nz
> > BASE dc=our,dc=long,dc=domain,dc=co,dc=nz
> > TLS_REQCERT never
> >
> > When you do:
> >
> > ldapsearch -x ""
> >
> > The LDAP server (A Windows Server 2003 Domain Controller) responds
> with:
> >
> > # extended LDIF
> > #
> > # LDAPv3
> > # base <dc=our,dc=long,dc=domain,dc=co,dc=nz> (default) with scope
> subtree
> > # filter: (objectclass=*)
> > # requesting:
> > #
> >
> > # search result
> > search: 2
> > result: 1 Operations error
> > text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform
> this ope
> >  ration a successful bind must be completed on the connection., data
> 0, vece
> >
> > # numResponses: 1
> >
> Hello Aaron,
>
> I am not a expert, but AFAIK AD does not allow searches without login
>
> http://support.microsoft.com/?scid=kb%3Ben-us%3B326690&x=1&y=11
>
> Bye
> Andreas

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

[Aaron Hicks]

Thanks Guillaume, it's been very helpful.

- added debug 1 to /etc/ldap.conf will see what additional reporting I get
- the AD does not respond to SSL on port 636, I'll try forcing TLS on port 389, but as ldapsearch works without them (i.e. once bound, it searches fine unencrypted) I don't think that's the issue. Have set 'tls_checkpeer no' to no effect.
- Currently negoitating with the admin for the directory servers to check their logs.
- base for searches is set, I must have deleted it and not put in a mangled replacement before posting to the list. it's of the form "base dc=our,dc=long,dc=domain,dc=co,dc=nz"

regards,

Aaron

> -----Original Message-----
> From: owner-nssldap@... [mailto:owner-nssldap@...] On Behalf
> Of Guillaume Rousse
> Sent: Thursday, 25 June 2009 9:12 p.m.
> Cc: pamldap@...; nssldap@...
> Subject: Re: [nssldap] pam_ldap and nss_ldap can't connect to LDAP
> server(s)
>
> 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.
>
> 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).
> [..]
> > ===========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.
>
> --
> BOFH excuse #390:
>
> Increased sunspot activity.

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

[Aaron Hicks]

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@... [mailto:owner-nssldap@...] On Behalf
> Of Buchan Milne
> Sent: Friday, 26 June 2009 1:30 a.m.
> To: Guillaume Rousse
> Cc: pamldap@...; nssldap@...
> 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

[Aaron Hicks]

Ok, some progress.

This error:

new result:  res_errno: 49, res_error: <80090308: LdapErr: DSID-
 0C090334, comment: AcceptSecurityContext error, data 525, vece>,

According to this page: http://www-01.ibm.com/support/docview.wss?rs=688&uid=swg21290631

Told me that the username was not correct. Some mucking about revealed that the quote marks around "User Name" were unecessary. nns_ldap is now binding to the domain server

id usr and getent passwd user are still unable to find usernames, so I'll look at the base DN used for searches and any filters in place.

Regards,

Aaron Hicks

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

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

[Aaron Hicks]

Hmm, getent passwd ldapuser and id ldapuser now produce these debug messages, and not find the LDAP user (even though it is exactly the same user it's binding with)

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 202.27.242.229:389
ldap_connect_timeout: fd: 3 tm: 120 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: 119 bytes to sd 3
ldap_result ld 0x2b37070 msgid 1
ldap_chkResponseList ld 0x2b37070 msgid 1 all 0
ldap_chkResponseList returns ld 0x2b37070 NULL
wait4msg ld 0x2b37070 msgid 1 (timeout 120000000 usec)
wait4msg continue ld 0x2b37070 msgid 1 all 0
** ld 0x2b37070 Connections:
* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x2b37070 Response Queue:
   Empty
ldap_chkResponseList ld 0x2b37070 msgid 1 all 0
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 1 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x2b37070 msgid 1 message type bind
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x2b37070 0 new referrals
read1msg:  mark request completed, ld 0x2b37070 msgid 1
request done: ld 0x2b37070 msgid 1
res_errno: 0, res_error: <>, 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_search
put_filter: "(&(objectClass=user)(sAMAccountName=ldapuser))"
put_filter: AND
put_filter_list "(objectClass=user)(sAMAccountName=ldapuser)"
put_filter: "(objectClass=user)"
put_filter: simple
put_simple_filter: "objectClass=user"
put_filter: "(sAMAccountName=ldapuser)"
put_filter: simple
put_simple_filter: "sAMAccountName=ldapuser"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 242 bytes to sd 3
ldap_result ld 0x2b37070 msgid 2
ldap_chkResponseList ld 0x2b37070 msgid 2 all 1
ldap_chkResponseList returns ld 0x2b37070 NULL
wait4msg ld 0x2b37070 msgid 2 (timeout 30000000 usec)
wait4msg continue ld 0x2b37070 msgid 2 all 1
** ld 0x2b37070 Connections:
* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x2b37070 Response Queue:
   Empty
ldap_chkResponseList ld 0x2b37070 msgid 2 all 1
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 245 contents:
read1msg: ld 0x2b37070 msgid 2 message type search-entry
wait4msg ld 0x2b37070 30 secs to go
wait4msg continue ld 0x2b37070 msgid 2 all 1
** ld 0x2b37070 Connections:
* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x2b37070 Response Queue:
 * msgid 2,  type 100
ldap_chkResponseList ld 0x2b37070 msgid 2 all 1
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 135 contents:
read1msg: ld 0x2b37070 msgid 2 message type search-reference
ber_scanf fmt ({v}) ber:
ldap_chase_v3referrals
ldap_url_parse_ext(ldap://DomainDnsZones.our.long.domain.co.nz/DC=DomainDnsZones,DC=landcare,DC=ad,DC=landcareresearch,DC=co,DC=nz)
re_encode_request: new msgid 3, new dn <DC=DomainDnsZones,DC=landcare,DC=ad,DC=landcareresearch,DC=co,DC=nz>
ber_scanf fmt ({it) ber:
ber_scanf fmt ({me) ber:
ldap_chase_v3referral: msgid 2, url "ldap://DomainDnsZones.our.long.domain.co.nz/DC=DomainDnsZones,DC=landcare,DC=ad,DC=landcareresearch,DC=co,DC=nz"
ldap_send_server_request
ldap_new_connection 0 1 1
ldap_int_open_connection
ldap_connect_to_host: TCP DomainDnsZones.our.long.domain.co.nz:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 202.27.242.229:389
ldap_connect_timeout: fd: 4 tm: 120 async: 0
ldap_ndelay_on: 4
ldap_is_sock_ready: 4
ldap_ndelay_off: 4
Call application rebind_proc
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush: 119 bytes to sd 4
ldap_result ld 0x2b37070 msgid 4
ldap_chkResponseList ld 0x2b37070 msgid 4 all 0
ldap_chkResponseList returns ld 0x2b37070 NULL
wait4msg ld 0x2b37070 msgid 4 (timeout 120000000 usec)
wait4msg continue ld 0x2b37070 msgid 4 all 0
** ld 0x2b37070 Connections:
* host: DomainDnsZones.our.long.domain.co.nz  port: 0
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009
  rebind in progress
    queue is empty

* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 4,  origid 4, status InProgress
   outstanding referrals 0, parent count 0
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 1, parent count 0
** ld 0x2b37070 Response Queue:
 * msgid 2,  type 100
ldap_chkResponseList ld 0x2b37070 msgid 4 all 0
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 4 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x2b37070 msgid 2 message type search-result
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x2b37070 0 new referrals
read1msg:  mark request completed, ld 0x2b37070 msgid 2
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
wait4msg ld 0x2b37070 120 secs to go
wait4msg continue ld 0x2b37070 msgid 4 all 0
** ld 0x2b37070 Connections:
* host: DomainDnsZones.our.long.domain.co.nz  port: 0
  refcnt: 2  status: Connected
  last used: Fri Jun 26 11:51:12 2009
  rebind in progress
    queue is empty

* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 1  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 4,  origid 4, status InProgress
   outstanding referrals 0, parent count 0
 * msgid 2,  origid 2, status RequestCompleted
   outstanding referrals 1, parent count 0
** ld 0x2b37070 Response Queue:
 * msgid 2,  type 100
ldap_chkResponseList ld 0x2b37070 msgid 4 all 0
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 4 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x2b37070 msgid 4 message type bind
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x2b37070 0 new referrals
read1msg:  mark request completed, ld 0x2b37070 msgid 4
request done: ld 0x2b37070 msgid 4
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 4, msgid 4)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 261 bytes to sd 4
adding response ld 0x2b37070 msgid 2 type 115:
wait4msg ld 0x2b37070 30 secs to go
wait4msg continue ld 0x2b37070 msgid 2 all 1
** ld 0x2b37070 Connections:
* host: DomainDnsZones.our.long.domain.co.nz  port: 0
  refcnt: 1  status: Connected
  last used: Fri Jun 26 11:51:12 2009

* host: ldap.our.long.domain.co.nz  port: 389  (default)
  refcnt: 1  status: Connected
  last used: Fri Jun 26 11:51:12 2009

** ld 0x2b37070 Outstanding Requests:
 * msgid 3,  origid 2, status InProgress
   outstanding referrals 0, parent count 1
 * msgid 2,  origid 2, status RequestCompleted
   outstanding referrals 1, parent count 1
** ld 0x2b37070 Response Queue:
 * msgid 2,  type 100
   chained responses:
  * msgid 2,  type 115
ldap_chkResponseList ld 0x2b37070 msgid 2 all 1
ldap_chkResponseList returns ld 0x2b37070 NULL
ldap_int_select
read1msg: ld 0x2b37070 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x2b37070 msgid 3 message type search-result
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x2b37070 0 new referrals
read1msg:  mark request completed, ld 0x2b37070 msgid 3
merged parent (id 2) error info:  result errno 0, error <>, matched <>
request done: ld 0x2b37070 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_free_request (origid 2, msgid 3)
ldap_free_connection 0 1
ldap_send_unbind
ber_flush: 7 bytes to sd 4
ldap_free_connection: actually freed
adding response ld 0x2b37070 msgid 2 type 101:
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt ([v]) ber:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt ([v]) ber:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ldap_msgfree
ldap_unbind
ldap_free_connection 1 1
ldap_send_unbind
ber_flush: 7 bytes to sd 3
ldap_free_connection: actually freed

> -----Original Message-----
> From: owner-nssldap@... [mailto:owner-nssldap@...] On Behalf
> Of Aaron Hicks
> Sent: Friday, 26 June 2009 11:25 a.m.
> To: pamldap@...; nssldap@...
> Subject: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP
> server(s)
>
> Ok, some progress.
>
> This error:
>
> new result:  res_errno: 49, res_error: <80090308: LdapErr: DSID-
>  0C090334, comment: AcceptSecurityContext error, data 525, vece>,
>
> According to this page: http://www-
> 01.ibm.com/support/docview.wss?rs=688&uid=swg21290631
>
> Told me that the username was not correct. Some mucking about revealed
> that the quote marks around "User Name" were unecessary. nns_ldap is
> now binding to the domain server
>
> id usr and getent passwd user are still unable to find usernames, so
> I'll look at the base DN used for searches and any filters in place.
>
> Regards,
>
> Aaron Hicks
>
> > -----Original Message-----
> > From: owner-nssldap@... [mailto:owner-nssldap@...] On
> Behalf
> > Of Aaron Hicks
> > Sent: Friday, 26 June 2009 10:23 a.m.
> > To: pamldap@...; nssldap@...
> > Subject: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP
> > server(s)
> >
> > 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@... [mailto:owner-nssldap@...] On
> > Behalf
> > > Of Buchan Milne
> > > Sent: Friday, 26 June 2009 1:30 a.m.
> > > To: Guillaume Rousse
> > > Cc: pamldap@...; nssldap@...
> > > 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
>
> 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

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

[Howard Chu]

Karl O. Pinc wrote:

>
> On 06/25/2009 07:19:45 PM, Aaron Hicks wrote:
>> Hmm, getent passwd ldapuser and id ldapuser now produce these debug
>> messages, and not find the LDAP user (even though it is exactly the
>> same user it's binding with)
>
> FWIW when that happens with an OpenLDAP server it's because you've
> rights to bind (or maybe lookup by direct dn match, I forget)
> but not search.  Or at least that's one way to exhibit those symptoms,
> there could be others.

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/

[Aaron Hicks]

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.

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

> -----Original Message-----
> From: Howard Chu [mailto:hyc@...]
> Sent: Friday, 26 June 2009 2:42 p.m.
> To: Karl O. Pinc
> Cc: Aaron Hicks; pamldap@...; nssldap@...
> Subject: Re: [pamldap] RE: [nssldap] pam_ldap and nss_ldap can't
> connect to LDAP server(s)
>
> Karl O. Pinc wrote:
> >
> > On 06/25/2009 07:19:45 PM, Aaron Hicks wrote:
> >> Hmm, getent passwd ldapuser and id ldapuser now produce these debug
> >> messages, and not find the LDAP user (even though it is exactly the
> >> same user it's binding with)
> >
> > FWIW when that happens with an OpenLDAP server it's because you've
> > rights to bind (or maybe lookup by direct dn match, I forget)
> > but not search.  Or at least that's one way to exhibit those
> symptoms,
> > there could be others.
>
> 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/

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

[Aaron Hicks]

Hi Karl,

When I use ldapsearch and bind with the same credentials, I get a sucessful search on the filter (&(objectClass=user)(sAMAccountName=ldapuser)), which is the same search filter used by nss_ldap when I execute an id ldapuser or getent passwd ldapuser

Regards,

Aaron Hicks

PS. None of thes LDAP users have previously logged into this server.

> -----Original Message-----
> From: Karl O. Pinc [mailto:kop@...]
> Sent: Friday, 26 June 2009 1:42 p.m.
> To: Aaron Hicks
> Cc: pamldap@...; nssldap@...
> Subject: Re: [pamldap] RE: [nssldap] pam_ldap and nss_ldap can't
> connect to LDAP server(s)
>
>
> On 06/25/2009 07:19:45 PM, Aaron Hicks wrote:
> > Hmm, getent passwd ldapuser and id ldapuser now produce these debug
> > messages, and not find the LDAP user (even though it is exactly the
> > same user it's binding with)
>
> FWIW when that happens with an OpenLDAP server it's because you've
> rights to bind (or maybe lookup by direct dn match, I forget)
> but not search.  Or at least that's one way to exhibit those symptoms,
> there could be others.
>
> Karl <kop@...>
> Free Software:  "You don't pay back, you pay forward."
>                   -- Robert A. Heinlein

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

[Howard Chu]

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/

[guillomovitch]

Aaron Hicks a écrit :

 >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.
Unfortunatly for you, I don't think there is anything as 'system
default' for nss values. In a mixed environment, user account
information is perceived exactly the same on every system, which cause
heavy troubles when login shell is different from '/bin/sh', for
instance (BSD systems don't have /bin/bash, usually).

Either you ensure an constant home directory is usable everywhere, by
customising your filesystem setup (a local nfs mount is supposed to have
  a very restricted I/O perf impact), either you override your user
account locally when needed (but you can't override just one attribute,
you have to override the whole account).
--
BOFH excuse #323:

Your processor has processed too many instructions.  Turn it off
immediately, do not type any commands!!