The event being logged (shown below) by the KXRPC service seems to verify that this function can not resolve a DC for the specified domain.

Does anyone know a fix that would allow one to specify "ResourceDomain\LocalGroup" and have INGROUP work?

Master domain architecture
--------------------------------
;Test Script
? "HomeDrive = @HomeDrive"
?
if InGroup("ResourceDomain\Account Operators")
? "Is a member of ResourceDomain\Account Operators"
else
? "ResourceDomain\Account Operators return code = "
InGroup("ResourceDomain\Account Operators")
endif

if InGroup("\\pipsqueak\Account Operators")
? "Is a member of Pipsqueak\Account Operators"
else
? "Pipsqueak\Account Operators return code = "
InGroup("\\Pipsqueak\Account Operators")
endif

if InGroup("MasterDomain\Administrators")
? "Is a member of MasterDomain\Administrators"
endif
--------------------------------
Results:
HomeDrive = H:

ResourceDomain\Account Operators return code = 0
Is a member of Pipsqueak\Account Operators
Is a member of MasterDomain\Administrators
===================================

The above result is the same on both NT and Win9x.

The following error is logged on the MasterDomain DC:
Runtime info : (Error : The specified domain did not exist. (0x54b/1355) GetLocalGroups : failed to find a domain controller for ResourceDomain)

The ResourceDomain PDC is \\Pipsqueak

Howard A Bullock
Tyco Electronics

How you making out with this one ?

Your problem has me facinated and I'm trying like the dickens to find a similar environment over here to replicate your problem.

Just to clarify things alittle...

You have a master domain and a resource domain with full two way trust (or is there only a one-way trust with resource domain trusting master) ?

Your logging into a workstation that is joined to the resource domain with a master domain user account.

My gut feelings still says something to do with access violation. When you try this on Windows NT - you mentioned ingroup() returns a zero, what is the value of @ERROR ?

Shawn.

Master Domain
Resource Domain (one-way TRUST to Master Domain)
NT Workstation and Win9x Clients

I have added output of @ERROR to the test script for each INGROUP operation. The results are below.
---------------------------------------------
C:\Data\Scripts>kix32 test.kix

HomeDrive = H:

ResourceDomain\Account Operators return code = 0
Err: 1355
Is a member of Pipsqueak\Account Operators
Err: 0
Err: 1355
C:\Data\Scripts>net helpmsg 1355

The specified domain did not exist.
---------------------------------------------

I have added a trust from the master domain to the resource domain thereby creating a two-way trust. The result is the same.

@error = 1355 : The specified domain either does not exist or could not be contacted.

Do you have the name of the resource domain correct?

What domain are you logging on to.

I see that you added a second trust making it a complete 2 way trust. Did you wait for full replication before attempting the test?

Bryce

New result (The problem still exists, but the result are accurate):
C:\Data\Scripts>kix32 test.kix

HomeDrive = H:

DSS_Test\Account Operators return code = 0
Err: 1355
Is a member of Pipsqueak\Account Operators
Err: 0
Is a member of AMP01\Administrators
Err: 0
-------------------------------------------
Again the resource domain can not be found. The Resource domain PDC (Pipsqueak) works as well as the Master domain (AMP01).

I re-established the the two-way trusted forced syncronization on both domains and re-ran the test to get the above results.

OK - I wasn't able to replicate this over here...

Here's my setup...

I have a master domain and resource domain. A ONE-WAY trust exists where resource domain trusts master.

I joined the the master\user account to a resource domain local group called TESTING...

I logged onto a workstation that is joined to the resource domain with the master\user account...

Here's the results...

code:

---

break on
$RS = INGROUP ( "RESOURCE\TESTING" ) ; TRUE
?"RS=$RS ERROR=@ERROR @SERROR"
$RS = INGROUP ( "\\RESPDC\TESTING" ) ; TRUE
?"RS=$RS ERROR=@ERROR @SERROR"
$RS = INGROUP ( "RESOURCE\OTHER" ) ; FALSE
?"RS=$RS ERROR=@ERROR @SERROR"
exit
c:\>kix32 test.kix
RS=2 ERROR=0 The operation completed successfully.
RS=2 ERROR=0 The operation completed successfully.
RS=0 ERROR=0 The operation completed successfully.

---

If I got this right - you're problem seems to be releated to something in particular instance.

Has anyone else been able to verify this ?

Shawn.

[This message has been edited by Shawn (edited 19 September 2000).]

My testing circumstance was that I am presently running NT. My workstation is a member of ResDomain1 and the test pointed to a local group in ResDomain2. My test was not yielding the desired result because it was not designed properly. I will correct my test and verify this on both Win9x and NT. Thanks for the dialog.

For Win9x: the 1355 error results when the domain where the KXRPC is running does not trust the domain where the local group resides. This just so happens to be the standard configuration of the master domain model. KXRPC is running on the master domain where the resource domains trust the master, but the master domain does not trust the resource domains. This configuration can not resolve local group in the resource domain.

For NT: The situation is slightly different. Since NT uses pass throught authentication, an NT workstation in a resource domain can verify local group in the domain where it is a member because it has a trust to that domain via the secure channel. INGROUP on NT can not resolve the local group of another resource domain unless it's resource domain trusts the target resource domain. This particular aspect is not required. It was just included for discussion.

This sucks. The only apparent solutions are either to build a complete 2-way trusts from the master domain to each resource domain or have each client use KXRPC on its local domain server.

Thanks Shawn for the time you invested.

I have seen similar behavior in some of my Perl scripts with the Lanman::NetGetAnyDCName($server, $domain, \$dcname). The underlying API must only examine the TRUSTS (secure channels) that it has available.

A workstation can only see the DC to which it is connected. that DC can only see and resolve domains that it trusts. This really sucks.