Yep, you could do this with adfind as well, I would make the query a little
more efficient though, something like
adfind -gc -b "" -bit -f
"&(serviceprincipalname=ldap*)(useraccountcontrol:AND:=8192)" name
You could also use
adfind -gc -b "" -bit -f
"&(objectcategory=computer)(useraccountcontrol:AND:=8192)" name
I expect the first will be more efficient and faster than the second as you
should have far more computer objects than objects with an SPN of ldap*.
Either should be able to get all of the info without a timeout, if there is
a timeout, add -t 0 and you will be fine.
Oh, another query I just thought of which would be the most efficient would
be
adfind -gc -b "" -bit -f
"&(primaryGroupID=516)(useraccountcontrol:AND:=8192)" name
I agree 100% that a force demoted DC will show up in this list as well as
DCs that crashed and burned and didn't have the metadata cleaned up and the
machine account deleted.
Interesting you mention the phantom root support. I was just discussing that
with ~Eric the other day, I had no awareness of its existence until I was
discussing how ADAM doesn't have a GC function for cross partition searches.
He mentioned the phantom root support and I slapped that control into a
switch in my "special" personal copy of adfind and sure enough, it works
like a champ. I can now do GC-like queries across an ADAM instance with any
number of partitions.
F:\DEV\cpp\AdFind>adfind -h . -b -f instancetype=5 -dn -pr
AdFind V01.27.00cpp Joe Richards ([EMAIL PROTECTED]) August 2005
Using server: fastmofo.joe.com
Directory: Active Directory Application Mode
dn:CN=Configuration,CN={E28AE3C2-1228-4F6B-917C-56B9757DB796}
dn:DC=etherpunk,DC=com
dn:DC=set-con,DC=org
dn:DC=mytest,DC=com
dn:CN=user
dn:CN=newpart
dn:DC=domain,DC=com
dn:DC=morphlabs,DC=com
8 Objects returned
F:\DEV\cpp\AdFind>adfind -h . -b dc=com -f instancetype=5 -dn -pr
AdFind V01.27.00cpp Joe Richards ([EMAIL PROTECTED]) August 2005
Using server: fastmofo.joe.com
Directory: Active Directory Application Mode
dn:DC=etherpunk,DC=com
dn:DC=mytest,DC=com
dn:DC=domain,DC=com
dn:DC=morphlabs,DC=com
4 Objects returned
It doesn't appear that you can do this type of query from ADSI or .NET
currently. But then, I don't care, I don't use those technologies for my
real programming, just ADSI for scripts. I would rather use perl to call out
to adfind than use perl or vbscript combined with ADSI/ADO to search AD.
joe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Friday, August 26, 2005 8:58 AM
To: [email protected]
Cc: 'Send - AD mailing list'
Subject: RE: [ActiveDir] Enterprise Domain Controllers
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/
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/
