Re: Help the newbie please

[Ryan Steele <ryans [at] aweber.com>]

Kean Johnston wrote:
>> 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?

I think you're misunderstanding or just haven't read the relevant documentation 
yet; the rootdn password is not included
there in plaintext, it's hashed.  Please read the man pages:

"...slappasswd(8) may be used to generate a hash of a password.  Cleartext and 
{CRYPT} passwords are not recommended..."

In normal day to day use, I would not advise using the rootdn to do anything, 
for the reasons you state above, among
others.  Assign your junior admins to accounts subject to the relevant ACL's.  
There is a lot of documentation out there
on this.  Perhaps it would be prudent for you to review the admin guide before 
proceeding further:
http://www.openldap.org/doc/admin24/index.html

> 
> 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.

I don't use nssov, so I don't know what the nss stub that comes with it looks 
like, and can't give you any educated
advice on using it.

> 2. Change nsswitch.conf to have filed ldap instead of ldap files

That's what I would do.  It's not going to solve all of your problems, but it 
might help stave off some.  Again, YMMV.

> 3. remove all references to pam_ldap from /etc/pam.d/system-auth

That depends.  Are you using LDAP for authentication?  If so, then doing so 
would be detrimental.  If you're using
Kerberos or something like that, perhaps that makes more sense.  You may want 
to read the pam_ldap documentation and/or
man pages for more clarification.

> Is that correct?

Honestly, I would take some time to read and understand the documentation, 
especially the admin guide I linked above.
And, for questions specific to OpenLDAP that aren't answered in the docs, I 
would send questions to their lists; all
nss-pam-ldapd is doing is acting as the glue between NSS/PAM and LDAP.  Things 
like your slapd configuration and using
OpenLDAP ACLs and privilege separation are out of the scope of this mailing 
list.  But, since many of the questions
you're asking are answered in the admin guide, and you did ask to be pointed at 
a good reference, I would again highly
suggest reading it (and the man pages).  The #openldap irc channel on Freenode 
may also prove useful to you.


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

No problem, we've all been there.  :)

-- 
Ryan Steele                                    ryans@aweber.com
Systems Administrator                          +1 215-825-2196 x758
AWeber Communications                          http://www.aweber.com
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users