Running "id omoris" on fixed nss_ldap with "nss_connect_policy oneshot" on i386 always returns 1 (failure) even though its output is correct: # cat /etc/ldap.conf uri ldap://ldap.bos.redhat.com base dc=redhat,dc=com nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm bind_policy soft ssl start_tls tls_cacertdir /etc/openldap/cacerts referrals no nss_connect_policy oneshot # cat /etc/nsswitch.conf ... passwd: files ldap shadow: files ldap group: files ldap ... # id omoris ; echo $? uid=14420(omoris) gid=14420(omoris) groups=14420(omoris),1070,1076 1 This happens on i386 only (I've tried two different i386 machines) and it does not matter if nscd is running or not. There is no relevant error message in /var/log/[messages | secure | audit/audit.log]. When "nss_connect_policy oneshot" is removed or "oneshot" is replaced by "persistent" it correctly returns 0.
(In reply to comment #12) > Running "id omoris" on fixed nss_ldap with "nss_connect_policy oneshot" on i386 > always returns 1 (failure) even though its output is correct: > > # cat /etc/ldap.conf > uri ldap://ldap.bos.redhat.com > base dc=redhat,dc=com > nss_initgroups_ignoreusers > root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm > bind_policy soft > ssl start_tls > tls_cacertdir /etc/openldap/cacerts > referrals no > nss_connect_policy oneshot > > # cat /etc/nsswitch.conf > ... > passwd: files ldap > shadow: files ldap > group: files ldap > ... > > # id omoris ; echo $? > uid=14420(omoris) gid=14420(omoris) groups=14420(omoris),1070,1076 > 1 That doesn't look correct -- the names for the supplemental groups with GID 1070 and 1076 weren't found, which is why id returned a non-zero exit status. When I use the same configuration, on an x86_64 test system, it works as I'd expect. Have you tried other architectures? Is the CA certificate stored in /etc/openldap/cacerts and world-readable, with a symlink from /etc/openldap/cacerts/e569cb81.0 which points to it?
Never mind, I can now confirm that the resolution failure you're seeing is also a bug.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message: ldap_result: Assertion `ld != ((void *)0)' failed. With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,5 +1,5 @@ Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message: - ldap_result: Assertion `ld != ((void *)0)' failed. +ldap_result: Assertion `ld != ((void *)0)' failed. With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,5 +1 @@ -Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused the "id <username>" command to exit with the following error message: +Previously, enabling the "nss_connect_policy oneshot" option in the /etc/ldap.conf configuration file may have caused an application crash. With this update, enabling "nss_connect_policy oneshot" works as expected.- -ldap_result: Assertion `ld != ((void *)0)' failed. - -With this update, enabling "nss_connect_policy oneshot" works as expected, and running the id command no longer fails.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0239.html