Discussion:
sysvol replication breaks when IPSec running between DCs & firewal
(too old to reply)
brad
2009-01-16 02:00:01 UTC
Permalink
-- Greetings,

I am using an IPSec policy to enforce the use of IPSec for all communication
between domain controllers. The appropriate security associations are showing
up in the IPSec monitor and each domain controller can ping the other one.
Active directory synchs OK. I can add or delete or disable an account on one
DC and the changes show up right away on the others.

Theoretically, when all traffic between DCs is IPSec, you only have to open
the firewall for ports required by IPSec, and everything will work .
However, I am having trouble with Sysvol replication. Sysvol will not
replicate as long as the firewall is enabled on the DC with the PDC role. I
have the following rule in the Windows Firewall to enable IPSec traffic to
pass:

50:ip protocol:*:enabled:IPSec ESP
51:ip protocol:*:enabled:IPSec AH

We have two root DCs and three child domain DCs. Sysvol works fine on the
child domain. Since it was not working on the root domain, I configured a
static port for FRS, as per KB319553 and enabled that port on all DCs. That
did not solve the problem. Actually, that step should not have been necessary
anyway since all traffic is between DCs is already encapsulated with IPSec.

Summary: 5 domain controllers, all using IPSec, all firewalls configured
identically, yet one server's firewall, when enabled, breaks replication of
sysvol for root domain. Sysvol replication works OK for child domain but not
for root domain.

It would seem that the problem lies with the firewall configuration on the
DC with the PDC role. However, if the firewall was misconfigured, it seems
that no traffic at all could pass between the two root DCs, since all traffic
must use IPSec.


QUestions:
(1) DO I have the syntax correct for the Windows firewall rule to allow
IPSec traffic to pass?
(2) If not, how is it that IPSec is working on all 5 DCs?
(3) On Windows 2003 Server SP2 ; does IPSec traffic bypass the firewall by
default? I do not have the "Windows Firewall:Allow authenticated IPSec
bypass" policy configured.
(4) Would the above-mentioned policy setting be the best way to get around
this problem? If so, I need some help with the SDDL string. My DCs are in an
OU but not in a group. Must I create a group for them in order to be able to
have an SID for the SDDL?


bb
Meinolf Weber [MVP-DS]
2009-01-16 09:10:26 UTC
Permalink
Hello bRad,

Also have a look here about UDP port 500:
http://support.microsoft.com/kb/233256/

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

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
Post by brad
Theoretically, when all traffic between DCs is IPSec, you only have to
open the firewall for ports required by IPSec, and everything will
work . However, I am having trouble with Sysvol replication. Sysvol
will not replicate as long as the firewall is enabled on the DC with
the PDC role. I have the following rule in the Windows Firewall to
50:ip protocol:*:enabled:IPSec ESP
51:ip protocol:*:enabled:IPSec AH
We have two root DCs and three child domain DCs. Sysvol works fine on
the child domain. Since it was not working on the root domain, I
configured a static port for FRS, as per KB319553 and enabled that
port on all DCs. That did not solve the problem. Actually, that step
should not have been necessary anyway since all traffic is between DCs
is already encapsulated with IPSec.
Summary: 5 domain controllers, all using IPSec, all firewalls
configured identically, yet one server's firewall, when enabled,
breaks replication of sysvol for root domain. Sysvol replication works
OK for child domain but not for root domain.
It would seem that the problem lies with the firewall configuration on
the DC with the PDC role. However, if the firewall was misconfigured,
it seems that no traffic at all could pass between the two root DCs,
since all traffic must use IPSec.
(1) DO I have the syntax correct for the Windows firewall rule to allow
IPSec traffic to pass?
(2) If not, how is it that IPSec is working on all 5 DCs?
(3) On Windows 2003 Server SP2 ; does IPSec traffic bypass the
firewall by
default? I do not have the "Windows Firewall:Allow authenticated IPSec
bypass" policy configured.
(4) Would the above-mentioned policy setting be the best way to get around
this problem? If so, I need some help with the SDDL string. My DCs are in an
OU but not in a group. Must I create a group for them in order to be able to
have an SID for the SDDL?
bb
Miles Li [MSFT]
2009-01-16 11:33:25 UTC
Permalink
Hello,

Thank you for posting here.

According to your description, I understand that:

The FRS replication between DCs blocks when you enable the IPSec to encrypt
network traffic between DCs.

If I have misunderstood the problem, please don't hesitate to let me know.

Suggestions:
========================
(1) DO I have the syntax correct for the Windows firewall rule to allow
IPSec traffic to pass?
(2) If not, how is it that IPSec is working on all 5 DCs?
(3) On Windows 2003 Server SP2 ; does IPSec traffic bypass the firewall by
default? I do not have the "Windows Firewall:Allow authenticated IPSec
bypass" policy configured.

Answer: From my knowledge, the IPsec exists underneath the Windows Firewall
(IPnat.sys). IPsec is in the network layer below ICF or Windows Firewall.
IKE is layered above ICF or Windows Firewall. Because of this, ICF or
Windows Firewall should statically permit IKE (UDP port 500) inbound, and
will not see IPsec AH or ESP protocols, but the TCP or UDP traffic after
IPsec has decapsulated it in the receive processing. If IPsec blocks
traffic, the ICF or Windows Firewall dropped packet log will not contain
the packets that IPsec discarded.

811832 IPsec default exemptions can be used to bypass IPsec protection
in Some Scenarios
http://support.microsoft.com/default.aspx?scid=kb;EN-US;811832



(4) Would the above-mentioned policy setting be the best way to get around
this problem? If so, I need some help with the SDDL string. My DCs are in
an OU but not in a group. Must I create a group for them in order to be
able to have an SID for the SDDL?

Answer: To isolate the issue to verify whether the issue is related to
IPSec or Windows Firewall, you may try to temporarily disable the Windows
Firewall on all DCs to check how it work. If the issue is related to the
Windows Firewall, you may configure the "Windows Firewall:Allow
authenticated IPSec bypass" policy to bypass the IPsec traffic for Domain
Controller group. You can input the SDDL string such as:

O:DDG:DDD:(A;;RCGW;;;S-1-5-<yourname_ID>-516)

Please replace the S-1-5-<yourname_ID>-516 with the SID of the domain
controllers group in your domain. A SID with RID 516 is the well known SID
for domain controller group in the domain.

For more SDDL Syntax information, you may refer to:

SDDL Syntax
http://www.washington.edu/computing/support/windows/UWdomains/SDDL.html

Please understand that in Windows Server 2003 DC IPsec between DCs are not
recommended. It will result in lots of unexpected errors. Moreover, if you
want to enable the Window firewall on the DC, you may have to configure AD
and FRS to use a specific port on the RPC traffic. For more detailed
information, you may refer to:

555381 How to configure Windows Server 2003 SP1 firewall
for a Domain Controller
http://support.microsoft.com/kb/555381

Hope it helps. If you have any questions or concerns, please do not
hesitate to let me know.




Best regards,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
brad
2009-01-16 19:49:04 UTC
Permalink
Miles,

thank you very much for your responses. I'm sorry but I still do not have a
full grasp of what needs to be done so I am writing to clarify my needs and
to ask more questions.

I am trying to implement the "encapsulate domain controller traffic inside
IPSec" as per as per Steve Riley

http://technet.microsoft.com/en-us/library/bb727063.aspx

Riley says" For IPSec replication and IPSec or PPTP promotion, configure
your firewall to permit the following."

IPSec ESP, encapsulated security payload
IP protocol 50

IPSec AH, authenticated header
IP protocol 51


The problem is, I do not know the syntax for allowing exceptions for IP
protocols. Since IP Protocols use a protocol ID number instead of port
numbers, I do not know how to write a firewall rule to ensure that IP
Protocols 50 and 51 are allowed through the firewall. I need to know how to
define a port exception in a group policy for these two IP Protocols. I know
how to write the rules for TCP and UDP but not for IP Protocol. Can you
please spell out for me exactly how to write the necessary firewall rules?

Not to confuse things, but Riley seems to contradict what you say about
IPSec ESP and AH protocols not being seen by the firewall. Are you saying
that I do not need to worry about creating the rules because these bypass the
firewall anyway?

Riley says you can "Encapsulate domain controller (DC-to-DC) traffic inside
IP Security Protocol (IPSec) and open the firewall for that", so that is what
I would like to do. However, if I can't get IPSec to work through the
firewall, I would be quite happy to configure it to bypass the firewall, but
I am also running into an issue with that.

I don't know what the SID of the domain controllers group is. Our domain
controllers are not in a GROUP, they are in an OU, so how can I find out what
the domain controller group SID is? Must I create a group and put the domain
controllers in it? If I do that, what are the potential repercussions of
placing domain controllers in a group?

I appreciate your comment about not recommending IPSec for DCs but I think I
am getting it close, it is working for some of the DCs so I don't want to
have to back out now.

Thanks for your help!
--
bb
Post by Miles Li [MSFT]
Hello,
Thank you for posting here.
The FRS replication between DCs blocks when you enable the IPSec to encrypt
network traffic between DCs.
If I have misunderstood the problem, please don't hesitate to let me know.
========================
(1) DO I have the syntax correct for the Windows firewall rule to allow
IPSec traffic to pass?
(2) If not, how is it that IPSec is working on all 5 DCs?
(3) On Windows 2003 Server SP2 ; does IPSec traffic bypass the firewall by
default? I do not have the "Windows Firewall:Allow authenticated IPSec
bypass" policy configured.
Answer: From my knowledge, the IPsec exists underneath the Windows Firewall
(IPnat.sys). IPsec is in the network layer below ICF or Windows Firewall.
IKE is layered above ICF or Windows Firewall. Because of this, ICF or
Windows Firewall should statically permit IKE (UDP port 500) inbound, and
will not see IPsec AH or ESP protocols, but the TCP or UDP traffic after
IPsec has decapsulated it in the receive processing. If IPsec blocks
traffic, the ICF or Windows Firewall dropped packet log will not contain
the packets that IPsec discarded.
811832 IPsec default exemptions can be used to bypass IPsec protection
in Some Scenarios
http://support.microsoft.com/default.aspx?scid=kb;EN-US;811832
(4) Would the above-mentioned policy setting be the best way to get around
this problem? If so, I need some help with the SDDL string. My DCs are in
an OU but not in a group. Must I create a group for them in order to be
able to have an SID for the SDDL?
Answer: To isolate the issue to verify whether the issue is related to
IPSec or Windows Firewall, you may try to temporarily disable the Windows
Firewall on all DCs to check how it work. If the issue is related to the
Windows Firewall, you may configure the "Windows Firewall:Allow
authenticated IPSec bypass" policy to bypass the IPsec traffic for Domain
O:DDG:DDD:(A;;RCGW;;;S-1-5-<yourname_ID>-516)
Please replace the S-1-5-<yourname_ID>-516 with the SID of the domain
controllers group in your domain. A SID with RID 516 is the well known SID
for domain controller group in the domain.
SDDL Syntax
http://www.washington.edu/computing/support/windows/UWdomains/SDDL.html
Please understand that in Windows Server 2003 DC IPsec between DCs are not
recommended. It will result in lots of unexpected errors. Moreover, if you
want to enable the Window firewall on the DC, you may have to configure AD
and FRS to use a specific port on the RPC traffic. For more detailed
555381 How to configure Windows Server 2003 SP1 firewall
for a Domain Controller
http://support.microsoft.com/kb/555381
Hope it helps. If you have any questions or concerns, please do not
hesitate to let me know.
Best regards,
Miles Li
Microsoft Online Partner Support
Microsoft Global Technical Support Center
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Miles Li [MSFT]
2009-01-19 10:31:36 UTC
Permalink
Hello,

Thanks for the update.

Yes, to allow the IPSec traffic ports and protocols for IPSec should be
allowed on the network device. The "Firewall" mentioned in the TechNet
article means the firewall that lays between the 2 (or more) DCs that use
IPSec to encrypt the traffic instead of the Windows Firewall.

In the Windows TCP/IP Architecture, IPnat.sys (Windows firewall) is always
processed after IPsec.sys. You may check the following article to get an
idea of the Windows TCP/IP Packet Processing Paths.

The Cable Guy - June 2005--->TCP/IP Packet Processing Paths
http://technet.microsoft.com/en-us/library/bb878072.aspx

In this issue, I think the FRS traffic is blocked by the Windows Firewall.
You may have a test to temporarily disable the Windows Firewall on all DCs
to check how it works. In the scenarios that you need the Windows Firewall
enabled on the DC, you can enable the Windows Firewall:Allow authenticated
IPSec bypass" policy to bypass the IPsec traffic for Domain Controller
group in the Windows Firewall.

Hope it helps. If you have any questions or concerns, please do not
hesitate to let me know.


Best regards,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
brad
2009-01-20 03:15:01 UTC
Permalink
Miles,

OK, we are making progress. It is very helpful to know that the firewall in
question refers to a firewall between the DCs instead of the Windows
firewall. That clears up half of the problem. Would you be able to address
the other part of the question as well. Please re-read the part about SID of
the domain controllers group. The DCs are not in a group, they are in an OU.
Must I create a group for them? It is not customary to put DCs in a group so
I am not sure this is what is intended. Please clarify.

Thanks,
--
bb
Post by Miles Li [MSFT]
Hello,
Thanks for the update.
Yes, to allow the IPSec traffic ports and protocols for IPSec should be
allowed on the network device. The "Firewall" mentioned in the TechNet
article means the firewall that lays between the 2 (or more) DCs that use
IPSec to encrypt the traffic instead of the Windows Firewall.
In the Windows TCP/IP Architecture, IPnat.sys (Windows firewall) is always
processed after IPsec.sys. You may check the following article to get an
idea of the Windows TCP/IP Packet Processing Paths.
The Cable Guy - June 2005--->TCP/IP Packet Processing Paths
http://technet.microsoft.com/en-us/library/bb878072.aspx
In this issue, I think the FRS traffic is blocked by the Windows Firewall.
You may have a test to temporarily disable the Windows Firewall on all DCs
to check how it works. In the scenarios that you need the Windows Firewall
enabled on the DC, you can enable the Windows Firewall:Allow authenticated
IPSec bypass" policy to bypass the IPsec traffic for Domain Controller
group in the Windows Firewall.
Hope it helps. If you have any questions or concerns, please do not
hesitate to let me know.
Best regards,
Miles Li
Microsoft Online Partner Support
Microsoft Global Technical Support Center
Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Miles Li [MSFT]
2009-01-20 10:03:05 UTC
Permalink
Hello,

Thanks for the update.

By default, all domain controller in a domain should be the member of the
Domain Controllers global group. You can see the groups in the Users
container. The Domain Controllers global group is a built-in group that has
the well-know RID just as I mentioned in my last post. If you have domain
controllers in different domains of a forest, you can easily create a
universal group and add domain controllers group in each domain as its
member.

I hope these steps will give you some help. If you have any questions or
concerns, please do not hesitate to let me know.




Best regards,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Loading...