Forum Discussion
NimbostratusKCD SmartCard Two Domains Same Forest Users in both
Afternoon all,
Have a KCD APM question.
I have successfully been able to setup KCD in a singe domain instance. Both the resource the client is accessing, the F5 KCD account and the clients account is in the same domain. Lets call it Domain A in Forest A. Now, I need to allow a client in Domain B, which is a child domain of Domain A access to the same resource in Domain A, again all within Forest A. The environment is at a 2008 R2 level so credential delegation does not cross domain boundaries. My KCD service account for F5 is in Domain A. Another thing, both clients in Domain A and Domain B share the same UPN suffix on their Smart Cards. Lets say @contoso.com. This is essentially the enterprise wide standard for authentication. NO USERNAME/PASSWORD. This suffix does not exist as a domain space for either Domain A or Domain B. Lets say Domain A's domain space is SOMETHING.COM and Domain B is EXT.SOMETHING.COM.
I have setup my VPE Policy to use an Active Directory Trusted Domains object which works great to query and verify the account exists in either domain. The problem I am running into is how to setup SSO so I can get a S4U Proxy TGT for accounts in either domain. Again, the resource and F5 KCD service account exist in Domain A SOMETHING.COM. I have tried to setup Multiple Domain SSO for my Policy in APM but to no avail.
Any and all help would be great!
Thanks
3 Replies
jspiglerj2rsolvesAlso for all for all intents and purposes, the service we are accessing is app1.something.com.- Kevin_Stewart
Employee
You're actually talking about a Kerberos "extension" referred to as "Canonical Referral". It's like a CNAME process for Kerberos. In any case, APM Kerberos doesn't follow these referrals today, so you have to tell it exactly which domain the user belongs to. This is complicated by the fact that your smartcard UPN doesn't match any single domain. So basically what you need to do is this:
-
Insert an LDAP Query in the VPE that queries the domain(s) or GC. You need to extract the user's real domain and their sAMAccountName.
-
Use the sAMAccountName and user's real domain as the Kerberos SSO input username and domain session values.
-
- Kevin_Stewart
This doesn't have anything to do with delegation. You simply cannot "chase" a referral to the correct domain, assuming you didn't already know what it was. If you're specifying the correct domain in the SSO then you don't have to chase a referral. Coincidentally, if the UPN domain doesn't match the real domain name, then it also involves referrals, which is why you'd use the sAMAccountName instead.
