1. Problem enumerating group members with NT4 & trust domains
We have two domains, say DOMA and DOMB, and multiple sites with a
subnetted TCP/IP WAN between them.
Users running Windows 95 (mainly OSR2) always log into DOMA, which has
a PDC, several BDCs and several member servers at the central IT site,
and BDCs in each of the subnetted remote offices.
DOMB is just a resource domain. It has a PDC and BDC at the central IT
site (and no DCs or members servers in the remote offices).
There are two one-way trusts between DOMA and DOMB, and all domain
controllers are NT4 SP5.
Because a specific application written by the superusers in DOMB is
required to behave certain ways, and use certain directories and limit
user behaviours according to certain user privileges (such as which
state office they are in, what job function they have, etc), we decided
that ADSI could possibly be used to determine this (much like Kixtart
can determine InGroup membership in a login script) based on the NT
We don't really want to duplicate the groups e.g. if DOMA already has
a "STATE1" global group, then we'd rather just trust DOMA
administrators (a different department) to add/remove users to it, and
then we just include "DOMA\STATE1" global group into our STATE1 group
However, ADSI doesn't seem to be able to enumerate the cross-domain
group memberships or for that matter the cross-domain users belonging
So, if DOMA has an account called USER1, and DOMB also has an account
called USER1 (since USER1 might be an admin or developer on the
resource domain, and once in a while he likes to log onto both), then
the enumeration of the local group which has both as members might show
on User Manager for Domains (viewed from DOMB) as:
But from ADSI we just get
i.e. no (apparent) way to distinguish which domain the user or group is
Can anyone suggest how it might be possible to get the enumerated group
membership information so that it is able to distinguish which domain
the group or username comes from ?
It seems that something is missing - is this an oversight in the ADSI
We also find that a user on the subnetted WAN is unable to make ADSI
work (referencing objects in DOMB, the resource domain). At first he
couldn't log in to DOMB (as a test case), so we got him to change
LMHOSTS to specify the domain controllers for DOMB via #DOM tags (I
seem to recall that this is a possible Microsoft fix for subnetted
domains). I suspect that a static mapping of the domain in the WINS
servers for DOMA would also resolve this problem.
The LMHOSTS changes still don't let ADSI work across the subnetted
domain though. *MUST* it be a WINS thing ? The same user when logged
in at the central site (no subnetting) DOES work correctly. The same
user logged in via RAS to the central site DOESN'T work correctly.
Any ideas appreciated
Jason (ADSI newbie chucked in a the deep end)
Sent via Deja.com http://www.deja.com/
Before you buy.
2. connecting Eps. Print to Mustek Scanner.
3. Using ADSI to add group to another group across domain.
4. IADs movehere method
5. Adding member to group with more than 1,000 members
6. Pop mail reader and multi user machine
7. domain users group added, but members are denied access
8. fatal error
9. Adding ID from NT4 Trusted domain to W2K Domain through LDAP Provider and vbscript
10. ADSI,Group Members and C#
11. ADSI and mutliple domains - Adding a user from domain X into a group in domain Y
12. Getting members from group in C#
13. Can I add a group to a group using ADSI?