Scenario: We have a resource forest/domain which contains our KMS host. We are trying to protect it by using server isolation as outlined in this document (http://technet.microsoft.com/en-us/library/cc723923.aspx). We are trying to make it so that only domain computers (including those in all trusts) are the only ones that can activate against our KMS server. I've setup a two-way forest trust between the resource forest and a 2nd forest that contains the KMS clients. If I create a connection security rule to require inbound and request outbound authentication then none of the clients can connect. If I remove the rule then the clients can activate with no issue. I've verified the trust is working as I can assign resources from each domain to the other and access them with no issue (with security rule off). Is is possible to use a connection security rule requiring authentication across a forest trust? I'm running this in a test setup so all servers are Windows 2008 R2 and all clients are Windows 7 Enterprise. I don't see any obvious errors in event viewer on either the KMS host or clients otherwise I would post them here. Any links to documentation or suggestions are greatly appreciated.

Hi, According to the article, multiple AD forests is supported by server isolation. To better understand the issue, please help confirm the following: 1. Has the IPSec policy (Connection Security Rule) been applied to all the KMS clients and KMS host? 2. Can the KMS clients in the same forest as the KMS host access the server? 3. Do you select the Computer (Kerberos V5) option on the Authentication Method page of the New Connection Security Rule Wizard? Meanwhile, after the policy being applied, please run gpresult /z on a KMS client and the KMS host and then post the output of the command here for research. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,How's everything going? We've not heard back from you in a few days and wanted to check the current status of the issue. If you need further assistance, please do not hesitate to respond back.Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Joson,Thanks for the reply. Answers to your questions are below1. Yes the IPSec policy has been applied to both the server and the client. It was done via the Windows Firewall MMC and not via a group policy.2. No, KMS clients in the same domain and forest cannot access the KMS host3. Yes, Computer (Kerberos V5) option was selected.Since the settings were not applied with group policy I didn't run the gpresult tool. If you still need me to run it let me know. I did notice some events in the event viewer and posted them below. Maybe my rule is not configured properly? Although it is setup like the screenshots in the documentation, I could be missing something.Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 12/28/2009 10:28:18 AMEvent ID: 4963Task Category: IPsec DriverLevel: InformationKeywords: Audit FailureUser: N/AComputer: KMSHOST.domain.localDescription:IPsec dropped an inbound clear text packet that should have been secured. If the remote computer is configured with a Request Outbound IPsec policy, this might be benign and expected. This can also be caused by the remote computer changing its IPsec policy without informing this computer. This could also be a spoofing attack attempt. Remote Network Address: <KMSClient IP>Inbound SA SPI: 0 Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 12/28/2009 10:28:18 AMEvent ID: 5152Task Category: Filtering Platform Packet DropLevel: InformationKeywords: Audit FailureUser: N/AComputer: KMSHOST.domain.localDescription:The Windows Filtering Platform has blocked a packet. Application Information: Process ID: 1856 Application Name: \device\harddiskvolume2\windows\system32\sppsvc.exe Network Information: Direction: Inbound Source Address: <KMS Client IP> Source Port: 54636 Destination Address: <KMS Host IP> Destination Port: 1688 Protocol: 6 Filter Information: Filter Run-Time ID: 76488 Layer Name: Receive/Accept Layer Run-Time ID: 44 Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 12/28/2009 10:28:18 AMEvent ID: 5157Task Category: Filtering Platform ConnectionLevel: InformationKeywords: Audit FailureUser: N/AComputer: KMSHOST.domain.localDescription:The Windows Filtering Platform has blocked a connection. Application Information: Process ID: 1856 Application Name: \device\harddiskvolume2\windows\system32\sppsvc.exe Network Information: Direction: Inbound Source Address: <KMS Host IP> Source Port: 1688 Destination Address: <KMS Client IP> Destination Port: 54636 Protocol: 6 Filter Information: Filter Run-Time ID: 76488 Layer Name: Receive/Accept Layer Run-Time ID: 44

Hi,The port 1688 is the default port of KMS. It seems that there is something wrong with the firewall settings. When the issue occurs, do you see any entries in Windows Firewall with Advanced Security\Monitoring\Connection Security Rules, Main Mode, and Quick Mode?Meanwhile, please export the Firewall policy on both the KMS host and a KMS client and upload the .wfw files to the following space for further research:https://sftasia.one.microsoft.com/choosetransfer.aspx?key=e2fd0aca-da11-4767-848b-ce6a3e39c309Password: rsnID6#3JPWpTThanks.This posting is provided "AS IS" with no warranties, and confers no rights.

The only entry I see in the Windows Firewall and Adv. Security areas is one for the KMS rule with a status of ok.I've uploaded both the KMS host and client policy exports.Thanks,Brian

Hi,Thanks for the information.From the .wfw files, I found that the IPSec policy on the KMS client does not match the one on the KMS server. Please change the "Endpoint 2 port" to 1688 (now is Any) in the IPSec policy on the KMS client and check if the issue can be resolved.If there is anything unclear, pleaes feel free to let me know. I look forward to your response.This posting is provided "AS IS" with no warranties, and confers no rights.

Wow, good catch. That seems to have resolved the issue. The isolation appears to be working as expected.Thanks for your support !!Regards,Brian

Glad to hear that. Have a nice day.Joson ZhouTechNet Subscriber Support in forumIf you have any feedback on our support, please contact tngfb@microsoft.com This posting is provided "AS IS" with no warranties, and confers no rights.