List SPN information
From the Windows command line, confirm that the SPN can be found in Active Directory.
C:\>setspn -L UC4EXP1 Registered ServicePrincipalNames for CN=UC4EXP1,OU=TechUser,DC=corp,DC=mycompany,DC=com: HTTP/awi-exp.mycompany.com.com |
Also confirm that exactly one user is associated with the SPN.
C:\>setspn -Q HTTP/awi-exp.mycompany.com.com
Checking domain DC=corp,DC=mycompany,DC=com
CN=UC4EXP1,OU=TechUser,DC=corp,DC=mycompany,DC=com
HTTP/awi-exp.mycompany.com.com
Existing SPN found!
|
Create a Kerberos keytab file
The official CA Automic instructions for setting up single sign-on is written based on the assumption that the person setting things up will have AD Domain Administrator access. We know this because the options indicated in the ktpass command in the section Generate keytab file on the AWI server are options that only a domain admin is authorized to use. If you have domain admin rights, you can follow the keytab creation instructions in that document, and then skip ahead here to the section Validate the keytab. The instructions below are written based on the assumption that you do not have domain admin access.
Determine the kvno & salt of an SPN
The kvno and salt are two pieces of information that are required when generating a keytab file. Each SPN has its own salt and kvno. The kvno is the key version number. Each time a new key is generated for a user in the KDC, the kvno is incremented in the KDC. Any keytabs created for this user must have the same kvno as the one associated with the SPN/user in KDC/AD.
The salt is a piece of information used to introduce pseudo-randomness into the keys. It is stored in the KDC and updated each time the ktpass.exe command is used with the +mapuser option.
The salt is derived from:
- The realm in all uppercase letters, and
- The most recent userPrincipalName (UPN) set using ktpass.exe.
Because the salt is not always straightforward to guess, it may be necessary to run a packet trace to discover it. The salt will be used later during creation of the keytab.
Extract the salt from a packet trace
To find out the salt you will need to use when creating the keytab, you must capture a packet trace of a kinit session, and examine this packet trace using WireShark.
Capture a packet trace of a kinit using tcpdump
You will need to run the tcpdump on a Linux box where you have root access.
# /usr/sbin/tcpdump -s 0 -w /tmp/krb_uc4exp1.pcap -i eth0 tcp port 88 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
|
While the tcpdump is running, in another screen/window, run kinit as the user whose salt you want to capture.
$ kinit uc4exp1 Password foruc4exp1@CORP.MYCOMPANY.COM: $ klist -e Ticket cache: FILE:/tmp/krb5cc_11041 Default principal: uc4exp1@CORP.MYCOMPANY.COM
Valid starting Expires Service principal
02 / 10 / 17 14 : 01 : 48 02 / 11 / 17 00 : 01 : 58 krbtgt/CORP.MYCOMPANY.COM @CORP .MYCOMPANY.COM renew until 02/11/17 14:01:48, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC Kerberos 4 ticket cache: /tmp/tkt11041
klist: You have no tickets cached
|
Enter the user’s password, if optionally list the TGT by running klist. Then switch batch to the screen/window running the tcpdump, and type Ctrl-C to cancel it. Transfer the file (uc4exp1.pcap in this example) to a Windows PC and open it in WireShark.
Examine the kinit packet trace in WireShark
Look at the KRB5 AS-REP packet. Expand the Kerberos section to reveal the salt. There, you can also see the kvno.
The salt and kvno of the user UC4EXP1, as seen in a packet trace of a kinit as this user, viewed in WireShark. In this example, the salt was CORP.MYCOMPANY.COMUC4EXP1, the realm name followed immediately by the user name. Again though, the salt may not always follow this pattern. The above method is the only 100% reliable way I have found to discover the salt of SPN that must be used when creating the keytab.
Show the kvno of an SPN from the Linux command line
It is also possible to reveal the kvno of an SPN from the Linux command line. Authenticate using kinit (as your user or any user), and then use the kvno command to show the kvno of an SPN.
$ kinit
Password for myuser@CORP.MYCOMPANY.COM:
$ /usr/lib/mit/bin/kvno HTTP/awi-exp.mycompany.com
HTTP/awi-exp.mycompany.com@CORP.MYCOMPANY.COM: kvno = 2
|
Create the keytab
The keytab should contain all three keys that will be needed: 1 for each AE node, and a third for the AWI. These commands must be run on Windows, because the equivalent ktutil command on Linux lacks the /rawsalt option. This command must be run on a Windows system where you have Administrator access.
ktpass.exe /out c:\temp\AE_EXP.keytab /princ HTTP/awi-exp.mycompany.com@CORP.MYCOMPANY.COM /pass XXXXXXXX /kvno 2 /crypto AES256-SHA1 /pType KRB5_NT_PRINCIPAL /rawsalt CORP.MYCOMPANY.COMUC4EXP1 -setupn
|
In the command above, ****** represents the UC4EXP1 user's AD password.
|
Note: As described in Microsoft’s ktpass documentation, the -setupn option prevents updating the userPrincipalName in AD.
Validate the keytab
Once you have successfully created the keytab, you should validate it.
List the keys in the keytab
You can list the keys in the keytab file (there should be only one key) using the klist command.
$ klist -eKk AE_EXP.keytab Keytab name: FILE:AE_EXP.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2
HTTP/awi-exp.mycompany.com@CORP.MYCOMPANY.COM
(AES-256 CTS mode with 96-bit SHA-1 HMAC) (0x108c5fc7e3861bc219d2e9e086cbe4648b1a2ff2c0a8c0cd24ec4ca100f32fcb)
|
Validate the format of the key in the keytab
You can validate the format of the key in the keytab using the kvno command.
$ /usr/lib/mit/bin/kvno -k /opt/uc4/server/AE_EXP.keytab AE_EXP/ae-exp-1.mycompany.com
AE_EXP/ae-exp-1.mycompany.com@CORP.MYCOMPANY.COM: kvno = 2, keytab entry valid
Test authenticating with the KDC using the keytab
Once you know that the keytab contains a key, and that the key is in a valid format, you can try authenticating with the KDC using the keytab. Because the authentication is performed using the key stored in the keytab, you should not need to enter a password.
$ kinit -kVt AE_EXP.keytab -S AE_EXP/ae-exp-1.mycompany.com AE_EXP/ae-exp-1.mycompany.com Authenticated to Kerberos v5 $ klist Ticket cache: FILE:/tmp/krb5cc_11041 Default principal: AE_EXP/ae-exp-1.mycompany.com@CORP.MYCOMPANY.COM
Valid starting Expires Service principal 03/10/16 13:34:15 03/10/16 23:34:15 AE_EXP/ae-exp-1.mycompany.com
renew until 03/11/16 13:34:15 Kerberos 4 ticket cache: /tmp/tkt11041 klist: You have no tickets cached $ /usr/lib/mit/bin/kdestroy
|