Auth.Server type: LDAP Server(openldap:linux base)
Almost client can login successful , but a few pepole will login failed if their account belong different ou(objectclass=alias).
my Role Mapping Rule on Relam:
username is "*" Assign:Users Role
When LDAP server type is Windows AD, I have never meet this issue, but in OpenLDAP(Linux base), it occurred, I would like to know is there any solution can resolved it? any advice will appreciate.
if you are not looking for users in the location that the user resides, yes, the login will fail. are you able to change where the user entries are found and still have successful login for the users that are currently working?
If you are role mapping only on the username and it is failing, it may be due to a slow response from the authentication server. When the end user attempts to log-in, does it take a long time to produce a failure message? If so, this is the most likely scenario.
Depending on the authentication server configuration, you should have a base dn field. If this is set to the top of the domain tree (dc=bbtest,dc=net), SA will search for all objects within the tree. If you can narrow down the search to a specific OU, this should help speed up the search time. For example, if all user objects are under the Sales OU, you should enter: OU=Sales,CN=Users,dc=bbtest,dc=net
Dear Zanyterp & Kita:
Thanks a lot for your response, this is set to the top of the domain tree, all ou is under domain tree, but if the uid belong two ou, this kind of user will login failed.
BTW, my auth.server is openldap server(linux base), not windows AD, in AD enviroment, it can work fine if user account belong different ou, but in openldap server, it doesn't work, is there any other idea?
I don't believe having the UID belonging to two OU should be an issue as long as the ldap is returning that it can successfully find the user. The only scenario I can think why it would fail is it is not receiving a timely response from the server and timing out. We see this type of behavior when searching the top of the domain tree and the specific user object is a number of levels below with a large amount of objects above it.
If modifying the user base dn does not help, a case should be opened with JTAC. For a firm root cause, JTAC will need to enable debug logging to see if or what is returned back from the authentication server.