6 Appendix C: Troubleshooting Logon Manager on Microsoft Active Directory

This appendix contains descriptions of issues that may arise during deployment of Logon Manager, and instructions for remedying those issues.

6.1 Active Directory Schema Extension Failures

If the AD schema extension fails, follow the steps below to identify and remedy the possible cause:

  1. Check the following, then retry extending the schema:

    • The machine from which you are performing the extension is on the same domain as the directory.

    • You are performing the extension against the schema master DC.

    • You are logged on as the schema administrator.

  2. If schema extension still fails, install the Logon Manager Administrative Console directly on your schema master DC and perform the schema extension locally. This solution rules out all possible network issues (such as DNS problems) and does not fail unless your AD schema contains errors.

  3. If you are still unable to extend your schema, the schema might be damaged. Check the health of your schema using Microsoft's MOM tool and make sure your schema adheres to Microsoft's best practices described in the following MS TechNet article: http://technet.microsoft.com/en-us/library/bb727085.aspx

6.2 All Users Unable to Store Credentials Under User Objects

When you enable the storage of credentials under user objects, Logon Manager grants all users rights to create objects of type vGOUserData and vGOSecret. These rights are granted at the directory root and are inherited all the way through to the respective user objects. When these rights are not granted or inherited properly, users are unable to store application credentials under their respective user objects. Possible points of failure include:

  • The necessary rights have not been granted. You must instruct Logon Manager to set the necessary rights by selecting Enable storage of credentials under the user object (AD only) from the Repository menu in the Logon Manager Administrative Console.

  • The rights were granted at the parent domain instead of the user-specific child domain and have not propagated to the child domain. In such case, you can use the Console running on the parent domain DC to grant the necessary rights automatically, or manually grant the rights at the root of each child domain and wait for them to propagate to the user objects.

Note:

If the issue affects only certain groups of users, specifically members of Administrators, Power Users, and other protected groups, see Appendix C: Troubleshooting Logon Manager on Microsoft Active Directory.

6.3 Select Users Unable to Store Credentials Under User Objects

The rights necessary to store credentials under user objects are granted at the tree root and inherited down to user objects. When only select users (specifically, members of protected user groups such as Administrators), are unable to store credentials under user objects, the most likely cause is blocked rights inheritance caused by the AdminSDHolder object. The object's ACL, which governs the ACLs of all protected groups, prohibits rights inheritance by default. More information about this issue is available in the following MS Knowledge Base article: http://support.microsoft.com/kb/817433.

The following protected user groups are known to be affected by this problem:

  • Enterprise Admins

  • Schema Admins

  • Domain Admins

  • Administrators

  • Account Operators

  • Server Operators

  • Print Operators

  • Backup Operators

  • Cert Publishers

To verify that you are experiencing this particular issue, do the following:

  1. Log in to the primary DC as a domain administrator.

  2. Open the Microsoft Management Console and load theActive Directory Users and Computers snap-in.

  3. From the View menu, select Advanced Features.

  4. Navigate to the affected user object, right-click it, and select Properties.

  5. In the dialog that appears, select the Security tab.

  6. Click Advanced. The "Advanced Security Settings" dialog appears: Surrounding text describes image100.png.

  7. In the dialog, check whether:

    1. The Allow inheritable permissions… check box is not selected.

    2. The permissions highlighted in the figure in step 6 are not present in the list.

If the above conditions are true, the user object is not inheriting the necessary permissions from the directory root.

To rectify this issue, you must manually modify the ACL of the AdminSDHolder object to grant the right to create objects of type vGOConfig and vGOUserData. The steps are as follows:

  1. Log in to the primary DC as a domain administrator.

  2. In the Microsoft Management Console, open the Active Directory Schema snap-in.

  3. In the left-hand tree, drill down the Classes node and locate the vGOUserData node.

  4. Right-click the vGOUserData class and select Properties from the context menu.

  5. In the dialog that appears, select the Relationship tab.

  6. Click the Add Superior button.

  7. In the dialog that appears, select container from the drop-down list and click OK. The "container" class appears in the Possible Superior field.

    Surrounding text describes image101.png.

  8. Click OK to close the properties dialog.

  9. In the Microsoft Management Console, open the Active Directory Users and Computerssnap-in.

  10. From the View menu, select Advanced Features.

  11. Navigate to the AdminSDHolder container located in: cn=AdminSDHolder,cn=System,dc=<domainName>,dc=<domainSuffix>

  12. Right-click the AdminSDHolder container and select Properties.

  13. In the "Properties" dialog, select the Security tab and click Advanced.

  14. In the "Advanced Security Settings" dialog, click Add… .

  15. In the "Select User, Computer, or Group" dialog, enter SELF and click OK.

  16. In the "Permission Entry" dialog, do the following:

    1. In the Apply onto: drop-down list, select This object and all child objects.

      Note:

      If the create and delete permissions for vGOUserData objects do not appear in the permissions list, select User objects from the Apply onto: drop-down list instead. This variation occurs between different versions and patches of Active Directory and the underlying operating system.

    2. In the list of permissions, select the Allow check box for the permissions highlighted below:

      Surrounding text describes image102.png.

    3. Click OK.

  17. Trigger the SD propagator (SDPROP) process to immediately propagate the changes throughout the network. Instructions for launching the SD propagator process are provided in the following Microsoft Knowledge Base article: http://support.microsoft.com/kb/251343.

Note:

If you encounter a version of this procedure that calls to apply the above permissions onto "This object only," disregard it. It is deprecated and has been superseded by the steps above.