|
»
»
pam_ldap and nss_ldap can't connect to LDAP server(s)
|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
 |
pam_ldap and nss_ldap can't connect to LDAP server(s)
by Aaron Hicks
::
Rate this Message:
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 |
|
|
|
Re: pam_ldap and nss_ldap can't connect to LDAP server(s)
by Karl O. Pinc
::
Rate this Message:
On 06/24/2009 11:35:22 PM, Aaron Hicks wrote: > Binding ldapsearch with an appropriate username and password allows > 'proper' searches, and gives meaningful responses. > /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 Well, this is just a guess after a long time not thinking of ldap.... I don't see a host in ldap.conf, so it's probably trying to connect to the default server (localhost?). Hence the above message. > My /etc/ldap.conf looks like (omitting sections left as default): > > # 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 If you use these credentials (and the right host) with ldapsearch you get a good answer? Karl <kop@...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
|
|
|
Re: pam_ldap and nss_ldap can't connect to LDAP server(s)
by bdptcob
::
Rate this Message:
I believe installing nscd resolves these messages.
On Thu, 2009-06-25 at 07:31 -0700, Karl O. Pinc wrote: On 06/24/2009 11:35:22 PM, Aaron Hicks wrote: > Binding ldapsearch with an appropriate username and password allows > 'proper' searches, and gives meaningful responses. > /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 Well, this is just a guess after a long time not thinking of ldap.... I don't see a host in ldap.conf, so it's probably trying to connect to the default server (localhost?). Hence the above message. > My /etc/ldap.conf looks like (omitting sections left as default): > > # 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 If you use these credentials (and the right host) with ldapsearch you get a good answer? Karl <kop@...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
|
|
|
|
Re: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by tkoeller
::
Rate this Message:
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 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 |
|
|
|
|
|
|
|
|
|
|
|
RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Aaron Hicks
::
Rate this Message:
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 |
|
|
|
RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Aaron Hicks
::
Rate this Message:
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 |
|
|
|
Re: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Karl O. Pinc
::
Rate this Message:
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 |
|
|
|
Re: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Howard Chu
::
Rate this Message:
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/ |
|
|
|
RE: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Aaron Hicks
::
Rate this Message:
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 |
|
|
|
RE: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Aaron Hicks
::
Rate this Message:
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 |
|
|
|
Re: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Howard Chu
::
Rate this Message:
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/ |
|
|
|
Re: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by vsp_123
::
Rate this Message:
Hi Aaron,
If you are connecting to AD, then you probably need "Microsoft Services for Unix" to provide the Unix-related schema (like uidNumber, gidNumber, homeDirectory etc.). Prakash On Jun 26, 2009, at 12:53 AM, Howard Chu wrote: > 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/ |
|
|
|
Re: RE: [nssldap] pam_ldap and nss_ldap can't connect to LDAP server(s)
by Karl O. Pinc
::
Rate this Message:
On 06/25/2009 11:53:19 PM, Howard Chu wrote: > 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. FWIW, Samba's winbindd is another approach to authenticating via PAM off of MS's AD, if you want to give up and leave the MS voodoo to samba. There's a wiki entry on the samba wiki. YMMV. Karl <kop@...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
signature.asc (500 bytes) 
| Free embeddable forum powered by Nabble | Forum Help |
