In the last article, “ Less administrators to everyone, ” I talked about how to work without administrator rights — in particular, about the Just Enough Administration (JEA) technology. This mechanism, though flexible, is difficult to configure, and in some situations you can do without it.

For example, if regularly updated software is used in accounting, then it is not necessary to issue administrator rights, use third-party solutions such as AdminLink, and moreover, update them by hand. There are other options.

Temporary group membership

In Windows 2016, a mechanism such as PAM - Privileged Access Management or Privileged Access Management System appeared. You can read more about PAM in the Microsoft Privileged Access Management for Active Directory Domain Services documentation. One of its tools is the ability to include a user in a group for a specific time.

To enable PAM, run the following command:

Enable-ADOptionalFeature "Privileged Access Management Feature" -Scope ForestOrConfigurationSet -Target corp.domain.com 

And confirm the inclusion of the option in the domain.

Turn on PAM.

Check that the option is enabled with the command:

 Get-ADOptionalFeature -filter {name -like "Privileged*"} 

Check that PAM is enabled.

Now you can set the time of the user's membership in the group. For example, let's give the user Vasya.Pupkin the right to manage accounts in the domain by including him in the Account Operators group:

 $Time = New-TimeSpan -Minutes 15 Add-ADGroupMember -Identity " " -Members Vasya.Pupkin -MemberTimeToLive $Time 

You can check the remaining user lifetime in a group with the command:

 Get-ADGroup " " -Property member –ShowMemberTimeToLive 

We check users in the group.

The lifetime in seconds is displayed in the TTL attribute. In my case, the value <TTL = 849> means that the user Vasya.Pupkin has “live” in the group of 849 seconds.

If necessary, the script to add a user to a group can be installed in the scheduler. And then technical support staff will be able to create new users at a given time: for example, only in the morning. Unless, of course, the creation of new users is not yet automated .

Unfortunately, not everyone is still fully enjoying the new features of Windows 2016. But you can do without them.

My name is George and I'm paranoid

Indeed, why include some new features if you can add an account to the group, and then remove the account from the group. This method is inconvenient for the temporary granting of authority to employees, but it is quite suitable for your own work if you, while observing all the IS precepts, do not work under a user with administrative rights.

Suppose we need to restart the 1C: Enterprise server. If you have rights, it is fairly easy to do with this command:

 Invoke-Command -ComputerName servername -ScriptBlock { Restart-Service "1C:Enterprise 8.3 Server Agent" } 

But I do not work with administrative rights, so I created a separate user admin-zhora , which is a member of the server-admins group. In turn, this group has been added to local server administrators using the Restricted Groups mechanism. Therefore, my script looks like this:

 $Credential = Get-Credential Invoke-Command-ComputerName servername -Credential $Credential -ScriptBlock { Restart-Service "1C:Enterprise 8.3 Server Agent" } 

Requesting credentials when running a script.

And I take care of security - if someone steals a user's credentials. Therefore, I modify the script: I add the inclusion of a user to a group and remove a user from a group:

 Add-ADGroupMember -Identity server-admins -Members admin-zhora ... Remove-ADGroupMember -Identity server-admins -Members admin-zhora –Confirm:$False 

Now it is safer. But it is not exactly.

Add more security to my script: each time we will change the password of the admin-zhora user to random, so as not to worry about its compromise. To do this, I will take the module New-SWRandomPassword.ps1, published on the Script Center portal, and with its help I will write the following function:

 #requires -Modules New-SWRandomPassword function Reset-InvokePassword { param ( [Parameter(Mandatory=$true)] [string]$UserName ) $NewSecurePassword = ConvertTo-SecureString -String (New-SWRandomPassword -MinPasswordLength 14 -MaxPasswordLength 14) -AsPlainText -Force try { Set-ADAccountPassword -Identity $UserName -NewPassword $NewSecurePassword -Reset -Confirm:$False -ErrorAction Stop } catch { Write-Output "Could not change password" $ErrorMessage = $_.Exception.Message $ErrorMessage break } New-Object System.Management.Automation.PsCredential($UserName,$NewSecurePassword) } 

At the output of this function, I get new credential credentials that I can pass to other cmdlets. Add to the original script password change before the execution of the main command and after it. The final script will be:

 #requires -Modules Reset-InvokePassword Add-ADGroupMember -Identity server-admins -Members admin-zhora -Verbose $Credential = Reset-InvokePassword -Username admin-zhora Invoke-Command -ComputerName servername -Credential $Credential -ScriptBlock { Restart-Service "1C:Enterprise 8.3 Server Agent" -Verbose } Reset-InvokePassword -Username admin-zhora | Out-Null Remove-ADGroupMember -Identity server-admins -Members admin-zhora -Confirm:$False -Verbose 

Now it is safe enough, and also does not request a password.

The attentive reader will note that my account must be given the rights to manage the group and the user in order to change the password and group membership. Well, in this example I’m ready to take risks, but in real practice I prefer JEA for such teams.

If you compare JEA with sudo , which requires pre-configuration and issuance of rights, then the add-delete mechanism in groups looks more like su and is more suitable for one-time rather than regular tasks.