Troubleshoot User Rights with Ldp.exe and Group Policy Modeling

The following Microsoft default domain policy and default domain controller policy can cause an AD Bridge Enterprise client to fail to join a domain or to fail to enumerate trusts:

  • Access this computer from the network: Users and computers that interact with remote domain controllers require the Access this computer from the network user right. Users, computers, and service accounts can lose the user right by being removed from a security group that has been granted the right. Removing the administrators group or the authenticated users group from the policy setting can cause domain join to fail. According to Microsoft, There is no valid reason for removing Enterprise Domain Controllers group from this user right.

For more information, please see Microsoft article 823659,.

Group Policy Object Editor :: User Rights Assignment

  • Deny access to this computer from the network: Including the domain computers group in the policy setting, for instance, causes domain-join to fail.

For more information, please see Microsoft article cc758316.

 

The symptoms of a user-right problem can include the following:

  • An attempt to join the domain is unsuccessful.
  • The AD Bridge Enterprise authentication service, lsass, does not start.
  • The /opt/pbis/bin/get-status command shows the domain or the AD provider as offline.

You can pin down the issue by using the ldp.exe tool to check whether you can access AD by using the machine account and machine password. Ldp.exe is typically included in the support tools (suptools.msi) for Windows and located on the Windows installation CD (Support folder, Tools subfolder). You might also be able to download the support tools that contain ldp.exe from the Microsoft website.

For more information, please see Ldp Overview.

To resolve a user-right issue, you can use Group Policy Modeling in the Group Policy Management Console (GPMC) to find the offending policy setting and then modify it with the Group Policy Management Editor (or the Group Policy Object Editor).

For more information, please see Group Policy Modeling.

  1. On the AD Bridge Enterprise client, run the /opt/pbis/bin/lsa ad-get-machine password command as root to get the machine password stored in Active Directory:
/opt/pbis/bin/lsa ad-get-machine password
Machine Password Info:
  DNS Domain Name: EXAMPLE.COM
  NetBIOS Domain Name: EXAMPLE
  Domain SID: S-1-5-21-3190566242-1409930201-3490955248
  SAM Account Name: RHEL5D$
  FQDN: rhel5d.example.com
  Join Type: 1
  Key Version: 0
  Last Change Time: 129401233790000000
  Password: i(2H2e41F7tHN275
  1. On a Windows administrative workstation that can connect to AD, start ldp.exe and connect to the domain.

For more information, please see LDP UI.

  1. In LDP, on the Connection menu, click Bind, and then use the AD Bridge Enterprise client's SAM account name and machine password from the output of the lsa ad-get-machine password command to bind to the directory.

LDP output example

  1. If the attempt to bind with the machine account and the machine password fails because of invalid credentials, as in the LDP output image shown, go to the GPMC and use Group Policy Modeling to try to identify the policy setting causing the problem.

 

  1. In the GPMC, run Group Policy Modeling to pinpoint the offending policy setting and then modify the policy setting to grant the correct level of user right to the computer or user.

For more information, please see Group Policy Modeling.

Group Policy Management example

In the screen shot, for example, the cause of the problem is that the Deny access to this computer from the network policy setting in the Default Domain Policy GPO contains the domain computers group.