[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM, LDAP and pam_mkhomedir

On Wed, Feb 18, 2004 at 05:40:12PM +0100, Matthias Saou wrote:
> I'm currently trying to have an FC2 test1 workstation authenticate against a
> central LDAP database. I currently only have RHL 7.3 machines doing something
> similar, so maybe these are changes/issues already present in FC1.
> - When I add the line below to /etc/pam.d/system-auth, the user's home
>   directory only gets created if the user has write access to the directory in
>   which his home directory will reside. Say I have /home/location/user,
>   the "user" directory is created only if /home/location already does too
>   and if there is write access to /home/location for the "user" user.
>   Is this a feature or security enhancement? It renders the module basically
>   useless for me...
> session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=076

SSHD is performing session setup as the user, not as root.  This gets
flipflopped every now and again to try to make pam_limits work (which
can't be fixed 100% within the framework PAM provides, sigh).

> - When an LDAP authenticated user logs in through ssh, it's impossible for him
>   to do any uid/gid <-> name mapping. For instance, if I change the owner of a
>   file to be a user in the LDAP database, doing "ls -l" on it as root does
>   generate connections to the LDAP database and shows the user's name, whereas
>   when logged in as the user, there is no LDAP activity and it shows the
>   numeric uid.
> Maybe related to this 2nd issue, here is what an LDAP user gets through ssh :
> $ ssh user computer
> user computer's password:
> Creating directory '/home/location/user'.
> /usr/X11R6/bin/xauth:  creating new authority file /home/location/user/.Xauthority
> id: cannot find name for user ID 501
> id: cannot find name for group ID 1000
> id: cannot find name for user ID 501
> [I have no name! computer user]$
> Where uid 501 is the user's uid, and gid 1000 his primary group.

These two look very related.  I'd guess that one or more configuration
files (/etc/ldap.conf, mainly) aren't readable by the user, so the
user's processes don't "know" how to contact your LDAP server.
Double-check the permissions, or try running "id" under strace and
monitor for access control (EACCES) and related errors.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]