powershell gpo user rights assignment

Set and Check User Rights Assignment via Powershell

You can add, remove, and check user rights assignment (remotely / locally) with the following powershell scripts..

Posted by : blakedrumm on Jan 5, 2022

How to get it

Local Computer

Remote computer, output types.

This post was last updated on August 29th, 2022

I stumbled across this gem ( weloytty/Grant-LogonAsService.ps1 ) that allows you to grant Logon as a Service Right for a User. I modified the script you can now run the Powershell script against multiple machines, users, and user rights.

Set User Rights

All of the User Rights that can be set:

Note You may edit line 437 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the Powershell ISE.

Here are a few examples:

Add Users Single Users Example 1 Add User Right “Allow log on locally” for current user: . \Set-UserRights.ps1 -AddRight -UserRight SeInteractiveLogonRight Example 2 Add User Right “Log on as a service” for CONTOSO\User: . \Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeServiceLogonRight Example 3 Add User Right “Log on as a batch job” for CONTOSO\User: . \Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeBatchLogonRight Example 4 Add User Right “Log on as a batch job” for user SID S-1-5-11: . \Set-UserRights.ps1 -AddRight -Username S-1-5-11 -UserRight SeBatchLogonRight Add Multiple Users / Rights / Computers Example 5 Add User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com: . \Set-UserRights.ps1 -AddRight -UserRight SeServiceLogonRight , SeBatchLogonRight -ComputerName $ env : COMPUTERNAME , SQL.contoso.com -UserName CONTOSO\User1 , CONTOSO\User2

Remove Users Single Users Example 1 Remove User Right “Allow log on locally” for current user: . \Set-UserRights.ps1 -RemoveRight -UserRight SeInteractiveLogonRight Example 2 Remove User Right “Log on as a service” for CONTOSO\User: . \Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeServiceLogonRight Example 3 Remove User Right “Log on as a batch job” for CONTOSO\User: . \Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeBatchLogonRight Example 4 Remove User Right “Log on as a batch job” for user SID S-1-5-11: . \Set-UserRights.ps1 -RemoveRight -Username S-1-5-11 -UserRight SeBatchLogonRight Remove Multiple Users / Rights / Computers Example 5 Remove User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com: . \Set-UserRights.ps1 -RemoveRight -UserRight SeServiceLogonRight , SeBatchLogonRight -ComputerName $ env : COMPUTERNAME , SQL.contoso.com -UserName CONTOSO\User1 , CONTOSO\User2

Check User Rights

In order to check the Local User Rights, you will need to run the above (Get-UserRights), you may copy and paste the above script in your Powershell ISE and press play.

Note You may edit line 467 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the Powershell ISE.

Get Local User Account Rights and output to text in console:

Get Remote SQL Server User Account Rights:

Get Local Machine and SQL Server User Account Rights:

Output Local User Rights on Local Machine as CSV in ‘C:\Temp’:

Output to Text in ‘C:\Temp’:

PassThru object to allow manipulation / filtering:

I like to collaborate and work on projects. My skills with Powershell allow me to quickly develop automated solutions to suit my customers, and my own needs.

Email : [email protected]

Website : https://blakedrumm.com

My name is Blake Drumm, I am working on the Azure Monitoring Enterprise Team with Microsoft. Currently working to update public documentation for System Center products and write troubleshooting guides to assist with fixing issues that may arise while using the products. I like to blog on Operations Manager and Azure Automation products, keep checking back for new posts. My goal is to post atleast once a month if possible.

• operationsManager
• troubleshooting
• certificates

• Outlook – General Tab
• Outlook – Phone Tab
• ADUC – General Tab
• ADUC – Address Tab
• ADUC – Account Tab
• ISA/TMG Scripts
• Active Directory on Fixed Ports
• RPC Internet Ports in Windows 2008
• DNS High Memory Utilization Issue
• WP – Cookies for Comments
• PHPBB HTTP 403 Forbidden Issue
• Shift Key and RDP Woes
• Domain Controller crash – memory leaking process
• Associate MP3 files to MPG123.EXE with parameters
• Privacy Policy

• Active Directory

Powershell GPO Deep Dive – Part 1

Creating a GPO in order to set User Rights Assignment completely in PowerShell: Can it be done?

This series of posts aims to share some interesting things learned about how GPOs are structured and things discovered about what backup-gpo and import-gpo routines are doing within the Powershell GPO module . The research was limited to User Rights Assignments and scripting up such a GPO – with absolutely no warranties what so ever!

Remember that changing security settings and user rights assignments can cause issues.

It turnns out that there is another way that this can be done by creating a blank GPO and creating the relevant files directly in SYSVOL in around 10 lines of code but this does feel even more dangerous / hacky to me.

Create a GPO for User Rights Assignment in Powershell

One of my colleagues asked me if we could script up an end-to-end GPO that would add in some Deny elements within the User Rights Assignments section. I immediately replied with “yeah sure, no worries” with a vague recollection that there was now a bunch of GPO commands like New-GPO that could create a GPO and command-lets that let you set registry values ( Set-GPRegistryValue ).

Some time later I discovered that actually…. NO.. No it is not possible to script up a full GPO to do what we wanted. It is possible to make a new empty GPO, Link it, add registry settings but if there is a need to add Deny Logon type elements to the Security node under User Rights Assignment, this is not currently possible.

This discovery disappointed me to say the least. What other options are available? Before moving any further let’s talk about what our given scenario was:

We would like to script up a GPO that will allow us to dynamically inject the usernames and groups that we want to be denied access to various User Rights Assignment elements in a GPO.

Of course, you could make a GPO through the GUI and then export it as a Backup using the Backup-GPO command and then save that somewhere and you could just import that GPO using Import-GPO . In our scenario, this just won’t cut it. We need to be able to inject our own account and group names – If we just blindly import, we’ll just get a bunch of stuff that may or may not be valid based on some statically exported values.

This got me thinking: what if we could Back up a GPO, get the resultant files prepared in such a way that we can replace the relevant values in the files that it creates with the user and group names of the things we want inside the GPO, and THEN run the Import-GPO command?

Before we jump down that rabbit hole, let us consider what gets created by the backup-gpo command-let in the specific scenario we are looking at.

What’s in an Empty GPO?

In order to back up a GPO, we first need a GPO to back up.  In our example, we will create a GPO called “NewGPO”

Looking at this GPO, we can see that it is empty. The only thing of note for us is the Unique ID (GUID) of {28AA0345-4804-4CE9-A41D-F7C89D5D5BD3}

We will find this policy “{28AA0345-4804-4CE9-A41D-F7C89D5D5BD3}” under sysvol. In the filesystem, it looks like this:

The first folder “Machine” is the structure for Computer related elements. The second folder “User” is for User related Policy Elements.

Since our GPO is empty, both folders will also be empty. However there is a file called “GPT.INI” in the root of this folder (note that the filename is in capital letters – strangely, capitals only when created not restored). At this point the GPT.INI contains the GPO Version (how many times the policy has been modified and saved) and displayName of the policy as shown in the console. The encoding for this file is “UTF-8” (see screenshot below as an example):

A GPO with one User Rights Assignment value set

Lets go back into our GPO and create a single element for Deny Access to this computer from the network and set it for Administrators as pictured below:

If we walk the filesystem under SYSVOL as we did earlier, we will find that everything is the same, except that the “Machine” folder tree now has a subfolder \Machine\Microsoft\Windows NT\SecEdit containing a single file called GptTmpl.inf

Looking at the file, we can see it is like any old school .inf file with sections in square brackets. The last section is where the actual Logon Rights are stored. In this case; we asked for Deny Access to this computer from the network to be set for administrators. The system translated that to DenyNetworkLogonRight = *S-1-5-32-544.

The system has converted our plain text request into this instruction. The SID shown here is simply a translation from the list of well known SIDs for Administrator.

What’s inside a Backup-GPO?

Let’s back up our example GPO using the Backup-GPO command in powershell:

This creates a file structure within the Administrator’s temp folder. It creates a folder with a newly created random guid (referred to as the Backup ID). The original GPO’s GUID {28AA0345-4804-4CE9-A41D-F7C89D5D5BD3} is stored in the backup as “GpoID” and can be seen in  the results of the command above (and in some of the GPO’s backed up files – more on that in a moment).

The backed up GPO has been saved under the new ID Folder name of {43E048D3-ECC6-4F29-AF9D-CF464EEF4CD5}.

Be aware that there are two extra hidden XML files that get created after running a Backup-GPO command. The first file is outside the GUID folder at the folder where the command ran, The file is called Manifest.xml and is very important if you wish to import the GPO somewhere else.

The manifest.xml file is quite ugly. It is in XML, but it will probably show as one big long line of unbroken text. Here’s a version of our manifest.xml (encoding is UTF-8) with wordwrap turned on in Notepad:

In short, the Manifest.xml file is used by the import-gpo routine to provide instructions on where GPOs that have been backed up can be found. It also contains information on the domain and domain controller it was backed up from. You will also find the time and the display name of the original GPO. Each GPO backed up will be found inside a <BackupInst> tag set.

As mentioned earlier, there is another hidden file. This file is in the GUID folder and called bkupinfo.xml. It looks remarkably similar to the Manifest file with one less tag. The first tag <backups> is not present – The Backups tag is only found in the manifest file and is used to encapsulate each GPO that can be found at the backed up folder location along with its associated GUID/ID pair. In our case, we only have one GPO, so the file looks almost identical (without the <Backups> tag).

NOTE: For this file to be able to be imported, you must not break some tags over new lines or the import command will completely crash the powershell session; eg; The file formatted as below would cause the client to crash. You can remove the empty lines without a problem.

The purpose of the SecuritGroups section is so that if you have custom user/group names inside your policy, they can be transformed if imported into a new domain. Be aware that the entire SecurityGroups section MUST be on a single unbroken line otherwise Import-GPO will crash and terminate the current powershell session.

The purpose of the GroupPolicyCoreSettings is to capture some of the basic GPO settings, Domain, original GPO GUID (stored as ID) and any machine policies that are in use. In our example, we are only using the one policy for the Security section of our GPO – {827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}. This section MUST all be on a single unbroken line otherwise Import-GPO will crash and terminate the current powershell session.

In our example, we are actually only using the Extension highlighted in blue, so we really don’t need the other extensions for import-gpo to work. In our scenario, we could safely remove the other extensions below the extension highlighted in blue. Be aware that the entire GPO Extension lines MUST be in a continuous unbroken line otherwise Import-GPO will crash and terminate the current powershell session.

Finally, we have the gpttmpl.inf file that is stored in the same subfolder location as the live GPO. The file also is identical to what was present in SYSVOL. Be aware that this file MUST be encoded as UTF-16LE (Unicode).

To build our GPO to set just our User Rights assignment, the minimum number of files is 4 (2 hidden):

Manifest.xml in the root of the folder where the backup was created (outside the GUID folder) – hidden. backup.xml inside the root of the GUID folder bkupinfo.xml inside the root of the GUID folder – hidden. GptTmpl.inf in the same subfolder structure as the oriignal real live GPO (<Guid>\DomainSysvol\GPO\Machine\microsoft\windows nt\SecEdit)

The structure looks like this:

The Backup.inf file

What if I told you… we could build this all out and remove most of the values present in the backup.inf and still import fine with import-gpo ? Tune in next week for the next part in this series to learn more. I’ll put together some example template files.

In the mean time, here’s a sneak peak at the script that will be discussed: https://github.com/Jigsolving/powershell/blob/main/User%20Rights%20Assignment%20GPO/create-customURAGPO.ps1

Happy GPOing.

A full list of User Rights Assignment

The table below lists all the User Rights Assignments and their translated constant values. Each Policy setting is linked to a page over at Microsoft (***except one – there seems to be an error over there).

Notes: *You MUST specify at least Administrator for this right ** Administrators and SERVICE MUST be granted this right *** The associated description for this right is missing over at Microsoft at time of writing.

The featured photo in this post: Part of a photo by Francisco Jesús Navarro Hernández on Unsplash

RELATED ARTICLES MORE FROM AUTHOR

Domain join – minimum permissions, domain rejoin or prestaging – minimum permissions, install rsat tools via powershell, scheduled tasks: on event triggers with variables, protecting rpc, leave a reply cancel reply.

Save my name, email, and website in this browser for the next time I comment.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Set-GPPermission

Grants a level of permissions to a security principal for one GPO or all the GPOs in a domain.

Description

The Set-GPPermission cmdlet grants a level of permissions to a security principal (user, security group, or computer) for one Group Policy Object (GPO) or all the GPOs in a domain. You use the TargetName and TargetType parameters to specify a user, security group, or computer for which to set the permission level. You can use the Name or the Guid parameter to set the permission level for the security principal on a single GPO, or you can use the All parameter to set the permission level for the security principal on all GPOs in the domain.

By default, if the security principal already has a higher permission level than the specified permission level, the change is not applied. You can specify the Replace parameter, to remove the existing permission level from the GPO before the new permission level is set. This ensures that the existing permission level is replaced by the new permission level.

Example 1: Set the permission level for a security group belonging to a GPO

This command sets the permission level for the Domain Users security group to GpoRead for the GPO named TestGpo . Because the Replace parameter is not specified, if the group already has a permission level higher than GpoRead , such as GpoEdit , no action is taken.

Example 2: Set the permission level for a security group that belongs to all GPOs

This command sets the permission level for the Marketing Admins security group to GpoEdit on all GPOs in the domain. This includes GPOs that are not linked to any site, domain, or OU. Because the Replace parameter is specified, the new permission level overwrites the existing permissions set for the group.

Example 3: Replace the permission level of a security group for all GPOs on which the group has permissions

This command replaces the current permission level of the Marketing Admins security group with GpoApply for all GPOs on which the Group has permissions. The command returns each GPO for which the new permission level is set.

The cmdlet is used to get all the GPOs in the domain. Then, the collection is piped into the ForEach-Object command. As each GPO is evaluated, it is piped into Get-GPPermission . If a permission level for the Marketing Admins group is returned, the GPO is piped into Set-GPPermission to set the permission level for the group. The Replace parameter is specified to make sure that the previous permission level is overwritten.

The ErrorAction parameter is set to SilentlyContinue for Get-GPPermissions . This is because a non-terminating error occurs if the specified security principal does not have permissions on the GPO. Specifying ErrorAction as SilentlyContinue prevents the error messages from being printed for GPOs on which the security principal does not have permissions. For more information about the ErrorAction parameter, see about_CommonParameters .

Specifies that the permission level is set for the specified security principal for all GPOs in the domain.

Prompts you for confirmation before running the cmdlet.

-DomainName

Specifies the domain for this cmdlet. You must specify the fully qualified domain name (FQDN) of the domain.

For the Set-GPPermission cmdlet, the GPO for which to get the permission level must exist in this domain.

If you do not specify the DomainName parameter, the domain of the user that is running the current session is used. If the cmdlet is being run from a computer startup or shutdown script, the domain of the computer is used. For more information, see the Notes section in the full Help.

If you specify a domain that is different from the domain of the user that is running the current session (or, for a startup or shutdown script, the computer), a trust must exist between that domain and the domain of the user or the computer.

You can also refer to the DomainName parameter by its built-in alias, domain. For more information, see about_Aliases .

Specifies the GPO for which to set the permission level by its globally unique identifier (GUID). The GUID uniquely identifies the GPO.

You can also refer to the Guid parameter by its built-in alias, Id .

Specifies the GPO for which to set the permission level by its display name.

The display name is not guaranteed to be unique in the domain. If another GPO with the same display name exists in the domain, an error occurs. You can use the Guid parameter to uniquely identify a GPO.

You can also refer to the Name parameter by its built-in alias, DisplayName .

-PermissionLevel

Specifies the permission level to set for the security principal.

The acceptable values for this parameter are:

• GpoEditDeleteModifySecurity

Specifies that the existing permission level for the group or user is removed before the new permission level is set. If a security principal is already granted a permission level that is higher than the specified permission level and you do not use the Replace parameter, no change is made.

Specifies the name of the domain controller that this cmdlet contacts to complete the operation. You can specify either the fully qualified domain name (FQDN) or the host name.

If you do not specify the name by using the Server parameter, the primary domain controller (PDC) emulator is contacted.

You can also refer to the Server parameter by its built-in alias, DC .

-TargetName

The name of the security principal for which to set the permission level. You can specify a user, a security group, or a computer. You can use either the domain-qualified name of the security principal (domain\account) or just its name.

For instance, in the contoso.com domain, to specify:

The user SomeUser, use contoso\SomeUser or SomeUser .

The Domain Admins security group, use contoso\Domain Admins or Domain Admins .

The computer computer-01, use contoso\computer-01 or computer-01 .

-TargetType

The type of security principal for which to set the permission level. You must specify User, Group, or Computer.

Shows what would happen if the cmdlet runs. The cmdlet is not run.

Microsoft.GroupPolicy.Gpo

You can pipe an object that represents a GPO to this cmdlet. Collections that contain GPOs from different domains are not supported.

This cmdlet returns an object that represents the GPO for which the permission level was set.

You can use the DomainName parameter to explicitly specify the domain for this cmdlet.

If you do not explicitly specify the domain, the cmdlet uses a default domain. The default domain is the domain that is used to access network resources by the security context under which the current session is running. This domain is typically the domain of the user that is running the session. For example, the domain of the user who started the session by opening Windows PowerShell from the Program Files menu, or the domain of a user that is specified in a runas command. However, computer startup and shutdown scripts run under the context of the LocalSystem account. The LocalSystem account is a built-in local account, and it accesses network resources under the context of the computer account. Therefore, when this cmdlet is run from a startup or shutdown script, the default domain is the domain to which the computer is joined.

Related Links

• Get-GPPermission

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Managing User Rights in Powershell

Managing User Rights Assignments in Powershell

Windows User Rights, also known as Windows Privileges, are traditionally managed via GPO or in the simplest of cases via the server’s Local Security Policy. These assignments control special permissions that are often needed by IIS applications or other application hosting on Windows Servers.

So how can we manage these assignments in Powershell? There’s no obvious solution provided in Powershell, but there are several options are available. None of which are a pure Powershell solution, but some are close.

• Wrap the ntrights.exe process in Powershell. This is relatively simple, but the downside is having an external dependency on the ntrights.exe file.
• Embed a wrapper class to the LSA API in your script. This is a pretty good solution but certainly bloats your script.
• Load and Reference the Carbon DLL (If you haven’t already checked out this Powershell library, you should it is very powerful and regularly updated. I choose this approach because it keeps the script clean and compact, it returns an array of strings for easy interrogation. It does require a dependency on carbon.dll, but this library provides a ton of functionality beyond just this.

I like the 3rd option, its very clean, and I like working with the Carbon library.

Now lets take this script to the next level and wrap it into a DSC Script implementation. We can use this same logic in a DSC configuration to make sure our desired User Rights Assignments are kept in place.

What else can we do? We could also create a Custom DSC Resource to have a cleaner DSC Configuration.

Related Posts

Local Administrator Audit Script

Powershell Log Archival Script

My new stories.

Give Administrative Group Policy Permissions With PowerShell

In this blog post, I will show you how to grant users and groups administrative permissions to Active Directory Group policy using PowerShell.

Giving users or groups administrative permissions to a group policy comes with four types of permissions, as shown below:

• GpoEditDeleteModifySecurity

Apply Permission To a Single Policy

Below, I will create a new GPO and grant a group called Ops users the permissions to link it.

To check the permissions of the GPO, I will run the following cmdlet.

Apply To All Group Policies

To apply permissions to all the GPOs in the forest, I will run the following code.

Join my email list

By clicking submit, you agree to share your email address with the site owner and Mailchimp to receive marketing, updates, and other emails from the site owner. Use the unsubscribe link in those emails to opt out at any time.

NTW – Content Network

Using PowerShell and GPO for User Access Rights

If I have two apps running on a server and both have service accounts that have user rights assignments.

I want to know if I can apply the second service account user rights with PowerShell or will the GPO from the first account stop me from setting another account with similar user rights.

Related Topics

• About the Authors

Managing “Logon As a Service” Permissions Using Group Policy or PowerShell

“ Log on as a service ” is a security policy in Microsoft Windows operating systems that specifies which user accounts or groups are allowed to start and run Windows services. Services are programs running in the background and performing various tasks without user interaction. They are essential components of the Windows operating system and are used for networking, hardware management, and system monitoring tasks.

When a service starts, it must run under a specific user account, either a built-in system account or a custom user account. The “Log on as a service” policy defines which accounts or groups have the privilege to be assigned as the login credentials for these services. This policy is crucial for maintaining security and preventing unauthorized access to system resources.

Configuring the “Log on as a service” policy involves assigning specific accounts or groups the right to log on as a service. By default, only certain built-in accounts and groups have this privilege. Suppose an application or service requires a specific user account to function correctly. That account needs to be explicitly added to the “Log on as a service” policy to ensure it has the necessary permissions.

“Log on as a service” Rights vs. Privileges User Account

Assigning a specific user account to run Windows services using the “Log on as a service” privilege offers several advantages over using the built-in Local System account or other privileged user accounts:

• Principle of Least Privilege: The principle of least privilege suggests that users, processes, and services should have only the permissions necessary to perform their tasks. Assigning a dedicated user account to run a service allows you to grant precisely the required permissions for that service, reducing the risk of unintended actions or security breaches.
• Isolation of Services: By using individual user accounts for each service, you can isolate the privileges and resources associated with each service. This isolation helps prevent one compromised service from affecting other services or system components.
• Auditability: Using separate user accounts for services makes it easier to track and audit the activities of each service. In the event of security incidents or unauthorized access, it’s simpler to identify the responsible service when services are associated with distinct user accounts.
• Controlled Access: Assigning specific accounts to services allows you to control who has access to run those services. You can restrict the accounts with the “Log on as a service” privilege, reducing the attack surface and improving overall security.
• Password Management: Services associated with dedicated user accounts can manage their passwords separately. This is especially useful in scenarios where password changes are required periodically or when following password management policies.
• Compatibility: Some applications and services are designed to work best under a specific user context rather than the Local System account. Running them as the Local System might lead to compatibility issues or limited functionality.
• Granular Permissions: User accounts assigned to services can have finely tuned permissions. This is particularly important when services interact with specific network resources, databases, or other systems. Assigning the appropriate permissions ensures smooth service operation without granting excessive privileges.
• Debugging and Troubleshooting: When services run under a specific user account, troubleshooting issues becomes easier. You can log in with that account to test and diagnose problems directly, which can be more challenging when using the Local System account.

While there are definite benefits to using dedicated user accounts for services, managing these accounts effectively is essential. Proper management includes maintaining strong passwords, adhering to password policies, and ensuring that the accounts themselves are not susceptible to unauthorized access.

In some cases, certain services may require more extensive privileges, making using the Local System account necessary. But, when possible, using the “Log on as a service” privilege to assign specific user accounts to services is a recommended security practice that enhances control, accountability, and overall system security.

Managing “Log on as a service” Rights Assignments via Group Policy

You can configure the “Log on as a service” rights assignment via the local or domain group policy.

Note . When you deploy the “Log on as a service” policy via Group Policy Object (GPO), the policy settings you define in the GPO will overwrite the existing list of accounts on the target computers. The GPO settings for “Log on as a service” will replace any existing accounts or groups granted the privilege.

• If deploying via GPO, open the Group Policy Management console ( gpmc.msc ) and open the group policy object to modify or create a new one.
• If modifying the local machine’s group policy, open the local group policy editor ( secpol.msc )

Note . The “NT SERVICESERVICES” group is added to the “ Log on as a service ” policy by default on Windows Server 2016, Windows 10, and later.

• THEITBROS\CA IT Ops — domain group
• THEITBROS\jmiller — domain user
• PCX\localadmin01 — local user

Related post . Configure NTP Time Sync Using Group Policy

Managing “Log on as a service” Rights Assignments via PowerShell

Managing the “Log on as a service” rights assignments in the command line is beneficial for systems without a desktop environment, such as Windows Server Core, and when managing computers during remote PowerShell sessions.

There are no native PowerShell cmdlets to manage the “Log on as a service” policy as of this writing. The only native command line tool that can modify the local security policies is the secedit.exe tool.

Download the “Log on as a service” Management Scripts

So, we created three PowerShell script wrappers for secedit.exe that you can download from the following links:

• [ PS-Manage-Log-On-As-A-Service ] — The public GitHub repository.
• [ Get-ServiceLogonRight.ps1 ] — A script to retrieve the local machine’s current “Log on as a service” rights.
• [ Add-ServiceLogonRight.ps1 ] — A script to add a user and group to the “Log on as a service” policy.
• [ Remove-ServiceLogonRight.ps1 ] — A script to remove a user or group from the current “Log on as a service” policy.

Download the above scripts and store them in a folder on your computer. Then open an elevated PowerShell session (run as admin), and change the working directory to where you saved the scripts.

List the Current “Log on as a service” Rights Assignments

To list the current accounts in the “Log on as a service” policy, run the below script.

Add Users and Groups to the “Log on as a service” Policy

To add a user or group to the “Log on as a service” Policy, follow the below example commands.

# Add a local group .\Add-ServiceLogonRight.ps1 -UserOrGroup <local group>

# Add a domain user account .\Add-ServiceLogonRight.ps1 -UserOrGroup <DOMAIN\user>

# Add a domain group .\Add-ServiceLogonRight.ps1 -UserOrGroup <DOMAIN\group>

Confirm that the new users and groups were added to the “Log on as a service” policy.

What happens if you add a non-existing group or user to the “Log on as a service” policy? You’ll get this message.

Remove Users and Groups from the “Log on as a service” Policy

When a group or user is no longer viable for the “Log on as a service” policy, you can remove it using the Remove-ServiceLogonRight.ps1 script.

# Remove a local group .\Remove-ServiceLogonRight.ps1 -UserOrGroup localadmingroup02

# Remove a domain user .\Remove-ServiceLogonRight.ps1 -UserOrGroup ‘THEITBROS\ebrown’

# Remove a domain group .\Remove-ServiceLogonRight.ps1 -UserOrGroup ‘THEITBROS\CA Server Admins’

Run the .\Get-ServiceLogonRight.ps1 script to confirm that the users and groups have been removed.

What happens if you remove a user or group not existing in the “Log on as a service” policy? You’ll get the following message.

While there are scenarios where services necessitate greater privileges and the use of the Local System account, assigning specific user accounts through the “Log on as a service” policy is recommended to enhance control, accountability, and overall system security.

This article has also covered methods for managing “Log on as a service” rights assignments via Group Policy and PowerShell.

For PowerShell users, the article introduced scripts using the secedit.exe tool to manage these rights assignments. These scripts include Get-ServiceLogonRight.ps1 to retrieve current rights, Add-ServiceLogonRight.ps1 to add users or groups, and Remove-ServiceLogonRight.ps1 to remove them.

Lastly, minimizing the number of user accounts to which you grant the “Log on as a service” permissions is advisable. To reduce security risks, you should turn off interactive and remote interactive sessions for service accounts.

Cyril Kardashevsky

I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.

Understanding ProxyAddresses Attribute in Active Directory

Fix: unable to find a default server with active directory web services running.

Thank you. Literally NO ONE in Enterprise IT understands this about most of the stuff in the USer Rights Assignment of Group Policy. I’ve fixed so many outages due to admins settings this via GPO across many servers and overwriting what’s already set in there by x, y, z application that was installed who put accounts in there. Admins just blindly follow along application documentation or posts like this. I’m so tired of it.

– Angry Sr. Systems Admin LOL

Been like this for 20 years now.

Microsoft really needs to add switches for append, remove and replace for setting group policy objects, or just remove these from GPO management altogether as it’s half baked.

Please follow this up with how to set Logon As a Service for a user or group policy on Windows Server 2016 Core – there is no GUI, no control panel, no gpedit.msc, no gpmc.msc, no services.msc, etc etc.

For example, to setup Jenkins requires a user account with Logon As a Service enabled. Thank you

Leave a Comment Cancel Reply

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

How to add a user group in the "Shut down the system" group policy in Windows Server by CMD or PowerShell

I've read some documentation on Microsoft and other sites. Some of them suggest GPRegistryValue for registry-based policies and other recommended third-party software.

The full path of the key is: "Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment"

But in my case I cannot use other packages except CMD or PowerShell (UI not available).

• group-policy
• windows-server

• superuser.com/questions/1254253/… and blakedrumm.com/blog/set-and-check-user-rights-assignment might help you for a starting point to play with. –  Vomit IT - Chunky Mess Style Nov 25, 2022 at 21:25
• This is just local security policy settings. What did you search for as this is a common task? powershell 'Local User Rights Management' –  postanote Nov 25, 2022 at 21:37

Windows provides the secedit.exe tool for this and or custom code, as per the link provided in my comment to you.

Also, did you check the mspowershellgallery.com site for modules that assist with local user security policy?

Update as per '@Vomit IT - Chunky Mess Style', suggestion.

The more succinct/elegant option.

FYI --- Update for '@Vomit IT - Chunky Mess Style'. Using the PS_LSA.Wrapper

• 1 @VomitIT-ChunkyMessStyle... update provided. –  postanote Nov 25, 2022 at 21:43
• Oh yeah, now you're talking!!! I saw github examples of that Indented.SecurityPolicy you suggested listed there. I like it! –  Vomit IT - Chunky Mess Style Nov 25, 2022 at 21:55
• 1 Yeppers, I've got a bunch of these I've collected, refactored, and written over the years in different engagements. Even one using the underlying OS PS_LSA Windows library. –  postanote Nov 25, 2022 at 22:06
• Thanks for helping me.The module of 'SecurityPolicy' is available, but when I try to find its modules "Get-Command -Module 'SecurityPolicy'" nothing is listed. Thus, I can't execute 'Add-UserRightsAssignment'. –  Daniel Teodoro Nov 29, 2022 at 13:38
• If you did this Get-Command -Module 'SecurityPolicy' , and you see nothing? If so, that means it's not installed/in your PSModulePath. Did you install the module as I show in my suggested answer? If not, then you need to. Then you use Get-Module -ListAvailable to validate it's on your system. –  postanote Nov 30, 2022 at 6:37

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged powershell group-policy windows-server ..

• The Overflow Blog
• What a year building AI has taught Stack Overflow
• Want to be a great software engineer? Don’t be a jerk.
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network
• Google Cloud will be Sponsoring Super User SE

Hot Network Questions

• What caused pink flares during the eclipse
• Do batteries have capacitance?
• Manga about a boy whose girlfriend was drafted into war against aliens
• What happens when an automatic transmission completely fails?
• Sight reader or busker?
• Why did Nicaragua file a case against only Germany at the ICJ?
• Average momentum of particle/anti-particle pairs
• Can you use existing in home coax cables to connect a Leaf antenna to TV?
• How do I deal with crying in front of my supervisor?
• Endomorphisms of simple dualizable objects in a linear abelian monoidal categories
• The sum of two linear compact operators is a linear compact operator
• Book about teen girl living in a town by herself (with her dog) as everyone died of radiation poisoning
• How do I properly exit a program and return to the CCP in CP/M?
• Split String Function Implementation in Python
• Can "sit" mean "receive no attention"?
• What is the difference between mind and consciousness?
• NSF grant proposal not reviewed despite being received
• Are wider tires on a road bike a good idea?
• What's a word that would describe "Technical Aptitude" as an "attribute"
• During the reformation what was the common view on how the Law ‘increased sin‘ rather than reducing it?
• Determining the CR of a monster with a 50% chance of absorbing damage
• Am I in my rights to ask a colleague to not take notes on everything I say outside a meeting?
• What is SpaceX doing differently with their falcon 9 so that it doesn't cost as much as the Space Shuttle?
• Is it good practice to place decoupling capacitors near connector pins?

AD Security 101: Lock Down Risky User Rights

• Active Directory Security
• Jun 16, 2023

In Active Directory (AD) environments, you can use Group Policy Objects (GPOs) to configure user rights. By using GPOs, you can easily enforce consistent user rights policies across all computers in the domain or organizational unit (OU). This capability makes it easier to manage and maintain user access control over time. But when granted to users who should not have them or when configured incorrectly, certain user rights can pose an AD security risk. Here’s what you need to know to protect AD—and your environment—from risky user rights.

What are user rights?

User rights are permissions that control user actions on a computer system. These rights differ from standard file and folder permissions and apply to specific user actions. User rights include (but are not limited to):

• Allow log on locally : Allows users to log on to a computer locally
• Change the system time : Allows users to change the system time on a computer
• Shut down the system : Allows users to shut down the computer
• Debug programs : Allows users to debug programs running on the computer
• Manage auditing and security log : Allows users to view and manage security logs on a computer
• Take ownership of files or other objects : Allows users to take ownership of files or other objects on a computer
• Load and unload device drivers : Allows users to load or unload device drivers on a computer
• Back up files and directories : Allows users to back up files and directories on a computer
• Restore files and directories : Allows users to restore backed-up files and directories on a computer
• Allow log on through Remote Desktop Services : Allows users to manage remote access to a computer

Using GPOs to configure user rights

To configure user rights using a GPO, first create or edit a GPO that applies to the users or computers that you want to configure. You need to link the GPO to the relevant domain or OU level. Then, you can use the Group Policy Editor application to specify the user rights that you want to assign. (A similar process applies to configuring GPO logon scripts, as discussed in a previous AD Security 101 post .)

To configure user rights:

• Open Group Policy Editor.
• Go to the Computer Configuration section.
• Select Windows Settings .
• Select Security Settings .
• Go to the Local Policies section.
• Select User Rights Assignment .
• Select the user right that you want to configure.
• Add the users or groups that should be granted that right.

For example, to grant a user the right to log on locally to a specific computer, select the Allow log on locally user right and then add the user to the list of allowed users.

Risky user rights and AD security

How can user rights pose a security risk? Consider the following example.

Suppose the Debug programs user right is granted to a user who does not need it. That user—or an attacker who manages to gain access to that user’s credentials—can use this right to:

• Debug a system process that runs as an elevated user
• Inject malicious code
• Gain system-level access
• Access sensitive data or processes that they would not normally have access to
• Disable security features or anti-malware tools on the system

Similarly, if the Change system time user right is granted to a user who should not have the right, that user (or an attacker) can modify the system time and cause issues with time-sensitive applications or services.

Additional potentially risky user rights include:

• Log on as a service
• Allow log on locally
• Act as part of the operating system

To determine which user rights are assigned to a user in AD, you can open the right for editing in the Group Policy Management Console (GPMC). Another option is to use GPO command-based tools (CLI or PowerShell) to check GPOs and their respective settings, including user rights assignments.

However, large organizations with thousands or more user objects and OUs can have tens or hundreds of GPOs, each containing multiple accumulated (and often overlapping) settings. For example, a domain-level GPO might assign specific user rights to one set of users or groups, while another OU-level GPO might add other user rights to some of those same users or groups.

As your AD environment evolves and changes over time, the complexity of the GPOs assigned to domain, sites, or OUs typically also increases. All these assignments gradually become more difficult to manage, making it challenging to determine which setting applies to which user.

Protecting AD from risky user rights

To mitigate the risks associated with a user right:

• Verify that the right is granted only to users who require it for specific tasks.
• Carefully monitor all users who are assigned the right.
• Protect sensitive processes so that they cannot be debugged by unauthorized users.

To ease the task of continuously assessing your AD security posture—including potentially risky user rights—you can use tools such as Purple Knight or Semperis Directory Services Protector (DSP) . When executed in your environment, these tools enumerate and parse all GPOs, determine whether any non-well-known SID has been assigned a “strong” non-default user right, and generate a clear report of these details. You can examine these findings to determine which unnecessary user rights to remove from the GPOs in your environment.

Using Purple Knight to secure risky user rights

Figure 1 shows a Purple Knight report indicating the assignment of a dangerous GPO-granted user right.

The report shows the severity of risk, describes the likelihood of compromise, lists the users who are assigned the right, and suggests remediation measures.

Using DSP to secure risky user rights

Figure 2 shows a DSP report indicating the assignment of a dangerous user right.

This report includes the same details as the Purple Knight report. With DSP, you also gain remediation capabilities, including custom alerts and automatic rollback of malicious changes, to help you mitigate the risk.

Keep tabs on risky user rights

After mitigating any risky user rights assignments, you should re-scan the AD environment to determine whether additional changes are required. You should continue to perform periodic scans of your AD to verify that no unauthorized changes are made to these settings.

Learn more about AD security

• AD Security 101: GPO Logon Script Security
• Do You Know Your Active Directory Security Vulnerabilities?
• AD Change Auditing and Rollback

Sign Up for the Latest Semperis News

• Oct 9, 2022

How to Create GPOs with Restricted Groups using PowerShell.

Updated: Oct 9, 2023

If you have ever tried 'PowerShell'ing' Group Policies, you know that support from Microsoft is sub-optimal, meaning that there is no support, of course, to fill this gap there are paid 3rd party offerings.

The Task at Hand:

A new 'Member Server' OU and various sub-OU's are needed, as well as their corresponding Group Policies, AD Groups and Restricted Groups. This feels like the millionth time I've manually accomplished this task and it's fairly repetitive and time consuming, alternatively, I can crack open PowerShell. The mantra is 'Why point and click when there's PowerShell' so let's get creative.

Components of a Domain GPO:

A Group Policy Object (GPO) is made up of various file types, strangely enough, the same as local GPO's configured via GPEdit.msc. Having scripted SecEdit, updating both User Rights AssignmenPats (URA) and Services previously the 'ask' should be straightforward.

Basic file layout of a Domain GPO:

C:\Windows\SYSVOL\domain\Policies\{GUID}\

Machine\Registry.pol

User\Registry.pol

Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Machine\Microsoft\Windows NT\Audit\Audit.csv

GPO security settings are written to GptTmpl.inf, an example of a GptTmpl.inf with Restricted Groups and User Rights Assignments from an SCCM installation including a SQL Member Server.

The above looks a little confusing and here's a quick breakdown to help:

*S-1-5-21-4000739697-4006183653-2191022337-1143

The SID of a Service Account

[Group Membership]

*S-1-5-32-544__Memberof =

*S-1-5-32-544__Members = *S-1-5-21-4000739697-4006183653-2191022337-1143

*S-1-5-32-544 = Builtin\Administrators Group

*S-1-5-32-573__Memberof =

*S-1-5-32-573__Members = *S-1-5-21-4000739697-4006183653-2191022337-1171

*S-1-5-32-573 = Builtin\Event Log Readers

*S-1-5-32-559__Memberof =

*S-1-5-32-559__Members = *S-1-5-21-4000739697-4006183653-2191022337-1171

*S-1-5-32-559 = Builtin\Performance Log Users

[Privilege Rights]

SeServiceLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1170

SeServiceLogonRight = Log on as a service

SeInteractiveLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1169

SeInteractiveLogonRight = Allow log on locally

SeBatchLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1187

SeBatchLogonRight = Log on as Batch

Overview of script actions:

Execute the script directly on the Domain Controller with the PDC role. The script will create a 'Resources' OU off the root of the Domain, then sub-ou's 'Member Servers' and 'Restricted Groups'. For each application service eg Exchange, SharePoint etc, an additional OU is then created with corresponding AD groups for both Administrator and Remote Desktop User Groups. Finally, GPOs are created for each OU and the AD Groups SID are assigned to both the Restricted Groups and Remote Interactive User Rights Assignment.

The script:

https://github.com/Tenaka/GPOs

Script Breakdown:

The following are extracts from the script that is accessible from Github.

Resolve the Domain Naming Context.

$rootDSE = (Get-ADRootDSE).rootDomainNamingContext

Resolve the path to Sysvol, just in case it was moved during Domain Controler installation.

$smbSysvol = ((Get-SmbShare -name "sysvol").path).replace("SYSVOL\sysvol","sysvol")

Set 'Resource' OU as a root for all subsequent OU's for member servers etc.

$resRoot = "Resources"

Stitch or join the Root DN and variables to create OU Distinguished Names.

$resourceOU = "OU=$($resRoot),$($rootDSE)"

$memSrvOU = "OU=$($memSrvRoot),OU=$($resRoot),$($rootDSE)"

$ResGroupOU = "OU=$($ResGroupRoot),OU=$($resRoot),$($rootDSE)"

Create an OU called 'Resources' as a top-level OU.

New-ADOrganizationalUnit -Name $resRoot #-ProtectedFromAccidentalDeletion $false

Create a variable based on the OU name for creating an AD group name.

$rgRtAdminGp = "RG_$($MemSrvRoot)_Admin"

Create a new Domain Global group based on the OU name for Admin and Remote user groups. Groups are created in the 'Restricted Groups' OU.

New-ADGroup -Name $rgRtAdminGp –groupscope Global -Path $ResGroupOU -Description $rgRtAdminDescrip

Get the SID of the new Group.

$getRtRGAdminSid = $getRtRGAdmin.SID.Value

Declare the variable for creating an OU.

$GPOName = "GPO_$($MemSrvRoot)_RestrictedGroup"

Create a new OU based on the variable and link to OU.

New-GPO -Name $GPOName | New-GPLink -Target $getOUMS.DistinguishedName

Set delegation permission on the OU so the AD group can edit their own policy.

Set-GPPermission -Guid $getGpoId -PermissionLevel GpoEditDeleteModifySecurity -TargetType Group -TargetName $rgAdminGp

Declared the path to the GPO directory.

$sysvol = "$($smbSysvol)\domain\Policies\{$($getGpoId)}\Machine\Microsoft\Windows NT\SecEdit"

Create a directory and GptTmpl.inf file.

New-Item -Path $sysvol -ItemType Directory -Force

New-Item -Path $sysvol -Name GptTmpl.inf -ItemType File -Force

Declare variables based on the Group SIDs for Admin and Remote Groups.

$addConAdmin = "*S-1-5-32-544__Members = *$($getRtRGAdminSid)"

$addConRDP = "*S-1-5-32-555__Members = *$($getRtRGRDPSid)"

$addConURARemote = "SeRemoteInteractiveLogonRight = *$($getRtRGAdminSid),*$($getRtRGRDPSid)"

Update GptTmpl.inf.

Add-Content -Path $gptFile -Value '[Group Membership]'

Add-Content -Path $gptFile -Value '*S-1-5-32-544__Memberof ='

Add-Content -Path $gptFile -Value $addConAdmin

Add-Content -Path $gptFile -Value $addConURARemote

Write the GPCMachineExtensionName attribute with the Client-Side Extension GUID of the areas of the GPO setting for the GPO. If not the settings won't display in the GPO Management tool and the target server won't be able to read the GPO.

Set-ADObject -Identity $getGPOPath -Replace @{gPCMachineExtensionNames="[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]"}

The Client-Side Extensions GUID can be extracted from Polices, there's no need to try and discover those GUIDS. Set the required policies and copy the GUIDs.

The initial scenario of creating Restricted Groups GPO's is complete, with a few alterations, Administrative Template settings could be set by copying Registry.pol into the GPO. A better use would be setting up URAs for service accounts eg SQL and the Logon as a Service right dynamically as part of an automatic installation of Microsoft SQL Server.

Enjoy and hope it proves useful and do give it a go prior to paying for a 3rd party tool.

Security Identities:

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers

Mapping User Rights Assignments:

https://www.tenaka.net/post/translate-user-rights-assignments-from-guids-to-group-names

Recent Posts

Deploy Domain Controllers with PowerShell and JSON (Part 1) - Domain Controllers

Deploy Domain Controllers with PowerShell and JSON (Part 2) - OU Structure and Delegation

This script is cool, thank you for posting it with a great writeup too.

• Assign User Rights to a Group in AD DS

Membership in Account Operators , Domain Admins , or Enterprise Admins , or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at https://go.microsoft.com/fwlink/?LinkId=83477 .

To open Group Policy Management, click Start , click Run , type gpmc.msc , and then click OK .

In the console tree, right-click Default Domain Controllers Policy , and then click Edit .

• Domains\ Current Domain Name \Group Policy objects\Default Domain Controllers Policy

In the console tree, click User Rights Assignment .

• Windows Settings\Security Settings\Local Policies\User Rights Assignment

In the details pane, double-click the user right that you want to assign.

Click Add User or Group .

If the button appears dimmed, select the Define these policy settings check box.

Type the name of the group to which you want to assign this right.

Additional considerations

• To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
• To perform this procedure, you must first install Group Policy Management as a feature in Server Manager.
• You can also perform the task in this procedure by using the Active Directory module for Windows PowerShell. To open the Active Directory module, click Start , click Administrative Tools , and then click Active Directory Module for Windows PowerShell . For more information, see Assign User Rights to a Group in AD DS ( https://go.microsoft.com/fwlink/?LinkId=138383 ). For more information about Windows PowerShell, see Windows PowerShell ( https://go.microsoft.com/fwlink/?LinkID=102372 ).

Additional references

• Managing Groups

Table Of Contents

• Understanding User Accounts
• Create a New User Account
• Reset a User Password
• Copy a User Account
• Move a User Account
• Set Logon Hours
• Disable or Enable a User Account
• Map a Certificate to a User Account
• Change a User's Primary Group
• Delete a User Account
• Understanding Group Accounts
• Create a New Group
• Add a Member to a Group
• Convert a Group to Another Type
• Change Group Scope
• Delete a Group
• Find Groups in Which a User is a Member
• Understanding Computer Accounts
• Create a New Computer Account
• Add a Computer Account to a Group
• Delete a Computer Account
• Manage a Remote Computer
• Move a Computer Account
• Reset a Computer Account
• Disable or Enable a Computer Account
• Understanding Domains
• Manage a Different Domain
• Manage the Domain Using a Different Domain Controller
• Understanding Organizational Units
• Create a New Organizational Unit
• Delete an Organizational Unit
• Move an Organizational Unit
• Delegate Control of an Organizational Unit
• Troubleshooting Active Directory Users and Computers
• Resources for Active Directory Users and Computers
• <Object> Properties - Object tab
• User Properties - Profile Tab
• User Properties - Account Tab
• Computer Properties - Delegation tab
• Read-only Domain Controller Properties - Password Replication Policy Tab
• Advanced Password Replication Policy Dialog Box - Policy Usage Tab
• Advanced Password Replication Policy Dialog Box - Resultant Policy Tab
• Prepopulating Passwords
• New Object - Organizational Unit Dialog Box
• Change <Domain> or <Forest> Dialog Box
• Change Domain Controllers Dialog Box
• Raise Domain Functional Level Dialog Box
• Tasks to Delegate
• Active Directory Object Type
• Permissions