FWeston
asked on
Establishing trust to a Windows domain with no DNS suffix
I have two windows 2003 domains, one is called office and one is called dmz.local. I need to have dmz.local trust the office domain, but when I try to establish a new trust and type office for the domain name it says that it can't find it. These domains use the same DNS server but are on different networks, so I assume the lack of a DNS suffix is causing the problem. I can't figure out how to tell dmz.local where the DC for the office domain is. I've tried using the lmhosts file as such, but no success:
192.168.50.10 dc01 #PRE #DOM:office
192.168.50.10 dc01 #PRE #DOM:office
ASKER
Not sure what creating a secondary DNS zone accomplishes, or how to go about doing it. Please elaborate.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Chris-Dent:
If he allows the DMZ server to do a zone transfer doesn't that put the internal network DNS at risk? If the DMZ server is compromised then the attacker would have full DNS access to the internal network correct?
If he allows the DMZ server to do a zone transfer doesn't that put the internal network DNS at risk? If the DMZ server is compromised then the attacker would have full DNS access to the internal network correct?
The zone transfer is pretty harmless. It exposes a bit too much internal data, but that's still fairly difficult to use.
I had hoped that it wasn't really a DMZ, I disagree much more with forming a trust with something in a DMZ. Name resolution between the two is extremely mild by comparison.
I would also disagree with transferring a zone with AD data onto a server accessible (as a DNS Service) by the public.
Hmm although going back to the original question, I suspect I missed the bit where it states they are both using the same DNS Server. In which case it would be necessary to check that Office has the necessary DNS records registered. The problems associated with registering those is discussed in the article I posted above. Requires a bit of registry modification to allow it all to happen.
I guess that's what happens when I post after a bit too much of a long day at work ;)
Chris
I do computer security for a living and I know of a lot of compromises that can start with pulling sensitive internal information. Once you get on a system you can do a nslookup and use the ls -d switch to list all records and there are plenty of other tools that will easily retrieve DNS info. From my experience I don't agree that it is harmless.
As for the original question... what traffic are you allowing through the firewall to/from the other domain? (I hate to ask this as it can put your neck out on a block if you answer with too much info). If you know how, you may want to sniff the traffic to see what is getting though and what isn't.
As for the original question... what traffic are you allowing through the firewall to/from the other domain? (I hate to ask this as it can put your neck out on a block if you answer with too much info). If you know how, you may want to sniff the traffic to see what is getting though and what isn't.
It would be simpler to say that permitting any traffic at all from a DMZ to an internal network is bad practice. DMZs are isolated for a reason, poking holes in the firewall is just counter productive.
ls -d is moot as they share a DNS server, doesn't make it any better, just something that should be highlighted.
Chris
I agree, if they share a DNS server it's moot. Typically you see DNS segregated into 2 systems, one for public consumption and one for internal use. I also agree that, in general, it is a risk to allow traffic from a DMZ to the internal network but there can be mitigating controls to reduce that risk. Many companies allow traffic though and can make it relatively secure.
p.s. Make sure your DNS server is patched for the very recent cache poisoning vulnerability. Especially if the public has/will access to it.
FWeston:
I suspect that your traffic is being filtered by the firewall. But as Chris-Dent and I have been discussing, it is risky to allow your domain in the DMZ access to your internal network like that. If that is a risk you and your company are willing to accept then you may want to look at opening TCP/UDP 53 between the domains as well as the MS ports (135,139, 445, etc).
p.s. Make sure your DNS server is patched for the very recent cache poisoning vulnerability. Especially if the public has/will access to it.
FWeston:
I suspect that your traffic is being filtered by the firewall. But as Chris-Dent and I have been discussing, it is risky to allow your domain in the DMZ access to your internal network like that. If that is a risk you and your company are willing to accept then you may want to look at opening TCP/UDP 53 between the domains as well as the MS ports (135,139, 445, etc).
ASKER
Let me rephrase as what I originally stated is not 100% accurate. The two networks do not share a DNS server, but the domain controller in the DMZ is running DNS that forwards to one of our internal active directory DNS servers (DNS is only running in the DMZ so other machines there can find the DMZ AD domain).
For the time being, I have permitted full access from the DC in the DMZ to one of our internal DCs. It's easier to permit everything for now and then lock it down later. Since there is currently no traffic allowed inbound to anything in the DMZ from the Internet I don't see this as a risk. I should have noted that the DMZ is new, and not yet in production...there is presently only one server in it (the DC). The trust will only be one way...IE the DMZ domain trusts our internal domain but not vice versa. It had to be done this way for various database, sharepoint, etc permissions, so our internal users can access resources in the DMZ.
I tried setting up a secondary copy of our internal DNS zone on the DC in the DMZ....it copied over fine, but the DC still could not locate the internal domain to establish a trust.
For the time being, I have permitted full access from the DC in the DMZ to one of our internal DCs. It's easier to permit everything for now and then lock it down later. Since there is currently no traffic allowed inbound to anything in the DMZ from the Internet I don't see this as a risk. I should have noted that the DMZ is new, and not yet in production...there is presently only one server in it (the DC). The trust will only be one way...IE the DMZ domain trusts our internal domain but not vice versa. It had to be done this way for various database, sharepoint, etc permissions, so our internal users can access resources in the DMZ.
I tried setting up a secondary copy of our internal DNS zone on the DC in the DMZ....it copied over fine, but the DC still could not locate the internal domain to establish a trust.
The .office zone, does it contain service records for the office domain under _msdcs?
Chris
ASKER
Yes, under _msdcs, > domains, > ..... > _tcp it has service location records for the three domain controllers.
Single label domain names are always a lot of fun.
That said, you should be able to configure a Secondary zone in DNS for the name and have it transfer successfully. Moderately sure that's what I ended up doing last time I had to deal with one.
You can read about the restrictions on single-label domain names here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q300684
HTH
Chris