base lookup from LDAP server or host domain, and /etc/nsswitch.conf file permissions

[Alexander Lasky <ALEXANDER.LASKY [at] sydneywater.com.au>]

Arthur:

 

Apologies if this is covering old ground, but I didn’t see any recent discussion on this in the email archive. I was trying to use the non-DN configurations for the "base" entry in nslcd.conf, i.e. DOMAIN and completely omitting the entry. These are very useful features, as they allow a fixed nslcd.conf file to be used across different domains.

 

According to the docs, omitting the "base" entry from nslcd.conf causes nslcd to lookup the base from the LDAP server. Unfortunately nothing was being returned for me with this configuration, causing failure of nslcd. The documentation was vague on which attributes of which objects it tries to retrieve from the LDAP server as the base in this case. Perusing the code revealed that nslcd tries to read the RootDSE object’s "defaultNamingContext" attribute, or failing that, the first element of "namingContexts". The query involved a BASE scope search for (objectClass=*) with an empty string for the base. This was all valid. However the attribute specification is hardcoded as "+", which at least for Active Directory returns nothing. The required attribute specification for Active Directory was "*" to return all attributes including "defaultNamingContext" and "namingContexts".

 

Could I suggest replacing or augmenting the attribute specification of "+" with "*"? Or perhaps even better, an explicit specification of  attributes "defaultNamingContext" and "namingContexts" for the query instead of "*" or "+", given that nslcd ignores any other returned attributes. It would also help users if the documentation explicitly stated the attributes and objects being queried here so that users could check the correctness of their configuration.

 

I also had difficulty using DOMAIN as the specified base due to the vague documentation and the lack of examples. The problem was that an explicit DN specification for "base" allows the inclusion of OU filters but the use of DOMAIN does not, as the word "DOMAIN" if used must constitute the entire value of this configuration field. To make this clearer, perhaps the documentation could be reworded from "If, instead of a DN, the value DOMAIN is specified" to "If, instead of a DN, the value DOMAIN (by itself) is specified". An explicit complete example in the docs would greatly help, e.g.:

By configuring nslcd.conf to include the line

base DOMAIN

 

and /etc/hosts to include

127.0.0.1 mymachine.testenv.local mymachine

 

then nslcd would set the base DN to dc=testenv,dc=local

 

Finally, on an unrelated matter, if /etc/nsswitch.conf has write permission on group or other, then whoami-related system calls will fail for LDAP users, but not for local users in /etc/passwd. As a result LDAP users get "I have no name!" shell command prompts, and empty names in response to id and whoami commands. Conversely, an absence of read permissions on /etc/nsswitch.conf for group or other can break certain commands and services. While all this is documented in various internet discussion forums, I couldn't find these restrictions on /etc/nsswitch.conf file permissions mentioned in the online man pages, nor in your docs. Perhaps it is worth explicitly mentioning that /etc/nsswitch.conf permissions must be set to octal 644 and nothing else?

---

     

---

NOTICE: This email is confidential. If you are not the nominated recipient, please immediately delete this email, destroy all copies and inform the sender. Sydney Water Corporation (Sydney Water) prohibits the unauthorised copying or distribution of this email. This email does not necessarily express the views of Sydney Water. Sydney Water does not warrant nor guarantee that this email communication is free from errors, virus, interception or interference.

---