Guys, Could somebody clarify a couple things about PAC, please? “Privileged Attribute Certificate (PAC) has all [client] group information” Thus allows Sever to calculate effective permission for a requested resource, right? Trivial case both client and server belongs to same domain – everything is clear. Simplest case with domains trusts: There are 3 domains “C”, “G”, “S” (all in different forests with forests transitive trusts between each forest for simplicity) There is a client “c” in domain “C” Client is a member of 3 groups “C\g”, “G\g”, “S\g” (one group in each domain) There is a resource “r” on server “s” in domain “S” “C\g” has READ access to “r” “S\g” has WRITE access to “r” “G\g” has DENY ALL access to “r” Question: Client “c” request access to resource “r”, but all domain controllers in “G” are unavailable. What is the “c” effective permissions for the resource “r” in this case? Or to rephrase, how PAC (group membership) is calculated to access resource across domain trusts? I’m sure, this very question everybody runs into when dealing with domain trust. And it was probably answered many times already. My search skills are just not good enough to find the answers. ;-( It there any blog or forum where all aspects/variation of domain trusts and Kerberos related issues and best practices are discussed and explained thoroughly?

Hi, Based on my understanding, the user should not get the permission set for G\g as the DC in G are unavailable. The following is a good article to understand Kerberos authentication: How the Kerberos Version 5 Authentication Protocol Works http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Joson, First of all – thank for your reply. I was wondering if you can clarify a little bit regarding the link you posted. There is an example: “Cross-Realm Authentication: Three Domains” 6. The KDC in east.tailspintoys.com replies with KRB_TGS_REP. The authorization data includes: The SID for the user's account. SIDs for groups in west.tailspintoys.com that include the user. SIDs for universal groups that include either user or one of the user's groups in west.tailspintoys.com. SIDs for groups in east.tailspintoys.com that include the user, one of the user's groups in west.tailspintoys.com, or one of their universal groups. It will be all user's account groups SIDs for both west.tailspintoys.com and east.tailspintoys.com, but there are no any SIDs for tailspintoys.com domain (i.e. G domain from my example). Am I missing something there? And one more question: Just two domains – C & S (no G) Client tried to access a resource, but access is denied. Admin realized, he forgot to add client to one of the groups. He fixed the error, but the client cannot access a resource still, because ticket is cached. Where and how Admin need to purge ticket cache? On all these systems: Client workstation and all KDC (more than one!) in C domain and resource server and all KDC (more than one!) in S domain, right? Does the answer depend on where client was added to a group – on C or S domain. Sorry for very basic questions, but not easy to find an answer…

Hi, I haven't tested it before, but I believe the SIDs for the G domain are also included. Otherwise, the target server won't know the user is a member of the groups in G domain. However, in this case, there is no domain controller in G domain to authenticate the user. Therefore, the user won't get the permissions set for the group in G domain. As for the cached ticket, you can use the klist utility to purge the ticket on the client workstation. http://technet.microsoft.com/en-us/library/cc733974(WS.10).aspx. In fact, the cache will be deleted after the user logoff. This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Joson, I haven't tested it before, but I believe the SIDs for the G domain are also included. Otherwise, the target server won't know the user is a member of the groups in G domain. However, in this case, there is no domain controller in G domain to authenticate the user. Therefore, the user won't get the permissions set for the group in G domain. I have a feeling G domain SIDs won’t be included at all. Why would client even need to login to G domain in order to get access to a resource in S one? As for the cached ticket, you can use the klist utility to purge the ticket on the client workstation. In fact, the cache will be deleted after the user logoff. What about client groups SIDs cached in DC (to avoid lookup penalty) How do they get cached purged in relation to klist or logoff Actually, is there a way to see what SIDs are in a ticket PAC? It’ll make much easier to troubleshot things…

Sorry for brining same question again, yet: Actually, is there a way to see what SIDs are in a ticket PAC? It’ll make much easier to troubleshot things…