User resource, ldap and nslcd troubles on Cent OS 6 nodes


#1

Hey All,

I am running into an interesting problem with chef 0.12.0 on CentOS 6.2/6.3 nodes. Our CentOS systems are utilizing the nslcd and nsswitch to for central user authentication against LDAP.

This is part of the nss-pam-ldapd package on CentOS. The system nsswitch uses the ldap module for the following elementsconfiguration is as follows:

passwd: files ldap
group: files ldap
protocols: files ldap
services: files ldap
netgroup: files ldap
automount: files ldap
sudoers: files ldap

I have a users cookbook to create/manage any new local users, but when ever a the user resource is executed during a chef run, we get this error from nslcd per user:

Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] ldap_search_ext() failed: Can’t contact LDAP server
Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] no available LDAP server found, sleeping 1 seconds

Turning on nslcd debug mode, it looks like the user resource is using nslcd/ldap to verify a user account instead of looking at the local files such as /etc/passwd or /etc/shadow. See the debug output below:

[2012-09-06T12:42:17-07:00] INFO: Processing user[testuser] action remove (users::local line 94)
nslcd: [3c9869] DEBUG: nslcd_passwd_byname(testuser)
nslcd: [3c9869] DEBUG: myldap_search(base=“dc=*,dc=com", filter="(&(&(objectClass=user)(!(objectClass=computer))(uidNumber=)(unixHomeDirectory=))(sAMAccountName=testuser))”)
nslcd: [3c9869] DEBUG: ldap_initialize(***)
nslcd: [3c9869] DEBUG: ldap_set_rebind_proc()
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_OFF)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD)
nslcd: [3c9869] DEBUG: ldap_simple_bind_s("***","***") (uri="***")
nslcd: [3c9869] DEBUG: ldap_result(): end of results

The major question here is can we restrict Chef to manage local users accounts/groups only without querying to LDAP using nslcd? It looks like the resource itself is potentially bypassing checks of local passwd/shadow files or checking them and then moving onto the next nsswitch module, which in this case is ldap. Has anyone else experienced these issues or have any insight on the inner workings of the chef user resource when using with ldap enabled Linux systems?

All the best,
Shane Sofos


#2

On Thursday, September 6, 2012 at 1:46 PM, Shane Sofos wrote:

Hey All,

I am running into an interesting problem with chef 0.12.0 on CentOS 6.2/6.3 nodes. Our CentOS systems are utilizing the nslcd and nsswitch to for central user authentication against LDAP.

This is part of the nss-pam-ldapd package on CentOS. The system nsswitch uses the ldap module for the following elementsconfiguration is as follows:

passwd: files ldap
group: files ldap
protocols: files ldap
services: files ldap
netgroup: files ldap
automount: files ldap
sudoers: files ldap

I have a users cookbook to create/manage any new local users, but when ever a the user resource is executed during a chef run, we get this error from nslcd per user:

Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] ldap_search_ext() failed: Can’t contact LDAP server
Sep 6 12:16:01 prn-configtest01 nslcd[1675]: [a21031] no available LDAP server found, sleeping 1 seconds

Turning on nslcd debug mode, it looks like the user resource is using nslcd/ldap to verify a user account instead of looking at the local files such as /etc/passwd or /etc/shadow. See the debug output below:

[2012-09-06T12:42:17-07:00] INFO: Processing user[testuser] action remove (users::local line 94)
nslcd: [3c9869] DEBUG: nslcd_passwd_byname(testuser)
nslcd: [3c9869] DEBUG: myldap_search(base=“dc=*,dc=com", filter="(&(&(objectClass=user)(!(objectClass=computer))(uidNumber=)(unixHomeDirectory=))(sAMAccountName=testuser))”)
nslcd: [3c9869] DEBUG: ldap_initialize(***)
nslcd: [3c9869] DEBUG: ldap_set_rebind_proc()
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_OFF)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
nslcd: [3c9869] DEBUG: ldap_set_option(LDAP_OPT_X_TLS,LDAP_OPT_X_TLS_HARD)
nslcd: [3c9869] DEBUG: ldap_simple_bind_s("***","***") (uri="***")
nslcd: [3c9869] DEBUG: ldap_result(): end of results

The major question here is can we restrict Chef to manage local users accounts/groups only without querying to LDAP using nslcd? It looks like the resource itself is potentially bypassing checks of local passwd/shadow files or checking them and then moving onto the next nsswitch module, which in this case is ldap. Has anyone else experienced these issues or have any insight on the inner workings of the chef user resource when using with ldap enabled Linux systems?

All the best,
Shane Sofos
The default provider for the user resource is the useradd provider, which is just shelling out to useradd. According to the manpage, useradd will always check if a user is defined in LDAP before creating it when you have LDAP configured.

You should be able to see the commands chef is running by setting the logger to debug (-ldebug on the command line). Posting the relevant section of that output would help someone here with more LDAP+CentOS experience than me troubleshoot your issue.

HTH,


Daniel DeLeo