Hi,
jbyars wrote:If you do the ldapsearch you want, you get this response
- Code: Select all
# extended LDIF
#
# LDAPv3
# base <ou=hsc,dc=health,dc=unm,dc=edu> with scope subtree
# filter: (cn=grattan)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
If grattan DN is
cn=rgrattan,...,ou=hsc,dc=health,dc=unm,dc=eduldapsearch should find it. Are you sure you used an appropriate manager account to connect to AD (anonymous may not allow you to see the result)?
- Code: Select all
ldapsearch -x -LLL -H ldaps://your_ldap_host -D "cn=manager,dc=example,dc=com" -W -b "ou=hsc,dc=health,dc=unm,dc=edu" -s sub "(cn=grattan)"
jbyars wrote:If you do
- Code: Select all
bin/omero ldap getdn --user-name grattan
You get back
- Code: Select all
Created session 66d5ef63-191e-4bd7-a438-10f90482416b (root@localhost:4064). Idle
timeout: 10 min. Current group: system
Unknown user: grattan
The user's account is RGrattan. I did make a mistake updating the DN record for that user in 5.0.6. Now I agree with you, that shouldn't matter in 5.1.3 if the DN information refreshes dynamically. But, it does matter. What I was trying to show you in the attachment from yesterday (if you don't have it please let me know) is the response from
- Code: Select all
bin/omero ldap getdn --user-name rgrattan
has changed.
I got your ldapsearch.txt (sorry, please make sure you always put your email address when submitting the file, then we can identify it faster).
jbyars wrote:When I first updated the server to 5.1.3 her getdn response was the mistake DN from the 5.0.6 table carried forward. After changing the username of her account, letting a new account generate for her, and switching account user names back for the real account the getdn response changed to match her DN on the ADS ldap server.
For some reason any mistakes I made in the 5.0.6 carried forward. Whatever event that regenerates the results for getdn, did not happen. The user can now log into the correct account without getting an error. I'm sorry, but I'm not sure I can reproduce the error again without rolling back to a 5.0.6 snapshot of the system and repeating the upgrade.
That sound very strange. As of 5.1 you should be able to easily switch between LDAP/AD with just updating omero.ldap config.
If you wish to enable or disable an ldap authentication for particular account you can always use
- Code: Select all
usage: bin/omero ldap setdn [-h] [--user-id USER_ID] [--user-name USER_NAME]
[--group-id GROUP_ID] [--group-name GROUP_NAME]
[-C] [-s SERVER] [-p PORT] [-g GROUP] [-u USER]
[-w PASSWORD] [-k KEY] [--sudo ADMINUSER] [-q]
choice
Enable LDAP login for user (admins only)
Once LDAP login is enabled for a user, the password set via OMERO is
ignored, and any attempt to change it will result in an error. When
you disable LDAP login, the previous password will be in effect, but if the
user never had a password, one will need to be set!
Positional Arguments:
choice Enable/disable LDAP login (true/false)
bin/omero ldap setdn --user-name rgrattan
Perhaps was easier to do it rather then create new and rename. See doc
https://www.openmicroscopy.org/site/sup ... entication- Code: Select all
bin/omero ldap getdn --user-name rgrattan
should always return appropriate DN.
Last thing you may want to check your operations and see if
- Code: Select all
omero user list
indicates that LDAP flag is True and
- Code: Select all
omero ldap list
returns appropriate DN for that user.
Sorry for a long response.
Ola