| Author | Messages | |
Brad.Smith@xxxx.yyy
 | | 08/24/2005 9:18 AM |
| 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/ | | | |
| listmail
Posts:822
| | 08/24/2005 1:02 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
Sent: Wednesday, August 24, 2005 5:17 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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/ | | | |
| dwells
Posts:53
| | 08/24/2005 1:44 AM |
| 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 ... and are necessary because of
the archaic underlying database engine we continue to insist on using :o)
.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday, August 24, 2005 9:01 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
Sent: Wednesday, August 24, 2005 5:17 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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/ | | | |
| Brad.Smith@xxxx.yyy
| | 08/24/2005 3:25 AM |
| Dean, Joe and all, thanks again for clearing up something that the net
didn't easily reveal.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dean Wells
Sent: 24 August 2005 14:43
To: Send - AD mailing list
Subject: RE: [ActiveDir] Enterprise Domain Controllers
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 ... and are necessary because of
the archaic underlying database engine we continue to insist on using :o)
.
--
Dean Wells
MSEtechnology
* Email: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday, August 24, 2005 9:01 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
Sent: Wednesday, August 24, 2005 5:17 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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/
This message has been scanned for viruses by MailControl - (see
http://bluepages.wsatkins.co.uk/?4318150)
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/ | | | |
| activedirsmaporg
Posts:0
| | 08/24/2005 3:49 AM |
| 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 ... and are necessary because of
> the archaic underlying database engine we continue to insist on using :o)
> .
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 9:01 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: Wednesday, August 24, 2005 5:17 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| listmail
Posts:822
| | 08/24/2005 4:48 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: Wednesday, August 24, 2005 11:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 ...
> and are necessary because of the archaic underlying database
> engine we continue to insist on using :o) .
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 9:01 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: Wednesday, August 24, 2005 5:17 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| dwells
Posts:53
| | 08/24/2005 5:25 AM |
| 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Ώ]) 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)
Ώ] 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: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday, August 24, 2005 12:48 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: Wednesday, August 24, 2005 11:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 ...
> and are necessary because of the archaic underlying database
> engine we continue to insist on using :o) .
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 9:01 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: Wednesday, August 24, 2005 5:17 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| PeterJ
Posts:5
| | 08/24/2005 11:02 AM |
| Hi Brad
It's in the User's container by default. One of the things that dsaccess
does, except on frontend machines IIRC, is verify that the server is in
the Exchange Domain Servers which is a member of Exchange Enterprise
Servers.
Regards
Peter Johnson
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
Sent: 24 August 2005 11:17
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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/ | | | |
| activedirsmaporg
Posts:0
| | 08/24/2005 11:11 AM |
| I don't think that's right at all ... he's talking AD EDC group, nothing
to do with Exchange.
I'm just going to make this up* ... it's a piece of data on the DC's
computer account object that helps SAM determine if you deserve the EDC
group in your token. Maybe it is a bit in the userAccountControl.
* I don't know what I'm talking about, I really did pretty much make that
up, because it sounded vaguely familiar, sooo I'm like only 12% sure of
all that stuff I just said.
Cheers,
BrettSh
G-Door Operator #7
Posting is provided "AS IS", and confers no rights or warranties ...
On Wed, 24 Aug 2005, Peter Johnson wrote:
> Hi Brad
>
> It's in the User's container by default. One of the things that dsaccess
> does, except on frontend machines IIRC, is verify that the server is in
> the Exchange Domain Servers which is a member of Exchange Enterprise
> Servers.
>
> Regards
> Peter Johnson
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: 24 August 2005 11:17
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| listmail
Posts:822
| | 08/24/2005 11:16 AM |
| 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
().
joe
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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Ώ]) 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)
Ώ] 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: dwells@xxxxxxxxxxxxxxxxx
http://msetechnology.com
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday, August 24, 2005 12:48 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: Wednesday, August 24, 2005 11:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 ...
> and are necessary because of the archaic underlying database
> engine we continue to insist on using :o) .
>
> --
> Dean Wells
> MSEtechnology
> * Email: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 9:01 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: Wednesday, August 24, 2005 5:17 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| PeterJ
Posts:5
| | 08/24/2005 11:18 AM |
| Oops. Completely miss read the question. I'm going to explain by stating
I was trying to build my first ISA Server at the time and the brain task
switching crapped out. I will now slink away and change my name to Homer
Simpson :( :(
Doh!!!!!!!!!
Sorry to all!
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: 24 August 2005 13:11
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Enterprise Domain Controllers
I don't think that's right at all ... he's talking AD EDC group,
nothing
to do with Exchange.
I'm just going to make this up* ... it's a piece of data on the DC's
computer account object that helps SAM determine if you deserve the EDC
group in your token. Maybe it is a bit in the userAccountControl.
* I don't know what I'm talking about, I really did pretty much make
that
up, because it sounded vaguely familiar, sooo I'm like only 12% sure of
all that stuff I just said.
Cheers,
BrettSh
G-Door Operator #7
Posting is provided "AS IS", and confers no rights or warranties ...
On Wed, 24 Aug 2005, Peter Johnson wrote:
> Hi Brad
>
> It's in the User's container by default. One of the things that
dsaccess
> does, except on frontend machines IIRC, is verify that the server is
in
> the Exchange Domain Servers which is a member of Exchange Enterprise
> Servers.
>
> Regards
> Peter Johnson
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> Sent: 24 August 2005 11:17
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| tkern
Posts:8
| | 08/24/2005 11:21 AM |
| Its in the "well known security principals" container in the config NC
of the forest root.
you can see it with adsiedit.msc
On 8/24/05, Smith, Brad wrote:
> 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/ | | | |
| listmail
Posts:822
| | 08/26/2005 3:50 AM |
| 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 (joe@xxxxxxxxxxx) 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 (joe@xxxxxxxxxxx) 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
Sent: Friday, August 26, 2005 8:58 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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
_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
> ().
>
> joe
>
>
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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Ώ]) 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)
>
> Ώ] 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: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 12:48 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
> Sent: Wednesday, August 24, 2005 11:48 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 ...
> > and are necessary because of the archaic underlying database
> > engine we continue to insist on using :o) .
> >
> > --
> > Dean Wells
> > MSEtechnology
> > * Email: dwells@xxxxxxxxxxxxxxxxx
> > http://msetechnology.com
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> > Sent: Wednesday, August 24, 2005 9:01 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> > Sent: Wednesday, August 24, 2005 5:17 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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/ | | | |
| activedirsmaporg
Posts:0
| | 08/26/2005 12:59 PM |
| 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
_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
> ().
>
> joe
>
>
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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Ώ]) 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)
>
> Ώ] 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: dwells@xxxxxxxxxxxxxxxxx
> http://msetechnology.com
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Wednesday, August 24, 2005 12:48 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
> Sent: Wednesday, August 24, 2005 11:48 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 ...
> > and are necessary because of the archaic underlying database
> > engine we continue to insist on using :o) .
> >
> > --
> > Dean Wells
> > MSEtechnology
> > * Email: dwells@xxxxxxxxxxxxxxxxx
> > http://msetechnology.com
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> > Sent: Wednesday, August 24, 2005 9:01 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Smith, Brad
> > Sent: Wednesday, August 24, 2005 5:17 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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/ | | | |
|
|