Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-8267: Basic Steps for Getting and Using a Host Ticket For Single Sign On

Authentication Service ,  

3 March,17 at 10:45 PM

Applies to:
Applies to all versions of Centrify DirectControl

What are the steps taken by a kerberos client to get and use a kerberos host ticket that allows single sign on to second machine?
In the steps in this example the user tetsu is logged into the source machine, deploy.  He is using PuTTY to single sign on to the target machine, rhel68. The KDC (Key Distribution Center) is the Domain Controller. 

1) When tetsu logs into deploy using credentials (username /password, or smartcard for example) a TGT (Ticket Granting Ticket) is requested and received from the KDC. An example of this ticket is seen below:

User-added image

In the image above, the Start Time and End Time on the ticket shows it is valid for 10 hours. This is the default value for MIT kerberos.

2) Tetsu uses a kerberos client (such as PuTTY, ssh or some other client) to login to the target machine rhel68.  The client (PuTTY in this case) will first go to the KDC. 
3) The client presents the TGT (on behalf of the user Tetsu) to the KDC and asks for the host ticket for rhel68 
4) KDC will look into Active Directory to check for the SPN (Service Principal Name) for rhel68. If its there, the KDC generates the kerberos host ticket for rhel68.   This image shows the SPNs that are available on the host rhel68 as seen in Active Directory.
User-added image
5) KDC will return the rhel68 host ticket to tetsu on deploy. An example of the host ticket looks like this: 
User-added image
6) PuTTY (running on deploy) contacts rhel68 and presents the host ticket 
7) rhel68 looks in the keytab file for the host to make sure it has this SPN.  In the image below, the root account has executed the klist command to show the SPNs that are stored on the host rhel68:
User-added image

8) If SPN is present (and the signature on the host ticket is valid and the time is not expired), rhel68 trusts (or accepts) the host ticket and grants access to tetsu

The user must still pass through other elements of login before login is allowed.  For example, the user still has to have authorization to login.

On the target machine:

A) Tetsu wants to login through PAM enabled application (PuTTY or ssh for example). If SSO is being attempted, the client will present the host ticket from the above process.

B) The Centrify PAM module is called.

C) The Centrify PAM module does a series of checks to make sure the user's credentials are valid. This series of steps for single sign on would include checking the host ticket that is presented to make sure it has a valid signature and the timestamp is not expired. The Centrify PAM module will make calls to GSSAPI (kerberos libraries) to validate the host ticket.

D) If host ticket is accepted, the Centrify PAM module will also check that the user has the proper authorization (or "right") to login.
If no login right is present... Centrify will deny login
If login right is present... Centrify will grant login**

**NOTE:  Even if Centrify grants the login, the next module in the PAM stack may be called and could still deny the login.  In this case, the denied login is coming from other elements in the PAM stack and not the Centrify PAM module. 

Related Articles

No related Articles