-
Notifications
You must be signed in to change notification settings - Fork 3
Setting up a Kerberos client, Centos 7
Return to main: Kerberos
I think this page is useful, through the section "SERVICES AND PROGRAMS". Starting there, it documents Rutgers-specific software. Source for it is in this site. Man pages are maintained. However it's now installed using ansible. (Currently the ansible scripts are available at https://github.com/clhedrick/kerberos-ansible.) So manual instructions here are likely out of date. To see how we actually set up clients, you'd need to look at the ansible scripts. Those are currently used for Centos 7 and 8, and Ubuntu 18 (though until recently we also did Ubuntu 14; there's a pretty good chance it would still work there).
This information is for people who need to set up manually. We're currently using ansible to set up. There are lots of details, not all of which are here. We have an ansible setup that can handle Centos 6 and 7, Ubuntu 14, and SLES 12. I'd be happy to give anyone a copy of the files.
I've only gotten this to work on Centos 7. On Centos 5 you could probably get to work for users who don't use OTP, but I recommend using pam_ldap pointing to the kdc for Centos 5 and Solaris.
- /etc/krb5.conf should be public read [note]. The appdefaults section has configuration for kgetcred and renewd. You'll need to specify at least the server for kgetcred. Otherwise the defaults are probably enough.
- /etc/krb5.keytab is generated for the system. It must not be public
kinit admin
ipa host-add c217.cs.rutgers.edu
ipa-getkeytab -p host/c217.cs.rutgers.edu -k /tmp/c217
# following two items will happen every 10 min automatically, so you only need this if you're going to enroll the host immediately
# they add the host to the firewall rule. Without this, attempts to use Kerberos or IPA will time out.
ipset add lcsr c217.cs.rutgers.edu
service ipset save
Note that the host needs to be added to the firewall (which is what ipset does) on the backup as well. But there's a cron job that will do that every 10 min. It's probaby not necessary to bother doing it manually on the backup.
Note that the two servers are symmetrical. You can change passwords on either one, however there will be a delay in update if you change on the backup server.
Now put /tmp/c217 into /etc/krb5.keytab on c217.cs.rutgers.edu and chmod 600.
WARNING: ipa-getkeytab increments the key version number. That will invalidate old key tabs. So if you need to move or merge key tabs, and you don't want to invalidate existing ones, you're better to copy them and merge keys using ktutil. This problem doesn't occur for user key tabs.
While you can use Kerberos without it, I recommend yum install krb5-workstation. That gives you kinit, klist, etc.
Without 2 factor:
In sshd_config:
GSSAPIAuthentication yes GSSAPICleanupCredentials noThe default is GSSAPICleanupCredentials yes. I prefer no. Credentials are often stored in the KEYRING, and are sometimes share by multiple sessions. If you clean up at logout and there's still another session active, it can lose its credentials. Renewd will remove credentials when there's no longer anything left that uses them.
in ssh_config
GSSAPIAuthentication yes, but that seems to be set by default GSSAPIDelegateCredentials yes, this isn't the default.GSSAPIDelegateCredentials yes causes a ticket to be sent to the other end. Without that, we can't use NFS or other services. This should be the only change you have to make.
As long as both systems have krb5.conf and krb5.keytab, that seems to be enough.
I think all you need to do is start the appropriate services. krb5.conf and krb5.keytab seems to be enough. On Centos 7, I found "systemctl start nfs" to be enough, though you'll also want enable to make it permanent.
Lots of web pages give lists of services to start, but Centos 7 consolidated them. I believe nfs includes both client and server, though server may only start by default if there are exports, and one of the NFS4 daemons only starts if there's a krb5.keytab.
I normally edit /etc/idmap.conf and set
Domain = cs.rutgers.eduin the General section, but for hostnames ending in cs.rutgers.edu this isn't needed. On my test system I didn't edit the file and things worked.
If the server has exported the file system with sec=krb5, a simple mount will work, without options. The mount command finds from the server that sec=krb5 is needed, and it picks the highest version that the server supports, which will often be NFS4.
I do not recommend mounting file systems exported with NFS4 without using Kerberos. sec=sys with NFS4 still does a half-based username mapping, so it still needs idmap. But the semantics are weird.
Note that you can use sec=krb5 with NFS3 also. I'd prefer NFS4 if possible, but on a server that's going to serve some non-Kerberos clients, NFS3 may be easier. If NFS4 is enabled on the server all mounts will be NFS4, and many clients don't have the ID mapping set up to handle it.
You don't need this section if you're using sssd, as it does its own Kerberos authentication, and it can handle two factor authentication. If you're using ldap rather than sssd, you'll need to use pam_krb5 for authentication. (LDAP would actually work, but it won't give the user a kerberos ticket. So Kerberized NFS would fail.)
You need to use my copy of pam_krb5 if you want to support two factor authentication. If you don't care about it, the pam_krb5 that comes with Centos is fine. This is based on Russ Allbery's pam_krb5, https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html. The source is in GitHub, https://github.com/clhedrick/kerberos.git.
auth sufficient pam_krb5_new.so use_first_pass debug anon_fast ccache=KEYRING:persistent:%u:%u session required pam_krb5_new.so ccache=KEYRING:persistent:%u:krb_ccache_XXXXXXccache for auth probably isn't used.
This works for ssh and login. For screen savers and other things that don't run as root, use pam_ldap pointing to the kdc. The kdc's ldap authentication does support one-time passwords.
To support two factor authentication, pam_krb5 needs a credentials cache that is known to be valid. This is used to "armor" the request to the KDC, i.e. to provide a key that can be used for encryption. For the moment it creates this from /etc/krb5.keytab. This is a key table for the host. For security reasons it can only be read by root. That's why you can't use it for screen savers and anything use running as the user.
This mechanism will work for pam_krb5, but not for kinit. I suggest that we create a script kinit_otp for otp users. Here's how to test manually:
kinit USER klist ; copy the credential file, e.g. KEYRING:persistent:1003:krb_ccache_G4Z1PgK kinit -T KEYRING:persistent:1003:krb_ccache_G4Z1PgK USER.adminor if you already have a ticket (which you normally will), simply
kinit -T $KRB5CCNAME USER.admin
It's cleaner to use sssd for authentication. It handles this stuff in a daemon that's running as root.
There is a tar file kerberos.tar in the git build area that has all the necessary files and man pages. Current this is c217:~hedrick/kerberos. However we're now using ansible to set up systems. So these instructions may not be entirely up to date.
Please copy the following from a machine that's been set up:
- /usr/sbin/renewd
- /etc/systemd/system/renewd.service
- /bin/kgetcred - note: must be setuid root
- /usr/local/bin/skinit
- /lib64/security/ pam_kgetcred.so, pam_kmkhomedir.so, and pam_reg_cc.so
- /usr/libexec/krenew-wrap.so
- ssh rename to ssh.real and install the /usr/sbin/ssh script
You will want to run renewd. It shouldn't require any configuration other than making sure it runs. It renews tickets for all users who are current logged in. This is important to make sure users don't lose access to their files in a long job. With the systemd file included you can do "systemctl enable renewd" and "systemctl start renewd" You'll need to install pam_reg_cc.so to make sure that credentials are registered to be renewed.
Kgetcred is intended for cron jobs and scripts that need Kerberos credentials. Kgetcred would be used for admin scripts. The pam version is intended to be called for crond, so that user cron jobs get credentials transparently.
Install kgetcred setuid root. Put the hostname of the server on which credserv will run in /etc/krb5.conf. It's in the sample above.
It gets a TGT and returns the name of a cache that it creates (or uses, if one already exists). The user must put a keytab on the server. We'll have a web service to do this. For testing, you can generate a user keytab and put it in a file like /var/credserv/hedrick-c217.cs.rutgers.edu.keytab on the server. This should be a keytab for hedrick. It authorized kgetcred to create credentials on c217.cs.rutgers.edu.
Note that kgetcred is supported for MacOS, with Macports installed.
This is a shell script that acts like kinit but supports onetime passwords. It depends upon kgetcred.
Note that skinit is supported for MacOS with Macports Kerberos installed.
You can't create home directories with pam_mkhomedir over Kerberized NFS. That's because root would have to do the creation, and it doesn't have the necessary privileges. This module calls a service running on the file server or a system that has a non-Kerberized mount. It requires configuration in /etc/krb5.conf. See the man page, as configuration is cluster-specific.
ssh passes your ticket to the other end. but the ticket you end up with won't have the same lifetime as the original. Suppose the original ticket is good for an hour, and you ssh to another system 30 min into that time. You'll end up with a 30 min ticket. Renewd probably won't catch it. If you ssh at the wrong time you could up with a very short ticket.
krenew-wrap.so is a library interposed around krb5_init_context. It's set up with LD_PRELOAD. It causes ssh to create a newly renewed ticket right before making the connection. That makes sure you get a full length ticket. For this to work, ssh has to be a shell script that defines LD_PRELOAD and then calls the real ssh.
Redhat currently recommends sssd. It supplies pam and nss. This should be used in place of nslcd and nscd.
Here's my current /etc/sssd/sssd.conf. Note that this sample is for ilab. You'll need to change it for other clusters in the obvious way.
In pam.d I have pam_unix and pam_sss. On user systems I don't use pam_ldap.
in nsswitch.conf, I have "files sss" for passwd, shadow and groups.
sssd, is started and enabled. nslcd and nscd are disabled. Make sure nscd is not running or things can get messed up.
If you have a machine used for services, and you only want to allow users in /etc/passwd, you can use sssd, with the default configuration (the changes above wouldn't be need), but point nsswitch.conf to just files. That way only users in /etc/passwd can login, but they use the password in our Kerberos system.
You may not need ldap on a client unless you're going to use it in NSS as a data source.
If you want just ldapsearch, yum install openldap-clients.
edit /etc/openldap/ldap.conf and add
URI ldaps://krb1.cs.rutgers.edu ldaps://krb2.cs.rutgers.edu BASE dc=cs,dc=rutgers,dc=edu NETWORK_TIMEOUT 5
The timeout is in case the primary is down. The default timeout is really long.
Since we're using a commercial cert, the CAs that come with openldap work. That may not be true for nss_ldap or other ldap clients.
In case you need certs, on krb1.cs.rutgers.edu ~hedrick/certs has the CA chain.
- cert is our cert
- int3 should be used for the CA cert. It's the Internet2 CA.
- if you need the whole CA chain, concatenate int1, int2, and int3.
The following subsection has my notes from ipa-client install. I had already done some setup, so I needed --force-join to do it again. You shouldn't.
Use this to set up the example you're going to copy, or if you need to get an existing machine into Kerberos. I recommend creating a tar file of all the configuration files, including /etc/ipa. The only thing machine-specific is /etc/krb5.keytab, and that could be created by ipa-join.
There is a tar file kerberos.tar in the git build area that has the Rutgers utilities and man pages for a client. Currently this is c217:~hedrick/kerberos.
yum install ipa-client
That installs the software. So set it up, do ipa-client-install. I did --no-sudo because their sudo support is kind of weird. --force-join was because the system had already been set up. You shouldn't need that. If you don't want to supply a username and password, you can do "ipa host-add --password" on the server to create a one-time join password for ipa-client-install. You need to specify --server twice to make sure it talks to both Kerberos servers. You may also want --fixed-primary
ipa-client-install --ca-cert-file=/home/hedrick/certs --no-sudo -w password
where password is the onetime password specified in ipa host-add. The certfile is /etc/ipa/ca.crt from any of the machines already set up. If you can't find it you can do
openssl s_client -connect krb2.cs.rutgers.edu:443 -showcerts > ~/certsand remove everything except the actual certs. Without --ca-cert-file the command will download a cert from the server, but it will be the server's self-signed cert. That won't work, because it needs a cert appropriate for https: to the server, and that's a commercial cert.
If this fails, you have to do ipa-client-install --uninstall. Since the password is one-time you may also have to do ipa host-del and redo the ipa host-add command to put the password back.
It sets up sssd, but doesn't change nssswitch.conf or pam.
I did this on a machine that was more set up than yours may be, so you may not need all of this
- they set up /etc/krb5.keytab, /etc/ipa, and /etc/krb5.conf. Their krb5.conf works, but has a number of options different from what we want. I'm producing a merge of ours and theirs. There are enough changes that I'm just including mine: krb5.conf for ipa client install
- nssswitch.conf. I'd use "files sss" for passwd, shadow, group. Also, add the following line. It causes an optimized call to be used when the system needs a list of all the groups a user is in.
initgroups: files [SUCCESS=continue] sss
- they add sss to services and netgroup. Not sure I want that.
- they set sssd running, which is fine
- they left nslcd running. Disable and stop it.
- they changed your /etc/ntp.conf server. Change it back to ntp.rutgers.edu and systemctl restart ntpd to activate it.
- they left nscd loaded but dead. Make sure it is disabled and stopped.
- they set up /etc/sssd/sssd.conf. See above for my version.
- systemctl stop sssd, rm -rf /var/lib/sss/db/*, systemctl start sssd # to make sure the changes took
- they added sss to pam. Make sure you remove pam_krb5 and pam_ldap from all pam files. You can get weird problems if any entries remain.
- in pam, add the following after pam_sss in account. It works with the declaration in sssd.conf to make sure the user is in the cluster's login group. It may only be needed for interactive logins.
account [success=2 default=ignore] pam_succeed_if.so user ingroup login-local account [default=bad success=1] pam_sss.so account [default=die] pam_echo.so You don't seem to have an account on this cluster. Please activate by going to URL.
- For interactive logins, have the following in the session section
session optional pam_reg_cc.so usecollection session optional pam_kmkhomedir.so
- For crond, have the following in the session section.
session optional pam_kgetcred.so
- make sure sshd_config includes "GSSAPICleanupCredentials no". All sessions share the same credentials, so you don't want to delete them at logout. I use a 1 hour expiration, so once there's no session credentials will expire. As long as the user is logged in, renewd will renew the credentials.
- If you have accounts that you want to login without any network information (e.g. linux-admin), put them in group 3000, login-local, in /etc/group
- install renewd and kgetcred, and the pam modules pam_kmkhomedir, pam_kgetcred, and pam_reg_cc. Configuration for them is in krb5.conf, which is documented above. pam_kmkhomedir and pam_reg_cc should be installed for session in password_auth. pam_kgetcred should be installed as a session module for crond only.
- ssh should be renamed to ssh.real, with the /usr/bin/ssh script replacing it. That needs /usr/libexec/krenew-wrap.so
- you probably want to define a group allusers 1234, in /etc/group. Otherwise all users will show as in ipausers, and sssd will fetch this huge group when users login. Everything will still work, but logins could be slower if the group has to be updated.
- if /etc/auto.master has an entry for /net, add -sec=krb5:sys to the end of the line, e.g.
/net -hosts -sec=krb5:sys
I suspect we're going to want to set up one client and then copy it. If we do that, the only thing we need to do on the copies (beyond what you'd normally do to configure the new hostname / IP address) is join the domain and edit one config file.
On server: ipa host-add --password=PASS HOSTFQDN On client: ipa-join -w PASS
The password you supply for ipa host-add is a one-time password that can only be used for ipa-join and only once per host. It's designed for bulk setup, in which case you'd probably do ipa host-add for the whole set of machines with the same password.
NOTE: it will take up to 10 min for the firewall to allow your system to connect to the server. The 10 min starts when you do the host-add. You can make it happen immediately by running /usr/local/scripts/hosts2fw/update on one of the Kerberos servers.
- On the client, you will also need to edit /etc/sssd/sssd.conf to change the hostname.
- We recommend rebooting after this setup.
For the NIS servers, I wanted enough of IPA to use the command line IPA, without disturbing the configuration of the system. I ended up installing the following:
yum install krb5-workstation ipa-client ipa-admintools
- /etc/krb5.conf
- /etc/krb5.keytab (for this system, obviously)
- /usr/bin/kgetcred (setuid root)
- /usr/local/bin/skinit
- /etc/ipa - whole directory, copied from krb1
- /usr/sbin/renewd
Where possible we'll be using SSSD. This is just for the record, in case you can't use sssd for some reason.
Because we're running multiple clusters from the same LDAP, you'll need to change the filters so you only use information for your cluster.
For /etc/nslcd.conf you need
uri ldaps://krb1.cs.rutgers.edu/ ; eventually you'll want both servers base cn=accounts,dc=cs,dc=rutgers,dc=edu binddn uid=ldap.admin,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu bindpw abcde12345! tls_cacertfile /etc/pki/tls/cert.pem filter group (&(objectclass=ipausergroup)(host=ilab)) filter passwd (&(objectclass=inetuser)(host=ilab)) map passwd homeDirectory "/ilab/users/$uid"
for the ilab domain.
I created a user ldap.admin with no special access. IPA will let you see a lot things without binding, but to see members of groups you have to bind. It can be a normal user. It doesn't matter. That particular user will never be allowed to login, so the password isn't that critical.
You'll also want to use pam_succeed_if to require that the user is in group "login-ilab" and not in disabled-ilab. login is maintained by the activation script. disabled is maintained manually, and is used to administratively disable a user.
auth requisite pam_succeed_if.so user ingroup login-ilab user notingroup disabled-ilab quiet_success
If you have a valid admin ticket, but all ipa commands return internal system error, and on the server side /var/log/httpd/error_log shows
ipa: ERROR: 500 Internal Server Error: KerberosWSGIExecutioner.__call__: KRB5CCNAME not defined in HTTP request environmentverify that your ticket is forward able. The IPA protocol transfers your ticket to the server and checks it there. This only works if it's forward able.