This article describes two possible causes of IPSec policy related event 1091 and event 1085 being generated intermittently in Event Viewer.
The descriptions of IPSec policy related event 1091 and event 1085 is as follows:
Event ID 1091:
Windows could not record the Resultant Set of Policy (RSoP) information for the Group Policy extension<IP Security>. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately.
Event ID 1085:
Windows failed to apply the IP Security settings. IP Security settings might have its own log file. Please click on the “More information” link.
Scenario One:
Symptom:
We configure the IPSec policy, assign it in GPOs, and publish the policy to machines. However, this policy can’t be applied and event 1091 and event 1085 keep being logged in Event Viewers on these machines.
Possible Cause:
This can be caused by the fact that the targeted machines do not have enough permissions to access the IPSec policy container. For machines to apply IPSec policies, they need to haveRead, Read All Properties, and List Contents permissions on the IPsec container underAD Users and Computers.
Solution:
Step 1: open Active Directory Users & Computers
Step 2: click View, choose Advanced Features
Step 3: go to <Domain>\System\IP Security
Step 4: select IP Security container, right click it and choose
Properties, go to the Security tab, and check whether the targeted machines are in the list underGroup or user names
Step 5: If these machines aren’t in the list, add these machines and allow them appropriate permissions.
For example, for domain computers to apply IPSec polices, they should be allowed permissions as shown in Figure 1:
Figure 1 IP Security Properties
Scenario Two:
Symptom:
In Active Directory environment, there is no IPSec policy being assigned or we assign a new IPSec policy but this new policy can’t get applied to the targeted machines, and both event 1091 and event 1085 keep being logged in Event Viewer with regular
intervals on these machines.
Possible cause:
This can happen if we delete an IPSec policy without un-assigning the IPSec policy. There may be other policies which are linked to the deleted IPSec policy object. We can assign an IPSec policy in different GPOs, for it doesn’t belong to a specific
GPO.
Solution:
To verify whether this is the cause to the issue we experience, log on to the problematic machine and go to the following registry path (Figure 2):
HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\GPTIPSECPolicy
Figure 2 GPTIPSECPolicy
In Figure 2, we find that the Data of DSIPSECPolicyName is New IP Security Policy (1). If we open IPSec policy editing snap-in (Figure 3) from any GPO on a Domain Controller,
however, we don’t see this IPSec Policy.
Computer Configuration\Policies\Windows Settings\Security Settings\IP Security Policies on Active Directory
Figure 3 IP Security Policies snap-in
This proves that there is an old IPSec policy named New IP Security Policy (1) which is still in place. In fact, if we delete the IPSec policy without un-assigning it, computers
in the Active Directory container to which the IPSec policy is assigned might treat the IPSec policy as if it cannot be located and continue to use a cached copy.
To fix the issue, we must find all the GPOs in which this deleted IPSec policy was assigned.
To do this, we can run the following command on CMD (Run as administrator):
ldifde –r “(objectClass=IpsecPolicy)” –f C:\ipsec.txt
This command will list out all the objects related to IPSec policy in the ipsec.txt (Figure 4). We can search the name New IP Security Policy (1) in the ipsec.txt.
Figure 4 ipsec.txt
In Figure 4, we find this name is a part of the following two objects:
dn: CN=IPSEC, CN=Windows, CN=Microsoft, CN=Machine, CN= {31B2F340-016D-11D2-945F-00C04FB984F9}, CN=Policies, CN=System, DC=*, DC=com
dn: CN=IPSEC, CN=Windows, CN=Microsoft, CN=Machine, CN= {6AC1786C-016F-11D2-945F-00C04FB984F9}, CN=Policies, CN=System, DC=*, DC=com
From CN=Policies, we can conclude that these two objects are GPOs. Besides, we can see the GUIDs of these two GPOs in the distinguished name (dn). As a result, we can utilize each GUID to identify its corresponding GPO.
An easy way to identify GPOs with their GUIDs is to use Powershell command, and we can run the command as follows:
Get-GPO –All | select displayname, id
This command will list the names and GUIDs of all GPOs (Figure 5) in our Active Directory environment.
Figure 5 Displaynames and GUIDs of GPOs
In Figure 5, it can tell that we once configured this IPSec policy in the default domain policy and default domain controller policy, for {31B2F340-016D-11D2-945F-00C04FB984F9}
is the GUID of default domain policy and {6AC1786C-016F-11D2945F-00C04FB984F9} is the GUID of default domain controller policy .
Now, to resolve the issue, we need assign another IPSec policy in all GPOs in which we assigned the deleted IPSec policy.
Using this case as an example, we perform the following steps:
1. Find an existing IPSec policy or create a new IPSec policy in any GPO
2. Assign this IPSec policy in both default domain policy object and default domain controller policy object.
3. Waiting after group policy getting updated on the problematic machines, un-assign this newly assigned IPSec policy in these two GPOs.