Oh, sorry, I didn't realize.
A GC lookup will occur anytime an application decides it
wants to use a GC instead of a DC. This is mostly done when looking for an
object that could exist in any domain in the forest. No one could give a
comprehensive list of when this is done because no one controls all programs.
Obviously Exchange is EXTREMELY GC bound. The SEARCH dialog on all of the PCs
for finding people and computers is handled through the GC. If you are truly
curious how much GC querying is going on, go to a couple of your GCs and start
capturing port 3268 traffic and see how much is there. The machines that
generate the queries combined with the queries themselves may give you a hint as
to what is generating the traffic.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, January 27, 2006 3:59 AM
To: [email protected]
Subject: RE: [ActiveDir] Limitations and issues with domain local groups and GC replicated data
LOL. You and Guido have both explained the underlying
architecture, which I understand. What I don't understand is under what
circumstances a GC lookup would be performed as opposed to a DC lookup in the
correct domain.
I am trying to build up a case where I can mitigate the
potential issues involved but cannot simulate a failure since a GC is not
queried. I appreciate that Exch is one "potential example" but can you suggest
any others?
Thanks,
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: 27 January 2006 04:55
To: [email protected]
Subject: RE: [ActiveDir] Limitations and issues with domain local groups and GC replicated data
Any tool that hits a GC to search can hit ANY GC regardless
of domain when it executes the query. There is no affinity to using a GC from a
specific domain UNLESS the application specifically codes it in. This is
something that Exchange 2003 SP2 is now doing to help with updating info through
Outlook. The problem there was more of a trying to update a GC, but the same
logic applies.
If you have 4 GCs that are DCs for Dom1, Dom2, Dom3, and
Dom4 in a single site and you are granted read access to some object in Dom1 via
a domain local group from Dom1 then when you have a machine that queries a
GC without specifying which server in that site you only have a 25% chance
of hitting a GC that you can actually read the object
on.
That make any sense?
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, January 26, 2006 4:01 AM
To: [email protected]
Subject: RE: [ActiveDir] Limitations and issues with domain local groups and GC replicated data
"Now the same data is replicated to a GC in
DomA.
1. DOMA-USR1 now tries to access
the OU on a DOMA-GC
2. only the user's
DomA token is valid on a DC or GC (or any other
resource) in DomA - this does not include the
DOMB-DLG1
3. so even though the user is a
member of the DLG of DomB, this group membership is unknown on the DOMA
GC and thus access will fail (again, assuming you've removed the
default READ permissions for auth. users)."
Can anyone offer me a scenario where a user in domainA
would try to access a GC-replicated object that exists in domainB, via a GC in
domainA?
This would create an issue with the DLG model, but
discussions and tests here have not been able to simulate this
scenario.
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido
Sent: 20 January 2006 18:58
To: [email protected]
Subject: RE: [ActiveDir] Limitations and issues with domain local groups and GC replicated data
> I'm trying to figure out
if this represents an issue to me in my (proposed) regional
> multi-domain environment or not.
>
> We are currently planning to use DLGs for permissioning AD data as well as server
> based data. We planned to then nest global groups (GGs) into these DLGs from various
> domains in the forest. Will such a scenario be affected by the issue described above?
> multi-domain environment or not.
>
> We are currently planning to use DLGs for permissioning AD data as well as server
> based data. We planned to then nest global groups (GGs) into these DLGs from various
> domains in the forest. Will such a scenario be affected by the issue described above?
Yes it does. Are you actually in the planning
phase of the domain-model / forest-structure itself? Or does this multi-domain
AD already exist and you need to plan the security model for it? If you're
still structuring the forest, you should seriously consider a single domain
approach to avoid many of the challenges involved with multiple domain forests
(the security on GC data using DLGs just being one of
them).
The
impact of AD data in GCs that are secured with DLGs certainly depends
on your overall security strategy in the AD forest. If you leave the default
ACLs in place (which grant a whole lot of READ permissions to authenticated
users) and are just planning to use the DLGs to add extra rights to OUs (or any
object) for delegating administrative tasks (e.g. permissions to change PW or to
add specific objects such as computers to an OU), this will typcially
not impact you negatively when trying to access the data from a
remote domain on a GC. Why? Well the data in the GC is read-only anyways so even
though those extra permissions will not be applicable on the GC in a remote
domain, the data can't be edited anyways so you won't notice the
difference.
If
however you are planning to take away a lot of the default rights - or you are
granting extra rights to read hidden data (e.g. hidden group-memberships in
Exchange or simply an OU where the default read-permissions have been removed so
that the data won't be visible for the normal users), granting rights using a
DLG will not suffice to make the data accessible on the GC in a remote
domain.
It
doesn't matter that you're planning to put the users from the various domains
into Global Groups (GGs) and then nest these into the DLGs => the GC of a
remote domain has no clue who is a member of the DLG (since the member attribute
of a DLG is not replicated to the GC), so it can't expand the token of the user
that tries to access the data on that remote GC.
To
make it clear:
1. a user in DomA (DOMA-Usr1) is
a member of a DLG in DomB (DOMB-DLG1).
2. DOMB-DLG1 is used to
grant read access on an OU in DomB (where auth. users READ access has been
removed)
3. when DOMA-Usr1 logs onto his client he is
authenticated via a DOMA DC
4. at this time he will only have
DOMA groups in his token + any Universal Groups of the forest
(needs to connect to a GC at logon to find the appropriate group-memberships of
the user). He will thus have the DLGs and GGs of his own domain (DOMA) and
UGs of any domain in his token.
5. he now connects to a DOMB DC
to look at the secured OU => because of the transitive trust he is
automatically authenticated - at this time the user's access token is generated
for the DOMB domain by a DOMB DC => this DC
knows of the user's DLG memberships in DOMB and adds DOMB-DLG1
to DOMA-Usr1's access token (only valid on DOMB resources); it
doesn't matter if the user has a direct membership in the DLG or via a GG of
DOMA.
6.
the user successfully accesses the secured OU on the DOMB
DC
Now
the same data is replicated to a GC in DomA.
1. DOMA-USR1 now tries to access
the OU on a DOMA-GC
2. only the user's DomA token is
valid on a DC or GC (or any other resource) in
DomA - this does not include the
DOMB-DLG1
3. so
even though the user is a member of the DLG of DomB, this group membership is
unknown on the DOMA GC and thus access will fail (again,
assuming you've removed the default READ permissions for auth.
users).
> If so, what are the alternatives / suggestions open to me?
well,
the first suggestion would be not to implement a multi-domain forest if you can.
Try to do everything with OUs. If you can't and you're going to
"hide" data in AD that you need to have accessible in the GC, then use UGs to
grant the required permissions. This will work for direct membership in the UGs
or nested GGs.
Last
warning: you do need to be careful with nesting GGs into UGs for other reasons
=> if membership of the UGs is expanded by other apps to determine their
membership (e.g. by Exchange Servers when determining recipients of a
distribution list), the nested GGs will not be a good thing. For similar reasons
as desribed above, the GC of DOMB will not know who is a member of the GG in
DOMA that is nested into a UG in DOMB - as such the Exchange server can't fully
expand the group and mail delivery will fail. So, for many circumstances it is
benefitial to populate the UGs directly with the users (or other
UGs).
Enough for today.
/Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Freitag, 20. Januar 2006 16:53
To: [email protected]
Subject: [ActiveDir] Limitations and issues with domain local groups and GC replicated data
It's Friday afternoon and I think I need more sugar and/or caffeine :)
I've recently read in several places how the use of domain local groups (DLGs) could represent an issue when used to permission GC replicated domain data.
For example - this an excerpt from a MS article:
"Special security consideration should be given when specifying permissions on domain data that is also replicated to the global catalog. When a user connects to a global catalog, an impersonation token is created for the user, which is used in subsequent access control decisions on the global catalog. The user's universal, global and domain local group memberships are represented in this token. However, only domain local groups from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to and of which the user is a member show up in the user's token. Domain local groups in the user's domain (and in other domains) of which the user is a member do not show up in the access token."
I'm trying to figure out if this represents an issue to me in my (proposed) regional multi-domain environment or not.
We are currently planning to use DLGs for permissioning AD data as well as server based data. We planned to then nest global groups (GGs) into these DLGs from various domains in the forest. Will such a scenario be affected by the issue described above? If so, what are the alternatives / suggestions open to me?
Can someone offer an example of when the above would represent a true issue? [Assuming my scenario above is not a good example.]
Thanks,
neil
___________________________
Neil Ruston
Global Technology
Infrastructure
Nomura
International plc
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
