Domain join with IPSec activated
Regarding some rare articles on the Internet, it should be possible to join a client to a domain using a regular domain join, whenever IPSec is activated on the domain controllers - as far as the OS of all participating hosts is Windows Server 2008 and Windows Vista or higher. For that I've to use the NTLMv2 authentication, which is new in this OS versions.I just created a connection security rule, which requires authentication for all inbound communication with the NTLMv2 protocol. I have added the NTLMv2 computer authentication (optional) and as the second method I have added the NTLMv2 user authentication (NOT optional). Further I created a inbound firewall rule for any traffic, which says "allow". With this configuration, it's not possible for me, to join a client to the domain. In my test lab I've got just one DC (W2K8) and one client (Windows 7).The client is not even able, to ask the DNS service on the DC about the domain information. Yes: I understand this - but the articles telling me, that it would work under Vista and higher. So: What I'm doing wrong and what I missed to configure? In one of the rare articles, they are writing something like: "By enabling the new feature in IPSec for Windows Vista and Windows Server 2008 that automatically determines when to use IPSec, you no longer havve to configure exemptions for domain controllers, simplifying IPSec policy and deplayment of IPSec protection in a domain." - WHICH feature AND HOW TO enable it???Thanks a lot for clarification and help!Regards,cal77
March 1st, 2010 1:19am

Hi, Based on my testing, it seems that the client computer will use the logon credential for user NTLM authentication. Therefore, we need to create a domain user account with the same user name and password as the user with which you logon the client computer. The following are the detailed steps for your reference: 1. Run the commands below to create the connection security rules on both the client computer and DC:Netsh advfirewall consec add rule name=”TCP 389” endpoint1=172.16.0.11/24 endpoint2=172.16.0.16/24 action=requireinrequestout port1=389 port2=any protocol=tcp auth1=anonymous auth2=userntlmNetsh advfirewall consec add rule name=”UDP 389” endpoint1=172.16.0.11/24 endpoint2=172.16.0.16/24 action=requireinrequestout port1=389 port2=any protocol=udp auth1=anonymous auth2=userntlm 2. Create a domain user account with the same user name and password as the local user with which you logon the client computer. 3. Logon the client computer with the local user account. 4. Join to the domain. Thanks. This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
March 2nd, 2010 12:41pm

Hi Joson,Thanks a lot for your explanation! Like this it is working, BUT: I like to protect my domain controller for ANY traffic (authenticated). If I add another connection security rule, which says authentication to any traffic, I can't join the domain...Do you have an idea to solve the whole scenario?Cheers,Andre
March 2nd, 2010 2:50pm

Hi, Thank you for your patience. To protect all traffic on DC by using IPSec, I am afraid that you need to create a rule for each port that is need for domain join. For example: ICMP exemption (optional) Add rule name=”ICMP Exemption” endpoint1=any endpoint2=any action=noauthentication protocol=icmpv4 All traffic; REQUIRE inbound, request outbound Add rule name=”all traffic” endpoint1=any endpoint2=any action=requireinrequestout auth1=anonymous auth2=userntlm LDAP; required inbound, request outbound Add rule name=”TCP 389” endpoint1=any endpoint2=any action=requireinrequestout port1=any port2=389 protocol=tcp auth1=anonymous auth2=userntlm Add rule name=”UDP 389” endpoint1=any endpoint2=any action=requireinrequestout port1=any port2=389 protocol=udp auth1=anonymous auth2=userntlm DNS … For the detail of the port requirement, please refer to the following article: Service overview and network port requirements for the Windows Server system http://support.microsoft.com/kb/832017/ Thanks. This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
March 4th, 2010 1:01pm

Hi Joson,Thanks a lot for your reply! For me, this sounds very complicated... Regarding the following article: http://technet.microsoft.com/en-us/library/bb726965.aspx it should be kind of easier to accomplish that:<-- snipp --> Client-to-DC IPsec Protection For Windows Server 2003 and Windows XP, Microsoft does not support IPsec to protect traffic between domain controllers and member computers (however, Microsoft does support protecting traffic between domain controllers). This is because the IPsec policy configuration can become very complex due to the different types of traffic sent between domain members and domain controllers. Additionally, there is a domain join issue. If the domain controller requires IPsec-protected traffic from computers that must provide domain-based credentials for authentication, a computer that is not a member of the domain cannot contact a domain controller to join the domain. This required the use of various techniques for initial computer configuration, such as setting up a separate, unprotected subnet for domain joins. Windows Server 2008 and Windows Vista supports securing traffic between domain members and domain controllers in the following deployment modes: You can configure IPsec policy in the domain to request protected traffic but not require it. Domain controllers will protect most traffic with domain members but allow clear text for domain joins and other types of traffic. You can configure IPsec policy to require protected traffic for domain controllers. Domain controllers are configured with IPsec settings that allow the use of Windows NT/LAN Manager version 2 (NTLM v2) user credentials for authentication. When a computer running Windows Server 2008 or Windows Vista attempts to join the domain, the user is prompted for the user name and password of a domain user account. IPsec protection with the domain controller is negotiated with Windows NT/LAN Manager version 2 (NTLM v2) user credentials for a protected domain join. This new behavior is only available for domain member computers running either Windows Vista or Windows Server 2008 and for domain controllers running Windows Server 2008. Because of the new negotiation behavior, you no longer have to configure exemptions for domain controllers, simplifying IPsec policy and deployment of IPsec protection in a domain.<-- snipp -->What do you think about this?Thanks a lot for your reply!Cheers,Andre
March 4th, 2010 1:56pm

something else:If I create those rules: - Add rule name=”all traffic” endpoint1=any endpoint2=any action=requireinrequestout auth1=anonymous auth2=userntlm - Add rule name=”TCP 389” endpoint1=any endpoint2=any action=requireinrequestout port1=any port2=389 protocol=tcp auth1=anonymous auth2=userntlm Is this really necessary? The first rule ("all traffic") already includes the second rule with a specific port, the same authentication method, etc. In my test lab, I just created the first rule, which doesn't work anyhow...Thanks a lot for any hint!Cheers,André
Free Windows Admin Tool Kit Click here and download it now
March 7th, 2010 9:06pm

Hi,The second rule is required for a non-domain joined client computer to locate a DC. Based on my test, the "all traffic" rule will not work for the non-domain joined client computer. We will have to create a rule for each port that is required for domain join. Regarding the article you mentioned, it is correct that the new feature such as NTLMv2 simplifies the deployment of client-to-DC IPSec protection. The behavior in Windows XP/Windows Server 2003 used to be that IPsec policies had to include large numbers of port exemptions for all DC’s in the enterprise or they had to exempt the full IP addresses of all the DC’s in the enterprise. With the inclusion of new AuthIP support for authentication options such as NTLMv2, many of the previous limitations to client to DC IPsec security have been removed. However, there remains some caveats that requires some additional rules or exemptions.Thanks. This posting is provided "AS IS" with no warranties, and confers no rights.
March 8th, 2010 11:37am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics