zenoss / microsoft.tools Goto Github PK

Tools for working with Microsoft Software.

Python 8.00% PowerShell 89.50% TSQL 2.49%

microsoft.tools's Introduction

Least Privileged User

Least Privileged User

This README documents what permissions are needed to monitor a Windows server by a non-administrative user. These changes are automated using the lpu/zenoss-lpu.ps1 powershell script. This script is known to work for Windows 2008 and 2012 member servers. To enable the LPU for a Domain Controller, one will need to run the script and also manually add the user to the Domain level security groups listed below.

Do not delete user without backing out changes made by the LPU script. See lpu/zenoss-backup-lpu.ps1 for an example of saving existing permissions.

Before running the LPU script, you should backup your settings.

The Least Privileged User requires the following privileges:

WMI namespace security(Enable, Method Execute, Read Security, Remote Access)
Winrm access
ReadPermissions, ReadKey, EnumerateSubKeys, QueryValues rights to several registry keys
Membership in local groups
“Read Folder” access to "C:\Windows\system32\inetsrv\config" if it exists
Service permissions

WMI namespace security(Enable, Method Execute, Read Security, Remote Access)

Added by invoking the SetSecurityDescriptor method

See http://blogs.msdn.com/b/spatdsg/archive/2007/11/21/set-wmi-namespace-security-via-gpo-script.aspx for information on using GetSD to backup the Security Descriptor for each namespace

Permission is set on the following namespaces:

"Root"
"Root/CIMv2"
"Root/DEFAULT"
"Root/RSOP"
"Root/RSOP/Computer"
"Root/WMI"
"Root/CIMv2/Security/MicrosoftTpm"

If IIS is installed, one of the following namespaces depending upon IIS version

"Root/Webadministration"
"Root/microsoftiisv2"

Winrm access

Access is given by through "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service\rootSDDL"

To backup the sddl you could do something like the following:

    $sddlkey = "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service"
    $rootsddlkey = get-itemproperty $sddlkey -Name “rootSDDL”

ReadPermissions, ReadKey, EnumerateSubKeys, QueryValues rights to specific registry keys

To backup registry security you could do something like the following for each registry key

    $regacl = (get-item $regkey).getaccesscontrol("Access")
    $regsddl = $regacl.sddl

Zenoss needs access to the following registry keys:

"HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib",
"HKLM:\system\currentcontrolset\control\securepipeservers\winreg",
"HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}",
"HKLM:\SYSTEM\CurrentControlSet\Services\Blfp\Parameters\Adapters",
"HKLM:\Software\Wow6432Node\Microsoft\Microsoft SQL Server",
"HKLM:\Software\Microsoft\Microsoft SQL Server"

Membership in the following groups

To remove users from a group, you could simply use a GPO.

The following groups are either local to a server or are at the domain level.

"Performance Monitor Users",
"Performance Log Users",
"Event Log Readers",
"Distributed COM Users",
"WinRMRemoteWMIUsers__"

“Read Folder” access to "C:\Windows\system32\inetsrv\config" if it exists

To backup the sddl

    $folderfileacl = (get-item $folderfile).getaccesscontrol("Access")
    $sddl = $folderfileacl.sddl

Service permissions

To backup a service sddl you could do something like the following on each service:

    $servicesddl = [string](CMD /C "sc sdshow `"$service`"")

We assign the following permissions:

SERVICE_QUERY_CONFIG
SERVICE_QUERY_STATUS
SERVICE_INTERROGATE
READ_CONTROL
SERVICE_START

Some services are owned by the SYSTEM account and the permissions cannot be altered by the administrator. In order to change the permissions on these services, you will need to run the zenoss-system-services.ps1 script as the SYSTEM user.

Use the PSExec sysinternals tool to open a cmd shell as the system account.

    psexec.exe -s cmd

You can then execute the powershell script to update the system owned service permissions.

    powershell -file "zenoss-system-services.ps1 -u [email protected]"

microsoft.tools's People

Contributors

Stargazers

Watchers

Forkers

stormhammer freetrog kickingsawdust olenazenoss 1redone rbramwell holtorfmarc ngeorgieff rlewkowicz poictesme tomloveland1 jstanley23 dekapito ramatam edmac45 saundersmatt

microsoft.tools's Issues

Script Problem

Using the script zenoss-lpu.ps1 to assign my domain user permissions to my servers for WinRM collection must be missing a permission. When modelling my servers I am missing some items from collection, what I've seen missing is Windows services. Sometimes as little as one service missing, or 3+. Adding the domain user to the local admin group of one of these servers and remodelling fixes the handful of missing service. But that negates why I'm using this script in the first place.

zenoss-lpu.ps1 - allow_access_to_winrm - $defaultkey value is incorrect for 2012R2.

In zenoss-lpu.ps1 there is a function named allow_access_to_winrm

The $defaultkey value used in the allow_access_to_winrm function is valid for 2008R2, but the default SDDL changed in 2012R2.

You can run "winrm get winrm/config" to see the defaults on each version of Windows (spaces added by me):

2012R2 - O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
2008R2 - O:NSG:BAD:P(A;;GA;;;BA)            S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

Instead of hard coding a default, I suggest parsing the output of running "winrm get winrm/config" to see what the current RootSDDL being used is. That would address the case where the "SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service" registry key does not exist and default values are being used.

=-=-=

With that said, I don't think the script should even be setting this registry key on 2008R2 or later.

According to the below link[1], starting with Windows 2008R2 "The value stored at winrm\Config\Service\RootSDDL is only used for security access checks if the requested resource URI does not specify its own specific SDDL as a part of the plug-in configuration.".

I see that both the "WMI Provider" and "Microsoft.PowerShell" Plugins specify their own SDDL (at least under 2008R2 and 2012R2). I assume that these are the two that are used by zenoss.

[1] https://technet.microsoft.com/en-us/library/ee922649(v=ws.10).aspx

The script is failing to work in non english installs

I have a windows install set in spanish, and one of the issues I had is that the scripts to restrict the users to the proper permissions do not work. It basically fails because the groups have different names depending on the language, and the variable $localgroups not always the same

Original content

$localgroups = @(
    "Performance Monitor Users",
    "Performance Log Users", 
    "Event Log Readers", 
    "Distributed COM Users", 
    "WinRMRemoteWMIUsers__"
    )

Group names in spanish

$localgroups = @(
    "Usuarios del monitor de sistema",
    "Usuarios del registro de rendimiento", 
    "Lectores del registro de eventos", 
    "Usuarios COM distribuidos", 
    "WinRMRemoteWMIUsers__"
    )

The correspondency would be like this:

Event Log Readers -> Lectores del registro de eventos
Distributed COM Users -> Usuarios COM distribuidos
Performance Monitor Users -> Usuarios del monitor de sistema
Performance Log Users -> Usuarios del registro de rendimiento

This is what I get when adding the privileges to an user called monitloc

Registry Security Descriptor failed for HKLM:\software\microsoft\ole
Group does not exist: Performance Monitor Users
Group does not exist: Performance Monitor Users
Group does not exist: Performance Log Users
Group does not exist: Performance Log Users
Group does not exist: Event Log Readers
Group does not exist: Event Log Readers
Group does not exist: Distributed COM Users
Group does not exist: Distributed COM Users
Group does not exist: WinRMRemoteWMIUsers__
Group does not exist: WinRMRemoteWMIUsers__
Zenoss Resource Manager security permissions have been set for SATAPPSDEV\monitorloc

I couldn't find a precreated group matching WinRMRemoteWMIUsers__, I can only connect properly if the user is also a member from the Administrator group (that is what we wanted to avoid in first term)
NOTE: I changed the value of the ExecutionPolicy directive to both unrestricted or remotesigned without any difference