Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Difference between revisions of "Kerberos"

From Livedoc - The Documentation Repository
Jump to: navigation, search
(Update Kerberos article for current server layout and configuration)
(removing obselete category since this page is now up-to-date.)
Line 37: Line 37:
[[Category:Production Service]]
[[Category:Production Service]]
[[Category:Obsolete Page]]

Revision as of 01:37, 16 January 2012

Kerberos is a network authentication service, which allows for authentication with passwords without transmitting the password itself. This page is not an explanation on Kerberos; for that, look at [1].


There are multiple implementations of Kerberos. In addition to the free ones, such as the MIT, Heimdal, and Shishi implementations, Microsoft has also made an implementation for Windows, and Sun Microsystems has an implementation for their Java programming language. Right now, all of the CSL's Kerberos servers run the Heimdal implementation built into OpenBSD. The clients are a mix of the MIT and Heimdal implementations. The Heimdal client is notable for its integration with AFS.

Server Layout

Right now, the kadmin and kpasswd servers are running on agni. KDCs are running on agni (the 'master') and scylla (the 'slave'). The service IPs kdc1 and kdc2 are configured so that agni will bring up kdc1 and scylla will bring up kdc2. All clients should be configured to try kdc1 first as it will always be pointed to the primary server where changes are reflected most rapidly. In addition, agni is configured to bring up the kerberos service IP which should always point to the admin server.


The layout is designed such that a single outage will not cause much disruption. If the slave KDC fails, there should be no change felt by the clients. If the master KDC fails, then it will be impossible to add, delete, or modify principals in any way (which includes changing passwords), but they will still be able to be read properly, which means that services will be able to authenticate without a problem.


The hprop command, paired with the hpropd daemon, allows for database replication (and propagation, hence the name) to occur. To propogate database changes to a slave server, the hprop command must be run, and the hpropd daemon must be running on the slave server. hprop is called every 30 minutes from cron on agni to replicate changes to the slave KDC(s). If you are adding a slave KDC, you must add a line in root's crontab on agni.

# propagate the heimdal kerberos DB to the slave KDCs
*/30    *       *       *       *       /usr/libexec/hprop scylla.csl.tjhsst.edu

Cross-realm Authentication

Currently, we have a two-way cross-realm trust with the Windows Domain LOCAL.TJHSST.EDU (which can be considered the same as a Kerberos Realm for purposes of this article). This trust allows our systems (which operate in the CSL.TJHSST.EDU realm) to verify and trust user principals from the LOCAL Domain as well as allowing the LOCAL Domain Controllers to verify the identity of our systems (which have keytabs in the CSL realm). Note that this alone does not give access to AFS from windows tickets. For information on that, see OpenAFS/cross-cell.

To re-create this trust, first generate a long random string to use as a Trust Password. Then, on the primary KDC, create two principals, krbtgt/CSL.TJHSST.EDU@LOCAL.TJHSST.EDU and krbtgt/LOCAL.TJHSST.EDU@CSL.TJHSST.EDU. For security, it is recommended to add the attributes disallow-renewable, disallow-tgt-based, and disallow-forwardable to both principals. Finally, on a LOCAL domain controller, go to Admin Tools -> Active Directory Domains and Trusts, and create a new two-way trust in the LOCAL domain using the same Trust Password. Alternatively, to setup the LOCAL domain side of the trust, you can use:

netdom TRUST CSL.TJHSST.EDU /add /realm /passwordt:<password> /twoway


Prior to the creation of the two-way trust, we had a one-way trust with the LOCAL.TJHSST.EDU Domain (CSL.TJHSST.EDU trusting LOCAL.TJHSST.EDU) to allow for users to login to CSL systems with their LOCAL domain passwords. This trust was created similar to the above example except with only the krbtbt/CSL.TJHSST.EDU@LOCAL.TJHSST.EDU principal being created on the primary KDC and only a one-way trust being created on the LOCAL domain controller. One downside to this system was that CSL systems needed to have computer accounts (keytabs) in the LOCAL domain (since the LOCAL domain controller would not trust a CSL keytab to verify the identity of a client system).

Issues with SSH passwordless login

Normally, the GSSAPI mechanism is used to authenticate someone to a machine who has already authenticated to another machine in the lab. This uses their existing Kerberos credentials to prove who they are, and it also forwards their Kerberos tickets to the new machine, so they can use them for accessing AFS. So far, this has been seen to work fine on workstations.

A problem with this, first seen when trying to implement on the TJforge system and the remote SSH access server, is when this system is attempted on a machine with multiple IPs to SSH to. For example, the TJforge system currently is run on the server robustus, which also contains service IPs for forge.tjhsst.edu and remote.tjhsst.edu. When a user attempts to use GSSAPI against the remote IP, robustus seems to attempt to obtain the host principal for remote (even though it is in robustus' /etc/krb5.keytab, it still contacts a KDC). This fails, because it is accessing the KDC from the IP of robustus, which reverse-maps in DNS back to robustus.tjhsst.edu, and so the KDC can see that it is trying to obtain the wrong host principal. This causes GSSAPI via SSH to fail with the message "Wrong principal in request" when verbosity is turned on.

External Links