Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I've tried googling for these questions, but to no avail.
1. What controls wether a user with an expired kerberos password can actually log in to a system instead of just being kicked out?
I assume it's configured through PAM, but I can't for the life of me figure out how.
2. Is it possible to configure PAM and ssh in such a way that when a user with an expired password tries to log in, he gets a message telling him the password has expired, and prompts him for a new one, instead of letting him in to the system or kicking him out?
1. What controls wether a user with an expired kerberos password can actually log in to a system instead of just being kicked out?
I assume it's configured through PAM, but I can't for the life of me figure out how.
So how does the PAM stack for login look like?
Quote:
Originally Posted by Akegata
2. Is it possible to configure PAM and ssh in such a way that when a user with an expired password tries to log in, he gets a message telling him the password has expired, and prompts him for a new one, instead of letting him in to the system or kicking him out?
It may be convenient to always provide users with the opportunity to aqcuire a new pass but if a user has gone that long without logging in or has ignored expiry warnings for that long then preventive measures, like mailing expiry warnings (anything more current than say k5expire?), and investigating seems a more appropriate first cause of action. That said, prompting depends on password expiry and is overruled by the disable account setting as far as I know and logging in depends on how you stack modules in your PAM stack.
/etc/pam.d/login:
#%PAM-1.0
auth required pam_securetty.so
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session include system-auth
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should be the last session rule
session required pam_selinux.so open
Quote:
Originally Posted by unSpawn
It may be convenient to always provide users with the opportunity to aqcuire a new pass but if a user has gone that long without logging in or has ignored expiry warnings for that long then preventive measures, like mailing expiry warnings (anything more current than say k5expire?), and investigating seems a more appropriate first cause of action. That said, prompting depends on password expiry and is overruled by the disable account setting as far as I know and logging in depends on how you stack modules in your PAM stack.
I'm actually not sure if the users get a warning at all when logging in, can't remember that I've seen one myself. However, I do know that most users just don't see the notifications when their passwords have actually expired, so I assume they wouldn't notice any warnings either.
Mailing out expiry warnings is a great idea though, that's probably a better solution than allowing users to change password when signing in, as you say.
Thanks for the tip, I'll write a script to take care of that.
When I have that in place, making sure people are actually not allowed to log in (and especially not allowed to run sudo..) when their password has exipired will be even more important, since then they can't blame me in case they're locked out. :P
I'm having trouble understanding here what the issue is. Your OP is about expired kerberos passwords but your login PAM stack does not show any KRB5-related modules? Are they in system-auth?
Sorry, I though you only wanted to see the /etc/pam.d/login.
I guess /etc/pam.d/system-auth-ac is more relevant (since this is actually where the kerberos configuration is):
Code:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_krb5.so use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
If you parse the stack for login you see it hands off most things by default to system-auth. First up is authentication by local UNIX password. If that succeeds then any subsequent module that has args "use_first_pass" will take that as a cue to not ask for a password. So if you would move the Kerberos entry above pam_unix, and if it returns user unknown or password expired to underlying modules, then maybe you got what you want. (BTW there's interesting switches default pam_krb5 doesn't provide for in Eyrie.org's pam_krb5).
So if you would move the Kerberos entry above pam_unix, and if it returns user unknown or password expired to underlying modules, then maybe you got what you want.
You're right, that seems to work perfectly.
Interestingly enough, I had the same exact config for system-auth on several fc5 machines as well as centos5 machines. The fc5 machines would just let users with expired passwords in, but the centos5 ones wouldn't.
I'm kinda thinking this is a bug in fc5, but it's time to get rid of this machines as soon as possible anyway.
The configuration change you suggested worked though, so thanks a million.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
