For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Feb 28, 2014

We already have this account already created. I do have a question about this though:

 

The account's UPN is formatted like this: "host/$SERVICE.ACCOUNT.NAME.domain.name.com@REALM.NAME.COM" One of the SPNs is then set to: "host/$service.account.name.domain.name.com" Do you think this would cause problems? Does the UPN need to exactly match one of the SPNs? One of the documents I was following didn't have me attach the realm name to the end of the SPN.

 

The AD user service account used for delegation needs the user logon name (UPN) to be a SPN value (ex. host/krb-svc.domain.com). You don't need to specify the additional @REALM in the name, because that's already implied in the drop down box to the right. The servicePrincipalName attribute in this account should be the same value. There was a time when things could go wrong if the SPN wasn't all lower case, but not sure if that's a factor anymore. I'm also not sure if the $ sign would cause a problem. I've not tested that.

 

I don't have access to the AD user and computers but when I query the user I get the following properties: TrustedForDelegation : True TrustedToAuthForDelegation : False I think I mentioned before that we set the user up for unconstrained delegation. This should provide the same delegation rights, just be less secure, correct?

 

The delegation service account MUST BE SET to "Trust this user for delegation to specified services only", and "Use any authentication protocol" with constrained delegation to the specified HTTP/ SPNs of the XML brokers. APM Kerberos SSO actually does Protocol Transition, which requires constrained delegation.

 

yes, the Kerberos SSO is set to use the session.ldap.last.attr.sAMAccountName as the Username Source. I was able to see the mapping in the SSO log. However, the SSO log did show this line which had me worried until it continued on and found the UCC Feb 28 15:15:23 BIP02 debug websso.3[18866]: 014d0001:7: ssoMethod: kerberos usernameSource: session.ldap.last.attr.sAMAccountName userRealmSource: session.logon.last.domain Realm: REALM.NAME.COM KDC: AccountName: host/$service.account.name.domain.name.com spnPatterh: HTTP/%s@REALM.NAME.COM TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 0 The pattern had a variable in it instead of a service name. Does this need to be fixed?

 

This SPN pattern in the log is normal. I assume you don't have any value in the SPN Pattern block in the Kerberos SSO profile?