dcom 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

• DigiCert product docs
• Trust Lifecycle Manager
• Integration guides
• DigiCert Autoenrollment Server
• Install Autoenrollment Server

Configure DCOM access rights

The Autoenrollment server is invoked by using the Distributed Component Object Model (DCOM). It is important to ensure that Microsoft Windows is configured for local DCOM access for system processes and accounts with administrative privileges.

On the My Computer > Default Properties tab, select the Enable Distributed COM check box.

Then, use certutil to ping "config", and autoenrollment should succeed. If you do not enable DCOM, then autoenrollment fails with the error "RPC server unavailable."

The usage of certutil commands is as follows:

To find the value of the config attribute, run the following command:

certutil -dump

The command will list name-value pairs including "config". For example, ‘SERVER\my ca’ . You must ignore the single quotes while copying the value.

Enter the “config” value copied above, within double quotes if it contains any spaces, using the -config flag in the following command:

C:> certutil -ping -config "SERVER\my ca

For example, the output will be displayed as follows:

Connecting to SERVER\my ca Server "<serverName>" ICertRequest2 interface is alive CertUtil: -ping command completed successfully

If you want to use autoenrollment services, you need to configure the system to allow global DCOM object access. You must also allow remote DCOM access to use the Autoenrollment Server across multiple machines.

To Configure DCOM access rights as the domain administrator on the machine on which the Autoenrollment Server is installed:

In Administrative Tools > Component Services , select Component Services in the left pane, and expand the tree view to the left of Computers .

Right-click My Computer and select Properties .

Select the COM Security tab.

Modify the access permissions:

In the Access Permissions dialog, select Edit Limits .

Set Configure Domain Computers: Allow Local and Remote Access .

Set Configure Domain Controllers: Allow Local and Remote Access .

Set Configure Domain Users: Allow Local and Remote Access .

If the groups for which you want to configure access permissions are not listed, you must add them (select Add and enter the group names). If you are not able to add the desired groups, you may need to add the object type by selecting Object Types . Note that the image below shows Local and Remote Access permissions granted to Everyone . If you have no special security requirements, you may want to grant access permissions to this group and remove other trustees from the list.

Perform the following steps to adjust the launch and the activation permissions:

Select Edit Limits under the Launch and Activation Permissions group.

Set Configure Domain Computers: Activate Local Activation and Remote Activation , and clear the Local Launch and Remote Launch check box.

Set Configure Domain Controllers: Activate Local Activation and Remote Activation , and clear the Local Launch and Remote Launch check box.

Set Configure Domain Users: Activate Local Activation and Remote Activation , and clear the Local Launch and Remote Launch check box.

You can add Active Directory users or groups that are authorized for configuring client certificate profiles. Once added, assign the appropriate permissions (similar to the permissions assigned to Domain Computers).

Search results

Searching...

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

A wrapper around secedit.exe to configure local security policies

dsccommunity/SecurityPolicyDsc

Folders and files, repository files navigation, securitypolicydsc.

A wrapper around secedit.exe to allow you to configure local security policies. This resource requires a Windows OS with secedit.exe.

Code of Conduct

This project has adopted this Code of Conduct .

For each merge to the branch master a preview release will be deployed to PowerShell Gallery . Periodically a release version tag will be pushed which will deploy a full release to PowerShell Gallery .

Contributing

Please check out common DSC Community contributing guidelines .

A full list of changes in each version can be found in the change log .

• AccountPolicy : Configures the policies under the Account Policy node in local security policies.
• SecurityOption : Configures the policies under the Security Options node in local security policies.
• SecurityTemplate : Configures user rights assignments that are defined in an INF file.
• UserRightsAssignment : Configures user rights assignments in local security policies.

AccountPolicy

For further explanation of these settings, please consult Account Policies Reference .

Note: The below settings pertain to Kerberos policies and must be set by a member in the domain admins group.

SecurityOption

For further explanation of these settings, please consult Security Options Reference .

SecurityTemplate

Userrightsassignment, code of conduct, contributors 24.

• PowerShell 100.0%

P: 1-888-665-3678 (US) or +1-704-849-2773 (Global), F: +1-704-849-6388 148A East Charles Street, Matthews, North Carolina, USA 28105 © Copyright Software Toolbox, Inc. 1996-20132011, All Rights Reserved Worldwide.  

This browser is no longer supported.

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

User Rights Assignment

• 1 contributor

Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows. User rights govern the methods by which a user can log on to a system. User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the User Rights Assignment item.

Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment , or on the local device by using the Local Group Policy Editor (gpedit.msc).

For information about setting security policies, see Configure security policy settings .

The following table links to each security policy setting and provides the constant name for each. Setting descriptions contain reference information, best practices for configuring the policy setting, default values, differences between operating system versions, and considerations for policy management and security.

Related topics

• Security policy settings reference

Additional resources

DCOM settings for Remote Servers

To start a server as remote server, the DCOM settings must ensure that the client can access the server and that the server is able to reach the client via callbacks and can send data.

You have to check the following settings on the computer on which the OPC server is running in order to establish DCOM connection:

General (system-wide) DCOM settings

Server-specific DCOM settings

User Account (only if you are using workgroups)

Disable the Windows firewall

DCOM was meant to be used in networks without any active firewall and where all computers belong to the same domain. Therefore, the configuration of DCOM in current networks is rather complicated and does not meet the increasing security requirements. The settings described in this chapter also have a negative impact on the network security. Therefore, to maintain the network security, we recommend to install a minimal WinCC OA version on the computer on which the OPC server is running and start the OPC driver as remote WinCC OA driver.

DCOM-Konfiguration

To use OPC via DCOM you have to configure DCOM correctly. It is possible to configure DCOM system-wide as well as server-specific.

System-wide DCOM settings

Open the window Component Services ("Windows button + R" > Enter "dcomcnfg" > OK).

Go to Console Root > Component Services > Computers in the tree view, click on My Computer with the right mouse button and select the context menu entry Properties .

Default Properties

Change to the Default Properties tab and apply the following settings:

Select Enable Distributed COM on this computer

Set the Default Authentication Level to Connect

Select the Default Impersonation Level to Identify

COM Security

Change to the COM Security tab.

Access Permissions

Click on the Edit Default button in the Access Permissions area and apply the following settings:

Add the users Anonymous, Everyone, Interactive, Network a nd System

Set Local and Remote Access to Allow for all mentioned user names.

Launch and Activation Permission

Click on the Edit Default button in the Launch and Activation Permission area and apply the following settings:

Set Local and Remote Launch respectively Local and Remote Activation to Allow for all mentioned user names.

Proceed with the server-specific DCOM settings after completing the general DCOM configuration.

Component Services - DCOM Config

Under Console Root > Component Services > Computers > My Computer click on the DCOM Config folder and select the appropriate OPC server.

Open the context menu with a right mouse click on the OPC server and select the entry Properties .

General Tab

Select the Connect entry from the Authentication Level selection list.

Security Tab

Change to the Security tab.

Select the Customize option in the Launch and Activation Permissions and Access Permissions area.

Add the users Anonymous, Everyone, Interactive, Network and System

Access Permission

Endpoints Tab

Change to the Endpoints tab. If the Connection-oriented TCP/IP entry is not displayed in the DCOM Protocols and endpoints field, you have to add it as follows:

Click on Add, select Connection-oriented TCP/IP from the selection list and enable the Use default endpoints checkbox.

Change to the Identity tab and select the This user option. Enter the appropriate user name and password.

Local Security Policy

To establish a DCOM connection between two computers, both computers must have appropriate access permission. If both computers are running in the same domain, user data is automatically synchronized. In this case, the steps described in this section are not necessary. However, if you are using workgroups you have to consider the following settings.

This configuration may have a negative impact on the network security.

Open the following window ( Start > Control Panel > Administrative Tools > Local Security Policy ).

Security Options - DCOM: Machine Access Restrictions

Go to Security Settings > Local Policies > Security Options, open the context menu with a right mouse click on DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax and select the Properties entry.

Click on the Edit Security button.

Security Options - DCOM: Machine Launch Restrictions

Back in the security options list, open the context menu with a right mouse click on DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax and select the Properties entry.

Security Options - Network access: Let Everyone permissions apply to anonymous users

Open the context menu with a right mouse click on the Network access: Let Everyone permissions apply to anonymous users entry and select the entry Properties . Choose the Enabled option in the Properties .

User Rights Assignment

Change to Security Settings > Local Policies > User Rights Assignment , open the context menu with a right mouse click on Access this computer from network and select the Properties entry.

Add the users Everyone and Users .

The Windows firewall prevents the DCOM communication. Go to Start > Control Panel > Windwos Firewall, select Turn Windows Firewall on or off and disable the Windows firewall.

If the following error occurs, you have to disable the firewall on the client as well:

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.

Which permissions/rights does a user need to run "Get-WmiObject win32_service" on a remote machine?

I am in almost the same situation as the person who asked this question (link). The only difference is that I'm not writing a monitoring service but trying to get a WMI-based monitoring service to work.

However after reading the linked question (and its answers) I am able to run the "Get-WmiObject win32_logicaldisk -computername WINSRV.genericdomain.local" command in a PowerShell remote-session without getting the "access denied" error as I followed the steps mentioned in the accepted answer.

Unfortunately executing the "Get-WmiObject win32_service -computername WINSRV.genericdomain.local" command gives me the error which I mentioned above ("access denied").

That is why I'm wondering if there are any other permissions the user needs in order to be able to successfully use the command in a PowerShell remote-session.

So, my questions is: what permissions/rights does my user require for this?

• permissions

2 Answers 2

I found out that you have to tweak the Service Control Manager security settings of Windows in order to get that command working.

I found the solution in this answer on stackoverflow.

Executing this command from the command prompt of the remote machine did the trick for me:

People might want to read a little bit more about this topic. In this article you can find find some more informations on adjusting these settings.

You must allow WMI through the Windows Firewall

On the target machine, as an admin, at the command prompt type netsh firewall set service RemoteAdmin enable

Per your post, you've already handled the DCOM stuff. For your reference https://msdn.microsoft.com/en-us/library/Aa393266.aspx Follow the steps

• To grant DCOM remote launch and activation permissions for a user or group
• To grant DCOM remote access permissions

Make sure the account you desire to use has the appropriate WMI permissions. This reference link is excellent for the steps on authorizing users for WMI access on your local computer and the remote computer. https://technet.microsoft.com/en-us/library/cc771551.aspx

Also, just for your consideration, for Powershell remoting to work, PSRemoting must be enabled on the target computer you want to manage remotely with Powershell. https://4sysops.com/archives/enable-powershell-remoting/

• Thanks a lot for your answer. It helped me to get sure that I had the DCOM settings done and the WMI permissions set correctly. It turned out that you have to tweak the Service Control Manager security settings in order to get that command working. I found the command which did the trick on stackoverflow. Here is the link to the answer: stackoverflow.com/a/4432737/5337142 . –  P. Albrecht Nov 9, 2015 at 16:41
• Gotcha. I am glad you got it solved and also I am glad to help! –  Art.Vandelay05 Nov 9, 2015 at 22:43

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged windows permissions service wmi dcom ..

• The Overflow Blog
• Why configuration is so complicated
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• How long would it take for nature to reclaim a completely abandoned city?
• When I am pedaling harder on a slope, the chain sometimes skips or get detached
• How may I find the string length of the index number of a bash array?
• Can someone be awarded the title of doctor without having been a doctoral student?
• Can my username include a D&D monster?
• Was Jesus physically anointed by someone?
• Manuscript rejected by a journal director
• Why different translations of Luke 2:14?
• How to politely say that I am not doing extra work after back to the office policies?
• What is this strake near the nose of the MD-80 for?
• Create a snail matrix
• Is every extension of by an Abelian Group isomorphic to a central extension?
• Why is store-bought ajvar marked as consume within 3-4 days?
• How do I find broken symbolic links in macOS?
• Improving my approach for plain water boiled brown lentils
• What's the reverse operation of TransferFunctionExpand?
• How practical would it be to use a handgun-knife hybrid weapon?
• Wordsworth and parts of speech
• Expressing a quantum state as a polynomial
• Can a connected planar graph have 10 vertices and edges? is this possible?
• What legal basis exists for challenging absurd (but technically-correct) invoices?
• Is there a way to make a series change signs every 2 terms?
• Make the number 606 50 percent bigger
• Is there a formalization of the butterfly effect?

Remote WMI With Read-Only Account

As a general rule, all Exoprise components operate in read-only mode. In most trial environments, running the Exoprise components as domain admin is the quickest installation option. If using a domain admin account isn’t acceptable, please follow the steps below to operate Exoprise components in a least privilege configuration.

In addition to read-only access to Active Directory (AD), Active Directory Federated Service (ADFS), or Exchange Server endpoints, some Exoprise components require Windows Management Instrumentation (WMI) access. WMI gives Exoprise access to the performance counters exposed by the target machine. Information collected via WMI is often a critical component of the overall service health. Therefore, a least privilege configuration will require that WMI access is provided to Exoprise components. The steps below were authored to detail how you would enable access to WMI providers for Exoprise components without using Administrator-level accounts in your Active Directory domain or forest.

The steps below were based on a Windows Server 2003 R2 Active Directory domain controller. Exact procedure steps may differ slightly if you are using Windows Server 2008 or 2012, Windows 7, or Windows Vista.

Prerequisites

• Full administrator rights to the domain or forest in which you will be making the changes
• Administrator rights to all servers in your AD for which you wish to enable WMI access

Group Membership, Security Policy Assignments And Permissions

• If you haven’t already done so, create a domain account that will represent the user that Exoprise will run as in your environment.
• Create a domain group that will receive all of the rights that the Exoprise user needs. Note: As a best practice, always assign permissions to a domain group instead of directly to a user account.
• Put the Exoprise user into this newly-created group.
• Put the newly created Exoprise group into the following domain groups: Performance Log Users Distributed COM Users
• the Local Security Policy snap-in (secpol.msc) for member servers, or
• the Default Domain Security Policy snap-in (dompol.msc) if you wish to configure these settings domain-wide as a GPO, or
• the Default Domain Controller Security Settings snap-in (dcpol.msc) if you wish to assign the rights only on domain controllers.
• Once the snap-in is started, expand Security Settings, then Local Policies, and finally User Rights Assignment.
• Act as part of the operating system
• Log on as a batch job
• Log on as a service
• Replace a process level token
• Exit the Policy Settings utility.

Distributed Component Object Model Rights Assignments

Configure DCOM security for the Exoprise group.

• Run Component Services by selecting Start -> Administrative Tools -> Component Services.
• Once there, expand Console Root, then Computers, and finally My Computer. Right-click on My Computer and select Properties…
• In the window that appears, click on the COM Security tab.
• Under Access Permissions, click Edit Limits.
• Review that the Distributed COM Users group has all items checked under Allow.
• Note: This step is not required, since the Exoprise group is a member of Distributed COM Users.
• Once you’ve reviewed the presence of Distributed COM Users, or added the Exoprise group, click OK to save your changes and be returned back to the COM Security tab.
• Now, under “Launch and Activation Permissions”, click Edit Limits.
• Like with the “Access Permissions” window, you are presented with a list of groups and permissions. You need to make sure that the Distributed COM Users group has all items checked under Allow.
• Note: This step is not required, since the Exoprise group is already a member of Distributed COM Users.
• Click OK to save your changes.
• Exit the Component Services utility. .

WMI Namespace Security Assignments

Set WMI namespace security so that the Exoprise group has access to WMI objects.

• From the Start menu, select Run…, and in the window that opens, type in wmimgmt.msc in the “Open:” field and click OK.
• Once there, right-click on WMI Control (Local) and click Properties.
• Click on the Security tab.
• Click on the Security button at the bottom right of the window. This action edits the security settings for the Root WMI namespace.
• You’ll now see a window that has the security settings for WMI on this machine. Click Advanced…
• Execute Methods
• Enable Account
• Remote Enable
• Read Security
• Note: Make sure that these permissions apply to this namespace and all the namespaces under it. Do that by selecting This namespace and subnamespaces in the dropdown box above the permissions list window.
• Click OK to save the new permissions.
• Then, click OK again to exit out of the Advanced Security Settings.
• Click OK a third time to exit the security properties.

Firewall Changes, UAC, Restarts And Testing

Now that you’ve set WMI namespace security, you need to make sure that Windows Firewall is not blocking WMI traffic.

• Enabling and disabling Windows Firewall in Windows Server 2003 (TechNet)
• Enabling and disabling Windows Firewall in Windows Server 2008, Windows Vista and Windows 7 (TechNet)
• Note: If you do not have permission to disable Windows Firewall/ICS on servers on your network, then you must explicitly configure it to allow WMI traffic. See your system administrator for information on how to do this.
• Review this MSDN article on the interaction between UAC and WMI.
• Rebooting the endpoints that have Exoprise components installed will force the security changes above to take effect. This is required because the Exoprise user logs into the domain – and only then gets a new authentication token – at service start.

After the Exoprise endpoint has been restarted, you should then be able to make WMI calls to the remote servers configured above.

If you are configuring a non-administrator Exoprise user for a large AD forest, you may need to wait a short time while AD replication takes place – up to 15 minutes – before remote queries over WMI will work.

Exoprise components operate in read-only mode when communicating with Active Directory (AD). Additional components within Sensor query the server via the Windows Management Instrumentation (WMI) interfaces and this functionality requires specific privileges on the server.

In a lab environment it is often easier to use a Domain Admin account for the Sensor installation credentials because the AD and WMI functionality runs smoothly as Domain Admin. The preferred way in a production environment is to limit and restrict the permissions of the Sensor account as detailed above.

Related Articles

• Statement on Log4J / Log4Shell Vulnerability
• Security Overview
• Public Key Infrastructure (PKI)
• SAML Integration

• Collapse All

• Documentation Home
• Palo Alto Networks
• Live Community
• Knowledge Base
• Map IP Addresses to Users

Create a Dedicated Service Account for the User-ID Agent

Next-generation firewall docs.

• Cloud Management of NGFWs
• PAN-OS 10.0 (EoL)
• PAN-OS 10.1
• PAN-OS 10.2
• PAN-OS 11.0
• PAN-OS 11.1
• Cloud Management and AIOps for NGFW
• PAN-OS 8.1 (EoL)
• PAN-OS 9.0 (EoL)
• Logon Success (4624)
• Authentication Ticket Granted (4768)
• Service Ticket Granted (4769)
• Ticket Granted Renewed (4770)
• If you are installing the Windows-based User-ID agent on a supported Windows server, Configure a Service Account for the Windows User-ID Agent .
• If you are using the PAN-OS integrated User-ID agent on the firewall, Configure a Service Account for the PAN-OS Integrated User-ID Agent .

Configure a Service Account for the Windows User-ID Agent

• Log in to the domain controller.

• In the navigation pane, open the domain tree, right-click Managed Service Accounts and select New User .
• Enter the First Name , Last Name , and User logon name of the user and click Next .
• Enter the Password and Confirm Password , then click Next and Finish .
• select Control Panel Administrative Tools Local Security Policy .

• Right-click Log on as a service , then select Properties .
• Select Active Directory Users and Computers <your domain> Builtin Distributed COM Users .
• Right-click Properties Members Add and enter the service account name.

• Add the name of the service account you created, Check Names to verify your entry, and click OK . You might have to change the Locations or click Advanced to query for account names. See the dialog help for details.

• Click OK twice.
• Use the Local Users and Groups MMC snap-in (lusrmgr.msc) to add the service account to the local Distributed Component Object Model (DCOM) Users and Remote Desktop Users groups on the system that will be probed.
• On the domain controller or Exchange server that contains the logs you want the User-ID agent to read, or on the member server that receives events from Windows log forwarding, select Start Run , enter MMC .

• Click OK twice to save the settings.
• Confirm that the builtin Event Log Reader group lists the service account as a member ( Event Log Readers Properties Members ).
• From the Windows Explorer, navigate to C:\Program Files(x86)\Palo Alto Networks , right-click the folder, and select Properties .

• 32-bit systems — HKEY_LOCAL_MACHINE\Software\Palo Alto Networks
• 64-bit systems — HKEY_LOCAL_MACHINE\Software\WOW6432Node\PaloAlto Networks

• Select Group Policy Management Editor Default Domain Policy Computer Configuration Policies Windows Settings Security Settings User Rights Assignment .
• For Deny log on as a batch job , Deny log on locally , and Deny log on through Remote Desktop Services , right-click Properties .

• Select Start Run , enter MMC , and select File Add/Remove Snap-in Active Directory Users and Computers Users .
• Right-click the service account name, then select Properties .

• As a next step, Configure User Mapping Using the Windows User-ID Agent .

Configure a Service Account for the PAN-OS Integrated User-ID Agent

• Select Active Directory Users and Computers <your domain> Builtin Server Operators Group .
• Right-click Properties Members Add add service account name
• Start Run , enter MMC , and select File Add/Remove Snap-in Active Directory Users and Computers Users .
• As a next step, Configure User Mapping Using the PAN-OS Integrated User-ID Agent .

Recommended For You

© 2024 Palo Alto Networks, Inc. All rights reserved.

Home » Steps To Fix Dcom Event Id 10010

Steps To Fix Dcom Event Id 10010

Table of Contents

Related posts: