Re: Help the newbie please

[Kean Johnston <kean.johnston [at] gmail.com>]

> 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/libnss_ldap.so.2.
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.

Kean
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users