Yeah, read that document before.  It doesn't say whether it's going to go scanning domains for SID History memberships, so I have to assume that unless I have a group that points to a user's SID History SID within that AD environment (or in that authentication chain), then it's not going to add in more SIDs to the user's token.

Example: I have a group that points a user's SID history as a ForeignSecurityPrinciple, then it will add in that object.

In other words, if user addomain\user1234 is accessing a file that is on server fileserver.addomain.com and only ACLs to groups that are within the local domain that are AD native and those groups only have memberships for the local domain, then is his token going to include his memberships from NTResourcedomain42 and NTResourcedomain78 or just his memberships which reside within addomain.com?


On 9/25/06, Almeida Pinto, Jorge de <[EMAIL PROTECTED] > wrote:
to read on how the access token is build see:
http://download.microsoft.com/download/8/f/3/8f36dfe4-47d0-4775-ad5a-5614384921aa/AccessTokenLimitation.doc

authentication across domains depends if NTLM is used (external trusts) or kerberos is used (forest trusts and intra-forest transitive trusts)

sIDHistory just adds SIDs to the access token, after that the process is the same

jorge


Met vriendelijke groeten / Kind regards,
Ing. Jorge de Almeida Pinto
Senior Infrastructure Consultant
MVP Windows Server - Directory Services

LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
(   Tel     : +31-(0)40-29.57.777
(   Mobile : +31-(0)6-26.26.62.80
*   E-mail : <see sender address>

________________________________

From: [EMAIL PROTECTED] on behalf of Matt Hargraves
Sent: Mon 2006-09-25 19:38
To: [email protected]
Subject: Re: [ActiveDir] SID History.


Unfortunately that's not even close to what I was having issues with Joe.

I'm more concerned with how tokens are created and whether they will by default query the old resource domains that haven't been migrated into the AD environment.

Theoretical situtation:  I am a member of 50 groups in my user domain, I'm accessing something in my user domain.  We have 150 trusted resource domains where I have 6 group memberships in each through SID history.  Is the GC/DC going to query all trusted domains for my memberships through SID history?  (resource domains are all NT4 domains)

I'm assuming that it's not going to, because of how the authentication path works (resource server - user domain DC - user domain GC - resource server DC, resource server), but everything I've seen never really talks about SID History much.




On 9/24/06, joe <[EMAIL PROTECTED]> wrote:

        I would recommend poking through the MSDN security docs. It sounds like there is a break in understanding of how the SIDs are used in combination with the DACLS.

        Start here:

        http://msdn.microsoft.com/library/default.asp?url=""

        but poke around that whole area.

           joe

        --
        O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm



________________________________

        From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Matt Hargraves
        Sent: Thursday, September 21, 2006 4:59 PM
        To: [email protected]
        Subject: [ActiveDir] SID History.



        Conceptual situation:

        User domain
        Resource domain (s)

        I bring all users into a single AD environment, bringing over SID History information.

        Now I start moving over file servers from the resource domain to the AD environment.  One of the file servers has groups ACL'd from the resource domain.  When the server goes to check for access rights, will it pull over *all* group memberships from the appropriate resource domain or simply pull over the single group membership and append that to the user's token?

        Mostly just looking at SID history impact between semi-active resource domains that are being decomissioned and current domains.  Microsoft's site mostly seems to point to groups that are pointing to SID history objects that are within the AD environment, not cross-domain SID history impact.





This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.


Reply via email to