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
m (Robot: Adding Category:Obsolete)
m (Robot: Changing Category:Obsolete)
Line 31: Line 31:
  
 
[[Category:Production Service]]
 
[[Category:Production Service]]
[[Category:Obsolete]]
+
[[Category:Obsolete Page]]

Revision as of 23:06, 27 January 2008

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].

Implementations

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 MIT implementation. 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 server is running on fiordland. KDCs are running on fiordland (the 'master') and royal (the 'slave'), and one will probably be set up on magellanic (slave) in the near future. DNS CNAME records are set up so that kdc1 points to fiordland and kdc2 points to royal. 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.

Outages

The layout is designed such that a single outage will not cause much disruption. If any of the slave KDCs fail, 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.

Replication

The kprop command, paired with the kpropd daemon, allows for database replication (and propagation, hence the name) to occur. To propogate database changes to a slave server, the kprop command must be run, and the kpropd command must be running on the slave server. Whenever a new user is added with the adduser script, kprop is run against all slaves to propogate changes. kprop is also called every so often from cron, to ensure that any other changes are replicated, as well.

Cross-realm Authentication

Currently, we have a one-way cross-realm trust with the windows realm, LOCAL.TJHSST.EDU. This was very simple to set up, as it consists of just creating a single principal: krbtgt/CSL.TJHSST.EDU@LOCAL.TJHSST.EDU. This just means that the CSL realm trusts the LOCAL realm, but not the other way around. For a two-way trust to occur (that is, for both realms to trust each other), then the principal krbtgt/LOCAL.TJHSST.EDU@CSL.TJHSST.EDU would have to be created on the windows KDC.

Note that this alone does not give access to AFS from windows tickets. For information on that, see OpenAFS/cross-cell.

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