Here’s the complete solution for migrating LDAP OU structure while preserving role assignments:
1. LDAP OU Structure Update
First, update the base DN configuration in Teamcenter. Edit your LDAP authentication properties file (typically ldap_auth.properties or in site.xconf):
Old configuration:
wt.auth.ldap.url=ldap://dc01.company.com:389
wt.auth.ldap.baseDN=ou=users,dc=company,dc=com
wt.auth.ldap.userSearchFilter=(uid={0})
wt.auth.ldap.groupSearchBase=ou=groups,dc=company,dc=com
New configuration with hierarchical structure:
wt.auth.ldap.url=ldap://dc01.company.com:389
wt.auth.ldap.baseDN=ou=users,dc=company,dc=com
wt.auth.ldap.userSearchFilter=(uid={0})
wt.auth.ldap.userSearchScope=subtree
wt.auth.ldap.groupSearchBase=ou=groups,dc=company,dc=com
wt.auth.ldap.groupSearchScope=subtree
The key change is adding searchScope=subtree which tells Teamcenter to search recursively through all child OUs. This allows it to find users in ou=engineering,ou=departments,ou=users,dc=company,dc=com without hardcoding the full path.
2. Role Mapping Configuration
Update role mapping to handle the new DN structure. The role mapping configuration needs to be flexible enough to work with varying DN paths:
In your role mapping configuration:
wt.auth.ldap.roleMapping.enabled=true
wt.auth.ldap.roleMapping.attribute=memberOf
wt.auth.ldap.roleMapping.stripDN=true
wt.auth.ldap.roleMapping.useGroupCN=true
The stripDN=true option makes role mapping use only the CN (common name) of groups rather than the full DN, making it resilient to OU structure changes.
Define specific role mappings:
wt.auth.ldap.role.Configuration_Manager=CN=TC_Config_Managers,ou=groups,dc=company,dc=com
wt.auth.ldap.role.Configuration_User=CN=TC_Config_Users,ou=groups,dc=company,dc=com
wt.auth.ldap.role.Baseline_Manager=CN=TC_Baseline_Managers,ou=groups,dc=company,dc=com
3. Base DN Configuration for User Sync
For the nightly synchronization job, update the sync configuration to use the new base DN:
Edit the LDAP sync job configuration:
// Sync job configuration
LDAPSyncConfig config = new LDAPSyncConfig();
config.setBaseDN("ou=users,dc=company,dc=com");
config.setSearchScope(SearchScope.SUBTREE);
config.setUserFilter("(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))");
This ensures the sync job searches the entire user tree, not just a specific OU.
Configuration Management Specific Updates:
Configuration management uses role-based access for contexts and revision rules. Update these configurations:
wt.config.roleValidation.useLDAPGroups=true
wt.config.roleValidation.groupAttribute=memberOf
wt.config.roleValidation.refreshInterval=3600
wt.config.context.roleMapping=Configuration_Manager:CN=TC_Config_Managers
wt.config.baseline.roleMapping=Baseline_Manager:CN=TC_Baseline_Managers
Migration Procedure:
- Pre-migration validation: Export current user-role mappings
tc_user_admin -list_roles > pre_migration_roles.txt
-
Update LDAP configuration with new base DN and subtree search scope
-
Test LDAP connectivity:
ldapsearch -x -H ldap://dc01.company.com:389 \
-D "cn=tcservice,ou=service,dc=company,dc=com" \
-W -b "ou=users,dc=company,dc=com" \
-s sub "(uid=john_smith)"
- Run manual role sync for test users:
tc_user_admin -sync_user john_smith -verbose
- Validate role assignments:
tc_user_admin -user john_smith -list_roles
-
Update configuration management ACLs if they reference specific LDAP groups
-
Run full user synchronization:
tc_user_admin -sync_all_users -force
Handling Legacy DN References:
Some configuration objects may have stored the old DN format. Run a cleanup script:
// Pseudocode - Key implementation steps:
1. Query all configuration contexts and revision rules
2. For each object, extract stored LDAP group references
3. If DN matches old format (ou=users,dc=company,dc=com):
a. Parse the CN from the old DN
b. Query LDAP for current DN using CN
c. Update object with new DN
4. Verify group membership still resolves correctly
5. Log all updates for audit trail
Verification Steps:
-
Test configuration manager access:
- Log in as a configuration manager
- Create a new configuration context
- Create a baseline
- Apply a revision rule
-
Verify role synchronization:
- Check Teamcenter logs for sync job completion
- Verify no ‘role not found’ errors
- Confirm all users have expected roles
-
Test effectivity management:
- Apply effectivity to a configured part
- Verify role-based access to effectivity controls
Troubleshooting Common Issues:
-
Partial role assignments: Some users have roles, others don’t
- Solution: Check LDAP replication-new OU structure may not be replicated to all DCs
-
Roles appear but access denied: Role mapping works but permissions don’t
- Solution: Configuration management ACLs need updating to reference new group DNs
-
Sync job timeout: Large user base causes sync to fail
- Solution: Implement paged results in LDAP queries (page size 1000)
Post-Migration Monitoring:
Enable detailed logging for role synchronization:
wt.auth.ldap.logging.sync=DEBUG
wt.auth.ldap.logging.roleMapping=DEBUG
wt.config.logging.roleValidation=INFO
Monitor for the first week to catch any edge cases or users in unexpected OUs.
After implementing these changes and running the full user sync, all users should regain their configuration management roles and access. The subtree search configuration makes the system resilient to future OU structure changes-as long as users remain under the base DN, they’ll be found regardless of the intermediate OU hierarchy. The role mapping based on group CN rather than full DN ensures that role assignments survive LDAP reorganizations.
This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.