Ignoring the conversation on FPOs / FSPs / SIDs / DN-refs / DB-layer
meaning / "membership or group defintion" / etc for a little bit
(something I'm keen to come back to though) ... and going back to the
original question about where the "membership is stored" and how to
check/see the Enterprise Domain Controllers "membership" list ...
So based on my 17% certainty that it is a bit in the userAccountControl,
and joe's suggestion (which I think is likely correct) that it is bit 8192
(UF_SERVER_TRUST_ACCOUNT), you can make a repadmin command to show the
list ...
Repadmin can tell you who belongs "in EDC" (or to state it how joe or Dean
might say it [which is more accurate anyway], who should get the EDC SID
in thier token):
D:\src\adam\r2\ds\adam\src\util\repadmin>portable\obj\i386\repadmin.exe
/showattr root-dc-74 "" /subtree
/filter:"(userAccountControl:1.2.840.113556.1.4.803:=8192)"
/atts:samAccountName,userAccountControl /gc
<... list of DCs in forest showed up ...>
_NOTE_: And this is important, the query is inefficient, and so in
addition to having adverse effects on the DC's performance, the query can
fail ...
Aside: It fails with an error I do _not_ expect, BTW
"8240(0x2030): There is no such object on the server"
I am looking into that. Does nothing work anymore?
So if you run it a few times you'll probably pull in enough DB cache to
get the query to finish. I'd be curious if you got a different error, the
error I'd expect, is some sort of "timeout" error ...
BTW, if you want see the list of DCs in a single domain, change the above
command thusly:
- drop "/gc" option,
- replace "" with "ncobj:domain:"
- change root-dc-74 to be DC for the domain you want to target.
I thought for sure I'd have to add phantom root support to repadmin to
make it get all DCs in the enterprise, but apparently /gc implies it.
Smart. And that is why you have to change the "" to ncobj:domain: (which
gets expanded to the domain NC's DN) when you drop the /gc.
Anyway, I hypothesize, it might be possible to get a machine that doesn't
belong "in" EDC, by force demotion. So you can review this list for
anyone you don't want in that "group".
Cheers,
BrettSh
SDE _ESE_
P.S. - I used an ADAM repadmin.exe to do the above commands, but I think
they would work on the repadmin that shipped in Win2k3 as well.
On Wed, 24 Aug 2005, joe wrote:
> I expect more than one person is confused by Dean's post since he is
> responding to comments I sent to him offline... But since he brought it up
> here, I guess will respond here. :o)
>
> BTW, the basics of the items brought up offline were...
>
> 1. The FSPs are for LDAP I think more than the DB underpinnings.
>
> 2. As an aside, if you had to guess, what do you think the query ANR=* gets
> you. Don't look until you make your guess.
>
>
> So now that you know the previous responses, Dean's response may make more
> sense. Now on to my responses to Dean's responses to my offline responses.
> ;o)
>
>
> 1. We certainly could use something other than DNs to represent membership
> in groups. The questions up of what? SIDs may, on the surface, seem like a
> good answer. However I think there are three major failings to using SIDS.
>
> A. This is an underpinning issue so I will let Dean/Brett and possibly ~Eric
> duke it out, but the MV attributes that can contain the most values are
> Linked-Value attributes. Those attributes currently need to be DN based.
> This would mean if using SIDs you could put far less members in any given
> group. Actually that goes for any attribute syntax other than the DN based
> attribute syntaxes.
>
> B. Not every object you want to put in a group has a SID, do we then start
> sticking SIDs on everything? That would seem to be a step backwards. Not
> because SIDs are bad, but because MS doesn't seem to be really going forward
> with them. Specifically, as a realistic example right now, think of contacts
> in a mailenabled group. Further think of the future when people really start
> using groups, say for example I want to group some OUs together for password
> complexity but don't want to have them hierarchical or have to specify each
> individually to the password filter I could add all of the OUs to a group.
> The fact that member is a DN attribute makes that possible. If it were a
> SID, then I couldn't do it because an OU doesn't have a SID. Already I have
> seen several LDAP based applications that are used for security though not
> for Windows Security. Windows security wouldn't touch the groups because the
> groups aren't security enabled and have all sorts of different objects but
> they are still used for security within the app.
>
> C. This isn't specifically against SIDs again like A, but I think the
> defacto standard for LDAP representation of group members is DN based.
>
>
> I guess another mechanism that could be used is a unicode string attribute
> where each value has a prefix like keywords are used for ADAM SCPs or each
> value is a whole XML record which can be broken out. But at that point I
> think we are adding confusion to applications and people looking at the
> results. Of course you also have the problem outlines in 1A still.
>
> I am not saying that it can't be done, but I think it would take
> considerable work to get there from where we are now and the first thing we
> would need to do is decide if we were willing to break with the LDAP
> "standard" for representing group membership.
>
>
>
>
> 2. The query of (ANR=*) is converted by AD into (FALSE). I agree that that
> is probably in some way related to the fact that the query is converted to
> some invalid value and bounced or the directory is tossing it out on its own
> merit. For those not familiar with ANR, normally an ANR query will get
> expanded to something a bit larger prior to the actual search, for instance
> in my test forest that has Exchange in it (where ANR is used quite a bit)
> the query (ANR=joe) gets converted to
>
> (|
> (displayName=joe*)
> (mail=joe*)
> (givenName=joe*)
> (legacyExchangeDN=joe)
> (msDS-AdditionalSamAccountName=joe*)
> (mailNickname=joe*)
> (physicalDeliveryOfficeName=joe*)
> (proxyAddresses=joe*)
> (name=joe*)
> (sAMAccountName=joe*)
> (sn=joe*)
> )
>
> In ADAM that gets converted to
>
> (|
> (displayName=joe*)
> (physicalDeliveryOfficeName=joe*)
> (proxyAddresses=joe*)
> (name=joe*)
> )
>
>
> So at a guess, anr=* gets converted to anr=** which is an invalid query.
> Interestingly enough though, anr=joe* doesn't get converted to anr=joe** and
> thrown out... Also interesting is that anr=*joe gets converted to
> (<UNKNOWN>).
>
> joe
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
> Sent: Wednesday, August 24, 2005 1:24 PM
> To: Send - AD mailing list
> Subject: RE: [ActiveDir] Enterprise Domain Controllers
>
> 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/
>
> 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/
