NAT issues trying to authenticate through an ASA to AD

Answered Question
Nov 6th, 2007

I am trying to authenticate from a DMZ host to an active directory server on the Inside. I have posted a clean configuration with everything I think that you will need to know. Basically I have opened all the correct ports for domain authentication (I think)... but I am still getting an error when I try to add the DMZ host to the domain.

The error I got and the lines I added for the AD authentication are in the txt file.

The deadline of this project was Monday, any help would be GREATLY appreciated.

Thanks,

Chris

I have this problem too.
0 votes
Correct Answer by JORGE RODRIGUEZ about 9 years 2 weeks ago

currection of acl and static above

AD = 192.168.5.100 ( Inside )

DMZ Host = 10.10.150.200 ( DMZ )

static (inside,DMZ) 192.168.5.100 192.168.5.100 netmask 255.255.255.255

access-list DMZ_access_in permit tcp host 10.10.150.200 host 192.168.5.100

access-list DMZ_access_in permit udp host 10.10.150.100 host 192.168.5.100

access-group DMZ_access_in in interface DMZ

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
JORGE RODRIGUEZ Wed, 11/07/2007 - 11:31

try changing your static NAT as " static (inside,DMZ) interface 192.168.1.xx netmask 255.255.255.255 " please test.

Rgds

Jorge

conversyschris Wed, 11/07/2007 - 11:49

So my Static statement for my DMZ server (static (Inside,DMZ) 10.10.xxx.xxx 192.168.x.xxx netmask 255.255.255.255) changed to "static (Inside,DMZ) interface 192.168.x.xx netmask 255.255.255.255"

so that will map my DMZ interface directly to that Inside server? Will that not affect all my other ACLs?

PS: Thanks a lot for responding, starting to sweat, the project is late

JORGE RODRIGUEZ Wed, 11/07/2007 - 12:45

Chris, please take my appologies, looking at the config :

your inside AD is under 192.168.x.x

DMZ host is 10.10.x.x

The 192.168.x.x should have a static NAT allocated address from the DMZ subnet, so the static should look as:

say you gave static NAT address for 192.168.x.x 10.10.x.y

static (isnide,DMZ ) 10.10.x.y 192.168.x.x netmask 255.255.255.0 0 0

and access list would look as:

access_list DMZ_access_in permit tcp host DMZ_HOST_IP 10.10.x.y eq 53

access-group DMZ_access_in in interface DMZ

conversyschris Thu, 11/08/2007 - 07:41

getting a bit confused at this point, thanks again for the help. lets just use fake IP addresses so I can get a better picture

10.10.150.200 is my DMZ host trying to authenticate

192.168.5.100 is my Active Directory server

So basically I have to create a new host IP address in the DMZ network for the Active Directory server to get back to the DMZ server?

static (inside,DMZ) 10.10.150.? (should this be a new IP address that I dont use in my network or the address of the actual DMZ host) 192.168.5.100 netmask 255.255.255.0 0 0

JORGE RODRIGUEZ Fri, 11/09/2007 - 10:46

Hi,

you could do it in two ways .

No1.

if you want to have DMZ to connect to AD with a NATed address and not the actual AD address so that AD actual IP address is hidden from DMZ you just have to give a nat address off the DMZ subnet that is available and use it for your AD server as NAT address on the DMZ side so that DMZ hosts will connect to AD NAT address instead of the actual inside address of your AD. If

10.10.150.200 is a regular physical host seating in your DMZ subnet trying to authenticate to AD 192.168.x.x allocate 10.10.150.115 that is not used off DMZ subnet and assign it to AD 192.168.x.x

in firewall NAT configuration.

example:

static (inside,DMZ) 10.10.150.115 192.168.x.x netmask 255.255.255.255 0 0

You could then create object group for TCP and another group for UDP ports

e.g

object-group service AD_PORTS_TCP tcp

port-object eq 53

port-object eq 445

port-object eq 389

port-object eq 88

etc..

object-group service AD_PORT udp

port-object eq 53

port-object eq 445

port-object eq 389

port-object eq 88

etc..

access list would be something like this:

access-list DMZ4_access_in permit tcp host 10.10.150.200 host 10.10.150.115 object-group AD_PORTS_TCP

access-list DMZ4_access_in permit udp host 10.10.150.200 host 10.10.150.115 object-group AD_PORT_UDP

access-group DMZ4_access_in in interface DMZ4

Or

No2.

By creating static nat to directly communicate from 10.10.150.200 to 192.168.x.x

static (inside,DMZ) 192.168.x.x 192.168.x.x netmask 255.255.255.255 0 0

access-list DMZ_access_in permit tcp host 10.10.150.200 host 192.168.x.x object-group AD_PORTS_TCP

access-list DMZ_access_in permit udp host 10.10.150.200 host 192.168.x.x object-group AD_PORT_UDP

access-group DMZ4_access_in in interface DMZ4

HTH

Jorge

conversyschris Wed, 11/14/2007 - 07:09

Hi Jorge,

Thanks for the response, unfortunately my problem isnt completely fixed but I think I am moving in the right direction. The DMZ host can now successfully query the DNS but I still cant actually join the domain.

The error on my host in Windows is:

A Domain Controller for the domain mydomain.com could not be

contacted. DNS was successfully queried for the service location (SRV)

resource record used to locate a domain controller for domain

mydomain.com:

The query was for the SRV record for _ldap._tcp.dc._msdcs.mydomain.com

The following domain controllers were identified by the query:

adservername.mydomainname.com

Common causes of this error include:

- Host (A) records that map the name of the domain controller to its

IP addresses are missing or contain incorrect addresses.

- Domain controllers registered in DNS are not connected to the

network or are not running.

For information about correcting this problem, click Help.

I also attached a clean configuration with the actual lines I added to my firewall configuration as well as the log that I was filtering based on the authentication hosts IP address. If you get a chance please take a look and see if you can come up with anything.

Thanks again,

Chris

JORGE RODRIGUEZ Wed, 11/14/2007 - 20:07

I tried to lab this out with a AD in inside same scenario as yours host in DMZ join AD domain inside interface and got same results, notice the output of your log once you try to add the host in DMZ to join the AD domain the client actualy sends UDP port 137 broadcast within same DZM subnet 10.10.yyy.255/137 expecting to find a server in DMZ to respond ,this is even though one have permitted all netbios-ns ports , I did a bit of a research but could not yet find out a workaround, hope someone in forum may jump in to comment while we seek for a solution.

7|Nov 14 2007 12:57:15|710005: UDP request discarded from 10.10.xxx.xxx/137 to DMZ:10.10.yyy.255/137

conversyschris Fri, 11/16/2007 - 06:05

No luck yet in terms of figuring it out. Tried editing a few things within my AD config and in the firewall, no luck unfortunately. Thanks again for the help, if I don't get this resolved by Monday we are calling in our Cisco consultant, hopefully I can come up with something before that.

Cheers,

Chris

JORGE RODRIGUEZ Fri, 11/16/2007 - 19:13

Chris Sorry for late reply, before you call someone else please try one more thing, re-do the whole access list and static entries. I believe this should work. I have not tested this but read some articles on AD and issues with Network Address Translations, so create a static as indicated bellow and re-create the access list, for sake of testing this implementation open up any any for tcp and udp and try adding the machine to the domain,if this proves to be successfull then be more granular with udp and tcp object-groups. This would be option 2 in my previous post as option 1 is out of question and not feasable with reagards to AD and NAT.

static (inside,DMZ) 192.168.1.100 192.168.1.100 netmask 255.255.255.255

access-list DMZ_access_in permit tcp host 10.10.150.200 host 10.168.100.50

access-list DMZ_access_in permit udp host 10.10.150.100 host 10.168.100.50

access-group DMZ_access_in in interface DMZ

Hope this should work, also download this arcticle from microsoft , the doc I was refering to on AD and Firewalls.

http://www.microsoft.com/downloads/details.aspx?familyid=C2EF3846-43F0-4CAF-9767-A9166368434E&displaylang=en

Let me know how it goes.

Rgds

Jorge

Correct Answer
JORGE RODRIGUEZ Sat, 11/17/2007 - 04:39

currection of acl and static above

AD = 192.168.5.100 ( Inside )

DMZ Host = 10.10.150.200 ( DMZ )

static (inside,DMZ) 192.168.5.100 192.168.5.100 netmask 255.255.255.255

access-list DMZ_access_in permit tcp host 10.10.150.200 host 192.168.5.100

access-list DMZ_access_in permit udp host 10.10.150.100 host 192.168.5.100

access-group DMZ_access_in in interface DMZ

conversyschris Mon, 11/19/2007 - 06:32

No luck again, I think that I may have found the command in the configuration that is messing things up though

nat (inside) 1 192.168.xxx.0 255.255.255.0

global (DMZ) 1 interface

So all addresses on my Inside subnet are PATd to the interface IP of my DMZ subnet, will the static mapping I entered over-ride this nat rule? This is the last thing I can think of that could be the issue.

Still getting the same error when I try to authenticate

Thanks,

Chris

JORGE RODRIGUEZ Mon, 11/19/2007 - 11:40

Hmm, that should have worked as there is not NAT involved when comming from DMZ to inside doing static(inside,DMZ) 192.168.5.100 192.168.5.100, I am not able to test this one as our AD has a static NAT but only for DNS on DMZ not authentication like in your case. Global (DMZ)1 interface will PAT traffic from inside hiting DMZ interface hosts it should not overwrite any rules becuase you don't have any that initiates from AD to DMZ host if IM not mistaking this far the acls are from DMZ to Inside AD.

One thing I want to throw in this issue is a bidirectional access list from DMZ host to AD host & vise versa.. let me know how you work out with the changes you have in mind.

Rgds

Jorge

conversyschris Mon, 11/19/2007 - 11:39

Jorje,

Its working! Not sure why but I just had to reboot the server that was trying to authenticate (I assume something was cached even though I tried flushing the DNS before that).

Thank you very much for all your help with this, no way I could have done it without you! I really appreciate it.

Cheers,

Chris

JORGE RODRIGUEZ Mon, 11/19/2007 - 11:47

Excellent, I was geting ready to do more thinking :-)

Good luck, we both learned in this one, Windows AD is another world.

Rgds

Jorge

Actions

This Discussion