Interesting, I'll check it.

Any word on this?

Hello David, Sorry, i was side tracked. Going to start work on this again today...

Hello again David, I just tried with latest 4.5.3 but couldn't reproduce the issue. I have created a test user for you to test... here it is: - https://mzico-wondrous-marlin.gluu.info/ - tester / tester@gluu.org

I think you meant 4.5.5 as that's what your test server shows, and also what I'm running. This is interesting, because it's clearly different than the behavior we're seeing. I will try to stand up a new 4.5.5 server with a local Postgres install from the installation script to see if maybe it's a difference in the Postgres configuration of our pre-existing server. I'll let you know what I find.

>> I think you meant 4.5.5 as that's what your test server shows, and also what I'm running. This is interesting, because it's clearly different than the behavior we're seeing. Sorry, yes: `gluu-server_4.5.5-3~ubuntu22.04` >> I will try to stand up a new 4.5.5 server with a local Postgres install from the installation script to see if maybe it's a difference in the Postgres configuration of our pre-existing server. I'll let you know what I find. Yes, let Gluu Server install postgres piece as well with setup script.

When I install a new Gluu server with the local Postgres option, the admin user is then able to login with a case-insensitive user name as expected. I was also able to manually add a 2nd user and verify the same. However I discovered that the problem starts after this point, when I turn on cache refresh and configure it to load users from our company's LDAP and set the default authentication method to use that. Once I do that, I'm unable to log in with the original admin account at all, and all the users that are created from our company's LDAP must log in with a case sensitive match on their username. This is different from the behavior I see when using LDAP as the Gluu server's backing storage. In that case I am still able to log in with the original admin user and company users loaded from LDAP can log in with case-insensitive usernames.

Hello David, >> Once I do that, I'm unable to log in with the original admin account at all,... That's normal because, your authentication mode is searching for user 'admin' in your company's LDAP and it don't see anything like that. >> .... and all the users that are created from our company's LDAP must log in with a case sensitive match on their username. That's not usual. I will check to load some users with Cache Refresh. >> This is different from the behavior I see when using LDAP as the Gluu server's backing storage. In that case I am still able to log in with the original admin user... May be your "Manage Authentication" section has some configuration than default one? Some script or some configuration which is reading both 'localhost' and 'remote company ldap'?

When using LDAP as backing storage, we leave the original auth_ldap_server active as well as adding/activating a 2nd LDAP server for our company. In this way we are still able to log in with the original admin user. When using Postgres, it seems that deactivating the auth_ldap_server is required as we get errors on startup otherwise. So I'm assuming that's why we lose the ability to login with the admin user. In any case I'm not too worried about this part. The primary concern is the users created from our company's LDAP requiring case sensitive usernames.

Hi David, >> When using Postgres, it seems that deactivating the auth_ldap_server is required as we get errors on startup otherwise. So I'm assuming that's why we lose the ability to login with the admin user. In any case I'm not too worried about this part. The primary concern is the users created from our company's LDAP requiring case sensitive usernames. I'll check the use case in my local setup.

In my /opt/shibboleth-idp/logs/idp-process.log I noticed errors like this: ``` 2024-10-24 14:42:53,599 - 127.0.0.1 - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:233] - Service 'shibboleth.AttributeRegistryService': Reload for shibboleth.AttributeRegistryService failed net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'siteDataConnector' defined in null: Could not resolve placeholder 'idp.attribute.resolver.sql.searchFilter' in value " %{idp.attribute.resolver.sql.searchFilter} "; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'idp.attribute.resolver.sql.searchFilter' in value " %{idp.attribute.resolver.sql.searchFilter} " at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:377) Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'siteDataConnector' defined in null: Could not resolve placeholder 'idp.attribute.resolver.sql.searchFilter' in value " %{idp.attribute.resolver.sql.searchFilter} "; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'idp.attribute.resolver.sql.searchFilter' in value " %{idp.attribute.resolver.sql.searchFilter} " at org.springframework.beans.factory.config.PlaceholderConfigurerSupport.doProcessProperties(PlaceholderConfigurerSupport.java:230) Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'idp.attribute.resolver.sql.searchFilter' in value " %{idp.attribute.resolver.sql.searchFilter} " ``` I'm not sure how to resolve this error but I found in the community-edition-setup repo here https://github.com/GluuFederation/community-edition-setup/blob/master/setup_app/installers/saml.py#L236 a line that looks relevant: Config.non_setup_properties['sql_search_filter'] = '''select * from "gluuPerson" where ((LOWER("uid") = '$requestContext.principalName') OR (LOWER("mail") = '$requestContext.principalName')) AND ("objectClass" = 'gluuPerson')''' So if my server does not have this sql_search_filter configured it won't know how to run this case-insensitive query.

Hello David, I prepared my testbed last night and I definitely faced issue during login there with `auth_ldap_server`. `auth_ldap_server` connected to my backend LDAP. Checking further now...

I resolved the idp.attribute.resolver.sql.searchFilter error by going to /opt/shibboleth-idp/conf and adding gluu-rdbm-bean.xml and datasource.properties. I think this was an artifact of using the LDAP to Postgres migration script provided in a different support ticket. This didn't help my original issue though, logging in still requires case sensitive usernames.

Hi David, That's correct. I have created a github issue: https://github.com/GluuFederation/oxAuth/issues/1927

OK, issue patched. We are going to release new war file on Monday. I'll let you know.

Hi David, New version released in maven repo. We are doing final testing atm.

**Update** Confirmed, this is the patched version: https://jenkins.gluu.org/maven/org/gluu/oxauth-server/4.5.6-SNAPSHOT/oxauth-server-4.5.6-SNAPSHOT.war If you need help to deploy this war, please let me know. Thanks!

Thanks, confirmed my username login is now case insensitive. It seems to only address the login though. If I go to Users->Manage People and try searching for users, this is case sensitive where LDAP searching is case insensitive. Makes me wonder what other scenarios will also have unexpected username case sensitivity. I will try running this patch and see if we run into any other issues with it.

Thanks David, We have created a Github Issue https://github.com/GluuFederation/oxTrust/issues/2444