Trying to configured LDAP to AD, but I am finding that it is forcing me to add a User Search Base (required). However my user search base is the same as my Root DN. Can this be changed so we can leave blank or not have groov auto-append the Root DN?
Also, any ideas about a 404 error when trying to access the LDAP user page to edit the user? (/manage/accounts/users/ldap:cn=…)
Welcome to the forums.
The configuration of LDAP is really specific to your IT department setup. Please work very closely with those guys to get the configuration dialed.
That said, I will get the software guys here to take a look at your question and see what they say.
Regarding the 404. Any chance you remember how you got this to show? I’d love to be able to reproduce that here.
Just to let you know, I personally don’t have a lot of LDAP configuration experience (ie, none).
Trying to help by just being the middle man, so with that said… Here is some feedback from our software engineers on your comments and questions.
Trying to configured LDAP to AD, but I am finding that it is forcing me to add a User Search Base (required). However my user search base is the same as my Root DN. Can this be changed so we can leave blank or not have groov auto-append the Root DN?
The User Search Base is currently required. You can work around this by dividing the Root DN and User Search Base into the two parts. For example, if your Root DN was dc=example,dc=com, you can set your Root DN to dc=com and your User Search Base to dc=example. You should set your Group DN to dc=example as well unless you’re using user attribute mode for group search.
Also, any ideas about a 404 error when trying to access the LDAP user page to edit the user? (/manage/accounts/users/ldap:cn=…)
When LDAP settings are modified groov Manage invalidates existing users in the database. For example, suppose the User Search Base was originally too broad, and there was a user who wasn’t intended to be allowed to sign in. Then, the User Search Base is made more specific, and the LDAP settings are re-saved. Manage. invalidates all LDAP users as a precaution. There’s a message that pops up to confirm this change, “LDAP users that have been assigned permissions in ‘Local Permissions Mode’ will be lost due to the configuration change, and all LDAP users will be signed out.”
The issue you’re running into is likely due to trying to access a URL of a user that was in the system prior to modifying LDAP settings but was invalidated and is no longer present until next time they sign in.
I hope that’s helpful.
Thanks for getting back to me. I am very familiar with our LDAP setup as I have many Ignition gateways that I manage that are fully configured for users using LDAP.
This was simply by clicking on the user on the users page.
I thought of this same thing, but got errors when I tried this, I didn’t capture the error, but can try again tomorrow. For now, I setup the user base to a subfolder, which works for now, but is not ideal longterm as some users are in different parts of the ldap structure. For example, in Ignition, we specify multiple fully qualified search bases for each part of the LDAP tree we want searched.
I was able to get the LDAP auth working for a user, but still not able to get the permissions working. Is there any way to see the LDAP logs to debug it further? Thanks!
Thanks for getting back to the forums.
Please shoot our support group an email.
https://www.opto22.com/support
