After going thru KEYCLOAK-4433 in more detail, I better understood the nature of the "fix" (it's fair to call it less than optimal) and used it... and all is good. Ideally we would not have to create the "hardcoded mapper", and instead commit all LDAP attributes in one transaction. Using a constraint on LDAP attributes for validation purposes means that we have to add these hardcoded mappers for each such attribute. Easily done ... but still. One more gentle suggestion: though the tool tips that pop up try to yell "Only during registration", I did not notice them at first because the hardcoded mapper seems very straightforward so I ignored the tool tips entirely. That mapper would be better served if its name included something like "hardcoded-registration-only" (yes the name is long, but long names are especially useful for temporary solutions). Sincere thanks to the Keycloak team: you help me make a living, and I cannot criticize your work except with the utmost humility. ________________________________ From: A. A. Sent: Saturday, April 13, 2019 9:04 AM To: keycloak-user(a)lists.jboss.org Subject: Re: [keycloak-user] Keycloak Identity Broker to LDAP User Storage? Actually, I've traced the source of my challenge I believe to this excellent analysis: https://issues.jboss.org/browse/KEYCLOAK-4433?focusedCommentId=13364626&a... In my case, I have a few attributes in OpenLDAP that have constraints associated with them (we are using the constraints overlay/extension provided by OpenLDAP). Those constraints prevent the creation of the "default" dummy object. I have confirmed that watching the logs: Keycloak first tries to create a dummy empty object, then moves forward with modifying the returned entry. Is there a workaround to this? Or a configuration option that instead of create empty then modify, instead simply does create with full attributes?