KB Article #70465

SSO authentication fails

Problem

-- SSO
-- SPN
-- setspn
-- Kerberos ticket
-- authentication fails



SSO is established per official documentation. When Outlook is (re)started, authentication window pops up asking for a manual login. What to look for in the AD infrastructure?


Resolution

Most likely there are duplicate SPNs in AD associated with the user account for FTD in the keytab file. It may happen that sometimes same SPN is mapped to more than one user in AD. When this happens Kerberos tickets are not generated and this prevents FTD SSO from working.



Microsoft has released update of their setspn.exe tool in order to make it easier identification of duplicate service principal names (SPNs) in Active Directory, and adds support for some new switches.



The tool can be downloaded from this link - http://support.microsoft.com/kb/970536



Once the tool is downloaded and installed, it does not require server restart, on AD Domain Controller it can be run from command prompt like this:



C:\>setspn -X
Processing entry 0
HTTP/ftd.example.com is registered on these accounts:
   CN=FTD User,CN=Users,DC=example,DC=com
   CN=Axway FTD,CN=Users,DC=example,DC=com



found 1 group of duplicate SPNs.



C:\>



As FTD needs only one SPN mapped to only one user in AD all duplicates should be eliminated. Best practice is to delete all but one users found by setspn -X and regenerate the keytab for the user using the following ktpass command:



ktpass -princ HTTP/ftd.example.com@EXAMPLE.COM -mapuser example\ftd -pass PASSWORD -out c:\ftdkeytab -kvno 3 -ptype KRB5_NT_PRINCIPAL



Desired output is as follows:



C:\>ktpass -princ HTTP/ftd.example.com@EXAMPLE.COM -mapuser example\ftd-user -pass PASSWORD -out c:\ftdkeytab -kvno 3 -ptype KRB5_NT_PRINCIPAL
Targeting domain controller: dc1.example.com
Using legacy password setting method
Successfully mapped HTTP/ftd.example.com to ftd
Key created.
Output keytab to c:\ftdkeytab:
Keytab version: 0x502
keysize 71 HTTP/freia.trimurti.com@TRIMURTI.COM ptype 1 (KRB5_NT_PRINCIPAL) vno
3 etype 0x17 (RC4-HMAC) keylength 16 (0x366b8b263da6cbb2e217893a27376bc2)



C:\>



Import the keytab into the FTD server and retry SSO from the client machine. If all was properly set (NTP, LDAP, etc as per SSO setup in FTD Admin Guide) SSO should work now flawlessly.