Re: Help the newbie please
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: Help the newbie please
- From: Ryan Steele <ryans [at] aweber.com>
- To: Kean Johnston <kean.johnston [at] gmail.com>
- Cc: nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: Help the newbie please
- Date: Wed, 17 Mar 2010 10:58:25 -0400
Kean Johnston wrote:
> Hello everyone,
>
> First let me preface this by stating I am a complete LDAP (and yes even
> PAM) newbie, as I come from a UNIX background where PAM wasn't an option
> and I have only ever used LDAP as a user before, never had to administer
> it. But I need you help please, as I have been struggling for well over
> a week to get things working. I think the problem I am having is with
> the PAM portion of nss-pam-ldapd but if it isn't, and you either happen
> to know the answer or can point me in the direction of docs or lists
> that may provide it, I would be much obliged.
>
> First let me describe the environment. Running CentOS 5.3 with a custom
> compiled version of OpenLDAP 2.4.21 with nssov. Using nss-pam-ldapd
> (which I will call N-P-L for short from now on) 0.7.3 but obviously not
> using the daemon part of it due to using nssov. Currently I just have
> one host running SLAPD but I plan on setting up replication in the near
> future when I have the basic stuff worked out. What I want to achieve is
> this:
>
> 1. Have all normal user accounts stored only in LDAP. Only root and one
> other special account, as well as all of the various package-specific
> pseudo accounts need to be in the local databases. Obviously I also want
> all user group membership handled in LDAP too.
> 2. Users must be able to change their own passwords when logged in to a
> host, preferably using the standard passwd command. root must be able to
> change any user's account just like in traditional UNIX using flat files.
> 3. Ideally I would like to be able to do some form of authorization to
> hosts on an individual host basis but that can come later.
> 4. If a user is defined in LDAP and allowed access to the host they must
> be able to SSH into the host from anywhere as long as they know their
> LDAP password.
>
> I think I have most of the required bits there but I just can't get this
> to work. I will include as much of the config stuff as I can think of in
> the hope that too much information is better than too little.
>
> The relevant bits of the various configuration files are posted here so
> I don't clutter the mailing list: http://unix42.com/ldap
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).
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 can do all the various LDAP things I want like ldapsearch and such but
> I absolutely cannot figure out how to log in. ssh fails (ssh -vvv yields
> absolutely no useful information at all), there are no errors in
> /var/log/messages and pam_ldap doesn't have any form of debugging (BTW
> would you accept a patch to add some?) so I can't see where its failing.
>
> The only GOOD news is that NSS seems to be working ok. It may in fact be
> the root of my problems:
> getent passwd jkj
> jkj:{SSHA}REMOVED:1009:1010:Kean Johnston:/home/jkj:/bin/bash
> getend shadow ldapadm
> ldapadm:{SSHA}REMOVED:::::::0
>
> The interesting thing to note here is that becuase user jkj does not
> have and objectClass: shadowAccount the userPassword attribute is being
> sent as part of the passwd lookups (getpwent) whereas ldapadm does so
> its userPassword is being sent as part of the /etc/shadow lookups. I
> have tried logging in via SSH with the jkj account set to have the
> shadowAccount objectclass and it made no difference.
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).
> The one other thing I noticed was trying to set a users password using
> the passwd command as root. It asked for the LDAP administrator pasword.
> What password is that? Any this flies in the face of traditional use of
> the passwd tool where a root user (a sysadmin) should have power to
> change a user's password but may very well NOT be the LDAP administrator
> becuase a sysadmin doesn't need and shouldn't have access to the full
> directory (thing: sensitive HR info in the LDAP directory).
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.
Would the
> following change to pam.c fix this? (line 695):
You should not need to hack up pam.c...
> if ((pwent!=NULL)&&(pwent->pw_uid!=getuid() && getuid() != 0))
>
> Anyway ... any help at all would be greatly appreciated. My thanks for
> your time and patience.
>
Before you try any of this though, run slapd in the foreground (slapd -d 16383)
and see what you get; syslog is
inherently lossy, so this is the only sure way to catch everything.
--
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