DMZ's uses can't join DC located inside ASA 7.2

balsheikh · ‎08-25-2007

Hi,

I have a concern related to DC (Domain Controller) located into DMZ on ASA running 7.2.

The scenario as following, all LAN segments reside behind the ASA's inside interface as well as the DC server, I have a bunch of branches connected all the way to my DMZ interface and accessed the DC with NATted IP address from the DMZ subnet.

The branch's user can't join the domain and they saw the DC with its real IP (inside IP) not the translated one, I overcome the problem by statically configured the DC to be shown with its real IP on DMZ and this solve the issue and users joined the domain smoothly.

How could I solve the issue and keep the DC shown with NATted IP on DMZ !!

Regards,

JORGE RODRIGUEZ · ‎08-25-2007

Hi Belal, Im not quite sure.. you indicated you have a DC located in the DMZ where also your branches connect to DMZ, but then you said your branches cannot access the DC natted IP address. How many DC do you have? one in the DMZ interface and one in the Inside interface or just one in the inside?

Lets assume you only have one Domain Controller in the Inside interface and you have given a NAT IP pertaining to DMZ, what you need to do is create a one-to-one static nat and create access-list to allow access between the DMZ and the inside DC so your users/branches can authenticate to the DC in the inside interface.

can you post config? strip out public IP info.

Thx

Jorge

Jorge Rodriguez

balsheikh · ‎08-26-2007

Hi Jorge,

Let me brief the picture clearly, the DC in the inside interface and the branches coming from DMZ interface.

Previous setup, DC configured with one-to-one static nat and ACL to grant the access to the DC. I can ping it and connected to it remotely (RDP) but users can't join the domain.

static (inside,Co-operate) 172.20.150.10 10.100.150.10 netmask 255.255.255.255

access-list Co-operate-ACL extended permit ip 172.20.0.0 255.255.0.0 any

Current setup, I disabled the natting for DC

static (inside,Co-operate) 10.100.150.10 10.100.150.10 netmask 255.255.255.255

access-list Co-operate-ACL extended permit ip 172.20.0.0 255.255.0.0 any

Regards,

JORGE RODRIGUEZ · ‎08-26-2007

ok,

DC Inside IP: 10.100.150.10, given IP for NAT Co-operative: 172.20.150.10

This should work.

static (inside,Co-operate) 172.20.150.10 10.100.150.10 netmask 255.255.255.255

access-list Co-operate_access_in permit tcp any host 172.20.150.10

access-group Co-operate_access_in in interface Co-operate

Users comming from co-operate interface will point to 172.20.150.10 to joing domain .

Jorge Rodriguez

o-campbell · ‎08-26-2007

Sounds like a DNS issue. Host on DMZ point to AD DNS servers which are resolving the DNS address of login AD server as the internal IP. The PIX 6.X code supported an alias command which allowed the PIX to overwrite information in DNS reply packets to change the addresses seen by clients. An example is below.

alias (DMZ) 10.100.150.10 172.20.150.10 255.255.255.255

This would overwrite DNS replies to dns clients on the DMZ interface containing 10.100.150.10 with the NAT'ed address 172.20.150.10.

HTH

anandramapathy · ‎08-27-2007

Turn on ASDM logging in the ADM, Logging options.

Check the ASDM Log what is happening when the users try to login to the DC.

Otherwise use the Packet tracer to find out where your packet is getting blocked.

Also check if you are hitting a bug like me. I was suggested to upgrade to 5.2(3) which sloved the issue

CSCsi89890

Externally found moderate defect: Verified (V)

nat-exempt failed on non-outside interface

balsheikh · ‎08-28-2007

Hi Jorge,

Trust me it's not a translation or permission issue, as HTH said it's a DNS resolution issue.

I had investigated deeply in this case and found a methodology called DNS Doctoring may help me to get it work as planned, I need a time for testing and I'll get back to you with the last result.

Have you configured DNS Doctoring before !! I believe it's a key for the solution..

Regards,

Belal

JORGE RODRIGUEZ · ‎08-28-2007

Hey Betal, I see, but if this is a dns issue you would also be experiencing dns issues on all other interfaces including inside/outside..

I would do one more last thing in ammending in my previous acl allowing udp 53 domain from Co-operate

access-list Co-operate_access_in permit udp any eq 53 host 172.20.150.10

access-group Co-operate_access_in in interface Co-operate

I have not run into dns issues yet and have not implemented dns doctoring before, it is a matter of reading how to implemented.

Did you try Owen's post above adding an Alias?

Jorge Rodriguez