RSS feed

Re: Help the newbie please

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: Help the newbie please

We haven't made the switch to nssov yet, so I can't vouch for that part of your 
config, but the rest I can certainly
comment on.  I always put 'files' before 'ldap' in nsswitch.conf, because it 
seems (for me, at least, YMMV) that I
encounter less problems that way, as the local files will be the first to be 
checked for users (avoiding delays when
doing lookups for local users like root).
That's easy enough to do. Right now I have it that way because I want LDAP to be the first thing tried while I test. I don't want to remove the normal user entries from /etc/passwd until teh LDAP stuff is working correctly. Obviously root and other special accounts will remain in /etc/passwd though, I wont ever be removing those.

Before commenting on your slapd.conf, I would advise that for new 
installations, one should use the new cn=config style
configuration backend; slapd.conf is being deprecated.
I shall do that when my config munging has stabalised. if I need to re-order things its a lot easier right now to move a line up or down. with the cn=config thing it appear (unless I am mistaken) that I would have to manually change the various indices if for example I wanted one schema to load before another.

Where root changing the password with the admin is concerned, you have defined 
no rootdn or rootpw in your slapd.conf,
so it is not surprising that you are unable to change the user's password; I 
would suggest a 'man slapd.conf'.  Once you
have that straightened out and you can start changing user passwords, to make 
sure the hash is really correct, I would
definitely change that password for the user with 'ldappasswd'.  Also, you may 
have to specify the 'password-hash
{SSHA}' option in your slapd.conf, if your version of slapd does not inherently 
assume that.  Where objectClasses are
concerned, users do not require shadowAccount to be able to log in via SSH, at 
least not on any system I employ LDAP
with (CentOS, Ubuntu).  I would also try making your PAM configurations simpler 
to start out with, until things work.  I
think CentOS has that auth-config-tui (or something similar) to autogenerate a 
basic working LDAP-aware config.
I will happily remove the shadowAccount object class. The fewer the better. But I am highly concerned by the need for a rootdn and rootpw. I didnt miss them in the config, I expressly ignored them. perhaps that was an error but here's how I understand things. The rootdn user has absolute full and unfettered access to the directory, not subject to ACL's or anything else. That user needs to be extremely trusted, especially if the LDAP directory will start housing things like people's SSN's, bank account details etc. For legal, ethical and simple common sense reasons that kind of access needs to be extremely limited. In a large organisation, many users may have root priveliges because its a reality of UNIX that you need that access in order to administer the system and networks correctly. Many of those sysadmins are fairly junior staff and certainly should NOT have access to sensitive personal information. But if they all have the rootpw pasword just so that they can change a user's password if they have lost it means that they now have unfettered access to the directory. This is really, really bad. There has to be some way of mimicking the traditional passwd behaviour of root being able to reset anyone's password without also giving away the keys to the castle?

Also, re you previous mail, you said:

That cannot possibly work.

I can assure you it does, but I was perhaps a bit broad and short in my 
explanation.  You do not need the entirety of
pam_ldap and nss_ldap; rather, just the slimmed-down stub provided to replace 
nss_ldap by nss-pam-ldap.  With nssov and
that stub, they talk directly to LDAP via IPC sockets, to avoid the overhead of 
traditional pam_ldap/nss_ldap
installations, where those modules acted as the TCP/IP supported glue between 
those two and LDAP.

The nss-ldapd directory inside the nssov source code, which contains the "stub library" is pretty much just an older version of nss-pam-ldapd. I've looked at the diffs. Some are just cosmetic, theres a wee bit of reordering and some minor tweaks here and there. Unless the server protocol has changed between the version thats in nssov and this latest 0.7.3 release, what you said still holds true. The still talk to LDAP over an IPC socket. Thats the beauty of nssov - it replaces the daemon but not the stub functionality. The single biggest difference I saw between the one in nssov's spource code and nss-pam-ldapd 0.7.3 is in the nssov one, pam.c is in the nss/ directory and gets built as part of the nss stub library. In nss-pam-ldapd its built as a separate module. Perhaps that difference is majorly important. either way I am going to try use just the stub that came with nssov (but I could have sworn I already tried that and it was that failing to work that led me to try the updated N-P-L).

If I am understanding you correctly, what I should do is:
1. Use the nss stub that came with nssov. Install this as /lib64/
2. Change nsswitch.conf to have filed ldap instead of ldap files
3. remove all references to pam_ldap from /etc/pam.d/system-auth

Is that correct?

Thanks so much for you time, it is greatly appreciated.

To unsubscribe send an email to or see