Search

Start Search

5Active Directory

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).

5.1.2Authentication

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 2.2.0.0 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

5.3.1LAPS Permissions

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

5.3.2Permissions Setup

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.

1. Launch PowerShell using an account which has the necessary Active Directory modification permissions.
2. Import the LAPS management module by typing: Import-Module AdmPwd.PS
3. Grant read permission to the Local Administrator password property with the command: Set-AdmPwdReadPasswordPermission -OrgUnit <Distinguished Name of the computer OU> -AllowedPrincipals <Account name>
4. 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>
5. 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:

1. Connect to Active Directory and attempt to find the object identified by the provided Distinguished Name.
2. Attempt to read schema information about the LAPS properties from Active Directory. If this fails then check that your LAPS installation was successful.
3. 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).
4. 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).

5.3.4Multi-Domain Permissions

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.

5.3.5.1WMI Namespace Permissions (locally on each computer)

1. On the computer to be managed, run wmimgmt.msc in a command prompt
2. Right-click WMI Control (Local), and select Properties
3. Select the Security tab
4. Select Root and click the Security button,
5. Click the Add… button
6. Click the Object Types button and make sure Computers is selected
7. Enter the name of the OVERLAPS server and click Check Names. The computer object of the server is now filled in automatically
8. Click OK
9. Click Advanced
10. Select the OVERLAPS server in the list
11. Click Edit
12. In the Applies to list, select This namespace and subnamespaces
13. Check the permissions boxes for: Execute Methods, Enable Account, Remote Enable and Read Security
14. Click OK in each dialog until you have exited back to the main window.

5.3.5.2User 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:

1. Act as part of the operating system
2. Impersonate a client after authentication
3. Log on as batch job
4. Log on as a service

5.3.5.4DCOM Machine Access Restrictions and Machine Launch Restrictions (Group Policy)

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

1. Double click the “DCOM: Machine Access Restrictions…” setting
2. Check the “Define this policy setting” box
3. Click “Edit Security”
4. Click “Add”
5. Click “Object Types”
6. Check the “Computers” option
7. Enter the name of the OVERLAPS server followed by “$” (e.g. “myserver$”)<,/li>
8. Click OK
9. With the server selected, check the Allow option for “Local Access” and “Remote Access”
10. Repeat these steps for “DCOM: Machine Launch Restrictions…”, except checking Allow for all four options.

5.3.5.5Firewall Setup (if using the Windows Firewall) (Group Policy)

Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules

1. Right click on the right pane and select New Rule
2. Select Predefined and Windows Management Instrumentation (WMI) in the list
3. Click Next
4. Tick all the Windows Management Instrumentation-rules in the list (usually 3 items)
5. Click Next
6. Select Allow the Connection
7. Click Finish

5.3.5.6Enable the Windows Management Instrumentation (WMI) and the Remote Procedure Call (RPC) Services (Group Policy)

Computer Configurations > Preferences > Control Panel Settings > Services

1. Right click in the right pane, select New -> Service
2. Change Startup to Automatic
3. Click the “…” button next to “Service name”
4. Scroll down to Windows Management Instrumentation (Winmgmt) and select it
5. Change “Service action” to “Start service”
6. 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:

https://support.microsoft.com/en-au/help/4020459/privilege-not-held-error-with-powershell-stop-computer-command-and-pow