Hi Michael

Recently we noticed this when the group DN under JTS Admin > Advanced properties was set to a higher level , maybe the root DN. Could you change the group DN to the folder where the groups reside?

And also, verify (or re-enter) the password for the LDAP user listed within JTS Admin > Advanced properties.

As Shubjit said, you need to check the JTS advanced properties for the LDAP configuration, particularly the "Group Member Property" value. If you are viewing a user profile other than your own, it's possible that you cannot see the repository role/permission assignment, particularly when the user registry type is "UNSUPPORTED". If the type is LDAP and the configuration is correct, it should work though. It works in my own CLM 4.0.3 + ApacheDS environment.

You can check against these details and see if any properties need to be changed.

1. When looking for a new user to import, JTS will send a query to the LDAP server with the "Base User DN" property as the base object, scope being (always) subtree, size limit being "Max Number of Entries Returned from User Search", filter being "Find Users by Name Query", and the attributes defined in "User Property Names Mapping" be to requested.

You will notice two things here - the first is the LDAP search will return a limited number (default 100) of users and you may not see all the users on the LDAP server. The second is it does not look for group information (membership) here.

2. JTS will also send a query to the LDAP server to get the group information, with the "Base Group DN" property as the base object, scope being (always) subtree, filter constructed from "Group Name Property" and "Jazz to LDAP Group Mapping" (a few (cn=JazzXXXX) filters combined), and the attribute "Group Member Property" (to show all the members of a group) to be requested.

If the user DN matches the ones returned in step 2, the user is considered to be in the particular group, in other words, has the corresponding repository.

When viewing a user's profile, the LDAP queries are a bit different - for the user query, it uses the "Find Users by User Id Query" property for the filter, and for the group query, it adds <Group Member Property>=<user DN> to the filter. It means that the user is considered to be in the group(s) returned by the group query.

Note that even though you may not see the repository permission in a user's profile, it does not necessarily mean that the user has no such permission as it is assigned by the application server such as WAS during authentication. In other words, the repository permission mapping in the application server is separate from the JTS advanced property settings. This makes perfect sense when you consider the case where the external user registry is the WAS filed-base federated registry (JTS cannot send query to request the group information at all).