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/
