Many of you probably saw my last post on LDAP. It was about forcing a synchronization of LDAP back to a specific date. My basic problem was that a small subset of users were being dropped from one of the LDAP groups within Documentum. We had removed and then added them again, and the re-synch seemed to work. A few days later, they were gone. The question was why?

Here is what we knew. We were bringing in all users belonging to LDAP_Group1. So, if you were in that group, you were able to authenticate into Documentum. That was working like a champ. We were also bringing in three groups, LDAP_Group1, LDAP_Group2, and LDAP_Group3. The groups came in fine as well. The third step was where it all fell apart.

The Hidden Step

After Documentum has processed your user and group filters, it then connects the dots. It looks at the membership of each LDAP group, using LDAP as the system of record, and assigns all appropriate users to the group. If the user was not already placed within Documentum, they don’t get created. Only those users that were brought in according to the person filter are assigned. It also only performs this step if the group has changed since the last synchronization. The more often you run it, the less likely that the check will take place.

Here is where I ran into problem. I has users in the system that were not part of my LDAP_Group1 group within Documentum. Think about it. They were in the group in LDAP, so they were brought into Documentum. However, when it came time for Documentum to assign users to LDAP_Group1 within the system, it decided that they didn’t belong

Now, picture the discussions between me and the Active Directory folk. It wasn’t my filters, everyone was in the system. Something, in Active Directory, had to be different between the hundreds that were working and the hand full that weren’t working. They went back and checked, reporting that all was well. It must be my fault.

Well, further investigation determined that it was everyone’s fault. When Documentum does the comparison, it looks at the name of the user in the group and compares it to the name in Documentum. The problem was that the Display Name in Active Directory had trailing spaces that Documentum had trimmed off. So the names weren’t technically equal.

Documentum should not be using display name to make this determination. It caches more information within the system and it should use it. Documentum could also just trim everything, even on the compare. On the other hand, the Active Directory folks could keep clean data.

How to Identify and Handle this in Documentum

One thing that you can look for to identify trailing spaces is to check to see if the User Rename job is running after the LDAP job. If so, check the report. If there are entries in it saying that users were not renamed as the old and new name were the same, you probably have the trailing spaces problem. This will help to identify those users that haven’t called into the help desk.

What can you do if you don’t have direct access to Active Directory? Follow these four steps:

1. Create group local to Documentum. Name it something clever like “LDAP_Group1 Local“.
2. Add the new local group to the corresponding local group.
3. Add any problem users to the group.
4. Try to block out James and Bex laughing behind your back.

Obviously, once you have resolved the issues in LDAP, you should remove the users from the temporary groups so that LDAP can continue to control the users.