Nabble - NSS LDAP

RE: Looking for support on nss_ldap issue

2009-11-20T08:47:51Z

It is a large patch but you might get better results if you try the patches I have recently released for nss_Ldap 265. They include a complete rewrite of the connect/reconnect code that is designed to honor the timeouts properly.

If you have trouble building this I can send you a Fedora 11 spec file which may give you a good starting point.

Regards, Howard

Coherent Technology Limited, 23 Northampton Square, Finsbury, London EC1V 0HL, United Kingdom
Telephone: +44 20 7690 7075 Mobile: +44 7980 639379
Company Email: coherent@... Website: http://www.cohtech.com <http://www.cohtech.com/>

________________________________

From: owner-nssldap@... on behalf of Douglas E. Engert
Sent: Thu 2009-11-19 21:03
To: nssldap@...
Cc: nssldap@...
Subject: Re: [nssldap] Looking for support on nss_ldap issue

nssldap@... wrote:

> On Tue, 17 Nov 2009, Douglas E. Engert wrote:
>> I don't have a CentOS system but we ran into issues with lost connections
>> and TLS. This sounds a lot like:
>>
>> BUG #392: call do_close() if ldap_result() or ldap_parse_result()
>> fails (before returning NSS_UNAVAIL)
>>
>> and not having a timelimit set.
>>
>> Fixes for these are in nss_ldap-265 announced on 11/6/2009
>>
>> You may want to try using this newer version, if only to see if it fixes
>> your problem even if CentOS does not have this version yet.
>>
>> Since this looks like issues with timeouts
>> You may also want to set:
>>
>> idle_timelimit 20
>> timelimit 30
>>
>> Good luck.
>
> Thanks! I have attached a document.
>
> I downloaded the source for that version that you describe and built it
> into packages for my CentOS machines. I tried it out, but I still
> encounter the timeout related failure. I added the following lines to
> ldap.conf but to no avail:
>
> bind_timelimit 5
> idle_timelimit 5
> timelimit 5
>
> My LDAP servers are local and are not stressed, so I figured a low
> timeout would be acceptable.
>
> The server that I hit with SIGSTOP that is detailed in the debug output
> was ldap1.management.example.com .
>
> Any additional help would be appreciated, thanks again!

I am no ldap expert, hopefully someone from Padl will respond.

But if you have all the timeouts set on the client, why
does this line near the end say infinite timeout?

wait4msg ld 0x55556e6dde40 msgid 1 (infinite timeout)

>
>>
>> --
>>
>> Douglas E. Engert <DEEngert@...>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>>

--

Douglas E. Engert <DEEngert@...>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Re: Looking for support on nss_ldap issue

2009-11-19T13:03:51Z

nssldap@... wrote:

>
>>
>> --
>>
>> Douglas E. Engert <DEEngert@...>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>>

--

Douglas E. Engert <DEEngert@...>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Re: Looking for support on nss_ldap issue

2009-11-19T07:51:34Z

On Tue, 17 Nov 2009, Douglas E. Engert wrote:

> I don't have a CentOS system but we ran into issues with lost connections
> and TLS. This sounds a lot like:
>
> BUG #392: call do_close() if ldap_result() or ldap_parse_result()
> fails (before returning NSS_UNAVAIL)
>
> and not having a timelimit set.
>
> Fixes for these are in nss_ldap-265 announced on 11/6/2009
>
> You may want to try using this newer version, if only to see if it fixes
> your problem even if CentOS does not have this version yet.
>
> Since this looks like issues with timeouts
> You may also want to set:
>
> idle_timelimit 20
> timelimit 30
>
> Good luck.

Thanks! I have attached a document.

I downloaded the source for that version that you describe and built it
into packages for my CentOS machines. I tried it out, but I still
encounter the timeout related failure. I added the following lines to
ldap.conf but to no avail:

bind_timelimit 5
idle_timelimit 5
timelimit 5

My LDAP servers are local and are not stressed, so I figured a low timeout
would be acceptable.

The server that I hit with SIGSTOP that is detailed in the debug output
was ldap1.management.example.com .

Any additional help would be appreciated, thanks again!

>
> --
>
> Douglas E. Engert <DEEngert@...>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
>
ldap_create
ldap_url_parse_ext(ldap://ldap1.management.example.com)
ldap_create
ldap_url_parse_ext(ldap://ldap1.management.example.com)
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap1.management.example.com:389
ldap_new_socket: 7
ldap_prepare_socket: 7
ldap_connect_to_host: Trying 192.168.1.2:389
ldap_connect_timeout: fd: 7 tm: 5 async: 0
ldap_ndelay_on: 7
ldap_is_sock_ready: 7
ldap_ndelay_off: 7
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 31 bytes to sd 7
ldap_result ld 0x55556e62adf0 msgid 1
ldap_chkResponseList ld 0x55556e62adf0 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e62adf0 NULL
wait4msg ld 0x55556e62adf0 msgid 1 (timeout 5000000 usec)
wait4msg continue ld 0x55556e62adf0 msgid 1 all 1
ldap_chkResponseList ld 0x55556e62adf0 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e62adf0 NULL
ldap_int_select
ldap_abandon 1
ldap_abandon_ext 1
do_abandon origid 1, msgid 1
ldap_msgdelete
ber_flush: 8 bytes to sd 7
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_free_request (origid 1, msgid 1)
ldap_err2string
ldap_unbind
ldap_free_connection 1 1
ldap_send_unbind
ber_flush: 7 bytes to sd 7
ldap_free_connection: actually freed
ldap_create
ldap_url_parse_ext(ldap://ldap2.management.example.com)
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap2.management.example.com:389
ldap_new_socket: 7
ldap_prepare_socket: 7
ldap_connect_to_host: Trying 192.168.1.3:389
ldap_connect_timeout: fd: 7 tm: 5 async: 0
ldap_ndelay_on: 7
ldap_is_sock_ready: 7
ldap_ndelay_off: 7
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 31 bytes to sd 7
ldap_result ld 0x55556e634240 msgid 1
ldap_chkResponseList ld 0x55556e634240 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e634240 NULL
wait4msg ld 0x55556e634240 msgid 1 (timeout 5000000 usec)
wait4msg continue ld 0x55556e634240 msgid 1 all 1
ldap_chkResponseList ld 0x55556e634240 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e634240 NULL
ldap_int_select
read1msg: ld 0x55556e634240 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x55556e634240 msgid 1 message type extended-result
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result: res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x55556e634240 0 new referrals
read1msg: mark request completed, ld 0x55556e634240 msgid 1
request done: ld 0x55556e634240 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
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 0, subject: /C=US/ST=New York/L=New York/O=Example/CN=example.com, issuer: /C=US/ST=New York/L=New York/O=Example/CN=example.com
TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=New York/O=Example/CN=ldap2.management.example.com, issuer: /C=US/ST=New York/L=New York/O=Example/CN=example.com
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
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: 14 bytes to sd 7
ldap_result ld 0x55556e634240 msgid 2
ldap_chkResponseList ld 0x55556e634240 msgid 2 all 0
ldap_chkResponseList returns ld 0x55556e634240 NULL
wait4msg ld 0x55556e634240 msgid 2 (timeout 5000000 usec)
wait4msg continue ld 0x55556e634240 msgid 2 all 0
ldap_chkResponseList ld 0x55556e634240 msgid 2 all 0
ldap_chkResponseList returns ld 0x55556e634240 NULL
ldap_int_select
read1msg: ld 0x55556e634240 msgid 2 all 0
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x55556e634240 msgid 2 message type bind
ber_scanf fmt ({eaa) ber:
ber_scanf fmt ({eaa}) ber:
new result: res_errno: 0, res_error: <>, res_matched: <>
read1msg: ld 0x55556e634240 0 new referrals
read1msg: mark request completed, ld 0x55556e634240 msgid 2
request done: ld 0x55556e634240 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
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=shadowAccount)(uid=mark))"
put_filter: AND
put_filter_list "(objectClass=shadowAccount)(uid=mark)"
put_filter: "(objectClass=shadowAccount)"
put_filter: simple
put_simple_filter: "objectClass=shadowAccount"
put_filter: "(uid=mark)"
put_filter: simple
put_simple_filter: "uid=mark"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 206 bytes to sd 7
ldap_result ld 0x55556e634240 msgid 3
ldap_chkResponseList ld 0x55556e634240 msgid 3 all 1
ldap_chkResponseList returns ld 0x55556e634240 NULL
wait4msg ld 0x55556e634240 msgid 3 (timeout 5000000 usec)
wait4msg continue ld 0x55556e634240 msgid 3 all 1
ldap_chkResponseList ld 0x55556e634240 msgid 3 all 1
ldap_chkResponseList returns ld 0x55556e634240 NULL
ldap_int_select
read1msg: ld 0x55556e634240 msgid 3 all 1
ber_get_next
ber_get_next: tag 0x30 len 79 contents:
read1msg: ld 0x55556e634240 msgid 3 message type search-entry
wait4msg ld 0x55556e634240 5 secs to go
wait4msg continue ld 0x55556e634240 msgid 3 all 1
ldap_chkResponseList ld 0x55556e634240 msgid 3 all 1
ldap_chkResponseList returns ld 0x55556e634240 NULL
ldap_int_select
read1msg: ld 0x55556e634240 msgid 3 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x55556e634240 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 0x55556e634240 0 new referrals
read1msg: mark request completed, ld 0x55556e634240 msgid 3
request done: ld 0x55556e634240 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
adding response ld 0x55556e634240 msgid 3 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 (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 ([v]) 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:
ldap_get_values
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:
ldap_get_values
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:
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_scanf fmt (x}{a) ber:
ber_scanf fmt (x}{a) ber:
ldap_msgfree
ldap_create
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap1.management.example.com:389
ldap_new_socket: 10
ldap_prepare_socket: 10
ldap_connect_to_host: Trying 192.168.1.2:389
ldap_connect_timeout: fd: 10 tm: 5 async: 0
ldap_ndelay_on: 10
ldap_is_sock_ready: 10
ldap_ndelay_off: 10
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 31 bytes to sd 10
ldap_result ld 0x55556e6dde40 msgid 1
ldap_chkResponseList ld 0x55556e6dde40 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e6dde40 NULL
wait4msg ld 0x55556e6dde40 msgid 1 (infinite timeout)
wait4msg continue ld 0x55556e6dde40 msgid 1 all 1
ldap_chkResponseList ld 0x55556e6dde40 msgid 1 all 1
ldap_chkResponseList returns ld 0x55556e6dde40 NULL
ldap_int_select

Re: Looking for support on nss_ldap issue

2009-11-17T13:34:06Z

nssldap@... wrote:

> Sorry for the repost, but I really would like to find out how to fix
> this as soon as possible.
>
> If I'm missing something or I'm wrong in the framing of this question in
> any way, or if I'm asking in the wrong place, I welcome any feedback
> about that as well.
>
> Hello,
>
> I use pam_ldap+nss_ldap with CentOS 5.x, and the problem that I'm seeing
> is that nss_ldap doesn't handle a failure of a server to handshake after
> STARTTLS properly. As such, it just hangs, causing an inability to
> authenticate with and gain access to the host using any user in the LDAP
> base. I have not run tcpdump or strace to verify this, but that
> description of the problem seems to be just as good as any I know of at
> this point. If there's any advice to determine the steps in more detail,
> it would be appreciated.
>
> This is the ldap.conf file that I have now:
> uri ldap://ldaphost1 ldap://ldaphost2
> base dc=example,dc=com
> pam_filter objectclass=posixAccount
> pam_login_attribute uid
> pam_member_attribute memberUid
> pam_password md5
> ssl start_tls
> tls_cacertdir /etc/openldap/cacerts
> tls_cacertfile /etc/openldap/cacerts/cacert.pem
> tls_reqcert demand
> bind_timelimit 5
> nss_initgroups_ignoreusers root,ldap,named
> bind_policy soft
>
> If slapd on ldaphost1 has "kill -SIGSTOP" invoked against it, a condition
> that simulates other possible conditions where the server opens a TCP
> connection but then doesn't have a conversation, the client hangs.
> Again, if I'm wrong here, please chime in.
>
> I have modified a perl script that someone else has written to handle a
> similar failure condition to handle this condition that may also directly
> relate to how LDAP over TLS works , but it is most definitely a kludgy
> workaround and something that I don't want to deploy across hundreds of
> servers. It's just an alarm stanza wrapped around the logic to check
> whether the LDAP server is alive to cause it to be skipped if it doesn't
> respond in a few seconds.
>
> The host acting as test case is using nss_ldap-253-5.el5 provided with
> CentOS
> 5.x. (I have hosts that are 5.0-5.3 and have tried them on all versions)
>
> I already looked this issue up and found that someone was having a similar
> problem with CentOS 4.x and they resolved it by using host and port
> parameters instead of uri. There are two problems with that.
>
> 1. I believe that host and port are deprecated parameters, please
> correct me
> if I'm wrong.
>
> 2. I actually tried that and found that I had a similar problem where
> there
> was something of a conversation, but it dropped somewhere because sshd
> dropped right after password entry, as if the conversation was disrupted
> somehow.
>
> Any advice would be greatly appreciated, thanks!

I don't have a CentOS system but we ran into issues with lost connections
and TLS. This sounds a lot like:

BUG #392: call do_close() if ldap_result() or ldap_parse_result()
fails (before returning NSS_UNAVAIL)

and not having a timelimit set.

Fixes for these are in nss_ldap-265 announced on 11/6/2009

You may want to try using this newer version, if only to see if it fixes
your problem even if CentOS does not have this version yet.

Since this looks like issues with timeouts
You may also want to set:

idle_timelimit 20
timelimit 30

Good luck.

>
>

--

Douglas E. Engert <DEEngert@...>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Re: Looking for support on nss_ldap issue

2009-11-17T12:48:48Z

Sorry for the repost, but I really would like to find out how to fix this
as soon as possible.

If I'm missing something or I'm wrong in the framing of this question in
any way, or if I'm asking in the wrong place, I welcome any feedback about
that as well.

Hello,

I use pam_ldap+nss_ldap with CentOS 5.x, and the problem that I'm seeing
is that nss_ldap doesn't handle a failure of a server to handshake after
STARTTLS properly. As such, it just hangs, causing an inability to
authenticate with and gain access to the host using any user in the LDAP
base. I have not run tcpdump or strace to verify this, but that
description of the problem seems to be just as good as any I know of at
this point. If there's any advice to determine the steps in more detail,
it would be appreciated.

This is the ldap.conf file that I have now:
uri ldap://ldaphost1 ldap://ldaphost2
base dc=example,dc=com
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
pam_password md5
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_reqcert demand
bind_timelimit 5
nss_initgroups_ignoreusers root,ldap,named
bind_policy soft

If slapd on ldaphost1 has "kill -SIGSTOP" invoked against it, a condition
that simulates other possible conditions where the server opens a TCP
connection but then doesn't have a conversation, the client hangs.
Again, if I'm wrong here, please chime in.

I have modified a perl script that someone else has written to handle a
similar failure condition to handle this condition that may also directly
relate to how LDAP over TLS works , but it is most definitely a kludgy
workaround and something that I don't want to deploy across hundreds of
servers. It's just an alarm stanza wrapped around the logic to check
whether the LDAP server is alive to cause it to be skipped if it doesn't
respond in a few seconds.

The host acting as test case is using nss_ldap-253-5.el5 provided with CentOS
5.x. (I have hosts that are 5.0-5.3 and have tried them on all versions)

I already looked this issue up and found that someone was having a similar
problem with CentOS 4.x and they resolved it by using host and port
parameters instead of uri. There are two problems with that.

1. I believe that host and port are deprecated parameters, please correct me
if I'm wrong.

2. I actually tried that and found that I had a similar problem where there
was something of a conversation, but it dropped somewhere because sshd
dropped right after password entry, as if the conversation was disrupted
somehow.

Any advice would be greatly appreciated, thanks!

Looking for support on nss_ldap issue

2009-11-13T13:18:29Z

Hello,

I use nss_ldap with CentOS 5.x, and the problem that I'm seeing is that
nss_ldap doesn't handle a failure of a server to handshake after STARTTLS
properly. As
such, it just hangs, causing an inability to authenticate with and gain
access to the host using any user in the LDAP base.

This is the ldap.conf file that I have now:
uri ldap://ldaphost1 ldap://ldaphost2
base dc=example,dc=com
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
pam_password md5
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_reqcert demand
bind_timelimit 5
nss_initgroups_ignoreusers root,ldap,named
bind_policy soft

If slapd on ldaphost1 has "kill -SIGSTOP" invoked against it, a condition
that simulates other possible conditions where the server opens a TCP
connection but then doesn't have a conversation, the client hangs.

I have modified a perl script that someone else has written to handle a
similar failure condition to handle this condition that may also directly
relate to how LDAP over TLS works , but it is most definitely a kludgy
workaround and something that I don't want to deploy across hundreds of
servers.

The host acting as test case is using nss_ldap-253-5.el5 provided with
CentOS 5.x.

I already looked this issue up and found that someone was having a similar
problem with CentOS 4.x and they resolved it by using host and port
parameters instead of uri. There are two problems with that.

1. I believe that host and port are deprecated parameters, please correct
me if I'm wrong.

2. I actually tried that and found that I had a similar problem where
there was something of a conversation, but it dropped somewhere because
sshd dropped right after password entry, as if the conversation was
disrupted somehow.

Any advice would be greatly appreciated, thanks!

Re: nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T09:51:10Z

Hello Buchan,

> referrals no

I owe you a beer or two. Thanks you a lot that solved my problem.

> (I am not sure if it would be enabled or not, but it looks like it is
> chasing referrals, and setting this should stop it).

I didn't know about ldap referrals but I read it up and now have an idea
what they're about.

http://sunschlichter0.informatik.tu-muenchen.de/Java/jnditutorial/ldap/referral/overview.html

and here it is from the sniff I took:

Lightweight-Directory-Access-Protocol
LDAPMessage searchResRef(2)
messageID: 2
protocolOp: searchResRef (19)
searchResRef: 1 item
Item: ldap://DomainDnsZones.ww004.glanzmann.net/DC=DomainDnsZones,DC=ww004,DC=glanzmann,DC=net
[Response To: 256]
[Time: 0.017066000 seconds]

Again, thank you a lot!

Thomas

Re: nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T09:33:40Z

On Thursday, 12 November 2009 12:37:20 Thomas Glanzmann wrote:

> Hello,
> I have RHEL 5.3 nss_ldap connected to active directory. The
> configuration (/etc/ldap.conf) is the following:
>
> host 157.163.212.208
>
> bind_policy soft
>
> base DC=ww004,DC=glanzmann,DC=net
> ldap_version 3
>
> binddn
> CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
> bindpw geheim
>
> nss_base_passwd DC=ww004,DC=glanzmann,DC=net?sub?uid=*
> nss_base_shadow DC=ww004,DC=glanzmann,DC=net?sub?uid=*
> nss_base_group DC=ww004,DC=glanzmann,DC=net?sub?gidNumber=*
>
> nss_map_objectclass posixAccount user
> nss_map_objectclass shadowAccount user
> nss_map_objectclass posixGroup group
>
> nss_map_attribute homeDirectory unixHomeDirectory
> nss_map_attribute gecos displayname
>
> nss_map_attribute group:cn displayName
> nss_map_attribute uniqueMember member
>
> schema rfc2307bis
>
> When I do a ,,getent passwd'' it shows the local users, the directory
> users, and than hangs. By sniffing the connection, I see that connectes
> to 157.163.212.208 does, search, gets the answer and even lists the
> users. But than it does a DNS lookup for
>
> DomainDnsZones.ww004.glanzmann.net
>
> And tries to connect these servers which results into a hang because there
> is a firewall in place which makes it impossible to connect the machines.
> Is there a way to get rid of this annoying behaviour using a configuration
> option or do I have to rebuild nss ldap?

Try adding:

referrals no

(I am not sure if it would be enabled or not, but it looks like it is chasing
referrals, and setting this should stop it).

Regards,
Buchan

Re: nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T04:53:15Z

Hello Rousse,

> Do you have ldap listed for 'hosts' entry in nsswitch.conf, by any chance ?

no, I don't:

[root@deerlf0x84 ~]# cat /etc/nsswitch.conf
# Managed by Cfengine do not edit this file locally
# thor:/var/cfengine/inputs/distributed/erlf_linux/etc/nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files

hosts: files dns

bootparams: files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files

automount: files
aliases: files

Thomas

Re: nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T04:30:30Z

Thomas Glanzmann a écrit :

> When I do a ,,getent passwd'' it shows the local users, the directory
> users, and than hangs. By sniffing the connection, I see that connectes
> to 157.163.212.208 does, search, gets the answer and even lists the
> users. But than it does a DNS lookup for
>
> DomainDnsZones.ww004.glanzmann.net
>
> And tries to connect these servers which results into a hang because there is a
> firewall in place which makes it impossible to connect the machines. Is there a
> way to get rid of this annoying behaviour using a configuration option or do I
> have to rebuild nss ldap?

Do you have ldap listed for 'hosts' entry in nsswitch.conf, by any chance ?
--
BOFH excuse #266:

All of the packets are empty.

Re: nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T03:50:46Z

Hello,

> DomainDnsZones.ww004.glanzmann.net

> And tries to connect these servers which results into a hang because there is a
> firewall in place which makes it impossible to connect the machines. Is there a
> way to get rid of this annoying behaviour using a configuration option or do I
> have to rebuild nss ldap?

this works, but doesn't give me a chance to use redundant ldap servers:

echo "157.163.212.208 DomainDnsZones.ww004.glanzmann.net" >> /etc/hosts

I hope there is another way. While reading the code, my understanding is
that it only tries to do the lookup if it doesn't have an uri or host
entry. I also tried to modify my host directive into a uri, but the same
problem occurs.

Thomas

nss ldap under RHEL 5 does first connects configured ldap server and than does dns lookup and tries to connect random ldap servers

2009-11-12T03:37:20Z

Hello,
I have RHEL 5.3 nss_ldap connected to active directory. The
configuration (/etc/ldap.conf) is the following:

host 157.163.212.208

bind_policy soft

base DC=ww004,DC=glanzmann,DC=net
ldap_version 3

binddn CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
bindpw geheim

nss_base_passwd DC=ww004,DC=glanzmann,DC=net?sub?uid=*
nss_base_shadow DC=ww004,DC=glanzmann,DC=net?sub?uid=*
nss_base_group DC=ww004,DC=glanzmann,DC=net?sub?gidNumber=*

nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group

nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute gecos displayname

nss_map_attribute group:cn displayName
nss_map_attribute uniqueMember member

schema rfc2307bis

When I do a ,,getent passwd'' it shows the local users, the directory
users, and than hangs. By sniffing the connection, I see that connectes
to 157.163.212.208 does, search, gets the answer and even lists the
users. But than it does a DNS lookup for

DomainDnsZones.ww004.glanzmann.net

And tries to connect these servers which results into a hang because there is a
firewall in place which makes it impossible to connect the machines. Is there a
way to get rid of this annoying behaviour using a configuration option or do I
have to rebuild nss ldap?

Thomas

Re: nss_ldap-265

2009-11-11T17:03:34Z

Thanks, will be in nss_ldap-266.

On 06/11/2009, at 6:56 PM, Guillaume Rousse wrote:

> Luke Howard a écrit :
>> 265 Luke Howard <lukeh@...>
>> * fix for BUG#132: add versioning information to binary
>> * fix for BUG#403: add AM_MAINTAINER_MODE
>> * fix for BUG#388: bad LDAP query for ether lookups
>> * fix for BUG#391: clarify bind timelimit defaults
>> in ldap.conf
>> * fix for BUG#392: call do_close() if ldap_result()
>> or ldap_parse_result() fails (before returning
>> NSS_UNAVAIL)
>> * fix for BUG#401: FreeBSD thread library check
>> * fix for BUG#409: deallocate context in
>> _nss_ldap_ent_context_release() to avoid bad usage
>> * fix for BUG#410: don't leak file descriptors in
>> _nss_ldap_readconfig
> I had to use this patch to make it build, as current directory is
> unlikely to be in PATH:
>
> --- nss_ldap-265/Makefile.am 2009-11-06 11:28:08.000000000 +0100
> +++ nss_ldap-265-Makefile/Makefile.am 2009-11-06 15:05:18.000000000
> +0100
> @@ -109,5 +109,5 @@
> @$(NORMAL_UNINSTALL)
>
> vers.c: $(top_srcdir)/CVSVersionInfo.txt
> - CVSVERSIONDIR=$(top_srcdir) vers_string -v
> + CVSVERSIONDIR=$(top_srcdir) $(top_srcdir)/vers_string -v
>
> --
> BOFH excuse #20:
>
> divide-by-zero error
>

--
www.padl.com | www.fghr.net

FResh release of Mega patch!

2009-11-11T09:53:15Z

I have refactored my mega patch into a number of smaller patches along
with one smaller mega patch. These have been published as Bug 412 on the
bugzilla. This patch set is against nss_Ldap 265. I would appreciate any
feedback on the patches or experience in the usage of this code in the
various environment. I have so far only build and run this in Redhat
environments. I intend to try a late release Fedora shortly and will try
Solaris 10 within the next few days. If anybody has other platform
experience that would be very useful.

The Kerberos code should not work and I would be grateful if people
could exercise this using both local credentials acquisition and third
party acquisition, with and without renewal enabled.

TLS/SSL based authentication needs testing - I hope I have not broken
anything.

Anonymous works for me on oen site, and I will test basic authentication
to the LDAP server in the next couple of days.

Most of my testing is against AD and Sun LDAP servers. Usage against
other LDAP environments would also be good.

I have made an attempt at documenting what I have done but all
contributions/criticisms (gratefully/grudgingly) accepted ;-)

Regards, HOward

P.S. I still have things that I need to fix in the core LDAP stuff but
this patch set should make things much more stable/useful going forward.

--
Howard Wilkinson <howard@...>
Coherent Technology Limited

Re: nss_ldap-265

2009-11-06T09:56:19Z

Luke Howard a écrit :

> 265 Luke Howard <lukeh@...>
>
> * fix for BUG#132: add versioning information to binary
> * fix for BUG#403: add AM_MAINTAINER_MODE
> * fix for BUG#388: bad LDAP query for ether lookups
> * fix for BUG#391: clarify bind timelimit defaults
> in ldap.conf
> * fix for BUG#392: call do_close() if ldap_result()
> or ldap_parse_result() fails (before returning
> NSS_UNAVAIL)
> * fix for BUG#401: FreeBSD thread library check
> * fix for BUG#409: deallocate context in
> _nss_ldap_ent_context_release() to avoid bad usage
> * fix for BUG#410: don't leak file descriptors in
> _nss_ldap_readconfig

I had to use this patch to make it build, as current directory is
unlikely to be in PATH:

--- nss_ldap-265/Makefile.am 2009-11-06 11:28:08.000000000 +0100
+++ nss_ldap-265-Makefile/Makefile.am 2009-11-06 15:05:18.000000000 +0100
@@ -109,5 +109,5 @@
@$(NORMAL_UNINSTALL)

vers.c: $(top_srcdir)/CVSVersionInfo.txt
- CVSVERSIONDIR=$(top_srcdir) vers_string -v
+ CVSVERSIONDIR=$(top_srcdir) $(top_srcdir)/vers_string -v

--
BOFH excuse #20:

divide-by-zero error

nss_ldap-265

2009-11-06T02:28:55Z

265 Luke Howard <lukeh@...>

* fix for BUG#132: add versioning information to binary
* fix for BUG#403: add AM_MAINTAINER_MODE
* fix for BUG#388: bad LDAP query for ether lookups
* fix for BUG#391: clarify bind timelimit defaults
in ldap.conf
* fix for BUG#392: call do_close() if ldap_result()
or ldap_parse_result() fails (before returning
NSS_UNAVAIL)
* fix for BUG#401: FreeBSD thread library check
* fix for BUG#409: deallocate context in
_nss_ldap_ent_context_release() to avoid bad usage
* fix for BUG#410: don't leak file descriptors in
_nss_ldap_readconfig

Re: Call for nss_ov and nss-ldapd Testers

2009-11-05T07:47:35Z

On Nov 5, 2009, at 2:54 AM, stephen mulcahy wrote:

> Hi Matthew,
>
> Apologies for asking but what is nss_ov? A quick google didn't shed
> any light on it.

Not at all- maybe a little history is in order:

Those of you familiar with Arthur's work will know that the nss-ldapd
project originally consisted of a very small nss_ldap library module
that communicated with a local daemon called ldapd, which in turn
communicated with a remote LDAP server. Many instances of the nss_ldap
library communicated with a single ldapd process. The ldapd process
performed the heavy lifting, and the nss_ldap module was therefore
much smaller, simpler and faster. In addition, consolidating the LDAP
communication functions into a daemon would make it easier to develop
caching strategies and enhanced access control features.
Unfortunately, since the ldapd was and is still relatively new, these
features are yet to be developed.

Howard Chu looked at Arthur's work and realized that the OpenLDAP
server daemon, slapd, already had everything needed to implement
caching, replication, and many more desirable features, and only
needed a listener to let it interface to the new nss_ldap module. Thus
was born nss_ov, a slapd overlay that listens for requests from nss-
ldapd's nss_ldap library and turns them into the appropriate internal
slapd operations for processing. A slapd server process could now
replace the original ldap process. For it's part, slapd could be
configured as a cache server, or as a full or partial replica of
another OpenLDAP server. The replication strategy allowed for fully
disconnected operation if desired. OpenLDAP's rich access control
policies enabled the creation of many more methods of managing login
access to systems.

The work done for nss_ldap was a great step forward, but any system
using it still had need of PAM functionality to handle LDAP
authentication. Configuring pam_ldap entailed installing and managing
much of the same infrastructure needed for the original nss_ldap code,
so it actually became more difficult to configure and manage systems
using pam_ldap and the new nss_ldap/ldapd combination. Our goal was to
only have to manage a single system, so Howard developed a small
pam_ldap module that could communicate with nss_ov/slapd and added the
necessary support functions to nss_ov. When Howard submitted the new
PAM module for inclusion in the nss-ldapd project, Arthur added the
requisite functionality to the ldapd daemon to support PAM operations.

So now the nss-ldapd pam_ldap and nss_ldap libraries can be used
either with Arthur's ldapd daemon, or with the OpenLDAP Project's
slapd daemon. Each has their advantages: ldapd is relatively small and
light, but at present doesn't support caching and is relatively
untested. The slapd daemon is larger and can consume more resources,
but offers caching, replication, a richer access control model, and
many more capabilities as discussed above. The need for additional
resources is mitigated by the fact that most systems these days can
provide them, and the fact that the functionality brought by using
slapd is well worth the additional resources.

With SUUM v4, Symas is providing an integrated package that blends the
nss_ldap and pam_ldap modules from the nss-ldapd project with a
version of OpenLDAP tailored to run on a client in any of several
modes. Sample configuration files will help the new user get started
quickly.

I should also point out that new work on OpenLDAP's pcache overlay
greatly enhances the ability of a client to run in disconnected mode
with master servers other than OpenLDAP, but that's a discussion for
another time.

Cheers,

-Matt

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

>
> Thanks,
>
> -stephen
>
> --
> Stephen Mulcahy, DI2, Digital Enterprise Research Institute,
> NUI Galway, IDA Business Park, Lower Dangan, Galway, Ireland
> http://di2.deri.ie http://webstar.deri.ie http://sindice.com

Call for nss_ov and nss-ldapd Testers

2009-11-04T12:22:57Z

For those of you interested in the intersection of the excellent work
done by Arthur de Jong on nss-ldapd and Howard Chu on nss_ov, Symas is
developing an integrated package consisting of the nss_ldap and
pam_ldap libraries from nss-ldapd and the OpenLDAP server configured
with the nss_ov overlay.

The new package has been dubbed Symas Unified User Management version
4 and is available now without download restrictions. Symas will
provide complimentary technical support during the testing period.

Available platforms include Solaris and Red Hat Linux, with more
platforms becoming available as we have the opportunity to port to
them. As always, the results of our work are submitted for inclusion
upstream in the nss-ldapd and OpenLDAP projects.

The release announcement is here: http://www.symas.com/updates/?p=37.
Subscribe to this blog's RSS feed to stay abreast of new releases as
they become available.

Please direct support questions to support@.... We'll do our
best to resolve any issues as quickly as possible.

Cheers,

-Matt

Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com

Re: disconnected nss_ldap

2009-11-01T22:24:06Z

On Sun, 2009-11-01 at 22:19 -0500, Brian J. Murrell wrote:
>

Hrm. I spoke too soon. :-(

> Some debugging in nscd reveals that the problem lies in that the
> only error value that nscd is allowing for the "unreachable server" case
> is EAGAIN. However, in my case (at least), where I am blocking the LDAP
> server with iptables configured to send back TCP RST, the error value is
> ENOTCONN and when I tell nscd that ENOTCONN is a vaild error for the
> "unreachable" case, nscd seems to hold on to the entries it had before
> the LDAP server became unreachable.

But in testing what nscd does when the network connection is down
altogether, it would seem that __getpw{nam|uuid}_r() returns an ENOENT
(2). Which of course it not valid for the "server unreachable" clause
of nscd which simply allows the cached record to live on.

I'm not sure why that is TBH. It seems reasonable that an ENOENT is
suitable for the local, /etc/passwd entry (in absence of any other
databases), but surely when configured with nss_ldap ("passwd: compat
ldap" in /etc/nsswitch.conf), an ENOENT for a missing /etc/passwd entry
is suppressed and the return from nss_ldap is the final return for the
__getpw{nam|uuid}_r() functions, yes?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-11-01T19:19:32Z

On Sun, 2009-11-01 at 19:59 -0500, Brian J. Murrell wrote:
>
> What can I do to help narrow this down?

OK. Some debugging in nscd reveals that the problem lies in that the
only error value that nscd is allowing for the "unreachable server" case
is EAGAIN. However, in my case (at least), where I am blocking the LDAP
server with iptables configured to send back TCP RST, the error value is
ENOTCONN and when I tell nscd that ENOTCONN is a vaild error for the
"unreachable" case, nscd seems to hold on to the entries it had before
the LDAP server became unreachable.

More time will tell for sure.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: disconnected nss_ldap

2009-11-01T18:01:13Z

Brian J. Murrell wrote:

> I got it to build and install without much ado.
>
> Unfortunately, it doesn't seem to do much better than we had before.
>
> I am using an iptables rule (which sends back a TCP RST to existing and
> new connection attempts) at my ldap server to simulate disconnection.
>
> For a short while after "disconnection" "id brian" returns a result, but
> as before, not very long after disconnection it starts failing.
>
> What can I do to help narrow this down?

You're chasing a dead-end. Even if you get this aspect working, nscd still
doesn't cache enumerations, which are the most expensive nss lookup operation.
(e.g., an unqualified "getent" call). nscd is broken by design.

--
-- 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: disconnected nss_ldap

2009-11-01T16:59:51Z

On Sun, 2009-11-01 at 15:19 -0400, Ryan Lynch wrote:
> Not yet--i ran into some problems compiling w/ Howard's 'mega'
> patch--there are some conflicts between ./configure options that I
> don't understand. Howard hasn't gotten back to me, yet, so I'm
> probably going to have to go trial-and-error on Monday.

I got it to build and install without much ado.

Unfortunately, it doesn't seem to do much better than we had before.

I am using an iptables rule (which sends back a TCP RST to existing and
new connection attempts) at my ldap server to simulate disconnection.

For a short while after "disconnection" "id brian" returns a result, but
as before, not very long after disconnection it starts failing.

What can I do to help narrow this down?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-11-01T11:19:51Z

Not yet--i ran into some problems compiling w/ Howard's 'mega'
patch--there are some conflicts between ./configure options that I
don't understand. Howard hasn't gotten back to me, yet, so I'm
probably going to have to go trial-and-error on Monday.

-Ryan

On 2009-11-01, Brian J. Murrell <brian@...> wrote:
> On Tue, 2009-10-27 at 22:10 -0400, Ryan Lynch wrote:
>> I'm sorry, I got busy with another project, and didn't get paste
>> making the RPMs. I'll see about it, tomorrow.
>
> Any progress there Ryan?
>
> b.
>
>

--
Ryan B. Lynch
ryan.b.lynch@...

Re: disconnected nss_ldap

2009-10-30T21:05:20Z

On Tue, 2009-10-27 at 22:10 -0400, Ryan Lynch wrote:
> I'm sorry, I got busy with another project, and didn't get paste
> making the RPMs. I'll see about it, tomorrow.

Any progress there Ryan?

b.

signature.asc (204 bytes) Download Attachment

Re: disconnected nss_ldap

2009-10-27T19:10:23Z

I'm sorry, I got busy with another project, and didn't get paste
making the RPMs. I'll see about it, tomorrow.

-Ryan

On 2009-10-27, Ryan Lynch <ryan.b.lynch@...> wrote:

> On Tue, Oct 27, 2009 at 11:27, Howard Wilkinson <howard@...> wrote:
>> Ryan,
>>
>> please try this out - it applies and runs in the environment here but I
>> would not call that an exhaustive test!
>>
>> This is very much a hack - but without a complete write through the
>> ldap-nss logic is too complex to do this any other way today.
>
> I should have something back to you in a few hours.
>
> -Ryan
>

--
Ryan B. Lynch
ryan.b.lynch@...

Re: Re: Re: disconnected nss_ldap

2009-10-27T08:38:46Z

On Tue, Oct 27, 2009 at 11:27, Howard Wilkinson <howard@...> wrote:
> Ryan,
>
> please try this out - it applies and runs in the environment here but I would not call that an exhaustive test!
>
> This is very much a hack - but without a complete write through the ldap-nss logic is too complex to do this any other way today.

I should have something back to you in a few hours.

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T08:27:00Z

Ryan,

please try this out - it applies and runs in the environment here but I would not call that an exhaustive test!

This is very much a hack - but without a complete write through the ldap-nss logic is too complex to do this any other way today.

Howard.

On Tue, Oct 27, 2009 at 10:35, Howard Wilkinson <howard@...> wrote:
> I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Fire when ready.

> This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

That's good--I was in the process of rebuilding RPMs with your latest
mega rev when I saw your original message, so I can save a little time
testing both at once.

-Ryan

diff -ruN nss_ldap-264-save/nss_ldap-264/ldap-nss.c nss_ldap-264/nss_ldap-264/ldap-nss.c
--- nss_ldap-264-save/nss_ldap-264/ldap-nss.c 2009-10-26 11:05:50.659588000 +0000
+++ nss_ldap-264/nss_ldap-264/ldap-nss.c 2009-10-27 15:19:42.053806000 +0000
@@ -308,6 +308,11 @@
static NSS_STATUS do_map_error (int rc);

/*
+ * Map status to status and errno - handles out of buffer fudges
+ */
+static NSS_STATUS do_map_errno (NSS_STATUS status, int *errnop);
+
+/*
* support the sasl interaction
*/
static int do_sasl_interact (LDAP * ld, unsigned flags, void *defaults, void *p);
@@ -1665,7 +1670,7 @@
}
}

-void
+static void
do_init_mechs (ldap_session_t *session)
{
int i;
@@ -2523,7 +2528,7 @@
#define _APPEND_STRING(_buffer, _buflen, _s, _len) do { \
if ((_buflen) < (size_t)((_len) + 1)) \
{ \
- return NSS_TRYAGAIN; \
+ return NSS_RETURN; \
} \
memcpy((_buffer), (_s), (_len)); \
(_buffer)[(_len)] = '\0'; \
@@ -2610,7 +2615,7 @@
len = strlen (filter);

if (buflen < len + 1 /* ')' */ )
- return NSS_TRYAGAIN;
+ return NSS_RETURN;

memcpy (bufptr, filter, len);
bufptr[len] = '\0';
@@ -2619,7 +2624,7 @@
}

if (buflen < 2)
- return NSS_TRYAGAIN;
+ return NSS_RETURN;

*bufptr++ = ')';
*bufptr++ = '\0';
@@ -2705,7 +2710,7 @@
args->la_arg1.la_triple.user,
args->la_arg1.la_triple.domain,
filterBufP, filterSiz);
- if (stat == NSS_TRYAGAIN)
+ if (stat == NSS_RETURN)
{
filterBufP = *dynamicUserBuf = realloc (*dynamicUserBuf,
2 * filterSiz);
@@ -2714,7 +2719,7 @@
filterSiz *= 2;
}
}
- while (stat == NSS_TRYAGAIN);
+ while (stat == NSS_RETURN);
break;
#endif /* HAVE_NSSWITCH_H || HAVE_IRS_H */
case LA_TYPE_STRING_LIST_OR:
@@ -2724,7 +2729,7 @@
stat = do_aggregate_filter (args->la_arg1.la_string_list,
args->la_type,
filterprot, filterBufP, filterSiz);
- if (stat == NSS_TRYAGAIN)
+ if (stat == NSS_RETURN)
{
filterBufP = *dynamicUserBuf = realloc (*dynamicUserBuf,
2 * filterSiz);
@@ -2733,7 +2738,7 @@
filterSiz *= 2;
}
}
- while (stat == NSS_TRYAGAIN);
+ while (stat == NSS_RETURN);
break;
default:
return NSS_UNAVAIL;
@@ -2963,6 +2968,7 @@
int maxtries;
int hard;
int firstTime = 1;
+ int errnotmp = 0;

debug ("==> do_with_reconnect");

@@ -3116,7 +3122,7 @@
"nss_ldap: could not %s %sconnect to LDAP server - %s",
hard ? "hard" : "soft", tries ? "re" : "",
ldap_err2string (rc));
- stat = NSS_UNAVAIL;
+ /* stat = NSS_UNAVAIL; */
break;
case NSS_SUCCESS:
if (log != 0)
@@ -3148,6 +3154,8 @@

debug ("<== do_with_reconnect returns %s(%d)", __nss_ldap_status2string(stat), stat);

+ stat = do_map_errno(stat, &errnotmp);
+
return stat;
}

@@ -3273,10 +3281,10 @@
return rc;
}

-static void
+static NSS_STATUS
do_map_errno (NSS_STATUS status, int *errnop)
{
- if (status == NSS_TRYAGAIN)
+ if (status == NSS_RETURN)
{
#ifdef HAVE_NSSWITCH_H
errno = ERANGE;
@@ -3284,11 +3292,17 @@
#else
*errnop = errno = ERANGE;
#endif
+ status = NSS_TRYAGAIN;
+ }
+ else if (status == NSS_TRYAGAIN)
+ {
+ *errnop = errno = EAGAIN;
}
else
{
*errnop = 0;
}
+ return status;
}

/*
@@ -3342,7 +3356,7 @@
buffer, buflen);

/* hold onto the state if we're out of memory XXX */
- ctx->ec_state.ls_retry = (parseStat == NSS_TRYAGAIN && buffer != NULL ? 1 : 0);
+ ctx->ec_state.ls_retry = (parseStat == NSS_RETURN && buffer != NULL ? 1 : 0);

/* free entry is we're moving on */
if (ctx->ec_state.ls_retry == 0 &&
@@ -3356,7 +3370,7 @@
}
while (parseStat == NSS_NOTFOUND);

- do_map_errno (parseStat, errnop);
+ parseStat = do_map_errno (parseStat, errnop);

debug ("<== do_parse");

@@ -3408,17 +3422,17 @@
* If we do not parse the entry because of a schema
* violation, the parser should return NSS_NOTFOUND.
* We'll keep on trying subsequent entries until we
- * find one which is parseable, or exhaust avialable
+ * find one which is parseable, or exhaust available
* entries, whichever is first.
*/
parseStat = parser (e, &ctx->ec_state, result, buffer, buflen);

/* hold onto the state if we're out of memory XXX */
- ctx->ec_state.ls_retry = (parseStat == NSS_TRYAGAIN && buffer != NULL ? 1 : 0);
+ ctx->ec_state.ls_retry = (parseStat == NSS_RETURN && buffer != NULL ? 1 : 0);
}
while (parseStat == NSS_NOTFOUND);

- do_map_errno (parseStat, errnop);
+ parseStat = do_map_errno (parseStat, errnop);

debug ("<== do_parse_s");

@@ -4076,7 +4090,7 @@
if (bytesleft (buffer, buflen, char *) < (valcount + 1) * sizeof (char *))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

align (buffer, buflen, char *);
@@ -4110,7 +4124,7 @@
if (buflen < (size_t) (vallen + 1))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

/* copy this value into the next block of buffer space */
@@ -4156,7 +4170,7 @@
vallen = strlen (ovr);
if (*buflen < (size_t) (vallen + 1))
{
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4184,7 +4198,7 @@
vallen = strlen (def);
if (*buflen < (size_t) (vallen + 1))
{
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4207,7 +4221,7 @@
if (*buflen < (size_t) (vallen + 1))
{
ldap_value_free (vals);
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4304,7 +4318,7 @@
ldap_value_free (vals);
}
debug ("<== _nss_ldap_assign_userpassword");
- return NSS_TRYAGAIN;
+ return NSS_RETURN;
}

*valptr = *buffer;
@@ -4679,6 +4693,7 @@
{
debug ("<== _nss_ldap_proxy_bind (empty password not permitted)");
/* XXX overload */
+ do_map_errno(NSS_TRYAGAIN, &rc);
return NSS_TRYAGAIN;
}

@@ -4749,6 +4764,8 @@

debug ("<== _nss_ldap_proxy_bind");

+ stat = do_map_errno(stat, &rc);
+
return stat;
}

Re: Re: Re: disconnected nss_ldap

2009-10-27T07:59:14Z

On Tue, Oct 27, 2009 at 10:35, Howard Wilkinson <howard@...> wrote:
> I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Fire when ready.

> This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

That's good--I was in the process of rebuilding RPMs with your latest
mega rev when I saw your original message, so I can save a little time
testing both at once.

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T07:35:31Z

Hi Ryan,

Howard,

On Tue, Oct 27, 2009 at 08:24, Howard Wilkinson <howard@...> wrote:
> If anybody who understands the nsswitch internals can confirm which is the correct response I will patch the nss_ldap library (I have half a patch already) and try this out.

I'm in a position to test patches for this, even if they're a bit
rough--I have a couple of throwaway VMs specifically intended for
this. Feel free to send anything you have, I'd love to see this issue
resolved, soon.

I am working on this now and hope to have something out today. The internals of nss_ldap are a bit of mess in this area, but I think I have a handle on it.

Also, will your patch for this issue sit on top of your "mega" patch,
or on the unpatched PADL tree?

-Ryan

This will have to go on the top of the mega patch as the original code is even worse in this area..... ;-(

Howard.

Re: Re: Re: disconnected nss_ldap

2009-10-27T07:21:28Z

Howard,

On Tue, Oct 27, 2009 at 08:24, Howard Wilkinson <howard@...> wrote:
> If anybody who understands the nsswitch internals can confirm which is the correct response I will patch the nss_ldap library (I have half a patch already) and try this out.

I'm in a position to test patches for this, even if they're a bit
rough--I have a couple of throwaway VMs specifically intended for
this. Feel free to send anything you have, I'd love to see this issue
resolved, soon.

Also, will your patch for this issue sit on top of your "mega" patch,
or on the unpatched PADL tree?

-Ryan

RE: Re: Re: disconnected nss_ldap

2009-10-27T05:24:37Z

Brian et al,

I think the problem with the nscd issue may be a bug in nss_ldap's interface with the nsswitch interface.

.......

nscd really does seem like it would complete the solution if it didn't
suffer from redhat bug 2132.

Cheers,
b.

I have looked into the nss_ldap code and it responds with NSS_STATUS_UNAVAIL, errno = EPERM for the following cases.

LDAP_SERVER_DOWN, LDAP_TIMEOUT, LDAP_UNAVAILABLE, LDAP_BUSY, LDAP_CONNECT_ERROR, LDAP_LOCAL_ERROR, LDAP_INVALID_CREDENTIALS.

The last 2 are I suspect correct but the first 5 are really candidates for 'server has gone away'. I suspect, but can't quite decide whether I am right, that the code should respond with either NSS_STATUS_TRYAGAIN, errno != ERANGE, or NSS_STATUS_UNAVAIL, errno = EAGAIN for the cache to continue to be populated with the entry.

If anybody who understands the nsswitch internals can confirm which is the correct response I will patch the nss_ldap library (I have half a patch already) and try this out.

Howard.

Re: Re: Re: how disable shadow map

2009-10-26T08:53:03Z

On Mon, 2009-10-26 at 09:50 -0500, Douglas E. Engert wrote:
> Well then set the userPassword attributes to "{crypt}NP"
> as I described on 10/21. pam_unix will not complain,

I'm not so sure of this. But as I posted to this thread a few days ago,
the real solution is to remove the shadowAccount object class from
records you don't want shadow information made available for.

b.

signature.asc (204 bytes) Download Attachment

Re: Re: Re: how disable shadow map

2009-10-26T07:50:22Z

Brian J. Murrell wrote:

> On Fri, 2009-10-23 at 20:16 -0700, Paul B. Henson wrote:
>> Sorry, I wasn't paying attention to the beginning of this thread, so I
>> don't recall what OS you're using. Linux variants of pam_unix support the
>> "broken_shadow" option:
>>
>> broken_shadow
>> Ignore errors reading shadow information for users in the
>> account management module.
>>
>> Which I think will do exactly what you want, if you're running Linux.
>
> Indeed, it does and I tested that before posting. But my distro
> (Ubuntu) maintainer reports that not having shadow map entries when the
> password is "x" is just broken (which given what I have read, I agree)
> and I tend to think they will likely refuse to use such hacks and insist
> that the breakage be fixed instead.

Well then set the userPassword attributes to "{crypt}NP"
as I described on 10/21. pam_unix will not complain,
and since you are using pam_krb5 for authentication this works
fine with our Ubuntu systems.

>
> I'm starting to feel like I'm pissing up a rope with regard to the basic
> bug here though.
>
> b.
>

--

Douglas E. Engert <DEEngert@...>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Re: Mega patch against nss_ldap 264

2009-10-25T07:12:48Z

I have revisited this code and posted some new patches to the bugzilla.
This now includes more comprehensive recovery code when the connection
to the server goes down.

I know of one outstanding issue with the group stuff, where recursion is
used to expand nested groups the recovery code fails. I intend to remove
the recursion and replace with list walking code to produce the
transitive closure needed for this function.

Anybody who is feeling brave and would like to test this out then I need
to know I have not broken any of:
1. Plain text password binds
2. Anonymous binds
3. SSL/TLS binds
4. Other LDAP backends - my major testing has been against Active
Directory, so tests against the Fedora Directory Server (389DS) and
OpenLDAP would be useful.

Furthermore, I have tested but not implemented in production the keytab
based renewal code. So if someone can hammer this it would be great.

Howard.

P.S. I think the hard/soft features in the Bind code should now function
as advertised - can somebody check this as well?

On Tue, 2008-12-09 at 22:13 +0000, Luke Howard wrote:

> Thanks Howard! I am a bit snowed under now but I really look forward
> to taking a look at this.
>
> -- Luke
>
> On 10/12/2008, at 5:30 AM, Howard Wilkinson wrote:
>
> > I have just pushed a large patch against nss_Ldap 264 up to the
> > bugzilla.
> >
> > This is a structural alteration at the source code level to ldap-
> > nss.c which is generally just changing how it reads. However, it
> > fixes some bugs in the kerberos pathways and also commons up code
> > that had multiple copies in the code source.
> >
> > I would be very grateful if anybody could try it out and let me
> know
> > what I have broken.
> >
> > My intention with this is to make the critical path through the
> code
> > run the minimal code when a connection to the LDAP server exists,
> > make recovery on failure more resilient, and provide for multiple
> > SASL mechs without need to alter the ldap-nss code.
> >
> > Comments, improvements and fault reports much appreciated.
> >
> > I am hoping that Luke will push this out as the basis for the main
> > development downstream, so that I can add the extra features on the
> > kerberos side I am looking for.
> >
> > Howard.
> >
> >
>
> --
> www.padl.com | www.fghr.net
>
>
>

--
Howard Wilkinson <howard@...>
Coherent Technology Limited

[solved] how disable shadow map

2009-10-24T07:15:34Z

On Wed, 2009-10-21 at 12:12 -0400, Brian J. Murrell wrote:
> Hi,
>
> I want to disable the shadow map, and specifically, stop the passwd map
> from returning "x" in the password field.

This is in fact quite simple to do, on a user-by-user basis even.

> I noticed from a quick browse of the code:
>
> if (_nss_ldap_oc_check (e, "shadowAccount") == NSS_SUCCESS)
> {
> /* don't include password for shadowAccount */
> if (buflen < 3)
> return NSS_TRYAGAIN;
>
> pw->pw_passwd = buffer;
> strcpy (buffer, "x");
> buffer += 2;
> buflen -= 2;
> }
> else
> {
> stat =
> _nss_ldap_assign_userpassword (e, ATM (LM_PASSWD, userPassword),
> &pw->pw_passwd, &buffer, &buflen);
> if (stat != NSS_SUCCESS)
> return stat;
> }

This above code snippet is really what led me to the solution.

One simply removes (if it exists, which it should if your passwd entry
is "x") the shadowAccount object class from the LDAP record (which your
nss_ldap is configured to map to the passwd map) for users which you
don't want shadow information available. The "x" in the password field
of the passwd entry changes to a "*" once this is done and there is no
entry in the shadow map any more.

Cheers,
b.

signature.asc (204 bytes) Download Attachment