Solved

DNS Name resolution between two untrusted forests

Posted on 2016-08-22
22
79 Views
Last Modified: 2016-09-30
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.
0
Comment
Question by:Aamer-
  • 6
  • 5
  • 4
  • +3
22 Comments
 
LVL 45

Expert Comment

by:Craig Beck
ID: 41766496
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.
1
 
LVL 68

Expert Comment

by:Qlemo
ID: 41766516
+1 for manual A DNS records for B in A.
0
 
LVL 29

Expert Comment

by:Rich Weissler
ID: 41766712
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.
0
 
LVL 36

Expert Comment

by:ArneLovius
ID: 41766823
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)
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 41767007
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.
0
 
LVL 29

Expert Comment

by:Rich Weissler
ID: 41767063
Clarify please:
[...]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?
0
 

Author Comment

by:Aamer-
ID: 41767327
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
0
 

Author Comment

by:Aamer-
ID: 41767333
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
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 41767404
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?
0
 
LVL 36

Expert Comment

by:ArneLovius
ID: 41768339
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)
0
 

Author Comment

by:Aamer-
ID: 41772983
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
0
 

Author Comment

by:Aamer-
ID: 41772992
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.
0
 
LVL 25

Expert Comment

by:DrDave242
ID: 41775067
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.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 41775126
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...

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.
0
 
LVL 25

Expert Comment

by:DrDave242
ID: 41775216
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.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 41775259
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 :-)
0
 
LVL 25

Expert Comment

by:DrDave242
ID: 41775269
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
0
 
LVL 45

Accepted Solution

by:
Craig Beck earned 500 total points
ID: 41775303
It has to be unless you create manual records or manually replicate the zone.

There, question solved. ;-)
0
 
LVL 25

Expert Comment

by:DrDave242
ID: 41775328
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.
0
 
LVL 25

Expert Comment

by:DrDave242
ID: 41820140
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.
0
 
LVL 36

Expert Comment

by:ArneLovius
ID: 41820273
If there is a SCCM environment for both domains on just one domain, not allowing DNS lookups/transfer from the dedicated SCCM DNS server that I suggested and the Site B DNS Server seems like an artificial limitation.
0

Join & Write a Comment

BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
In this article, we will see the basic design consideration while designing a Multi-tenant web application in a simple manner. Though, many frameworks are available in the market to develop a multi - tenant application, but do they provide data, cod…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now