Let's continue with the security of operating systems - this time the “victim” will be MS Windows and the principle of providing minimum rights for system administration tasks.

Employees responsible for certain servers and workstations do not need to be granted “domain administrator” rights. Although not by malicious intent, by mistake, but it can spoil the lives of all, and even cost someone's weekend. Under the cat we will examine in detail the principle of granting minimal rights as one of the technologies of granting minimal rights.

Limited groups

As an example from practice, I can cite a sad story with a happy ending. In organizations, historically, the print server was located on a domain controller. At one point, an IT officer needed to reflash a printer, which he did by running a Chinese utility on the server. The printer earned, but the utility during the process of flashing transferred the time a few years ago. Active directory does not like time travelers very much, and the domain controller safely went to the “tombstone” ( tombstone ).

The incident added gray hair, but the second domain controller saved the situation: the roles of FSMO were transferred to it, and the time traveler was again made a domain controller. Since then, the company has to earn the rights of "domain administrator".

To prevent such situations, it would be nice to give those who want exactly as many rights as necessary: ​​if you only need to administer workstations, you only need to issue rights to users' computers.

When there are not many computers, you can also manually turn on the helpdesk domain security group into the local group “administrators”. But on a large volume come to the aid of group policies. There are two convenient ways.

The first way: through Restricted groups located in group policies at Computer Configuration - Policies - Security Settings .

The location of the Restricted groups policy.

Next, you need to create the Administrators group and add the necessary group to it. There is only one caveat - if done this way, then everything will disappear from the local group “Administrators”, except for the built-in administrator and the group itself. Even Domain Admins:

We add the group “Administrators” to which we add the group helpdesk.

And we get the local group "Administrators" without Domain admins.

Of course, this opportunity can be used to the benefit of - clean up local groups from unnecessary participants. If you want to avoid such a sweep, then you can create a domain group in the “Restricted Groups” and assign it to the Administrators group:

With this setting, the local group "Administrators" will not be cleaned.

The second way is to set up Group Policy Preferences (Group Policy Preference, hereinafter GPP). You should search in Computer Configuration - Settings - Local Users and Groups .

Configure security group via GPP.

Like all settings in GPP, this one is easier to understand and has a more user-friendly interface. But if your infrastructure contains not updated Windows XP or even Windows 2000, then only the first option remains.

In the same way, you can give rights to certain servers to the right employees. For example, give rights to a group of developers on a test stand.

Using built-in security groups

Of course, IT staff and system accounts (for example, under which backup tasks are performed) are easier to immediately include in the “Enterprise Admins” group and don’t know grief.

But for security reasons, it’s better not to. On Windows, there is a set of built-in accounts with a set of typical rights. Groups are slightly different for the computer and for the domain, and a number of services introduce their groups.

If there are not enough standard groups, then Windows allows you to configure permissions more finely. For example, to give a separate user group the right to change the time or the ability to forcibly shut down a server on the network. For this, there is a mechanism for “assigning user rights”. You can search in the local security policy - secpol.msc or in the group policy at Computer Configuration - Windows Configuration - Security Settings - Local Policies - User Rights Assignment .

Setting permissions through group policies.

I recommend using this setting in extreme cases, and it should be documented. Remember that sometime someone will replace you and will understand why it works this way and not otherwise.

In general, it is always better to document everything. Imagine the situation that you quit the organization and a man came from the street instead of you. Put yourself in that person’s place. If your eyes began to twitch or your hair began to move, take the time to write documentation. You are welcome!

There is another good method for restricting access to objects - delegation. About this technology on Habré already written , so I just add that with the help of delegation conveniently given the right to enter a new computer into the domain.

All these technologies have been around for a long time in Windows systems. With the advent of Windows 10 \ 2016, there was another interesting opportunity to restrict accounts - it will be discussed later.

Enough administration

Just Enough Administration (JEA) is a technology for providing access to PowerShell cmdlets. Works on operating systems up to Windows 7 when installing the Windows Management Framework 5.1 (although, in the oldest operating systems support is limited). The work is done through the so-called "virtual accounts" and specially prepared configuration files. An example of using JEA is issuing limited rights to manage certain virtual machines — for example, for your developers.

You can read more about JEA in the official documentation , so we’ll analyze a specific example of how a virtual machine can be restarted.

First, we need to allow remote connection to the server using the Enable-PSRemoting cmdlet , and at the same time make sure that we have the Windows Management Framework of the required version using the $ PSVersionTable.PSVersion cmdlet.

Check the version and resolution of remote connections using PS.

Create a security group and special user:

$VMOperatorGroup = New-ADGroup -Name "VM-operators" -GroupScope DomainLocal -PassThru $OperatorUser = New-ADUser -Name "VMOperator" -AccountPassword (ConvertTo-SecureString 'P@ssword1' -AsPlainText -Force) -PassThru Enable-ADAccount -Identity $OperatorUser Add-ADGroupMember -Identity $VMOperatorGroup -Members $OperatorUser 

Now we will create the necessary configuration files and folders. First common:

 New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module" -ItemType Directory New-ModuleManifest -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module\Demo_Module.psd1" New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities" -ItemType Directory 

And then create a specific configuration file for our virtual machine operator named win. For example, let's allow a virtual machine to start and stop:

 $VMRoleCapabilityParams = @{ Author = ' ' Description = 'VM Role Capability File' CompanyName = 'ServerMall' VisibleCmdlets= 'Get-VM', @{ Name='Start-VM'; Parameters=@{ Name='Name'; ValidateSet='win' } }, @{ Name = 'Stop-VM'; Parameters = @{ Name = 'Name'; ValidateSet = 'win'}} New-PSRoleCapabilityFile -Path "$ENV:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\VMRoleCapability.psrc" @VMRoleCapabilityParams 

Now you need to prepare the PowerShell session file:

 $NonAdministrator = "DOMAIN\VM-win-Operators" $ConfParams = @{ SessionType = 'RestrictedRemoteServer' RunAsVirtualAccount = $true RoleDefinitions = @{ $NonAdministrator = @{ RoleCapabilities = 'VMRoleCapability'} } TranscriptDirectory = "$env:ProgramData\JEAConfiguration\Transcripts" } New-Item -Path "$env:ProgramData\JEAConfiguration" -ItemType Directory $SessionName = 'VM_OperatorSession' New-PSSessionConfigurationFile -Path "$env:ProgramData\JEAConfiguration\VM.pssc" @ConfParams 

Register the session file:

 Register-PSSessionConfiguration -Name 'VM_OperatorSession' -Path "$env:ProgramData\JEAConfiguration\VM.pssc" 

Now everything is ready for verification. Let's try to connect to the server with the credentials of the user created by the cmdlet:

 Enter-PSSession -ComputerName SERVERNAME -ConfigurationName VM_OperatorSession -Credential (Get-Credential) 

Check the list of available commands with get-command and try to stop our virtual machine win and then another machine win2.

Access to the server is limited to managing one virtual machine.

To make it easier for the community to create configuration files, a utility called the JEA Toolkit Helper was created, where a graphical interface will help you create files with the necessary parameters.

Interface JEA Toolkit Helper.

If necessary, it is possible through group policies to enable auditing of module execution at Computer Configuration - Administrative Templates - Windows Powershell - Enable module journaling . Then the Windows log will display entries about what, where and when.

PowerShell runtime log.

An alternative would be to include an entry in the file. Also through the group policy, the option " Enable PowerShell transcriptions " is configured. The path can be set both in the policy itself (and then the entry will be kept there for all modules), or in the JEA session configuration file in the TranscriptDirectory parameter.

JEA file log.

With the help of delegation, assignment of rights and JEA, you can avoid using accounts with administrative rights in your daily work. In the end, they are also used to UAC in Windows, and we don’t turn them off simply because “shut up, I already know what to do with my files!”.