5.1Forests with Multiple Domains
OVERLAPS supports multiple domain environments with a properly configured trust relationship.
5.1.1Navigating Other Domains
By default, when populating Organizational Units, OVERLAPS will look to the root domain of the forest and from there discover any accessible child domains. However this can be modified from the Configuration Utility’s Settings tab by changing the “MultipleDomainPreference” value to the following:
0 = “RootFirst” (Default)
Seeks the root domain in the current Forest and then attempts to include child domains.
1 = “SingleDomainOnly”
Limits OVERLAPS to the domain that the server is in only. No attempt will be made to attempt to read any other domains in the Forest.
2 = “MemberFirst”
Selects the domain that the OVERLAPS server is a member of first, and then attempts to include any other domains in the current Forest (including the root if it is not the same).
In “SingleDomainOnly” mode, user authentication is also limited to the current domain. Otherwise in a multi-domain environment, users will be prompted for their domain prior to logging in (or have to supply it in the form “domain\username” in the case of Windows Integrated Authentication).
Universal Groups are supported for user login, as are per-domain groups.
When adding a user or group in a multi-domain environment, the autosuggest mechanic will search all domains once you start typing and allow you to select from the found users.
5.1.3Enabling/Disabling Individual Domains
If you are in a multi-domain environment but wish to stop OVERLAPS from talking to one or more of those domains, you can disable them individually from the Config -> Settings -> Active Directory section.
For more information, see Configuration - Settings - Active Directory.
5.2Cross Forest Trust Support
In version 126.96.36.199 OVERLAPS added support for adding users and groups from other Active Directory Forests with an appropriate trust relationship.
Note that it is still the case that only computers in the current forest can be managed.
5.3Active Directory Permissions for OVERLAPS
In order to view and expire the Microsoft LAPS managed Local Administrator passwords, OVERLAPS requires the following permissions in Active Directory to the Organizational Units (containers) in which the managed computers reside:
- Read ms-McsAdmPwd
- Read ms-Mcs-AdmPwdExpirationTime
- Write ms-Mcs-AdmPwdExpirationTime
Configuring these permissions manually can lead to unexpected behaviour, so it is recommended to make use of the PowerShell scripts that come with Microsoft LAPS.
As OVERLAPS runs as Local System on the host server by default, you will need the server’s computer account name to proceed unless you are using a designated Service Account (see Active Directory Settings). This should be the name of the server followed by a dollar sign ($), so if the server is called “myoverlaps” for example, the computer account name would be “myoverlaps$”.
- Launch PowerShell using an account which has the necessary Active Directory modification permissions.
- Import the LAPS management module by typing:
- Grant read permission to the Local Administrator password property with the command:
Set-AdmPwdReadPasswordPermission -OrgUnit <Distinguished Name of the computer OU> -AllowedPrincipals <Account name>
- Also grant write permission so that you can reset the password expiry time, forcing a reset when LAPS next runs on the client (on a Group Policy update):
Set-AdmPwdResetPasswordPermission -OrgUnit <Distinguished Name of the computer OU> -AllowedPrincipals <Account name>
- Restart the OVERLAPS service to make sure it picks up the new permissions.
If everything went to plan, OVERLAPS will now be able to view and trigger a reset of the Local Administrator passwords. Be aware that, due to AD replication, the permissions may not apply immediately.
5.3.3Testing the LAPS Permissions
You can test your Active Directory permissions using the LAPS Debug tool within OVERLAPS. See the LAPS Debug tool for more information.
OVERLAPS also includes a pair of command line tools for testing your LAPS permissions: “lapscheck.exe” and “lapscheck_system.exe”. Both allow you to specify the Distinguished Name of either a computer or Organizational Unit in Active Directory to check the LAPS setup.
“lapscheck.exe” also allows you to specify a username and password if you want to check the access of another AD account, while “lapscheck_system.exe” will attempt to check the access that the LOCAL SYSTEM account on the current computer has. The latter is useful for checking the access that OVERLAPS has as this is the account it runs as by default.
The process followed and problems checked for are:
- Connect to Active Directory and attempt to find the object identified by the provided Distinguished Name.
- Attempt to read schema information about the LAPS properties from Active Directory. If this fails then check that your LAPS installation was successful.
- Get the permissions on the object and search specifically for ones granting read/write permission to the LAPS properties (ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime).
- Finally, if the distinguished name is for a computer, attempt to read the LAPS password itself and the expiration time.
If you have any problems with this process, please get into contact with our Support Team for assistance (see Contacting our Support Team).
The output of the “lapscheck.exe” and “lapscheck_system.exe” processes may contain identifying information about a computer and its current Local Administrator password. For security reasons, if you are emailing us this output data, please remove any sensitive information first.
In multi-domain environments, the LAPS permissions will need to be applied to each domain.
5.3.5Computer Managmenet Tool Permissions
Most of the Computer Management Tools (CMT) require the Windows Management Instrumentation (WMI) interface to be configured and enabled on your clients, and for the OVERLAPS server to have permission to access it.
If you don’t wish to use the tools which make use of WMI (everything except the Ping tool), then you can ignore this section.
The easiest way to configure WMI is by adding the OVERLAPS server's computer account to the Local Administrators group of the computers it needs to manage.
Alternatively, to setup the precise permissions manually, follow the below guide. Most of these settings are configured in Group Policy except for the first, which must be done on each computer.
188.8.131.52WMI Namespace Permissions (locally on each computer)
- On the computer to be managed, run wmimgmt.msc in a command prompt
- Right-click WMI Control (Local), and select Properties
- Select the Security tab
- Select Root and click the Security button,
- Click the Add… button
- Click the Object Types button and make sure Computers is selected
- Enter the name of the OVERLAPS server and click Check Names. The computer object of the server is now filled in automatically
- Click OK
- Click Advanced
- Select the OVERLAPS server in the list
- Click Edit
- In the Applies to list, select This namespace and subnamespaces
- Check the permissions boxes for: Execute Methods, Enable Account, Remote Enable and Read Security
- Click OK in each dialog until you have exited back to the main window.
184.108.40.206User Rights Assignment (Group Policy)
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment
The OVERLAPS server may require to be added to the following policies to grant it permission to remotely manage computers:
- Act as part of the operating system
- Impersonate a client after authentication
- Log on as batch job
- Log on as a service
220.127.116.11DCOM Machine Access Restrictions and Machine Launch Restrictions (Group Policy)
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
- Double click the “DCOM: Machine Access Restrictions…” setting
- Check the “Define this policy setting” box
- Click “Edit Security”
- Click “Add”
- Click “Object Types”
- Check the “Computers” option
- Enter the name of the OVERLAPS server followed by “$” (e.g. “myserver$”)<,/li>
- Click OK
- With the server selected, check the Allow option for “Local Access” and “Remote Access”
- Repeat these steps for “DCOM: Machine Launch Restrictions…”, except checking Allow for all four options.
18.104.22.168Firewall Setup (if using the Windows Firewall) (Group Policy)
Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules
- Right click on the right pane and select New Rule
- Select Predefined and Windows Management Instrumentation (WMI) in the list
- Click Next
- Tick all the Windows Management Instrumentation-rules in the list (usually 3 items)
- Click Next
- Select Allow the Connection
- Click Finish
22.214.171.124Enable the Windows Management Instrumentation (WMI) and the Remote Procedure Call (RPC) Services (Group Policy)
Computer Configurations > Preferences > Control Panel Settings > Services
- Right click in the right pane, select New -> Service
- Change Startup to Automatic
- Click the “…” button next to “Service name”
- Scroll down to Windows Management Instrumentation (Winmgmt) and select it
- Change “Service action” to “Start service”
- Repeat this for the Remote Procedure Call (RPC) (RpcSs) service.
If you have done all of these steps but are still getting an “Access Denied” or “Privilege not held” error, refer to the Microsoft Support article below: