LDAP-UX Client - User restrictions

[PatRoy]

Hi.

If I have a user jdoe in /etc/passwd with uid 110 and this user ALSO exists in my LDAP server with a uid of 500 in there... How can I prevent jdoe from login on with his ldap password? I *only* want this fellow to login with his local pwd.

I can't seem to figure it out quite right with the pam_authz.policy file...

Regards, Patrick.

[Steven E. Protter]

Shalom Patrick,

The way LDAP is supposed to work is to attempt a local login first.

Check /etc/nsswitch.conf

At that point you can program /etc/profile to check the numeric user id and reject logins from uid 500.

SEP

[PatRoy]

This is what I have in my nsswitch.conf :

passwd: files ldap

Even if I completely remove that entry.. no matter what, I'm able to login with either password: local from passwd or using the ldap!

And even if I do login using ldap, because the user exists locally, the effective uid will become 110 and not 500!


If it can help... I've copied the pam.trusted file to pam.conf... here's it's content:

# Authentication management
#
login auth required libpam_hpsec.so.1
login auth sufficient libpam_ldap.so.1 debug
login auth required libpam_unix.so.1 try_first_pass
su auth required libpam_hpsec.so.1 bypass_setaud
su auth sufficient libpam_ldap.so.1 debug
su auth required libpam_unix.so.1 try_first_pass
dtlogin auth required libpam_hpsec.so.1
dtlogin auth sufficient libpam_ldap.so.1 debug
dtlogin auth required libpam_unix.so.1 try_first_pass
dtaction auth required libpam_hpsec.so.1
dtaction auth sufficient libpam_ldap.so.1 debug
dtaction auth required libpam_unix.so.1 try_first_pass
ftp auth required libpam_hpsec.so.1
ftp auth sufficient libpam_ldap.so.1 debug
ftp auth required libpam_unix.so.1 try_first_pass
rcomds auth required libpam_hpsec.so.1
rcomds auth sufficient libpam_ldap.so.1 debug
rcomds auth required libpam_unix.so.1 try_first_pass
sshd auth required libpam_hpsec.so.1
sshd auth sufficient libpam_ldap.so.1 debug
sshd auth required libpam_unix.so.1 try_first_pass
OTHER auth required libpam_hpsec.so.1
OTHER auth sufficient libpam_ldap.so.1 debug
OTHER auth required libpam_unix.so.1 try_first_pass
#
# Account management
#
login account required libpam_hpsec.so.1
login account required libpam_authz.so.1
login account required libpam_unix.so.1
su account required libpam_hpsec.so.1
su account required libpam_unix.so.1
dtlogin account required libpam_hpsec.so.1
dtlogin account required libpam_unix.so.1
dtaction account required libpam_hpsec.so.1
dtaction account required libpam_unix.so.1
ftp account required libpam_hpsec.so.1
ftp account required libpam_unix.so.1
rcomds account required libpam_hpsec.so.1
rcomds account required libpam_unix.so.1
sshd account required libpam_hpsec.so.1
sshd account required libpam_unix.so.1
OTHER account required libpam_hpsec.so.1
OTHER account required libpam_authz.so.1
OTHER account required libpam_unix.so.1
#
# Session management
#
login session required libpam_hpsec.so.1
login session required libpam_ldap.so.1 debug
login session required libpam_unix.so.1
dtlogin session required libpam_hpsec.so.1
dtlogin session required libpam_ldap.so.1 debug
dtlogin session required libpam_unix.so.1
ftp session required libpam_hpsec.so.1 bypass_limit_login bypass_umask bypass_nologin
ftp session required libpam_ldap.so.1 debug
ftp session required libpam_unix.so.1
rcomds session required libpam_hpsec.so.1 bypass_limit_login
rcomds session required libpam_ldap.so.1 debug
rcomds session required libpam_unix.so.1
sshd session required libpam_hpsec.so.1
sshd session required libpam_ldap.so.1 debug
sshd session required libpam_unix.so.1
OTHER session required libpam_hpsec.so.1
OTHER session required libpam_ldap.so.1 debug
OTHER session required libpam_unix.so.1
#
# Password management
#
login password required libpam_hpsec.so.1
login password sufficient libpam_ldap.so.1 debug
login password required libpam_unix.so.1 try_first_pass
passwd password required libpam_hpsec.so.1
passwd password sufficient libpam_ldap.so.1 debug
passwd password required libpam_unix.so.1 try_first_pass
dtlogin password required libpam_hpsec.so.1
dtlogin password sufficient libpam_ldap.so.1 debug
dtlogin password required libpam_unix.so.1 try_first_pass
sshd password required libpam_hpsec.so.1
sshd password sufficient libpam_ldap.so.1 debug
sshd password required libpam_unix.so.1 try_first_pass
OTHER password required libpam_hpsec.so.1
OTHER password sufficient libpam_ldap.so.1 debug
OTHER password required libpam_unix.so.1 try_first_pass

Thanks again...

[Bob Neal-Joslin]

Hi Patrik,

I notice you have pam_ldap before pam_unix in your pam.conf file. Using this method will always attempt to authenticate users defined in LDAP before authenticating users in /etc/pam.conf.

Are you using LDAP-UX on a trusted-mode system? It appears you have selected the /etc/pam.ldap.trusted sample pam.conf configuration file. This file is only used when you have enabled trusted-mode.

I don't believe that pam_authz will do what you want (require user be authenticated using a password from a particular identity repository.) Instead, you would need to changing the ordering of the authentiation modules in the pam.conf file (in this case, put libpam_unix before lib_pamldap.)

Bob

[PatRoy]

Hi Bob.

Yes, my system is a trusteed system. Local passwords are NO longer stored in /etc/passwd. They're in the /tcb/... folder.

I've tried fooling around the pam.conf file to put the pam_ldap AFTER the pam_unix modules... but that doesn't change a thing.

Actually now, here's what happens, if I have:

login auth required libpam_unix.so.1 try_first_pass
login auth sufficient libpam_ldap.so.1 debug

then, the user will first need to login with his local pwd, then he'll be prompt for the ldap pwd. If the local one is invalid, he'll still be asked for his ldap, but regardless login WILL fail !

if I put "sufficient" for the unix module, if user enters the right pwd for local, access is granted right away without going to ldap. However, failing the local pwd will bring him to his ldap, but again regardless, login WILL fail.

Starting to think my problem has nothing to do with pam.conf. But thanks anyways Bob... I am learning here at least ;)

[Bob Neal-Joslin]

Hi Patrik,

Thanks for the additional information. Having users with the same account name, but in different name service repositores (files and ldap) is definitely a challenging configuration...

If you are using trusted-mode, then I recommend using the pam.ldap.trusted sample configuration file, as it's the only supportable configuration. There are several side effects if pam_ldap is after pam_unix in trusted mode. Using standard mode security with /etc/shadow, is a simipler configuration to integrate with LDAP.

If /etc/shadow doesn't meet your security requirements, then you might be able to use disable_uid_range as you originally thought. But we haven't figured out why you're having problems. I'll need to go check your other post.

Bob