none
Unable to lock down Network Connections settings with Group Policy

    Question

  • I'm running server 2008 and Win7 workstations (except  on XP), I've just recently started using group policy which so far seems to be working fine.

    I wanted to prevent users from changing the DNS IP Addresses in their Network Connection settings, as I don't want them to bypass opendns.

    This looked pretty straightforward, I went into GPMC.msc from my workstation and set the following in User Configuration / Admin Templates / Network / Network Connections:

    Enable Windows 2000 Network Configuration Settings for Administrators
    Prohibit access to properties of components of a LAN connection
    Prohibit access to properties of a LAN connection

    I know the last one isn't necessary, but for testing purposes I thought I'd enable it too.

    Using a test account which IS a member of the local admin group on this workstation, I force a policy updated, rebooted several times, waited several days - but still I have full access to change all properties of the LAN connection.

    I can't imagine what could be preventing this from working, any ideas?
    It seems strange that there's no way to prevent local admins from editing network connection properties.
    Help appreciated ASAP...
    Saturday, July 07, 2012 4:17 AM

Answers

  • Hello Rakesh, 

    Remove users from security group "Network Configuration Operators"local admins group and check for the difference.



    Regards, Ravikumar P

    Saturday, July 07, 2012 6:33 AM
  • Hi,

    What’s your user permission level, local administrator or what?

    If users have local administrator permission or users are member of Network Configuration Operators group, users are able to modify network connection settings by default.

    We have some group policies to prevent users change network connection:

    User Configuration\Administrator Templates\Network\Network Connections

    - Prohibit access to properties of components of a LAN connection

    This setting determines whether administrators and network configuration operators can change the properties of components used by a LAN connection.

    If you enable this setting, the Properties button is unavailable for users and network configuration operators.

    If you disable this setting or do not configure it, the Properties button is enabled for administrators and network configuration operators.

    If the "Enable Network Connections settings for Administrators" Group Policy setting is enabled, this setting also applies to administrators on computers running Windows XP. (However, this setting can’t apply to administrator on a Windows 7 computer).

    User Configuration\Administrator Templates\Network\Network Connections

    - Prohibit TCP/IP advanced configuration
    - Prohibit access to properties of a LAN connection

    We can’t prevent local administrator to modify network connection settings in Windows7, this is by design.

    For more information please refer to following MS articles:

    A Description of the Network Configuration Operators Group
    http://support.microsoft.com/kb/297938
    Using Group Policy Settings with Windows XP Home Networking Features
    http://technet.microsoft.com/en-us/library/bb457072.aspx

    Lawrence

    TechNet Community Support

    Monday, July 09, 2012 4:28 AM
    Moderator

All replies

  • Hello Rakesh, 

    Remove users from security group "Network Configuration Operators"local admins group and check for the difference.



    Regards, Ravikumar P

    Saturday, July 07, 2012 6:33 AM
  • Hi,

    What’s your user permission level, local administrator or what?

    If users have local administrator permission or users are member of Network Configuration Operators group, users are able to modify network connection settings by default.

    We have some group policies to prevent users change network connection:

    User Configuration\Administrator Templates\Network\Network Connections

    - Prohibit access to properties of components of a LAN connection

    This setting determines whether administrators and network configuration operators can change the properties of components used by a LAN connection.

    If you enable this setting, the Properties button is unavailable for users and network configuration operators.

    If you disable this setting or do not configure it, the Properties button is enabled for administrators and network configuration operators.

    If the "Enable Network Connections settings for Administrators" Group Policy setting is enabled, this setting also applies to administrators on computers running Windows XP. (However, this setting can’t apply to administrator on a Windows 7 computer).

    User Configuration\Administrator Templates\Network\Network Connections

    - Prohibit TCP/IP advanced configuration
    - Prohibit access to properties of a LAN connection

    We can’t prevent local administrator to modify network connection settings in Windows7, this is by design.

    For more information please refer to following MS articles:

    A Description of the Network Configuration Operators Group
    http://support.microsoft.com/kb/297938
    Using Group Policy Settings with Windows XP Home Networking Features
    http://technet.microsoft.com/en-us/library/bb457072.aspx

    Lawrence

    TechNet Community Support

    Monday, July 09, 2012 4:28 AM
    Moderator
  • Thank you  Lawrence . 

    In this scenario I had given local admin right. With out local admin right it was working for me.

    conclusion :- We can’t prevent local administrator to modify network connection settings in Windows7, this is by design.

    Monday, July 09, 2012 5:40 AM
  • Yes without local admin right it works for me ..


    Monday, July 09, 2012 5:41 AM

  • We can’t prevent local administrator to modify network connection settings in Windows7, this is by design.


    Let me rephrase this:

    <big><big>We can't prevent local administrators from anything in any version of windows. Neither through Group Policy nor through ACLing nor through whatever else. The one and only solution: Do not make them administrators.</big></big>

    The policy settings you tried to implement were nonsense from the very beginning, so eventually someone at MS noticed that and dropped support for it. If you take a look at the "Requirements" section: Server 2003 and XP only, no Vista and above.

    regards, Martin
    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Thursday, July 12, 2012 12:05 PM
  • This is a really old thread, but the last response made by the MVP Martin Binder aggravated me so much I'm going to add my comment regardless.

    Martin Binder said: "The policy settings you tried to implement were nonsense from the very beginning, . . ."

    What an arrogant, short-sighted, and insulting comment.  Too bad that attitude is all too common with these so-called MVP's who live in their Microsoft company-shill fantasy world.  Trying to understand why someone wants to do a particular thing is fine, as is giving alternate solutions.  But it's not okay to basically call someone stupid for wanting to do something, even if you don't understand or agree with their reasons.

    There are MANY valid reasons why users may need Local Administrator rights in an organization, but there are tons of Group Policies and Group Policy Preferences that a Domain Administrator may still want to push to those users' machines.  Most of those GPOs take affect regardless of whether or not the user is a Local Admin.  Yes, with Local Administrator rights, a user could edit the Local Policy and undo many of the settings, at least temporarily for that login session.  But that assumes the users know how and where to make the change and that they care enough about it to do so.  So 98% of the time, the GPO achieves its goal.

    I found this thread right away when I started to look for a quick and easy way to lock down the default gateway setting on my users' primary workstations, and 2/3 of them must have Local Administrator rights.  I'm simply trying to prevent people from easily changing their own default gateways whenever our primary ISP is acting a bit flaky.  Rather than informing me there's an issue with the primary, some users will change their gateways to use our backup firewall and secondary ISP, which has limited bandwidth.  But if the primary ISP isn't completely down and my primary firewall cluster doesn't fail over to the secondary ISP, and/or I'm not at my own PC at the time, it might be awhile before I even realize there's an issue in order to fix it.  Even when I do fix the problem, some users don't change their default gateways back to the primary like they should.  However, if they couldn't change their own gateways so quickly and easily, they might actually have to go out of their way to let me know there's an issue.  (I don't even mind the fact that the users could change the Local Policy in a pinch.  Some of my users need to be able to change their gateways for various testing purposes, and there could come a day where I might need to walk one of the other users through the procedure over the phone.)

    Anyway, even if this GPO did work but it locked down all of the TCP/IP properties, that probably wouldn't be granular enough to work for me.  (Some of my Local Administrator users often need to give themselves temporary secondary static IP addresses on various subnets in order to configure devices/PCs intended for customer sites.)  But there are some other ways I might be able to address the problem via the firewalls, or programmatically by importing a .reg file at logon, or even on the fly using a remote regedit app or something.  Even setting the default gateway value at login would at least put the gateway back to what it should be for those users who change their own and forget to change it back.  I'm sure I'll come up with something.  Regardless of that though, I stand by what I said about the MVP's comments and attitude.


    • Edited by Sage_Eagle Tuesday, December 31, 2013 10:23 PM
    Tuesday, December 31, 2013 10:22 PM