How To: Test Read/Write Access to an Attribute Using LDP.EXE – SecureAuth Support

Version Affected: All

Overview

This article explains how to use Microsoft's LDP.exe tool to confirm whether the service account configured in a realm's Datastore has permission to read and write a specific Active Directory attribute — useful when a realm cannot read or write an expected attribute and the cause is unclear.

Test Read/Write Access to an Attribute Using LDP.EXE

On the SecureAuth appliance, open the Run dialog and type ldp.exe.

Windows Run dialog with ldp.exe typed into the Open field.

The Ldp window opens, with Connection, Browse, View, Options, Utilities, and Help menus.

Empty Ldp window showing its menu bar: Connection, Browse, View, Options, Utilities, and Help.

Bind the service account to Active Directory: click Connection > Bind.

Ldp Connection menu open, with Bind highlighted.

In the Bind dialog, enter the service account's username and password and the domain — the same credentials configured on the affected realm's Data tab — then click OK.

Ldp Bind dialog filled in with a service account username, password, and domain, with Bind with credentials selected.

For comparison, the realm's own Datastore Credentials fields on the Data tab show the same service account and domain values used for the bind.

SecureAuth realm's Datastore Credentials fields on the Data tab, showing the same service account and domain used in the Ldp Bind dialog.

If the bind succeeds, the status bar at the bottom of the Ldp window shows Authenticated as dn:'<service account>'. If it does not, confirm the service account's password is correct.

Find the distinguished name (DN) of the affected user: click Browse > Search.

Ldp Browse menu open, with Search highlighted.

In the Search dialog, set Base DN to the same fully qualified domain used in the realm's Datastore connection, set Filter to samaccountname=<username> for the affected user, select Subtree, and click Run.

Ldp Search dialog with Base DN and a samaccountname filter entered, Subtree selected as the scope.

SecureAuth realm's Datastore Connection fields on the Data tab, showing the same Domain and Base DN values used in the Ldp Search dialog.

The search result shows the user's DN — copy it, since it is needed in the next two steps.

Ldp search results pane showing the returned distinguished name (DN) for the searched user.

Confirm which attributes the service account can read: click View > Tree.

Ldp View menu open, with Tree highlighted.

In the Tree View dialog, paste the DN copied in the previous step and click OK.

Ldp Tree View dialog with the user's distinguished name pasted into the BaseDN field.

Ldp attribute list returned for the searched user, showing every attribute the service account is able to read.

This lists every attribute the service account is able to read for that user. Confirm the attribute in question (for example, otherMobile) actually appears in this list — if it does not, the service account cannot read that attribute at all, and the read/write test in the next step will not succeed either.

Test whether the service account can write to the attribute: click Browse > Modify.

Ldp Browse menu open, with Modify highlighted.

In the Modify dialog, enter the DN found earlier, enter the attribute name (for example, otherMobile) and a test value, select Add (or Replace if the attribute already has a value), click Enter, then click Run.

Ldp Modify dialog with a distinguished name, an attribute name, and a test value entered, Add selected as the operation.

If the operation fails, an error such as Error 0x2098 Insufficient access rights to perform the operation appears — this means the service account does not have write permission on that attribute.

Ldp error message reading Error 0x2098 Insufficient access rights to perform the operation.

If it succeeds, a message confirming the modify appears instead. Check the attribute's value in the AD profile to confirm the test value was actually written.

Ldp log showing a successful Modify call, confirming the user's distinguished name was modified.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.