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

5.3.6Bitlocker Recovery Key Permissions

If you wish to make use of the ability to retrieve Bitlocker Recovery Keys from Active Directory, the OVERLAPS server must be granted permission to read it.

Bitlocker Keys make use of the Active Directory Confidentiality bit, which is designed to limit visibility of the object or property to only users who have full control access to that object.

There are two ways to grant access to view this data: the quick, easy and arguably less secure way, and the more in-depth but ultimately more secure way. If you are in any doubt as to which method is best for you, or if you require more information, it is recommended to consult official Microsoft documentation on the topic.

5.3.6.1The Quick Way

The quick way involves granting OVERLAPS full delegate rights to an Active Directory container in which the Bitlocker secured computers are located.

5.3.6.2The More Secure Way

More advanced control over access to the Bitlocker Recovery Key object can be achieved using Microsoft's Ldp.exe tool. This involves directly editing the ACL Security Descriptor on an OU and can lead to unexpected results, this should only be carried out by an experienced person who is confident in what they are doing.

The basic logic is that any property or object with the Confidentiality bit set requires a user with the "Control Access" permission to access it. The only way to achieve this when editing an OU's permissions normally is by granting Full Control to it. This unfortunately necessitates giving up far more control over the container/object than is actually necessary though. However, by setting an Access Control Entry (ACE) manually through Ldp.exe, you can specify only the permissions you actually need. The steps to achieve this are shown below.

1. Run Ldp.exe

2. Connect to a Domain Controller by going to Connection -> Connect, and entering it's details.

   

   You should see that a connection has been established.

3. Set the Server Binding Information by going to Connection -> Bind.

   

4. Open your Active Directory tree by going to View -> Tree, and clicking OK (leaving BaseDN empty).
5. Navigate to the OU containing your Bitlocker secured devices
6. Right click the OU and select Advanced -> Security Descriptor
7. When prompted to confirm the Distinguished Name (DN) of the object to edit, click OK.

8. You will see the Security descriptor for the container object.

   

9. To add an ACE, click the Add... button.

10. Fill out the information for the new ACE as shown in the example below. In this example we have created a group "BitlockerReader" to control access so that we don't have to go in and edit ACEs every time we want to make a change:

    

    The fields to edit are:

    1. Trustee: The User or group name in the form domain\username
    2. ACE type: Allow
    3. Access Mask: Read property, Control Access
    4. ACE flags: Inherit
    5. Object Type: (none)
    6. Inherited Object Type: msFVE-RecoveryInformation
11. Once done, click OK to add the ACE to the container and then click Update to apply the change.
12. Changes made here may take some time (possibly up to 4 hours) to propagate through AD, and may require the OVERLAPS service to be restarted to take effect.

You can read more about the Confidential bit and granting permission to read properties at:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential