Cross-Domain question (Parent - Child)

[Guest]

Hello,
I am by no means not an expert on ADS. Can any body help me to answer this
parent-child domain question?
A simplified scenario is:
DomainA: Windows2000 Parent Domain in native mode. This is a global catalog
server.
DomainB: Windows2000 Child Domain in native mode.
UserB: User object defined in DomainB.
RoleA: Universal group object defined in DomainA.
Using the ADS Users and Computers admin screen, I made UserB a member of
RoleA.

ISSUE 1: The RolesA property in the ADS Users and Computers admin screen for
DomainA shows UserB as a member. But,UserB's property screen in the ADS Users
and Computers admin screen for DomainB does not show RoleA as "MemberOf".

ISSUE 2: Created a C++ progam that connects to UserB with ADsOpenObject()
passing "LDAP//DomainB/CN=UserB,DC=DomainB,DC=DomainA,DC=com", and attempts
to get the "memberOf" property through GetEx() interface. There was no
"MemberOf" returned for UserB.

Now, I enabled global catalog for DomainB server. After this change, both
ISSUE1 and ISSUE2 are resolved. I can now view RoleA of which UserB is a
member from DomainB.

QUESTION1: According to ADS documentation, in native mode, DomainA and
DomainB get the transitive two way trust. Also, the univeral group should be
visible from any domain in a forest. So, why do I need to enable the global
catalog for DomainB to make RoleA visible from DomainB?

QUESTION2: Without enabling the global catalog for DomainB, is there any way
I can view RoleB as a MemberOf property for UserB programmatically? According
to some document, during the Microsoft Login process, the Local Security
Authority constructs a security token consists of every group that the user
is a member of. That is exactly what I need to do. I like to do it
efficiently minimizing the possible searches for every group and then each
member in that group.

Thanks in advance.
jinjkim

 

[Herb Martin]

Hello,
I am by no means not an expert on ADS. Can any body help me to answer this
parent-child domain question?
A simplified scenario is:
DomainA: Windows2000 Parent Domain in native mode. This is a global
catalog
server.
DomainB: Windows2000 Child Domain in native mode.
UserB: User object defined in DomainB.

If you only have 2 DCs, or even a few, then why not just
make EVERY DC into a GC? Presumably the number of
users and computers is reasonably small.

[Also what about DNS?]

RoleA: Universal group object defined in DomainA.
Using the ADS Users and Computers admin screen, I made UserB a member of
RoleA.

ISSUE 1: The RolesA property in the ADS Users and Computers admin screen
for
DomainA shows UserB as a member. But,UserB's property screen in the ADS
Users
and Computers admin screen for DomainB does not show RoleA as "MemberOf".

ISSUE 2: Created a C++ progam that connects to UserB with ADsOpenObject()
passing "LDAP//DomainB/CN=UserB,DC=DomainB,DC=DomainA,DC=com", and
attempts
to get the "memberOf" property through GetEx() interface. There was no
"MemberOf" returned for UserB.

Now, I enabled global catalog for DomainB server. After this change, both
ISSUE1 and ISSUE2 are resolved. I can now view RoleA of which UserB is a
member from DomainB.

QUESTION1: According to ADS documentation, in native mode, DomainA and
DomainB get the transitive two way trust.

This has nothing to do with "native mode" (nor any other
mode -- the automatic 2-way transitive trusts is due to
joining the same Forest (technically due to being a child
of an existing domain or tree top since the transitive takes
care of the rest of the forest.)

Also, the univeral group should be
visible from any domain in a forest. So, why do I need to enable the
global
catalog for DomainB to make RoleA visible from DomainB?

Every client must have access to a GC, no matter what
domain that client (or the GC) lives within.

Global Catalog servers are required on a PER SITE basis
(within each forest) and are really not related to "domains"
except that they must run on SOME DC in some domain of
that forest.

GCs can be enabled on EVERY DC if your multi-domain
forest is reasonably small. (And for all single domain
forests too.)

QUESTION2: Without enabling the global catalog for DomainB, is there any
way
I can view RoleB as a MemberOf property for UserB programmatically?

You really need to get your GCs "right" without thinking
of this on a "per domain" basis, instead of trying to do
without necessary GCs.

According
to some document, during the Microsoft Login process, the Local Security
Authority constructs a security token consists of every group that the
user
is a member of. That is exactly what I need to do.

And the Universal Group lists are maintained on the GCs
(which do not have to be from any particular domain but
which must be available.)

Technically you can use "Universal Group Caching" enabled
on a Win2003 (ONLY) DC but I hesitate to suggest that unless
you have a very large domain/forest and a serious WAN
replication problem.

Fix the GCs.

I like to do it
efficiently minimizing the possible searches for every group and then each
member in that group.

What is preventing you from adding GCs?

 

[Guest]

Thanks, Herb.
I think I have simplified the scenario too much. In fact, this is a real
customer (Financial Institute) case where they have multiple branches. Each
branch has its own domain. Since each branch is in different site, I agree
that each site has to have a GCs. For Windows 2000 server environment, my
current program, that is performing the operations as I briefly described in
my original email, works fine.
I just tested the same thing with Windows 2003 server environment, and found
out, even though I enabled GC for a child domain, the two issues that I
raised in my original email are not resolved. I think I may need to set some
access rights or somthing for Windows 2003. Do you know what I am missing?

Regards,
jinjkim

Hello,
I am by no means not an expert on ADS. Can any body help me to answer this
parent-child domain question?
A simplified scenario is:
DomainA: Windows2000 Parent Domain in native mode. This is a global
catalog
server.
DomainB: Windows2000 Child Domain in native mode.
UserB: User object defined in DomainB.

If you only have 2 DCs, or even a few, then why not just
make EVERY DC into a GC? Presumably the number of
users and computers is reasonably small.

[Also what about DNS?]

RoleA: Universal group object defined in DomainA.
Using the ADS Users and Computers admin screen, I made UserB a member of
RoleA.

ISSUE 1: The RolesA property in the ADS Users and Computers admin screen
for
DomainA shows UserB as a member. But,UserB's property screen in the ADS
Users
and Computers admin screen for DomainB does not show RoleA as "MemberOf".

ISSUE 2: Created a C++ progam that connects to UserB with ADsOpenObject()
passing "LDAP//DomainB/CN=UserB,DC=DomainB,DC=DomainA,DC=com", and
attempts
to get the "memberOf" property through GetEx() interface. There was no
"MemberOf" returned for UserB.

Now, I enabled global catalog for DomainB server. After this change, both
ISSUE1 and ISSUE2 are resolved. I can now view RoleA of which UserB is a
member from DomainB.

QUESTION1: According to ADS documentation, in native mode, DomainA and
DomainB get the transitive two way trust.

This has nothing to do with "native mode" (nor any other
mode -- the automatic 2-way transitive trusts is due to
joining the same Forest (technically due to being a child
of an existing domain or tree top since the transitive takes
care of the rest of the forest.)

Also, the univeral group should be
visible from any domain in a forest. So, why do I need to enable the
global
catalog for DomainB to make RoleA visible from DomainB?

Every client must have access to a GC, no matter what
domain that client (or the GC) lives within.

Global Catalog servers are required on a PER SITE basis
(within each forest) and are really not related to "domains"
except that they must run on SOME DC in some domain of
that forest.

GCs can be enabled on EVERY DC if your multi-domain
forest is reasonably small. (And for all single domain
forests too.)

QUESTION2: Without enabling the global catalog for DomainB, is there any
way
I can view RoleB as a MemberOf property for UserB programmatically?

You really need to get your GCs "right" without thinking
of this on a "per domain" basis, instead of trying to do
without necessary GCs.

According
to some document, during the Microsoft Login process, the Local Security
Authority constructs a security token consists of every group that the
user
is a member of. That is exactly what I need to do.

And the Universal Group lists are maintained on the GCs
(which do not have to be from any particular domain but
which must be available.)

Technically you can use "Universal Group Caching" enabled
on a Win2003 (ONLY) DC but I hesitate to suggest that unless
you have a very large domain/forest and a serious WAN
replication problem.

Fix the GCs.

I like to do it
efficiently minimizing the possible searches for every group and then each
member in that group.

What is preventing you from adding GCs?

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Thanks in advance.
jinjkim

 

[Joe Richards [MVP]]

The member and memberof attributes are special in that they are linked.
The member attribute is the forward link and the memberof attribute is
the back link. You populate the forward link and depending on the DC you
query in a multidomain forest you may or may not see the value populated
in the backlink.

The normal case, with all groups excluding universal is this...

1. If the group and the user exist on the same domain and you query a
non-GC domain controller, you will see the user listed in the group's
member attribute and you will see the group listed in user's memberof
attribute. This is because both the user and the group exist in the
local copy of the DIT.

2. If the group and the user exist on different domains and you query
non-GC domain controllers, you will see the user listed in the group's
member attribute but you will NOT see the group listed in the user's
memberof attribute. This is because both the user and the group do NOT
exist in the local copy of the DIT. On the DC that is a DC for the
domain the user exists in, the user exists but the group does not. On
the DC that is a DC for the domain the group exists on, the group exists
and the user exists as a phantom which is something that you can't
directly see, it is simply a placeholder so the group can hold the
membership since what is really in the member attribute is basically a
row number (a DNT) in the DIT, not an actual DN.

3. If you query a GC that is a domain controller for the domain that the
group is a member of and you query the LDAP or GC port, you will see
that the user is listed in the group's member attribute. If you query
the GC port (but not the LDAP port) you will see that the group is
listed in the user's memberof attribute. This is because both the user
and the group exist in the local copy of the DIT but you can only query
the user on the GC port because that object only exists in the read only
partitions.

4. If you query a GC that is the domain controller for ANY domain that
the group is not a member of and you query the GC port you will NOT see
that the user is a member of the group. If you query the GC port you
will not see the group listed in the user's memberof attribute. This is
because the membership of domain local and global groups is not
maintained in the GC partitions, you can only see that membership on DCs
that host the domain the group is part of.

Now with universals...

1. No change

2. No change

3. No change

4. Now you will again see the user listed in the group's member
attribute and the group listed in the group's memberof attribute. This
is because Universal group membership is maintained in the GC partitions
and so both the user and the group exist in the local DIT.


Now for specific questions:

ISSUE 1:

Correct, read above for reasons.

ISSUE 2:

Correct, read above for reasons.

Now, I enabled global catalog for DomainB server. After
this change, both
ISSUE1 and ISSUE2 are resolved.

Correct, read above for reasons.

According to ADS documentation, in native mode, DomainA and
DomainB get the transitive two way trust.

Mode has nothing to do with this. There is always a 2-way transitive
trust but the trust status has zero to do with this. This is about
object visibility and back end implementation, nothing to do with trusts...

Also, the univeral group should be
visible from any domain in a forest.

Not sure where you got this, but it is incorrect. Universal groups have
presence on all GCs, you don't necessarily have to have GCs in every
domain. And even if you did, it membership is only available on the GCs,
not every DC in every domain that has a GC.

So, why do I need to enable the global
catalog for DomainB to make RoleA visible from DomainB?

Read above.

QUESTION2: Without enabling the global catalog for DomainB,
is there any way
I can view RoleB as a MemberOf property for UserB programmatically?

Yes, you just know which DCs to ask and how. Read above.

According to some document, during the Microsoft Login process,
the Local Security Authority constructs a security token consists
of every group that the user is a member of.

That is incorrect. It only builds the membership that is in scope for
the current session. So for instance, in a single domain, yes, you will
get every domain group the user is a member of in the token. If however
you have a multi-domain environment and the user is a member of domain
local groups in different domains, only the domain local groups that are
appropriate for the scope of the authentication will be placed in the
token. If the user logs into domain1 on a domain1 machine, they will get
domain1 DLGs. If the user logs into domain1 from a domain2 machine, they
will get domain2 DLGs. Universal groups from any domain will be present
because one of the requirements of an auth in native mode is for a GC to
be available to populate the token with the universal groups. There are
ways of circumventing this but they are special cases and I don't care
to go into the issues surrounding those special cases (i.e.
IgnoreGCFailures and Group Caching). Also local groups on various
members do not get added to your token either again, unless it is
appropriate for to do so. I.E. If you logon to machine1, it doesn't
matter to machine1 that you are in group5 on machine2. When/If you make
a connection to machine2, your token ON MACHINE2 will have group5 in it,
but your local token on machine1 still will not.

That is exactly what I need to do. I like to do it
efficiently minimizing the possible searches for every
group and then each member in that group.

If you need every group membership in every domain regardless of scope,
you will need to query at least one DC in every domain at least once.
Depending on group nesting and other variables it could be more, far more.


There is no magic query that will get you all group memberships. About
the best is the tokenGroups attribute but that has an affinity of the
local domain and universal groups (assuming you queried a GC).


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Guest]

Thanks a lot, Joe.
It is one of the most comprehensive description I can find in any of the
microsoft documents regarding AD 'Cross-Domain' case. Your response ought to
be published for ADS general user. Our banking software product uses the
groups that a user is a member to figure out the assigned roles for a user.
The roles are specific for our product. I believe there are many software
products out there to retrieve the application specific authorization
information like this. In this scenario, it is important that at user login
time, we need to retrieve all the groups that the user is a member of very
efficiently.
Based on the information in your response, I am able to make a direction for
our product and our customers:
1. Our software will authenticate the user against the user login DC.
2. Upon a successful login, I will get the user object from GCs, and
retrieve the groups that this user is member of.
3. This logic only works for universal groups. We will advise our customer
that our product will only support the universal groups in cross-domain case.
Even though some customer may not be happy with this, I don't think this
will become a big issue because I see the native mode ADS is a trend that
most of our customers are heading.

Thanks again for your help.
jinjkim

 

[Joe Richards [MVP]]

I would recommend you NOT force a requirement of universal groups. I
know several large companies (Fortune 25 and bigger) which have very
explicit policies to not use Universal/Global groups due to their scopes
and only allow Domain Local Groups and no product is good enough to make
them change that policy. Making your product only work with a specific
group type will limit your customer base.

You should have a preference and then have a configuration that works
with the other group scopes in some limited fashion. Depending on how
your app is authenticating (please tell me it ISN'T using LDAP binds)
then you should be able to have the token for the auth'ed user available
and so you don't have to worry about scopes, just indicate that that is
how you get the info and if the group isn't in the token, it won't work
with your app.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Guest]

Thanks, Joe, for your comments. Our product, more precisely, the product I
inherited, is Java based, and run on Tomcat. It has its own proprietary
authentication and ACLs, and uses JNI to access ADSI. I agree that most of
the customers have their own security policy, and it is next to impossible to
change it. But, in our product case, the roles are defined very specific for
our product, and don't need to be mixed with the customer's usual business.
So, hope that limiting to 'universal group' for those specific roles would
not breach their usual business security practice, and would simplify the
management. (We do not want to end up with trouble-shooting hundred customers
who may have all sorts of configured DC combinations.) Having said that,
glancing some documents on Windows 2003 R2 or ADAM reveals that Microsoft has
made a good stride on security subject, and in the future, when I have an
opportunity, I am willing to use them.
I have one question though. In your response, you seems to prefer not to use
LDAP binding for authentication. Unfortunately, that is what we are currently
using in our product. During the user authentication, we simply need to know
whether the user credential is present in the logon domain. We could probably
use core Windows authentication interfaces such as 'LsaLogonUser()' too, but
it may be too heavy for our product at this time which is not a pure
Microsoft technology based. On top of that, as explained in your previous
response, the resulting token may not contain all the groups and may only
contains the membership that is in scope.

Thanks,
jinjkim

 

[Joe Richards [MVP]]

Well I think having lots of different DC configurations is pretty much a
fact of life for any AD aware app unless you leverage ADAM. You can say
what you want it to look like but customers can also decide that they
don't want to do it and that is a customer you lose. I know at least one
Fortune 5 right now that you would list that requirement and you would
be back out the door, there wouldn't even be a conversation. There are
several other Fortune 25 and bigger companies that fit the same thing.
Their thought is that you don't change the environment to fit the apps
and it is a valid way to do things because every app can want something
different. If you need anything outside of your product, I would
recommend that you be very flexible up front or else you will not have
the opportunity to get some customers and some customers may just beat
your sales staff / CEO such that you have to change later which will be
much more difficult and likely expensive.

Yes I am not a fan of LDAP authentication... LDAP isn't an
authentication protocol. Most folks that do it do it poorly and you end
up seeing clear text simple binds. SSL makes it a little better but
still folks who are managing the DCs or the server the app is running on
still have the opportunity to see the clear text passwords. This is not
the same as having the ability to crack into accounts normally, this is
additional exposure that allows bad things to happen that
logging/auditing will have a tough time working out.

If you just need to know if the user exists in the domain and you don't
need to verify their password, that doesn't require authenticating the
user over LDAP, have a service ID query AD for the user.


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[RBot]

Joe

I have a question for you that I think you can answer. I could really
use your help on this one, as I have been unable to find anybody who
can give any.

I am using Event Log Explorer to create filters to view certain logs in

saved event log files. Everything works perfectly and I get exactly
the information that I am looking for out of each log; HOWEVER, I have
come to notice that if any changes are made to user or computer
accounts using the Active Directory Remote Management tool, it is not
logged the same as when I make the changes in Active Directory while
logged into the server. (As a matter of fact, I am unable to find any
logs for the changes whatsoever).
Just so you know where I am coming from, here is an example:
Lets say that a new account is created with the name of "TestAccount"
by user "AccountCreator" at 12:30am on 12/25/1955. I can go into Event

Log Explorer, load the event log from the specified date, and apply a
filter to show me all important changes for the day (a filter that I
have setup that filters by Event ID), and get this output:
Event ID 624
User Account Created:
New Account Name: TestAccount
New Domain: TestDomain
New Account ID: TestDomain\TestAccount
Caller User Name: Account Creator
Caller Domain: TestDomain
When I create a new account using Active Directory Remote Management
tool, I don't get an Event ID 624, and all other events that show up at

the time of setup are either unreadable, or do not have anything to do
with a new user account.
My question is, is there another Event ID that replaces Event ID 624
(if so I will need one to replace many others as well that I can
elaborate on in the future), or, is there a way to DISABLE Active
Directory Remote Management on the servers so I know that all new users

or computers in the domain will show up in Event Viewer. (reports are
used to verify that we have paperwork for all new users created, and if

one shows up in Event Viewer that we don't have paperwork for, it is a
problem. This becomes useless if one can bypass Event Viewer by using
Active Directory Remote Management)

Any advice would be greatly appreciated. Thank you.
Robert Jacobs e-mail: (e-mail address removed)

 

[Joe Richards [MVP]]

My expectation is that when it is done remotely, it is done against a
different DC so the DC you are looking at doesn't get the audit entries.
The audit entries should be generated regardless of how you do it.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[RBot]

Thanks Joe,

I actually am only using one DC (this is in a test lab right now). I
am sure that the audit entries ARE being generated, however they may be
labeled differently and contain different information. Since I am
unable to find any documentation on where these entries are located, do
you know of any way to completely disable Active Directory Remote
Management on the server so nobody can make any changes to user or
computer accounts unless logged in directly to the server? This isn't
what I would like to do, but security is a much bigger factor now that
the company I work for has gone public and we are required to meet
different Hippa and SOX regulations. Any help at all would be
appreciated, again.

Thank you,
Robert Jacobs

 

[Joe Richards [MVP]]

You would have to stop all outside access to the DC. Block all RPC and
LDAP, basically make the DC worthless, and then if you weren't careful,
you would also make it so you can't manage it locally. The same
interfaces are used either way. Again, the audit events should be the same.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm