Device registry LDAP sync fails to create new users due to insufficient permissions in twx-97

IoT PTC ThingWorx
, , , , , , , ,
1

We’re experiencing a critical issue with our device registry LDAP synchronization in ThingWorx 9.7. New users are not being created during the sync process, and we’re getting permission-related errors in the logs.

The LDAP service account appears to have read access, but I suspect there’s an issue with write/create rights on the target OU. The Directory Services configuration seems correct based on the documentation, but clearly something is missing.

Error from ApplicationLog:


LDAP: bind failed - insufficient access rights
javax.naming.NoPermissionException: [LDAP: error code 50]
at DirectoryServices.syncUsers(line 342)

This is blocking our entire user onboarding process for new device operators. Has anyone dealt with LDAP permission issues in the Directory Services subsystem? What specific rights does the service account need beyond basic read access?

2

We had this issue last year during our 9.7 upgrade. Beyond the AD permissions, make sure your Directory Services subsystem configuration has the correct bindDN format. It should be the full distinguished name of the service account, not just the username. Also double-check that SSL/TLS is properly configured if you’re using LDAPS - certificate validation failures can sometimes manifest as permission errors in the logs.

3

Thanks for the responses. I checked with our AD team and the service account does have read permissions but they confirmed no write permissions were granted. They’re hesitant to give broad write access. What’s the minimum permission set needed specifically for user creation in ThingWorx Directory Services?

4

For ThingWorx LDAP sync, the service account requires Create User objects and Write all properties permissions on the specific OU where users will be created. You don’t need domain-wide write access - scope it to just the OU path specified in your Directory Services configuration. Also ensure the account has Read memberOf attribute permission if you’re syncing group memberships for role mapping purposes.

5

I had the same problem and struggled with it for days until I found the root cause. Here’s the comprehensive solution:

LDAP Service Account Permissions (Active Directory): You need these specific permissions on the target OU:

  • Read (standard read access to search/enumerate)
  • Create User objects (allows creation of new user entries)
  • Write all properties (enables setting user attributes during sync)
  • Reset password (if ThingWorx manages passwords)

ThingWorx Directory Services Configuration: Verify your configuration in platform-settings.json:


"DirectoryServices": {
  "LDAPServer": "ldaps://dc.company.com:636",
  "BaseDN": "OU=ThingWorxUsers,DC=company,DC=com",
  "BindDN": "CN=twx-service,OU=ServiceAccounts,DC=company,DC=com"
}

The BindDN must be the full distinguished name, not a simple username. The BaseDN should point to the exact OU where users will be created - this is where your service account needs the write/create permissions.

Testing the Configuration: After granting permissions, restart the Directory Services subsystem from Composer (don’t restart the entire platform). Then test with:


// Test LDAP bind and search
LDAPConnection conn = DirectoryServices.getConnection();
SearchResult result = conn.search(baseDN, filter);

Common Gotchas:

  1. OU Write Rights Inheritance: Ensure permissions aren’t being blocked by deny ACEs higher in the OU tree
  2. Service Account Format: Use full DN format, not UPN (user@domain.com) or SAM (DOMAIN\user)
  3. Group Claim Mapping: If you’re mapping AD groups to ThingWorx roles, the service account also needs Read memberOf on user objects
  4. SSL Certificate Trust: For LDAPS, import the AD domain controller certificate into ThingWorx’s Java keystore

Verification Steps:

  1. Grant Create User and Write properties permissions to service account on target OU
  2. Update platform-settings.json with correct BindDN format
  3. Restart Directory Services subsystem
  4. Test sync with a single test user first
  5. Monitor ApplicationLog for successful user creation messages

After implementing this, our sync started working perfectly. The key was the combination of proper AD permissions scoped to the specific OU and using the full distinguished name format for the bind account. Let me know if you need help with any specific step.

6

I’ve seen this exact error before. The LDAP service account needs explicit Create Child and Write permissions on the target OU in Active Directory, not just read access. The error code 50 specifically indicates insufficient access rights for the operation you’re attempting.