Jazz to LDAP
Hi,
We have an external user registry LDAP AD configured, however, when importing users into JTS there doesn't seem to be any indication which repository groups these members belong.
I was expecting to see a checkmark against JazzUsers but nothing no boxes ticked. I should stress however, JazzAdmins my profile has checkmarks.
Rgds
We have an external user registry LDAP AD configured, however, when importing users into JTS there doesn't seem to be any indication which repository groups these members belong.
I was expecting to see a checkmark against JazzUsers but nothing no boxes ticked. I should stress however, JazzAdmins my profile has checkmarks.
Rgds
2 answers
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.
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.
/Shubjit
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).
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).