Can a single AD domain DC be used as the DC for multiple subdomains?

[Robert Gordon]

We currently have a single flat sunbet domain, with the name of company.com.
That subnet contains a Windows 2003 domain controller, with a DHCP server
and AD-integrated DDNS. Call this server dc1.company.com.

What I want to implement is a second subnet, named subnet.company.com, that
will be connected via a router. The new subnet will have it's own Windows
2000 DHCP server (call this server1.subnet.company.com). I want to have
this DHCP server authenticate to dc1.company.com, so that the AD-integrated
DDNS server on the dc1.company.com will have a subdomain on it for
subnet.company.com that gets updated when new DHCP clients register with the
DHCP server on server1.subnet.company.com. Obviously
server1.subnet.company.com would also point to dc1.company.com for it's DNS
look ups as well as would all clients on the second subnet.

Do I need to create subnet.company.com in AD, before I create the new
subnet? And if so, how do I delegate to any hosts in subnet.company.com
that they need to authenticate to the active directory server located on
dc1.company.com?

Does this makes sense? I'm jsut trying to avoid creating separate DCs for
each subnet. I want both subnets to authenticate to a single AD controller,
while still retaining a separate distiguishable domain name for each subnet.

Ideas?

 

[Herb Martin]

Nope. Not up to Win2003 but maybe in a future version.

What I want to implement is a second subnet, named subnet.company.com, that
will be connected via a router.

Subnet's don't really have "names" (that matter) except for identification
purposes
in tools like...

The new subnet will have it's own Windows
2000 DHCP server (call this server1.subnet.company.com).

....DHCP server where the SCOPE name is just so you can tell one scope from
another.

I want to have
this DHCP server authenticate to dc1.company.com,

DHCP is promiscuous and doesn't authenticate clients -- if you put it in a
domain
it needs to be AUTHORIZED (within the forest really.)

so that the AD-integrated
DDNS server on the dc1.company.com will have a subdomain on it for
subnet.company.com that gets updated when new DHCP clients register with the
DHCP server on server1.subnet.company.com.

Sound like you may be confusing DNS subdomains and zones with Active
Directory
Domain Controllers (DCs.)

Multiple DNS zones (for subdomains or even unrelated domains) can be on one
DNS server BUT only one AD Domain per DC.

Obviously
server1.subnet.company.com would also point to dc1.company.com for it's DNS
look ups as well as would all clients on the second subnet.

Subnet's don' t have names and are typically not used to define Domains.

Does this makes sense?

No. Not really.

I'm jsut trying to avoid creating separate DCs for each subnet.

THAT makes more sense.

Put them all in the SAME domain, company.com, with names like
DC1.company.com
etc.

I want both subnets to authenticate to a single AD controller,

That isn't completely controllable and you don't REALLY want that (probably)
since it defeats fault tolerance and much of the reason for having a
"Multimastered
Active Directory Domain".

while still retaining a separate distiguishable domain name for each

subnet.

Bad design probably -- what if you move them around later (DC and Domain
names
cannot be changed (until Win2003 and then not easily or always.)

 

[Michael Johnston [MSFT]]

What are you trying to accomplish by having seperate DNS names? Is there a technical reason for this? If you simply want machines to register in the child
DNS domain, this isn't a problem. There are two ways to have the clients register in the child DNS domain. Either change the primary DNS suffix of the client to
the child DNS domain you want the client to register within. The client will of course still need to be a member of the parent AD domain. You will also want to
make sure that the client has enabled to option to "Append parent suffixes of the primary DNS suffix". This will allow the client to find the AD. The second
option would be to create a connection specific DNS suffix on the client that points to the child DNS domain. Then check the option to "Use this connection's
DNS suffix in DNS registration". This will then force the client to register within the Child DNS domain. This may cause slow logon problems though since the
client will initially try to find the AD based on the child DNS domain. It will eventually fail over to the parent domain. This doesn't create a Child AD domain only
a child DNS domain name so all authentication to the domain goes to the parent AD domain DC. This certainly would not be recommended or supported.

Thank you,
Mike Johnston
Microsoft Network Support

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.