IPSec and Group Policy

[Bill Tomlinson]

I am trying to use Group Policy to apply IPSec policy to an Organizational
Unit and I am having difficulty getting it to work when logged into a
workstation as a standard domain user.

I have been following Article: KB313195 HOW TO: Use IPSec Monitor in
Windows 2000

Following this article I have logged into two W2k SP3 clients, in the same
W2k domain, as the local administrator, and set the Local Security Policy to
Assign one the IPSec-Client (Responds Only) modified policy (modified the
filter according to the article to 'require' security), and set the other
client's Local Security Policy to Assign the IPSec-Secure Server (modified
the filter according to the article to 'require' security) modified policy.

When I bring up the IPSecmon on each machine, the IPSecmon status window
shows: "IP security is enabled on this computer." When I open a cmd window
and use: ping -t [ipaddress of other client] the cmd window shows several
lines of "Negotiating IP security" and then the ping round trip information
starts to show up in the cmd until it is closed. The IPSecmon utility shows
the IPSec policy that is being used, and the packet counters increment with
each ping sent.

If I leave the Local Security IPSec policies assigned but logout as a local
administrator and login as a normal domain user, when I start the IPSecmon
utility it's status window shows: "IP security is not enabled on this
computer" and the same cmd ping test simply shows the normal round trip
statistics and the IPSecmon utility shows no policy or packet counters
incrementing. I am confused why the IPSec policy is no longer being used to
manage the same communication that was secured when I was logged is as an
Administrator. If I log back into the clients as a domain administrator I
can achieve the same results that I did as the Local Administrator; seems
like a permissions issue - not sure.

I have logged into each of the W2k workstations as the local administrator
and 'unassigned' the Local Security Policy IPSec policies; at that point
when I start the IPSecmon it's status window shows: "IP security is enabled
on this computer" but the ping test does not show the "Negotiating IP
security," and the packet counters do not increment with each ping sent.
This is confusing me, if the IP security is enabled, then where is it being
assigned? I have scoured the Site, AD OUs and Local Policies to ensure that
no IPSec policies are assigned anywhere, yet the IPSecmon shows it is
enabled, yet not being used for the ping test.

I am not sure if this is part of the problem I am having with trying to use
Group Policy to apply the IPSec policies.

I am trying to create the situation on these two workstations where the
IPSecmon status shows: "IP security is enabled on this computer," and the
ping test shows: "Negotiating IP security" and the IPSecmon's shows the
policy being used and the packet counters increment with each ping sent,
using Active Directory and Group Policies instead of Local Security Policy,
while logged in as a standard domain account user.

I have created two Group Policies, each one has an IPSec policy that has
been modified exactly as I did on my Local Security Policy example above,
and the modified IPSec policy has been assigned inside it's Group Policy. I
have linked each of these Group Policies to two different Active Directory
(AD) Organizational Units (OU), each one containing one of the domain user's
accounts I am using to log into the W2k clients with.

I get the same problem as when I logged to the workstation as a normal
domain user in the example above, the IPSecmon status window shows "IP
security is not enabled on this computer" and the ping test does not show
any "Negotiating IP security" and the IPSecmon shows no policy being used or
packet counter incrementing. My understanding is that when the domain
user's account is in an OU that has a Group Policy linked to it, when that
user logs into the client workstation it re-assigns the Group Policy, and
the IPSec policy that is part of the Group Policy. I have tried configuring
these Group Policies to "no override" and it had no effect.

I have even tried putting the two domain users accounts in the Domain
Administrator's group at the server level, and when I login to the
workstations and start the IPSecmon it's status window shows the same as
above when I turned off the Local Security IPSec policies: the IPSecmon
status window shows: "IP security is enabled on this computer" but the ping
test does not show the "Negotiating IP security," and the packet counters do
not increment with each ping sent.

Any help you could provide toward helping me understand how to get the IPSec
policy assigned, and to be in effect when a standard domain user is logged
in would be greatly appreciated.

BT

 

[Steven L Umbach]

Hi Bill. On your first question, I really do not know what the deal is
without being there and recreating the scenario. It sure sounds like a
permission problem, however ipsec policies are machine specific - not user.
That brings me to my next point. Since ipsec policies are part of machine
configuation in group policy you need to move those computers into those
OU's in order for the ipsec policy to be assigned to them. Of course it take
a while for polices to propagate "secedit /refreshpolicy machine_policy
/enforce" first on the domain controller and then a reboot of the computers
would speed things up. You can verify that the polices have been assigned in
Local Security policy or by running netdiag on a computer. Netdiag will give
you better info on assigned policies than ipsecmon will. When you configure
ipsec for your domain you should be aware that using the "require" policy as
is will not work on domain controllers and will cause problems in the
domain - critical domain controller traffic is encrypted anyway. W9X and
NT4.0 computers can not use ipsec and will not be able to access any
computers with a "require" policy. Be sure to test your policies before
production implementation so as to not disrupt the network. --- Steve

http://support.microsoft.com/?kbid=254949
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257225

I am trying to use Group Policy to apply IPSec policy to an Organizational
Unit and I am having difficulty getting it to work when logged into a
workstation as a standard domain user.

I have been following Article: KB313195 HOW TO: Use IPSec Monitor in
Windows 2000

Following this article I have logged into two W2k SP3 clients, in the same
W2k domain, as the local administrator, and set the Local Security Policy to
Assign one the IPSec-Client (Responds Only) modified policy (modified the
filter according to the article to 'require' security), and set the other
client's Local Security Policy to Assign the IPSec-Secure Server (modified
the filter according to the article to 'require' security) modified policy.

When I bring up the IPSecmon on each machine, the IPSecmon status window
shows: "IP security is enabled on this computer." When I open a cmd window
and use: ping -t [ipaddress of other client] the cmd window shows several
lines of "Negotiating IP security" and then the ping round trip information
starts to show up in the cmd until it is closed. The IPSecmon utility shows
the IPSec policy that is being used, and the packet counters increment with
each ping sent.

If I leave the Local Security IPSec policies assigned but logout as a local
administrator and login as a normal domain user, when I start the IPSecmon
utility it's status window shows: "IP security is not enabled on this
computer" and the same cmd ping test simply shows the normal round trip
statistics and the IPSecmon utility shows no policy or packet counters
incrementing. I am confused why the IPSec policy is no longer being used to
manage the same communication that was secured when I was logged is as an
Administrator. If I log back into the clients as a domain administrator I
can achieve the same results that I did as the Local Administrator; seems
like a permissions issue - not sure.

I have logged into each of the W2k workstations as the local administrator
and 'unassigned' the Local Security Policy IPSec policies; at that point
when I start the IPSecmon it's status window shows: "IP security is enabled
on this computer" but the ping test does not show the "Negotiating IP
security," and the packet counters do not increment with each ping sent.
This is confusing me, if the IP security is enabled, then where is it being
assigned? I have scoured the Site, AD OUs and Local Policies to ensure that
no IPSec policies are assigned anywhere, yet the IPSecmon shows it is
enabled, yet not being used for the ping test.

I am not sure if this is part of the problem I am having with trying to use
Group Policy to apply the IPSec policies.

I am trying to create the situation on these two workstations where the
IPSecmon status shows: "IP security is enabled on this computer," and the
ping test shows: "Negotiating IP security" and the IPSecmon's shows the
policy being used and the packet counters increment with each ping sent,
using Active Directory and Group Policies instead of Local Security Policy,
while logged in as a standard domain account user.

I have created two Group Policies, each one has an IPSec policy that has
been modified exactly as I did on my Local Security Policy example above,
and the modified IPSec policy has been assigned inside it's Group Policy. I
have linked each of these Group Policies to two different Active Directory
(AD) Organizational Units (OU), each one containing one of the domain user's
accounts I am using to log into the W2k clients with.

I get the same problem as when I logged to the workstation as a normal
domain user in the example above, the IPSecmon status window shows "IP
security is not enabled on this computer" and the ping test does not show
any "Negotiating IP security" and the IPSecmon shows no policy being used or
packet counter incrementing. My understanding is that when the domain
user's account is in an OU that has a Group Policy linked to it, when that
user logs into the client workstation it re-assigns the Group Policy, and
the IPSec policy that is part of the Group Policy. I have tried configuring
these Group Policies to "no override" and it had no effect.

I have even tried putting the two domain users accounts in the Domain
Administrator's group at the server level, and when I login to the
workstations and start the IPSecmon it's status window shows the same as
above when I turned off the Local Security IPSec policies: the IPSecmon
status window shows: "IP security is enabled on this computer" but the ping
test does not show the "Negotiating IP security," and the packet counters do
not increment with each ping sent.

Any help you could provide toward helping me understand how to get the IPSec
policy assigned, and to be in effect when a standard domain user is logged
in would be greatly appreciated.

BT

 

[Seaver]

Dear Bill,

Thank you for your posting.

According to your post, I understand that IPSec policy only works in
Administrator accounts.

If I have misunderstood your concern please don't hesitate to let me know.

1. When assigning an IPSec policy in Active Directory, please ensure that
the following factors have been considered:

a. IPSec policies assigned to a domain policy will override any active,
local IPSec policy only when that computer is connected to the domain.

b. IPSec policies assigned to an organizational unit will override an IPSec
policy assigned to the domain policy, for any member computers of that
organizational unit. The IPSec policy assigned to the lowest-level
organizational unit will override an IPSec policy assigned to a
higher-level organizational unit, for any member computers of that
organizational unit.

I suggest you temporarily unassign all the IPSec policy, and then assign
only 1 policy to test the situation.

2. If problem still remains, we need to check the results of the Phase One
and Phase Two exchanges by enabling Audit Policy, which causes security
events to be logged in the security log of the Event Viewer.

Please follow the instructions in the following link to enable Audit
Policy:
http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.a
sp#heading3

For further troubleshooting steps, since the instructions are lengthy,
please refer to the following article:

257225 Basic IPSec Troubleshooting in Windows 2000
http://support.microsoft.com/?id=257225

More Information
===========
265112 IPSec and L2TP Implementation in Windows 2000
http://support.microsoft.com/?id=265112

Hope them help!

Sincerely,

Seaver Ren

Product Support Services
Microsoft Corporation

Get Secure! - www.microsoft.com/security

 

[Bill Tomlinson]

Seaver,

Thanks for your advice, I was able to resolve the problem by linking the
group policy to the ou where the computer/workstations are memebers.

My situation has led me to believe that the ipsecmon and netdiag IPSec
verbose tests both require some Administrator level of permission to show
the IPSec policy that may be active. It is my assumption that in order to
show the IPSec policy in action between two client computers, that both have
standard user's logged in, is to use some type of network monitor such as
the SMS provides.

I am always a bit concerned when something only appears to work for
adminitstrators.

Thanks again

 

[Steven L Umbach]

Hi Bill. Ipsec is definitely machine policy and independent of who is logged onto
computer. You experience on non admins using those tools - you probably are right, I
will have to try it out myself sometime. It actually is pretty simple as far as GPO.
There are two parts as seen when editing a Group Policy - machine configuration and
user configuration. Machine configuration is independent of who is logged onto that
computer. User configuration applies to the users that are in the scope of influence
of the GPO - domain/OU/sub OU. Normally when a user is logged onto a computer, the
user configuration for that user applies. There is an exception called "loopback
processing" which applies the user configuration based on the location of the
computer and can either work in a replace or merge mode. That is what you would use
in your example of having a particular setting to apply to all users that log onto a
particular computer regardless of their own user configuration. I will leave you with
some helpful links. -- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;231287
http://www.labmice.net/activedirectory/grpolicy.htm
http://www.microsoft.com/windows2000/techinfo/howitworks/management/gptshoot.asp

Steven,

I linked my IPSec-Group Policies to the OUs where the computer objects are
and this did work.

Using netdiag I can now see the IPSec policies applied from the AD GP.

I have noticed that even with netdiag if you try to use the verbose mode,
for example: netdiag /v /test:IPSec
It will fail on the verbose details of the IPSec output, it does however
reveal that the Group Policy and IPSec policy are in place.

Further when I run the first test between the two computers (logged in as
normal users): ping -t [ip address] it does show that the two computers are
negotiating IP Security, before the ping begins to send packets. At this
point if the ping has negotiated security and I bring up ipsecmon, it shows
that security is not enabled and there is no sign that the IPSec policy is
in place, or working.

From what I can tell, I would need to use a network monitor to detect the
IPSec policy being applied to packets being sent to the two computers when
non-administrators are logged into the workstations. My assumption is that
only when you are logged in as an administrator/equivalent on the
workstations that you can use the local tools such as netdiag or ipsecmon to
view the IPSec policy in action.

Do you have any suggestions on where I could read more on when Group Policy
objects, such as IPSec, are part of the "machine configuration" or part of
the "user configuration" or both?

For example if you apply a screen saver in a Group Policy, can you link the
GP to a computer in an OU and effect anyone who logs in, because it is at
the machine level and not the user level? Are there strategies about these
possiblities that are in a white paper for example?

Thanks Again

Hi Bill. On your first question, I really do not know what the deal is
without being there and recreating the scenario. It sure sounds like a
permission problem, however ipsec policies are machine specific - not user.
That brings me to my next point. Since ipsec policies are part of machine
configuation in group policy you need to move those computers into those
OU's in order for the ipsec policy to be assigned to them. Of course it take
a while for polices to propagate "secedit /refreshpolicy machine_policy
/enforce" first on the domain controller and then a reboot of the computers
would speed things up. You can verify that the polices have been assigned in
Local Security policy or by running netdiag on a computer. Netdiag will give
you better info on assigned policies than ipsecmon will. When you configure
ipsec for your domain you should be aware that using the "require" policy as
is will not work on domain controllers and will cause problems in the
domain - critical domain controller traffic is encrypted anyway. W9X and
NT4.0 computers can not use ipsec and will not be able to access any
computers with a "require" policy. Be sure to test your policies before
production implementation so as to not disrupt the network. --- Steve

http://support.microsoft.com/?kbid=254949
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257225

I am trying to use Group Policy to apply IPSec policy to an Organizational
Unit and I am having difficulty getting it to work when logged into a
workstation as a standard domain user.

I have been following Article: KB313195 HOW TO: Use IPSec Monitor in
Windows 2000

Following this article I have logged into two W2k SP3 clients, in the same
W2k domain, as the local administrator, and set the Local Security

Policy

to
Assign one the IPSec-Client (Responds Only) modified policy (modified the
filter according to the article to 'require' security), and set the other
client's Local Security Policy to Assign the IPSec-Secure Server (modified
the filter according to the article to 'require' security) modified policy.

When I bring up the IPSecmon on each machine, the IPSecmon status window
shows: "IP security is enabled on this computer." When I open a cmd window
and use: ping -t [ipaddress of other client] the cmd window shows several
lines of "Negotiating IP security" and then the ping round trip information
starts to show up in the cmd until it is closed. The IPSecmon utility shows
the IPSec policy that is being used, and the packet counters increment with
each ping sent.

If I leave the Local Security IPSec policies assigned but logout as a local
administrator and login as a normal domain user, when I start the IPSecmon
utility it's status window shows: "IP security is not enabled on this
computer" and the same cmd ping test simply shows the normal round trip
statistics and the IPSecmon utility shows no policy or packet counters
incrementing. I am confused why the IPSec policy is no longer being

used

to
manage the same communication that was secured when I was logged is as an
Administrator. If I log back into the clients as a domain administrator I
can achieve the same results that I did as the Local Administrator; seems
like a permissions issue - not sure.

I have logged into each of the W2k workstations as the local administrator
and 'unassigned' the Local Security Policy IPSec policies; at that point
when I start the IPSecmon it's status window shows: "IP security is enabled
on this computer" but the ping test does not show the "Negotiating IP
security," and the packet counters do not increment with each ping sent.
This is confusing me, if the IP security is enabled, then where is it being
assigned? I have scoured the Site, AD OUs and Local Policies to ensure that
no IPSec policies are assigned anywhere, yet the IPSecmon shows it is
enabled, yet not being used for the ping test.

I am not sure if this is part of the problem I am having with trying to use
Group Policy to apply the IPSec policies.

I am trying to create the situation on these two workstations where the
IPSecmon status shows: "IP security is enabled on this computer," and the
ping test shows: "Negotiating IP security" and the IPSecmon's shows the
policy being used and the packet counters increment with each ping sent,
using Active Directory and Group Policies instead of Local Security Policy,
while logged in as a standard domain account user.

I have created two Group Policies, each one has an IPSec policy that has
been modified exactly as I did on my Local Security Policy example above,
and the modified IPSec policy has been assigned inside it's Group

Policy.

I
have linked each of these Group Policies to two different Active Directory
(AD) Organizational Units (OU), each one containing one of the domain user's
accounts I am using to log into the W2k clients with.

I get the same problem as when I logged to the workstation as a normal
domain user in the example above, the IPSecmon status window shows "IP
security is not enabled on this computer" and the ping test does not show
any "Negotiating IP security" and the IPSecmon shows no policy being

used

or
packet counter incrementing. My understanding is that when the domain
user's account is in an OU that has a Group Policy linked to it, when that
user logs into the client workstation it re-assigns the Group Policy, and
the IPSec policy that is part of the Group Policy. I have tried configuring
these Group Policies to "no override" and it had no effect.

I have even tried putting the two domain users accounts in the Domain
Administrator's group at the server level, and when I login to the
workstations and start the IPSecmon it's status window shows the same as
above when I turned off the Local Security IPSec policies: the IPSecmon
status window shows: "IP security is enabled on this computer" but the ping
test does not show the "Negotiating IP security," and the packet

counters

do
not increment with each ping sent.

Any help you could provide toward helping me understand how to get the IPSec
policy assigned, and to be in effect when a standard domain user is logged
in would be greatly appreciated.

BT