Repository navigation
Replies: 1 comment 2 replies
|
While I don't have direct experience with your use case in particular, did you try adding and then removing a user from an AD group too see if the changes are correctly reflected in Keycloak (without performing any local changes otherwise)? From your description, it sounds like the user was added to the Keycloak group by a Keycloak administrator, and they were not removed from the group when the sync ran even though they were never a part of the group as far as the AD sync was concerned (so there was no change to sync). If that is the case, but Keycloak correctly updates memberships when the data comes from LDAP exclusively, it may simply be a case of having two sources of change in the system; when that happens, automatic resolution will never be able to correctly handle all cases - would it be correct for the admin decisions to override LDAP settings (I would argue that it likely would be, in most cases), or should the LDAP settings be the "one source of truth" in the system, so changes in the user federation would override any local changes? From an implementation standpoint, it may just be that local changes are kept in the local database, while federated user data may not be directly stored in the database - it's dynamically mapped from LDAP data to a Keycloak user representation; consequently, the LDAP information does not have a direct representation to the Keycloak user information tables, making it impossible to override existing data (local group membership) with non-existing (lack of group membership) federated information. |
|
Unfortunately it seems this also happens when the groups are not manually edited in Keycloak and also when those edits come from AD |
|
I don't have a LDAP instance set up to test it right now, but could you please confirm what you see in the following flow?
The LDAP integration does have some quirks, such as creating users in the Keycloak database and keeping some data split between the database (e.g., OTP / webauthn data) and LDAP (e.g., the password). I don't expect that the database entry is removed if the user is removed from LDAP; Keycloak will probably check whether the entry still has a mapping to LDAP when the user information is requested, or authentication will simply fail since the password cannot be verified. Some information is synchronized between LDAP and Keycloak conditionally using mappers (https://www.keycloak.org/docs/latest/server_admin/index.html#_ldap_mappers) and group membership is part of the mappers. If not enabled by default, you probably need to enable the |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We are attempting to use Keycloak to both sync groups from an Active Directory (Read Only) as well as maintain groups within Keycloak that are not stored nor synced into the Active Directory. When we turn on the Full Sync feature, it does not seem to remove users from groups that exist in the Active Directory but that the user is not a member of.
For example:
GroupA is a group in Active Directory. John Smith is a member of GroupA in Keycloak and in Active Directory. John Smith is removed from GroupA in Active Directory. When a full sync occurs, John is still a member of GroupA in Keycloak.
The only option that seems that it would possibly help would be “Drop non-existing groups during sync”, but because we maintain some groups that are specific to Keycloak and do not get synced to Active Directory, those groups would be deleted.
Is this a bug in Keycloak or just a limitation of how LDAP syncing functions?
All reactions