Permissions for domains separated by a firewall

[John Coke]

Posting here is kind of a defeat for me, I wished that I could have
found the answer to this on my own. My thanks in advance. On to the
issue

I have a WS 2003 domain with an administrative root and 3 children.
One child is in the DMZ, one on an internal segment and one at another
location (not important right now). I would like to populate ACLs on
DMZ member server resources with groups from the internal domain for
administration. The DMZ and the INTERNAL domains are separated by a
firewall. When I attempt to assign permissions on the DMZ member
server, the firewall separating the two domains logs denys from the
DMZ member server to the INTERNAL DC. DMZ and INTERNAL are each in
their own sites and I was under the impression that the "flow" for
this should go through the DMZ DC and not directly to the INTERNAL DC.

That said, is there a way to force this behavior? Again, thank you.

Regards,
-John

 

[Tim Springston \(MSFT\)]

Hi John-

If you have not already, you need to set AD sites and then add subnets to
associate with the respective sites.

Once the DMZ server is aware (by it's subnet) that it is in the same AD site
as a particular DC it will establish a secure channel with the DC in it's
own site in preference to other DCs. As you are probably already aware,
this is all configurable in AD Sites and Services (DSSITE.MSC).

When Windows 2000, 2003 and XP machines try to find a domain controller they
query
DNS for site specific SRV (Service Locator Records) that are in their AD
site
(which is defined by an IP subnet or subnets that those domain controllers
which reside in that site are using).

A possible scenario (if I wanted Member Server A to have a secure channel to
DC
A) would be to give them both the same IP subnet and put DC A in Site A.

The only problem there is that if DC A has a problem or fails to respond
normally or quickly to an authentication request from Member Server A then
the
member server would attempt to find a different DC to create a secure
channel
to. This can be circumvented by specifying the CloseSiteTimeout entry in
the
registry to a very high length of time. The CloseSiteTimeout registry entry
governs how long a machine will tolerate a timeout before attempting to find
a
new DC to create a secure channel with. I have included more information on
that below.
****************************************
Cache Time-out and Closest Site

If a domain member computer requests a domain controller while all domain
controllers in its site are offline, the Locator necessarily returns a
domain
controller in a different site. The location of this domain controller is
stored in the client cache. The cache lifetime is controlled by the
CloseSiteTimeout entry in the registry.

In addition, the domain controller performs authentication, and a secure
channel is set up. On subsequent location attempts, the lifetime of the
cache
and the lifetime of the secure channel are secondary to the location of a
domain controller in the closest site.

If the domain controller that is stored in the client cache is not in a site
that is close to the client, Net Logon attempts to find a close domain
controller when either of the following events occurs:

An interactive logon process uses pass-through authentication on the secure
channel.

The value in the CloseSiteTimeout registry entry has elapsed since the last
attempt, and any other attempt is made to use the secure channel (for
example,
pass-through authentication of network logons).

Thus, Net Logon attempts to find a close domain controller only on demand.
The
default value of the CloseSiteTimeout period is 15 minutes; the maximum
value
is 49 days, and the minimum value is 60 seconds. The implications of this
setting are that if the time-out value is too large, a client never tries to
find a close domain controller if there is not one available at startup. If
the value of this setting is too small, secure channel traffic is
unnecessarily slowed down by discovery attempts.

For more information about creating the CloseSiteTimeout entry, see the
Microsoft Windows 2000 Resource Kit Technical Reference to the Windows 2000
Registry (Regentry.chm).
**********************
Please repost if this does not help.

 

[John Coke]

Tim,
I should clarify and say that there is no DC for internal.domain.com
in the DMZ site. Let me give you the real world example. I have a
group of web guys that need log on locally privileges on their web
server that is on dmz.domain.com. Their user accounts are on an
internal domain and when I attempt to add their internal.domain.com
group to the policy it cannot load it (the group) because the
dmz.domain.com member server is trying to pull the group off of a
server that it cannot talk directly to (the internal.domain.com DC).

So is this a behavior that I cannot change? Does every dmz.domain.com
member server have to be able to connect directly to the
internal.domain.com's DCs in order to place internal.domain.com
users/groups into ACLs/policies on dmz.domain.com member servers?
Thank you Tim.

-John