You are not logged in.
Hi,
I'm working on setting up a software distribution for class laptops.
Our school uses kerberos to authenticate students, and we'd like to use this as well.
Right now, I have kerberos authentication working if there is a local user with the student's name.
This is not ideal, so we'd like to have it authenticate and in case of success, create the user if it doesn't already exist.
I have tried using pam_script for this, and having a script running on auth. This has two disadvantages: it runs on both successful and unsucessful authentications and login always fails the first time.
This is my current system-auth file:
auth sufficient pam_unix.so try_first_pass nullok
auth required pam_krb5.so use_first_pass no_user_check
account sufficient pam_unix.so
account required pam_krb5.so no_user_check
account optional pam_permit.so
account required pam_time.so
password sufficient pam_unix.so try_first_pass nullok sha512 shadow
password required pam_krb5.so use_authtok no_user_check
session required pam_limits.so
session optional pam_permit.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_script.soAnother bug I'm running into is that using pam_krb5, the ticket cache for the user gets owned by root. Right now, I'm just using a hack to solve this: run a pam_script on every login that finds all the files with the pattern /tmp/krb5_0_* and if it exists, changes its owner to be the one logging in.
This seems to work, so it's not a big issue, unless there is more than one user logged in to the laptop (which is not our use case). But it would be nice to know how to fix it.
Thanks for any help!
EDIT: changed the script content because the previous one had a bug.
Last edited by rgomes (2013-12-05 15:33:29)
Offline
Trying to create users on-demand is pretty hairy, I don't think PAM expects that type of behavior. You could _possibly_ use pam_script to create the user and print a message that says "your account has been created, please try again." Generally though, if you don't want to mess with /etc/passwd and /etc/shadow (possibly because you are dealing with multiple machines), you really need to stand up an OpenLDAP directory.
On my campus, we use Kerberos for authentication but there is also an LDAP directory. Furthermore Kerberos isn't even needed and is being retired because binds directory to LDAP are supported for authentication. I've found it easiest to stand up my own OpenLDAP server for the CS department which pulls data from the campus LDAP. Thus, I have 'ldap' in /etc/nsswitch.conf as well as pam_ldapd and pam_krb5 in /etc/pam.d/.
Offline
I actually found out last night how to do this, after studying up on PAM a bit more.
Turns out I wasn't putting the user creation script in the right place.
PAM does allow you to create the user, but it has to be the first thing you do, before any other script fails because it doesn't exist.
So, I just created the following script:
#!/bin/sh
useradd -s /bin/bash $PAM_USER 2> /dev/null || true(this fails silently)
as the first line in login and gdm-passwd, as optional, and it works well.
As for the ticket cache being owned by root, I found a hacky way of solving the issue. I just format the name of the cache so it is fairly unique, and modify its owner with a script at the start of session:
In system-auth I have this for kerberos auth:
auth sufficient pam_unix.so try_first_pass nullok
auth requisite pam_krb5.so use_first_pass no_user_check ccname_template=FILE:%d/krb5cc_athena_%u
And this script running in session start to fix the tickets:
#!/bin/sh
FILES=/tmp/krb5cc_athena_$PAM_USER_*
for f in $FILES
do
chown $PAM_USER $f
done
exit 0;
To fix the issue of the script running on unsuccessful authentications, we just delete the user on logout---this turns out to be the desired behavior by the professor, so we don't keep any of the students' files (important because they will be using SSL certificates). For the students to be able to save their work, we'll have some simple version control software.
Offline
Note to be careful with use of no_user_check. When I set it this way with a slim login I found that the cred cache was unreadable by the user who had logged in. It makes sense when you understand what that option does:
no_user_check
tells pam_krb5.so to not check if a user exists on the local system, to skip authorization checks using the user's .k5login file, and to create ccache files owned by the current process's UID. This is useful for situations where a non-privileged server process needs to use Kerberized services on behalf of remote users who may not have local access. Note that such a server should have an encrypted connection with its client in order to avoid allowing the user's password to be eavesdropped.
removing it solved the issue
Last edited by MatteusBlanc (2014-04-27 21:07:03)
Offline