none
AD Cross forest access token creation and resource access

    Question

  • Dear all!

    Could someone explain me an access token creation process for user with two  AD forests (2003 - 2008R2) that are joined by forest trust.

    Domain and Forest functional levels are  2003 native and 2008 R2 respectively.

    http://technet.microsoft.com/en-us/library/cc780455(v=ws.10).aspx

    As I understood from the link above (not only from there), when user logs on to the domain joined computer the LSA subsystem constructs the user’s access token by virtue of netlogon.dll that communicates with localDC+GC+ForestRootDC to get:

    -           user’s own SID;

    -           user’s SIDhistory attribute, if any

    -           SIDs of all the groups that the user is member of (global, universal, domain local, computer local) along with their SIDs, if any

    -           well-known groups’ SIDs (depending on access type)

    -           privileges and other pieces

    If I add user (DOM1\User1) from one forest to “domain local” group of the second forest (DOM2\DL-Group2) (for assigning permissions to resources in DOM2) this will lead to ForeignSecurityPrincipals object creation in  the second forest DOM2.

    This foreign object will be seen as part of part of a particular  DOM2\DL-Group2 group and vice versa.

    The question is the following:

    How “LSA + netlogon.dll + something else (WHAT ? )” know that user is member of some group in different AD forest so that to include SID of that group into user’s access token ?

    Could someone provide me with a detailed mechanisms and processes that are taking place that cover inter-forest resource access in conjunction with cross-forest access token creation?

    1. When DOM1\User1 logs on to DOM1\PC1 and access resources in foreign forest

    2. When DOM1\User1 logs on to DOM2\PC2 and access resources in foreign forest

    Any help is appreciated!

    Monday, May 27, 2013 6:41 PM

All replies

  • The authenticating context (either a user or computer) gain the security principals (group membership) from a GC in it's own forest + membership of universal groups/domain local groups in trusted forest truh foreign security principals.

    For more information see:
    http://technet.microsoft.com/sv-se/library/cc773178(v=ws.10).aspx

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Monday, May 27, 2013 9:04 PM
  • Yes, user gets one's SIDs from GC in one's forest during logon. So this is limited to user's AD forest.

    GC knows only info about it's forest and a little about trusts with different forests (TDOs, domain trees, name suffixes etc.)

    Description of interforest resource access (link that you've provided) depicts only situation when user was inserted directly into ACL of the remote forest server (not through group in DOM2\DL-Group2).

    Excerpt from technet article:

    http://technet.microsoft.com/en-us/library/bb727067.aspx

    If you place an external group (or user) directly into a Discretionary Access Control Lists (DACLs), the security identifier (SID) of the user is added to the DACL and, in this case, no foreign security principal object is created.

    -

    How the user domain's DC/GC knows that this user was put inside some "domain local" security group in different forest (ForeignSecurityPrincipal was created there) so that to include SID from that remote group to user's access token during user logon? 

    Any more info?

    Tuesday, May 28, 2013 9:01 AM
  • Yes, user gets one's SIDs from GC in one's forest during logon. So this is limited to user's AD forest.

    GC knows only info about it's forest and a little about trusts with different forests (TDOs, domain trees, name suffixes etc.)

    Description of interforest resource access (link that you've provided) depicts only situation when user was inserted directly into ACL of the remote forest server (not through group in DOM2\DL-Group2).

    Excerpt from technet article:

    http://technet.microsoft.com/en-us/library/bb727067.aspx

    If you place an external group (or user) directly into a Discretionary Access Control Lists (DACLs), the security identifier (SID) of the user is added to the DACL and, in this case, no foreign security principal object is created.

    -

    How the user domain's DC/GC knows that this user was put inside some "domain local" security group in different forest (ForeignSecurityPrincipal was created there) so that to include SID from that remote group to user's access token during user logon? 

    Any more info?


    Yes, the group from a 'foreign' domain (diffrent forest or external domain) is represented as a FSP in the users domain, and the user is a member if the FSP that have the same SID as the real group in the 'foreign' domain/forest.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Tuesday, May 28, 2013 10:41 AM
  • Good and interesting topic

    I would go by datastructures most of the times . So SID has its own datastructure, one of the structure member is "SID_IDENTIFIER_AUTHORITY IdentifierAuthority" and SUBAuthority Array . These both are key members which stores information.

    Access checks  determines the sid ( as kernel never understand User name string and validation is performed using SID ) of the user and the list of groups that user belongs to . so the subauthority array consists of the RID values and relative information for that user.

    each user which gets created will be assigned a RID which are created by the Domain controller. ( if you need more info just open winnt.h and you can read the RID and their descriptions. )

    And any time the user gets added across domains / forests, the subauthority array gets appended with known RID.

    when access check is performed against dc = its knows what RID to authenticate to

    Tuesday, May 28, 2013 11:36 AM
  • Thanks for the reply, but I didn't get the whole picture yet.

    When the ForeignSecurityPrincipal is created in resource forest it has cn,name,objectSID attributes set to SID from accounts forest's user object.

    What I don't understand is that how resource server (e.g. SMB) knows that user from remote forest had been put inside resource forest group (listed in ACL on that SMB server) so that to make decision about access?

    SMB server transfers access token that user presents (with no resource forest's group SID) to resource forest DC for verification. What is happening next?

    Friday, May 31, 2013 9:43 AM
  • If you are logged in you can see that you have SIDs of groups that you are memberof outside your own forest as well by running 'whoami.exe /groups' - those are in your ticket and are passed to resource servers in diffrent forests as well. 

    Enfo Zipper
    Christoffer Andersson – Principal Advisor
    http://blogs.chrisse.se - Directory Services Blog

    Friday, May 31, 2013 9:56 AM
  • Unfortunately it's not there.

    What I've done for verification:

    1. created a testGroup in resource forest and added a user from remote (account) AD forest to that group.

    2. forced synchronization between all the domain controllers in the resource forest and verified each of them.

    3. logged into account forest as account forest user.

    4. run whoami /groups and tried to find SID of domain local group (testGroup) from resource forest. It wasn't found.

    Note: I have two forests each of which consists of a single domain.

    Any more info?

    Saturday, June 01, 2013 7:09 AM
  • Come on guys! Does anyone know the answer? It works someway but how?
    Wednesday, December 25, 2013 2:57 PM