Univention Bugzilla – Bug 57205
User Filter in LDAP federation settings prevent some pages in Keycloak's web interface from loading
Last modified: 2024-04-24 14:56:11 CEST
You recently allowed machine accounts to login via Keycloak. Those are LDAP objects without a uid, but with a cn instead. Keycloak now runs into errors when trying to load some pages. The web interface then states "Network response was not OK." Reproducible example: Got to Clients, open the settings of a client, open the tab "client scopes." root@pdn:~# univention-app info UCS: 5.0-7 errata1011 Installed: cups=2.2.1 keycloak=23.0.7-ucs1 nextcloud=27.1.6-0 samba4=4.16 squid=3.5 ucsschool=5.0 v5 4.4/ucsschool-veyon-proxy=4.7.4.14-0 Upgradable: The DEBUG log: Caused by: org.keycloak.models.ModelException: User returned from LDAP has null username! Check configuration of your LDAP mappings. Mapped username LDAP attribute: uid, user DN: cn=backup,dc=schultraeger-xz,dc=intranet, attributes from LDAP: {entryUUID=[8fcb60b2-8537-103e-94fa-43fc3b954a5c], sn=[backup], createTimestamp=[20240402122331Z], modifyTimestamp=[20240402122331Z]} at org.keycloak.storage.ldap.LDAPUtils.getUsername(LDAPUtils.java:169) Working workaround: Go to User Federation -> ldap-provider. In the section "LDAP searching and updating" edit the formerly empty field "User LDAP filter": Add the filter (uid=*) and save. Result: The client scopes can be opened again.
> You recently allowed machine accounts to login via Keycloak. Those are LDAP objects without a uid, but with a cn instead. Small correction: machine accounts have a uid (uid: hostname$). It's just the LDAP-filter that we use in Keycloak that didn't require uid.
Two additional insights for the record: 1) The "cn=backup" object that was blocking here is not a machine account. It's and account similar to cn=admin, that seems to be a relict from the past, see Bug 31252, which suggests to remove it. 2) Why did cn=backup block, but cn=admin doesn't? Because cn=admin is covered by a dedicated LDAP-ACL in slapd.conf
(In reply to Arvid Requate from comment #3) > 2) Why did cn=backup block, but cn=admin doesn't? > Because cn=admin is covered by a dedicated LDAP-ACL in slapd.conf Nit: `cn=admin` is *rootdn* for which *NO* ACL is applied: <man:slapd.conf(5)>: > access to … > … The rootdn can always read and write EVERYTHING! … > > rootdn <dn> > Specify the distinguished name that is *not* subject to access control or …
> Nit: `cn=admin` is *rootdn* for which *NO* ACL is applied: That rule applies only to cn=admin as binddn. What I was talking about is cn=admin as object of a search. Note also: Having cn=admin represented as an actual object in LDAP is UCS specific and usually not required.
The ldap filter now requires the uid attribute. Successful build Package: univention-keycloak Version: 1.0.11-2 Branch: 5.0-0 Scope: errata5.0-7 User: fbotner Package: ucs-test Version: 10.0.21-24 Branch: 5.0-0 Scope: errata5.0-7 User: fbotner
OK: Admin console doesn't crash anymore OK: YAML OK: Jenkins OK: Keycloak product tests Verified
<https://errata.software-univention.de/#/?erratum=5.0x1028>