«

I have a PIX 515e running 7.0(4)2, and for the most part, it works great.

We're putting a file server into the DMZ so that outside users will
be able log in to our Windows network and access files there, a NAS.
This means we have a Windows server in the DMZ, and when it boots,
(and in the future authenticates clients that login) will contact
a domain controller on the INSIDE of the PIX.

I've set up the configuration to allow the server in the DMZ to
communicate with the domain controller in the INSIDE, with the
the usual steps for access from a lower to higher security system.
That is:

static (inside,dmz) dmz_ip inside_ip netmask 255.255.255.255

And set up the global NAT so this works. I've done this lots of
times, configuring access to our servers from the OUTSIDE. And so
I'm sure that I've gotten basic access from the DMZ to the domain
controller on the INSIDE.

However, there is still an error in the Windows Event log when the
NAS server in the DMZ boots up, which is Windows error / Event 1054:

Windows cannot obtain the domain controller name for your
computer. (The specified domain either does no exist, or could
not be contacted) Group Policy processing aborted.

I looked up the error on the Microsoft site, and it suggests that
the NIC connection is fluctuating up and down. And suggests, among
other things, a different NIC card. I tried a new card, to no avail.
It appears that the PIX slows down the data exchange between the NAS
sever and the domain controller just enough to make the connection
look bogus. There are a couple of other errors, but they all stem from
not being able to connect up with the domain controller. And these
errors are critical, since they block user authentication, and thus
access to the files on the NAS.

Technically, this is really a Windows problem, since the PIX is passing
the packets between interfaces, (albeit slowly?) But I'm sure someone
out there has seen this error, because the obvious strategy is to put a
Web server in the DMZ that relies on a domain controller on the INSIDE.
And that creates exactly the same problem.

Thanks in advance for any help.

B Squared

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
When legendary Pop Warner coached the Carlisle Indians - a university
for native Americans - he'd try anything to motivate his players.
Minutes before a 1917 game with Army at West Point, Warner offered
his shortest and cleverest pep talk:
"Just remember. These are the boys who took your land."
Carlisle went on to massacre Army 28-0.

<B Squared> wrote in message
news:gq6dnezCIbqOL1bZnZ2dnUVZ_uudnZ2d@scnresearch. com...
>
> I have a PIX 515e running 7.0(4)2, and for the most part, it works great.
>
> We're putting a file server into the DMZ so that outside users will
> be able log in to our Windows network and access files there, a NAS.
> This means we have a Windows server in the DMZ, and when it boots,
> (and in the future authenticates clients that login) will contact
> a domain controller on the INSIDE of the PIX.
>
> I've set up the configuration to allow the server in the DMZ to
> communicate with the domain controller in the INSIDE, with the
> the usual steps for access from a lower to higher security system.
> That is:
>
> static (inside,dmz) dmz_ip inside_ip netmask 255.255.255.255
>
> And set up the global NAT so this works.

you do not need global and NAT statements when you have a static NAT ...

> I've done this lots of
> times, configuring access to our servers from the OUTSIDE. And so
> I'm sure that I've gotten basic access from the DMZ to the domain
> controller on the INSIDE.
>

What does your DMZ binded-ACL looks like ?
Are there any deny logs when you boot ?


> However, there is still an error in the Windows Event log when the
> NAS server in the DMZ boots up, which is Windows error / Event 1054:
>
> Windows cannot obtain the domain controller name for your
> computer. (The specified domain either does no exist, or could
> not be contacted) Group Policy processing aborted.
>
My guess is that some ports are being blocked.


HTH
Martin

Martin Bilgrav wrote:
> <B Squared> wrote in message
> news:gq6dnezCIbqOL1bZnZ2dnUVZ_uudnZ2d@scnresearch. com...
>
>>I have a PIX 515e running 7.0(4)2, and for the most part, it works great.
>>
>>We're putting a file server into the DMZ so that outside users will
>>be able log in to our Windows network and access files there, a NAS.
>>This means we have a Windows server in the DMZ, and when it boots,
>>(and in the future authenticates clients that login) will contact
>>a domain controller on the INSIDE of the PIX.
>>
>>I've set up the configuration to allow the server in the DMZ to
>>communicate with the domain controller in the INSIDE, with the
>>the usual steps for access from a lower to higher security system.
>>That is:
>>
>> static (inside,dmz) dmz_ip inside_ip netmask 255.255.255.255
>>
>>And set up the global NAT so this works.
>
>
> you do not need global and NAT statements when you have a static NAT ...

Good point. The global and NAT statements are for other outbound
traffic, and aren't relevant to this problem.
>
> What does your DMZ binded-ACL looks like ?

Excellent question... I'm using this:

access_list dmz_inside permit ip any any
access_list dmz_inside permit icmp any any

access_group dmz_inside in interface dmz

It turns out Windows actually uses icmp to boot from a domain
controller, so I've openned it as well.

> Are there any deny logs when you boot ?

What deny logs are you thinking of? And where do I read them?

>>However, there is still an error in the Windows Event log when the
>>NAS server in the DMZ boots up, which is Windows error / Event 1054:
>>
>> Windows cannot obtain the domain controller name for your
>> computer. (The specified domain either does no exist, or could
>> not be contacted) Group Policy processing aborted.
>>
>
> My guess is that some ports are being blocked.

This was my guess as well. Which is why I openned up the access list
to be permit any any. Later on, I'll use a more restrictive list, but
for testing, I didn't want to worry about blocked ports.

B Squared

<B Squared> wrote in message
news:zeednXxgdJ5l31HZnZ2dnUVZ_s6dnZ2d@scnresearch. com...

>> What does your DMZ binded-ACL looks like ?
>
> Excellent question... I'm using this:
>
> access_list dmz_inside permit ip any any
> access_list dmz_inside permit icmp any any
>
> access_group dmz_inside in interface dmz
>
> It turns out Windows actually uses icmp to boot from a domain
> controller, so I've openned it as well.


permit IP any any ... includes ICMP aswell ...

show access-l will not show any hits on the ICMP acl line 2.


>
>> Are there any deny logs when you boot ?
>
> What deny logs are you thinking of? And where do I read them?

logg mon deb (CR)
term mon (CR)
will show you EVERYTHING going on in the firewall.
depending upon your traffic rates this could be a extra load on your
firewall.
use with caution before apply.


do a
logg mon war
term mon
will show you only warning - hence all the denied log entries.

>
>>>However, there is still an error in the Windows Event log when the
>>>NAS server in the DMZ boots up, which is Windows error / Event 1054:
>>>
>>> Windows cannot obtain the domain controller name for your
>>> computer. (The specified domain either does no exist, or could
>>> not be contacted) Group Policy processing aborted.
>>>
>>
>> My guess is that some ports are being blocked.
>
> This was my guess as well. Which is why I openned up the access list
> to be permit any any. Later on, I'll use a more restrictive list, but
> for testing, I didn't want to worry about blocked ports.

My sec. guess:
What sort of switch is the DMZ server's NIC connecting to ?
If fx its a Cisco or other managed switch running STP the ports might not be
set to spanningtree portfast, causeing a huge delay in AD bound traffic,
which interms might cause timeout, hence your eventlog.
Or the switch and NIC could have speed/duplex mismatch, resulting in poor
performance.
Check and then check again your Layer 1+2 connection.
When you are done, get someone to verify your findings.


Regards
Martin Bilgrav




>
> B Squared
>
>

Might be stating the obvious, but can the server in the DMZ locate the
DC's using DNS?

Maybe run dcdiag or netdiag on the problem server.

http://support.microsoft.com/kb/321708

dcdiag /test:registerindns /dnsdomain
dcdiag /test:connectivity

Hope this helps.

Might be stating the obvious, but can the server in the DMZ locate the
DC's using DNS?

Maybe run dcdiag or netdiag on the problem server.

http://support.microsoft.com/kb/321708

dcdiag /test:registerindns /dnsdomain
dcdiag /test:connectivity

Hope this helps.