Re: Cross-Domain question (Parent - Child)

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]" wrote:

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


jinjkim wrote:
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]" wrote:

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


jinjkim wrote:
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


.

Relevant Pages

  • Re: Cross-Domain question (Parent - Child)
    ... I would recommend you NOT force a requirement of universal groups. ... 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. ... 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. ... If you logon to machine1, it doesn't matter to machine1 that you are in group5 on machine2. ...
    (microsoft.public.win2000.active_directory)
  • Re: Cross-Domain question (Parent - Child)
    ... 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. ... 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. ... 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. ... We will advise our customer that our product will only support the universal groups in cross-domain case. ...
    (microsoft.public.win2000.active_directory)
  • Re: LDAP Authentication from Linux
    ... As of Windows Server 2003 SP1, you must be a member of Authenticated Users to query Active Directory. ... So a limited account on the domain should have enough privileges to query it via LDAP if its properly bound. ... I'm trying to implement a secure authentication from an apache2 server across to my SBS2003 server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Cross-Domain question (Parent - Child)
    ... groups that a user is a member to figure out the assigned roles for a user. ... that our product will only support the universal groups in cross-domain case. ... query in a multidomain forest you may or may not see the value populated ... According to ADS documentation, in native mode, DomainA and ...
    (microsoft.public.win2000.active_directory)
  • Re: Cross-Domain question (Parent - Child)
    ... The member attribute is the forward link and the memberof attribute is the back link. ... 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. ... 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. ... If you logon to machine1, it doesn't matter to machine1 that you are in group5 on machine2. ...
    (microsoft.public.win2000.active_directory)