DNS Name resolution between two untrusted forests
I am installing SCCM in two untrusted forests as part of a single sccm site. I have two forests one with internet connectivity (forest A) and the second without internet connectivity (Forest B)
sccm components installed in both forests use certificated and ad user accounts for communication and authentication.
to resolve names between two forests I can create conditional forwarders. but for security reasons I don't have an issue to create a conditional forwarder from Forest B to Forest A. but I do not want to create conditional forwarder from forest A which has internet connectivity to Forest B. but still be able to reach domain controlllers and sccm servers in the other forest.
without creating conditional forwarding is there a way to resolve names of only specific coomputers in the other forest. I don't want users in the forest that have internet access to resolve names of all servers in forest B. I need this only for a few servers.
sccm components installed in both forests use certificated and ad user accounts for communication and authentication.
to resolve names between two forests I can create conditional forwarders. but for security reasons I don't have an issue to create a conditional forwarder from Forest B to Forest A. but I do not want to create conditional forwarder from forest A which has internet connectivity to Forest B. but still be able to reach domain controlllers and sccm servers in the other forest.
without creating conditional forwarding is there a way to resolve names of only specific coomputers in the other forest. I don't want users in the forest that have internet access to resolve names of all servers in forest B. I need this only for a few servers.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I think you're going to have to either create conditional forwarders for each specific host that you want to be able to resolve, or create manual A records in a new zone.
You'll find you'll also need to create a zone of Forest B on the DNS server in Forest A, which means you'll have a split brain DNS for Forest B. (And in that case: yes, you'll be creating A records.)
If you'll be attempting to reach the domain controllers in the B forest and use domain controller type services there, be aware that there are a fair number of SRV records in the _msdcs.<domain>, _sites.<domain, _tcp.<domain>, and _udp.<domain>. You might want to consider scripting the creation of those records in Forest A, or delegating those 'subzones' back to Forest B so the domain controller services work correctly.
If you'll be attempting to reach the domain controllers in the B forest and use domain controller type services there, be aware that there are a fair number of SRV records in the _msdcs.<domain>, _sites.<domain, _tcp.<domain>, and _udp.<domain>. You might want to consider scripting the creation of those records in Forest A, or delegating those 'subzones' back to Forest B so the domain controller services work correctly.
How about a different approach.
Spin up a new DNS server, not AD integrated, and add each of the forest zones as stub zones, point SCCM at this DNS server to get full resolution of both forests while everything else just uses their normal DNS servers
The new DNS server does not need to be a dedicated server, you could add it as a role on your SCCM server(s)
Spin up a new DNS server, not AD integrated, and add each of the forest zones as stub zones, point SCCM at this DNS server to get full resolution of both forests while everything else just uses their normal DNS servers
The new DNS server does not need to be a dedicated server, you could add it as a role on your SCCM server(s)
OP said...
without creating conditional forwarding is there a way to resolve names of only specific coomputers in the other forest. I don't want users in the forest that have internet access to resolve names of all servers in forest B. I need this only for a few servers.
Clarify please:
Or you need all the users in Forest A to see a few of the servers in Forest B?
[...]I need this only for a few servers.Need a few servers from Forest A to see all the servers in Forest B?
Or you need all the users in Forest A to see a few of the servers in Forest B?
conditional forwarders from domain B that does not have internet access to Domain A that has internet access is allowed. but they don't want me to create a conditional forwarder from domain A to domain B. but I will have SCCM servers authenticate to servers in domain B using user accounts in domain B. i.e they do not want to open port 53 in this direction from domain A to domain B. so I need to find a mechanism that I am able to resolve names locally without forwarding requests to domain B, .
so maybe I can create a primary zone for domain B in domain A and add dns records manually. but how about srv records that clients use to discover services. maybe I can export the zone and import it or something like this. Is this the best solution or do I have other options
so maybe I can create a primary zone for domain B in domain A and add dns records manually. but how about srv records that clients use to discover services. maybe I can export the zone and import it or something like this. Is this the best solution or do I have other options
stub zone is like conditional forwarder which is again going to forward requests to domain controllers in domain B. so I don't think stub zone will solve my issue
I think they dont want full-blown conditional forwarders for the whole domain. You can conditionally forward for a subdomain though which is really just conditionally forwarding for the hostnames you want in the remote domain, so you get over the split-DNS issues while only allowing resolution for select servers.
See what I mean?
See what I mean?
I think you have missed my point, which was that you can add DNS servers that are only accessed by the SCCM server(s), if this DNS server just hosts stub zones, the overhead is minimal, and you could have it installed on the SCCM server(s)
but sccm is member of a domain and its primary dns server is pointing to a domain controller that had the dns server role. even if I install dns on the sccm server and create a stub zone, the sccm still goes to the domain controller for name resoultion
I want sccm servers in forest A to be able to resolve names in forest B. I don't want clients in forest A to be able to resolve names in forest B.
I think you have missed my point, which was that you can add DNS servers that are only accessed by the SCCM server(s), if this DNS server just hosts stub zones, the overhead is minimal, and you could have it installed on the SCCM server(s)
but sccm is member of a domain and its primary dns server is pointing to a domain controller that had the dns server role. even if I install dns on the sccm server and create a stub zone, the sccm still goes to the domain controller for name resoultion
You can't forward queries from A to B, but are you allowed to perform a zone transfer from B to A, or from B to something reachable by the SCCM servers in A? If so, I'll throw in with a slight modification of ArneLovius's suggestion:
- Create that additional DNS server and configure the SCCM servers to use only it for DNS. (Add more than one DNS server for redundancy if you want to avoid a single point of failure.)
- On that DNS server, create a secondary zone for forest B's lookup zone (and another one for _msdcs if it's a separate zone), then configure the zone transfer on the other side.
- Finally, configure a simple forwarder on the new DNS server to forward all other queries to forest A's DNS servers, so that the SCCM servers can still locate their domain controllers. Queries for external resources from the SCCM servers will take an extra hop, but that's trivial.
- Configure the firewall on the new DNS server(s) to allow queries only from the SCCM servers so that other machines in forest A won't be able to use it to resolve names in forest B.
You absolutely can use conditional forwarders to resolve from A to B, and in this scenario it would be recommended. As I said earlier, you can create a conditional forwarder in the same way in which you would implement a pinpoint zone, in that you can forward conditionally for specific hostnames by adding a conditional forwarder for each host individually.
Have a look at this article...
http://blogs.msmvps.com/acefekay/2012/09/18/what-should-i-use-a-stub-conditional-forwader-forwarder-or-secondary-zone/
To quote the link...
Have a look at this article...
http://blogs.msmvps.com/acefekay/2012/09/18/what-should-i-use-a-stub-conditional-forwader-forwarder-or-secondary-zone/
To quote the link...
Stub Zone
Organizations own their own AD zones. When business partners need to resolve data at a partner’s organization, there are a few options to support this requirement. Years ago, prior to Stub or Conditional Forwarders, there weren’t many options to handle this other than to use Secondary Zones and keep copies of each others zones via zone transfers. While the solution worked well in regards to name resolution, it was not the best security-wise, due to trust level between partners, because zone data is fully exposed at the partner. This became a security concern because the partner is able to see all of their business partner’s records. When the zone was transferred to partners, who knows what they were doing with the information. If the information was made public, attackers would have a field day with all of the IPs for the networked devices.
When stub zones were made available, it became a solution to overcome this security issue. What is also beneficial about Stubs, is you can AD integrate them instead of manually creating a Stub on each indivdual DC. THis way the zone will be available domain or forest-wide, depending on replication scope.
However, some may say due to the fact that the SOA records are included in the zone file, it may be a concern that the SOA and NS data is exposed. In such high security concerns, the better solution would be to use a Conditional forwarder.
===
Conditional Forwarder
This option is heavily used, and many look at them as the best regarding security concerns with zone data exposure, because no data is exposed. This option has worked very well in many environments.
With Conditional Forwarders, no information is being transerred and shared. The only thing you would need to know is one or more of your business partner’s DNS server IPs to configure it, and they don’t have to be the SOA, rather any DNS server that hosts the zone or that has a reference to the zone.
However, it does require open communication and let each other know when their DNS server IPs may change, because you must manually set them.
Windows 2003 introduced Conditional Forwarders, but it did not have the option to make it AD Integrated. If you have 10 DNS servers, you must create the Conditional Forwarder on each server manually. The AD integrated option was added to Windows 2008 or newer DNS servers, so you don’t have to manually create them on each DNS server. THis way the Conditional Forwarder will be available domain or forest-wide.
You absolutely can use conditional forwarders to resolve from A to B, and in this scenario it would be recommended.
You can, yes, but it sounds like the higher-ups in the OP's environment don't want that for whatever reason:
but they don't want me to create a conditional forwarder from domain A to domain B.
I understand that completely, but they don't want FULL forwarding per zone. Using conditional forwarders for full hostnames doesn't allow queries for the full zone; just the specific hosts that SCCM wants. That fulfils the requirements IMO.
Any other way either allows full resolution of the zone or requires manual synchronisation. My way doesn't :-)
Any other way either allows full resolution of the zone or requires manual synchronisation. My way doesn't :-)
Sure. Unfortunately, I don't think forwarding of any queries from A to B, even FQDN-specific ones, is an option, because they don't want port 53 opened at all in that direction:
they do not want to open port 53 in this direction from domain A to domain B
It has to be unless you create manual records or manually replicate the zone.
There, question solved. ;-)
There, question solved. ;-)
Now that you mention it, my suggestion won't work either. The secondary server won't be able to query the primary to initiate a zone transfer without port 53 being opened in that direction...unless the secondary server is isolated, and they don't mind opening the port from it to the primary.
Before deleting the question, you should provide more information on why the suggestions already provided won't work. If they don't fit your situation, that's fine, but it would be helpful to us to know why this is the case. It may also be helpful to someone else in a similar situation in the future.
Also, bear in mind that restrictions in the environment (e.g., blocking port 53) sometimes make certain things impossible to accomplish. In that case, "It can't be done" is a perfectly valid answer.
Also, bear in mind that restrictions in the environment (e.g., blocking port 53) sometimes make certain things impossible to accomplish. In that case, "It can't be done" is a perfectly valid answer.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial