it does not need to mention that... with sidhistory it just adds additional SIDs to the token where the same rules apply as mentioned in that doc >>>>>Example: I have a group that points a user's SID history as a >>>>>ForeignSecurityPrinciple, then it will add in that object nope.... if a user (AccDomA) is member of some group in another domain (ResDomA) and that user has been migrated to another domain (AccDomB) with the sidhistory of its previous domain (AccDomA), the access token will contain it's new SID (AccDomA) and the sidhistory of the previous user (AccDomB). as soon as the user crosses the trust to access a resource protected by that "some group", then the SID of that some group will be added (ResDomA) >>>>>In other words, if user addomain\user1234 is accessing a file that is on >>>>>server fileserver.addomain.com <http://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 <http://addomain.com> ?
only within the user's own domain. if the user was in ADDOMAIN and the server in NTResDom78, then the SIDs of groupmemberships within domain NTResDom78 would be added to the list because the resource access was across a trust the access token always includes all groups in the same domain as the user (including nesting within own domain) and all universal groups (direct or indirect membership) and eventual sidhistory values it is on a need to know basis....imagine if it needed to ask the complete forest to see where group memberships existed. that would be a PITA as it needed to ask a DC for each domain in the forest for the domain local groups and to ask all member servers for local groups. 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 21:55 To: [email protected] Subject: Re: [ActiveDir] SID History. 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=/library/en-us/secauthz/security/how_dacls_control_access_to_an_object.asp 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] <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.
<<winmail.dat>>
