cross domain group policy question

  • Thread starter Thread starter Jay
  • Start date Start date
J

Jay

I have a parent domain, lu.edu, and a child domain, ac.lu.edu

My user accounts live in the parent (lu.edu) - I want my users to be able to
use their normal name/password to access a computer lab, where the client
computers are members of the ac.lu.edu domain. Right now I have an OU in
ac.lu.edu and a GPO applied to it. I am using loopback processing, since I
want to restrict the desktop regardless of which user logs on.

When I log on as a user from lu.edu it logs on OK, but I don't get the
loopback policy applied. If I log on to a user that lives in ac.lu.edu (as
a test) I get the loopback. Since the GPO applies to the computer object,
which is in the child domain, it seems to me this should work.

Thoughts?
 
It should work without issue. Check the security group filtering
of the GPO to make sure it is still at Authenticated Users. Perhaps
also check that the part of the GPO in sysvol can be read by the
Authenticated Users group instead of ac.lu.edu\domain users

Roger
 
Thanks, Roger.

That makes sense - I'll try that. Are there any relevant logs that might be
helpful?
 
I am getting an error on the client event log:

Windows cannot obtain the domain controller name for your computer network.
(The specified domain either does not exist or could not be contacted. ).
Group Policy processing aborted.

Here is my setup: the clients on ac.lu.edu have access to a DC/DNS server,
which is AD integrated for that zone. ac.lu.edu is the child domain of
lu.edu, but I don't want the clients on ac.lu.edu to be able to resolve all
my 'internal' systems, which are hosted on the lu.edu name servers.
Consider the following:

dc1.lu.edu

dc_ac.lu.edu

dc_ac.lu.edu has the zone for ac.lu.edu. dc1.lu.edu has the zone for lu.edu
and a delegated zone for ac.lu.edu, which points to dc_ac.lu.edu.

Does a client on the child domain have to be able to see the DCs (sysvol, I
would guess) of the parent to get this group policy config to work? I don't
really need to get the GPOs for the parent (the user) since I am using
loopback processing for all these workstations.

Thanks for any input.
 
MS says:

Replace mode
In this mode, the list of GPOs for the user is not gathered. Instead, only
the list of GPOs based on the computer object is used. The User
Configuration settings from this list are applied to the user.

MY GPO is set for REPLACE in loopback processing. It seems like the GP
processing on the client PC is indeed trying to get the GP info for the user
(which is in the parent domain, and not accessible). It then aborts. Is
there a 'on error rusume next' option. :)

Basically I want to set the 'user' options in a GPO to these clients but
allow them to authenticate using IDs that live in the parent domain. I
don't want to expose my parent DCs to these workstations, however.

Thoughts?
 
my userenv file looks like this:

USERENV(1d8.1dc) 15:03:28:361 Profile was loaded but the Ref Count is 1 !!!
USERENV(1d8.f0) 15:03:28:820 GetGPOInfo: Local GPO's gpt.ini is not
accessible, assuming default state.
USERENV(1d8.1dc) 15:04:25:235 UnloadUserProfileP: Didn't unload user profile
<err = 19>
USERENV(1d8.200) 15:04:38:064 ProcessGPOs: Loopback is not allowed for
downlevel or local user accounts. Loopback will be disabled.
USERENV(1d8.200) 15:04:38:064 GetGPOInfo: Local GPO's gpt.ini is not
accessible, assuming default state.
USERENV(1d8.1dc) 15:05:56:581 Profile was loaded but the Ref Count is 1 !!!
USERENV(1d8.7ac) 15:05:59:199 MyGetUserName: GetUserNameEx failed with
1355.
USERENV(1d8.7ac) 15:05:59:698 MyGetUserName: GetUserNameEx failed with
1355.
USERENV(1d8.7ac) 15:06:00:198 MyGetUserName: GetUserNameEx failed with
1355.
USERENV(1d8.7ac) 15:06:00:697 MyGetUserName: GetUserNameEx failed with
1355.
USERENV(1d8.7ac) 15:06:00:697 ProcessGPOs: MyGetUserName failed with 1355.
 
Jay said:
MS says:

Replace mode
In this mode, the list of GPOs for the user is not gathered. Instead, only
the list of GPOs based on the computer object is used. The User
Configuration settings from this list are applied to the user.

MY GPO is set for REPLACE in loopback processing. It seems like the GP
processing on the client PC is indeed trying to get the GP info for the
user (which is in the parent domain, and not accessible). It then aborts.
Is there a 'on error rusume next' option. :)

Basically I want to set the 'user' options in a GPO to these clients but
allow them to authenticate using IDs that live in the parent domain. I
don't want to expose my parent DCs to these workstations, however.

Thoughts?
Click to expand...

You do not have any choice. If those workstations are going
to authenticate an account of the other domain then they need
to be able to locate and speak on tcp ports with those DCs.

Roger
 
Roger,
I must disagree with you on one point. I CAN authenticate without being
able to talk to the parent DCs (I am doing it now). The clients can't
access SRV records for the parent domain and can't physically connect to the
parent DCs (due to the firewall).

However, I think you are 100% right about the group policy stuff. It isn't
going to let me use loopback processing because it wants to get the personal
GP information from the parent domain. :(

Would a trust work? Basically I want the DCs to be able to communicate, but
I'd rather not have the clients talking to my production DCs.

Thanks
 
Jay said:
Roger,
I must disagree with you on one point. I CAN authenticate without
being able to talk to the parent DCs (I am doing it now). The clients
can't access SRV records for the parent domain and can't physically
connect to the parent DCs (due to the firewall).

However, I think you are 100% right about the group policy stuff. It
isn't going to let me use loopback processing because it wants to get the
personal GP information from the parent domain. :(

Would a trust work? Basically I want the DCs to be able to communicate,
but I'd rather not have the clients talking to my production DCs.
Click to expand...

Well, that is all very interesting. I have always needed to make
sure the server of login (network) could contact the DCs of the
accounts' domain, else login for those accounts is no joy.

Keep in mind that DCs can also be located by LDAP against AD.
 
Jay said:
I appreciate your help, Roger. Back to the drawing board...
Click to expand...

Not a problem Jay.
AD in its basic design really is not too supportative of being
carved up into disjoint parts.
You might find some use for the domain segmentation concepts
that you will find mentioned in the MS docs about using IPsec
for domain isolation.

Roger
 
Back
Top