Using Identity Awareness AD Query without Active Directory Administrator privileges on Windows Server 2003 and lower
The AD Query (previously called Identity Logging) is designed to work when provided an Active Directory domain administrator user. This is, by far, the easiest way to set it up since the members of the Administrators group are allowed to remotely connect to the computer (by default). On the other hand, it can also use a Non-Admin user, given specific permissions. Check Point only recommends doing so, if you cannot use an admin user.
Important: Sometimes, the procedure does not take effect immediately and requires restarting the WMI service on the Domain Controllers.
AD Query uses Windows Management Instrumentation (WMI) to query Active Directory Domain Controllers for the Security Event logs. To handle the remote calls to the Domain Controllers, AD Query uses the Distributed COM (DCOM) technology. In order to connect to a remote computer using WMI, WMI permissions should be granted, and DCOM settings and WMI namespace security settings should enable the connection. After a user/group can connect to the Domain Controller using WMI, it should have the permissions to read the Security Event logs.
There are four main stages:
- Creating a user/group and granting it DCOM permissions.
- Granting the user/group WMI permissions.
- Adding read permissions to the Security Event logs.
- Configuring the user/group to be used for AD Query in the SmartDashboard.
Note that due to the complexity of the procedure for adding read permissions to the Security Event logs (Stage 3), and the fact that it should be applied on each Domain Controller, a PowerShell script was created to automate the procedure.
Check Point recommends using this script to ease the process and avoid errors.
Create a user with Distributed COM permissions
- Create a domain user. It is possible to create a security group, add this user to the group and apply the procedure, described in this article, on the group.
- Add this user/group to the built-in domain group "Distributed COM Users".
- Make sure that DCOM remote launch, activation permissions and remote access permissions are granted for the Distributed COM Users group (as described in Securing a Remote WMI Connection).
Grant the user WMI permissions
Note: This step should be performed on each Domain Controller.
- Run Windows Management Instrumentation (WMI) console:
Go to Start menu - click on Run... - type wmimgmt.msc - click on OK/press Enter.
- Right-click on WMI Control - click on Properties.
- Go to Security tab - expand Root.
- Select CIMV2 - click on Security button.
- Add the domain user that you have created to work with AD Query.
Grant the domain user the Enable Account and Remote Enable permissions.
- Click on Advanced button.
- Make sure that the permissions for the domain user apply to This namespace and subnamespaces.
- Click on OK and close the dialogs.
Add read permissions to the Security Events log
Note: This step should be performed on each Domain Controller.
There are three different ways of completing the next step:
Way 1: Using AD Query Permissions script:
The PowerShell adq_permissions script can save you the trouble of dealing with this step.
Note: To install PowerShell on Windows Server 2003, download and install the KB968930 - Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0) (pre-requisites are KB914961 - Windows Server 2003 Service Pack 2, and .NET Framework, at least .NET 2.0 Service Pack 1).
To run the script, copy it to the Domain Controller, open the Windows Command Prompt (as Administrator), and run the following command:
powershell [full path]\adq_permissions.ps1 [/U=username] [/G=group name] [/S=SID] [/P] [/C]
Where the command line arguments optionally apply the permissions to a user, a group or a SID:
- The /S switch enables the administrator to specify the SID of the user or group that he wants the permissions to be applied to.
- The /P switch is for preview mode (will not modify anything on the Domain Controller).
- The /C switch prints the commands without executing them in a way that is ready for copy-and-paste to the Command Prompt.
That way it is possible to verify the commands and then apply them manually.
- You need to unrestrict the script execution policy by running:
powershell Set-ExecutionPolicy Unrestricted
After running the script, you can restrict the policy again by running:
powershell Set-ExecutionPolicy Restricted
- You should specify only one of the username, group or SID switches.
- It is also possible to use the PowerShell Terminal. If this option is preferred, then omit the "powershell" from the command above.
- Related solution: sk93330 - AD Query permissions script from sk43874 might produce error messages when running in Preview mode.
Way 2: Adding the permissions manually:
If you are not interested in running the script, you can perform the step manually. Note that you need to perform the following only if you choose not to use the script:
Get the SID:
Grant the user permissions to the Windows Event logs:
For more information, refer to KB2028427 - Writing to the Windows Event Log from an ASP.NET or ASP application fails.
Way 3: Getting the script to prepare the commands for you to review and manually input.
Configure the user to be used for AD Query in the SmartDashboard
- Enter the user that you have created under the AD Query configuration (either in the Wizard, or in the LDAP Account Unit editor) as an "Administrator user".
- Install policy to apply the change.
Ensure you are using the latest version of the script - the script has been updated to support the newest SID. If you are using an older version, you might get the following error:
PS C:\install\adq^ .\adq_permissions.ps1 /U=cpiaservice *********************************************************************** Check Point AD Query Permissions script will give permissions to user name ^cpiaservice^ to view security events created on the domain controller. *********************************************************************** Method invocation failed because [System.Object] doesn^t contain a method nam ed ^Trim^. At C:\install\adq\adq_permissions.ps1:229 char:19 + $SID = $SID.Trim ^^^^ () + CategoryInfo : InvalidOperation: (Trim:String) , RuntimeExcep tion + FullyQualifiedErrorId : MethodNotFound Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\Application... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\Directory Service... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\DNS Server... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\File Replication Service... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\ForwardedEvents... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\Internet Explorer... permissions for this user already exist Settig CustomSD for \SYSTEM\CurrentControlSet\Services\Eventlog\Microsoft-Windows-EventCollector/Operational... permissions for this user
This normally occurs if a forest is moved from one domain to a new domain, in which case it will have a second SID applied.
A workaround would be to add the user based on SID instead of username.
If you need the selected user to be able to reset password, then apply this to the Windows Server for that user:
Delegate 1 Task - Reset user passwords and force password change at next logon
KB296999 - Minimum permissions are needed for a delegated administrator to force password change at next logon procedure