Interesting conversation ... I'd certainly agree with Joe's assessment of well-known membership in that the SIDs denote something that you are by virtue of what you're doing as opposed to something that you are an explicitly configured member of.
Assuming I understand you (Joe) correctly, you're saying that LDAP needs the FSP (or FPO[1]) to maintain foreign domain membership since no object reference exists locally? If that understanding is correct, I would wonder if you've (Joe) not been blinkered by the way we're doing it at present :o) If I adopt the role of the devil's advocate for a second; who says that group membership has to be maintained using a pair of database-local objects (or rows if we're to expand the terminology) ... that was intended as a rhetorical question but please feel free to offer up an opinion. I certainly that the current approach offers many advantages and that its absence would likely cause an array of potentially painful scenarios but when used within the context of foreign membership, such justifications don't apply IMO ... for example, why not merely maintain the members SID in those instances where the member exists in a foreign forest or are well-known? Maybe because this single property wasn't designed to (or can't) work in a way requiring 2 distinct behaviors and FSPs are a means of 'making it fit' the behavior that we do have. That's nothing more than a hypothesis since I'm not aware of the motivation behind such design decisions. Anyway, with all of that said, I remain unconvinced that FSPs should be deemed a requirement of LDAP. Regarding your earlier ANR question; that's interesting, I'd expected far more than an empty result set. It appears to be using the generic dn index (i.e. the index that it reverts to when a non-existent property is specified within the filter). I suppose this may indicate that the ANR behaviors are not triggered when wildcarding the entire value ... possibly because ANR uses an implicitly wildcarded query which is mis-generated and dismissed when it results in a double asterisk (**) or because it is designed to ignore silly queries ?? :o) [1] FSP vs. FPO - that specific piece of terminology seems to depend on whether you're an aging Borg or just a familiar. -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, August 24, 2005 12:48 PM To: [email protected] Subject: RE: [ActiveDir] Enterprise Domain Controllers I would stay the course and say there is no membership. There are security principals that could have the SID added to their token which I agree is most likely controlled by userAccountControl & 8192. However it is a state of being authenticated coupled with being a domain controller that controls what objects have that SID at any given moment. It is like an authenticated user, what is the membership? Given the idea stated below, authenticated users are any security principal that can be authenticated, but wait, if someone isn't logged on, how could they be "authenticated"? We know that authenticated users are only the users that are currently authenticated and have the authenticated users SID in their token. Now for a group which has real membership. You can look at an attribute and it tells you who is at this exact moment a member of the group. State of authentication has no bearing. For instance, if you have Exchange, mailenable and send an email to some random group you have in your domain. Then try the same with Enterprise Domain Controllers. Those are some of the reasons why I say there is no membership to list, there are only principals that occasionally have the SID in their token. If you want, I guess you could consider it a dynamic group with the membership, if I were to admit it had membership, completely dependent on the state of being both a domain controller (or at least flagged in a way in the directory to indicate such) and authenticated. :o) joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Wednesday, August 24, 2005 11:48 AM To: [email protected] Cc: Send - AD mailing list Subject: RE: [ActiveDir] Enterprise Domain Controllers After reading joe's description, which sounds accurate to a non-expert like myself, I am willing to raise my confidence in my answer from a measly 12% to a full 17%. Well, I agree with most of what joe said, except for the part about not being able to "look" at the membership, you _sort of_ can as I alluded to in my mail, just not via the typical member attribute as joe was pointing out. Cheers, Brett On Wed, 24 Aug 2005, Dean Wells wrote: > > To further clarify Joe's point; the subset of > foreignSecurityPrincipals within the domain NC under the > ForeignSecurityPrincipals container (many [or all] of which will be > well-known security principals) are present there because of a relationship with another object within that partition. > > The foreignSecurityPrincipals within the config. NC serve as a > template and represent the well-known security principals listed by > the object picker when, for example, editing an ACL (do not test this > by deleting one, unless it's a sandpit, since recreating them can be problematic). > > As a general rule of thumb, and as far as I can recollect, foreign > security principals are created to represent any security principal > that cannot be resolved by a forest-local GC, e.g. users from a > foreign forest's domain or well-known security principals ... > <teasing> and are necessary because of the archaic underlying database > engine we continue to insist on using :o) </teasing>. > > -- > Dean Wells > MSEtechnology > * Email: [EMAIL PROTECTED] > http://msetechnology.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Wednesday, August 24, 2005 9:01 AM > To: [email protected] > Subject: RE: [ActiveDir] Enterprise Domain Controllers > > It isn't an actual group. > > It is a Well-Known security principal (SID=S-1-5-9) like Authenticated > Users or Everyone or Terminal Server User. You don't have the ability > to look at the membership, let alone modify it. When a token for a > domain controller is built, the SID is simply added to it. > > It is represented in the directory as a foreignSecurityPrincipal so it > can be added to groups and ACEs like Everyone is. As Tom indicated, it > is maintained in the Wellknown Security Principals container of the > configuration partition with other Well Known Security Principals. > > Here is a quick listing of all the FSPs listed in that container > > Anonymous Logon > Authenticated Users > Batch > Creator Group > Creator Owner > Dialup > Digest Authentication > Enterprise Domain Controllers > Everyone > Interactive > Local Service > Network > Network Service > NTLM Authentication > Other Organization > Proxy > Remote Interactive Logon > Restricted > SChannel Authentication > Self > Service > Terminal Server User > This Organization > Well-Known-Security-Id-System > WellKnown Security Principals > > > joe > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Brad > Sent: Wednesday, August 24, 2005 5:17 AM > To: [email protected] > Subject: [ActiveDir] Enterprise Domain Controllers > > Hey All, > > Can anyone tell me where this group is stored? It isn't in the > directory, and it isn't a local group...any ideas on how to check it's > membership list is correct? > > TIA, > > > Brad > > > This email and any attached files are confidential and copyright protected. > If you are not the addressee, any dissemination of this communication > is strictly prohibited. Unless otherwise expressly agreed in writing, > nothing stated in this communication shall be legally binding. > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
