LDAP connector resets User Registrations

[yb98]

Hello, I was wondering if it would be possible for FusionAuth to save a user's registration information after they have logged in via LDAP?

The issue we are currently facing is that our customer's LDAP does not contain any information pertinent to a user's registration, rather, LDAP is used in this scenario for authentication only. As such, the reconcile lambda code does not modify the "registrations" attribute of the user, this field is left blank each time the user logs in via LDAP and the resulting user is created inside of FusionAuth without any registrations.

After the user account has been created inside of FusionAuth, they can be assigned roles using the UI. While these roles are saved inside of FusionAuth, it seems that the next time the user attempts to log in via LDAP, their account inside of FusionAuth gets recreated according to the reconcile lambda, as such, they have no registrations again.

Is it possible to designate the LDAP connector to perform authentication only? Or to mark a user account to not get recreated each time it uses LDAP to sign in?

I do know we can migrate the user to FusionAuth, but this will not address issues if the user's account changes within LDAP. I am also aware that there is currently an open issue to allow for the reconcile lambda to communicate with the API (https://github.com/FusionAuth/fusionauth-issues/issues/267), which would solve this issue entirely. Furthermore, it may be possible to implement our own authentication API using the generic connector, although this approach will take longer to implement.

[jared]

This is something that is a potential issue for us as well.

The other big implication of the user being recreated/fully resynchronized is that not only are the registrations removed, but so is any multi-factor authentication that was set up on the user.

[dan]

@jared @yb98

Sorry for the late reply, this slipped through the cracks!

I think this would be an interesting feature request and I see similar issues in GitHub but nothing specifically about authentication only connectors.

Please file an issue with details about your use case (feel free to reference this forum post) if you are still interested in this functionality.

[jared]

@dan
I was the filer of GitHub issue #1438 that mentioned these issues and you and I went back and forth a little bit on it.

"Is it possible to designate the LDAP connector to perform authentication only? Or to mark a user account to not get recreated each time it uses LDAP to sign in?"

This would be my thought process as to how it would work, as my assumption would be that someone who's attempting to connect LDAP is expecting to use LDAP for password management; and that LDAP is likely AD.

Our ideal use case would be to layer FusionAuth on top of using the LDAP system in order to unify access. Specifically, our internal users could use their Active Directory logins in order to enter our public facing website application, but we could layer the TOTP MFA on top of it within that web site user experience (for regulatory reasons). Our external users would entirely be based within FusionAuth with password management handled there. We could also then control application access (registration) for both sets of users totally within FusionAuth.

[dan]

Our ideal use case would be to layer FusionAuth on top of using the LDAP system in order to unify access.

I agree that this is a valid use case, thanks for sharing. I'm just not sure FusionAuth currently meets those needs, as it gets thorny when we have some of the identity managed by AD (like passwords) and then other parts by FusionAuth. A straight passthrough or clean migration are both conceptually easier.

That said, it may make sense to have an overarching feature request explaining the use case you outline here (rather than bits and pieces of it as the link to the github issues query I have above). Please feel free to file that.

[jared]

@dan, do you want feature requests filed via GitHub issues, or is there another location that I'm missing?

[dan]

@jared GitHub issues are the right place for feature requests, thanks!

There's an 'additional context' section for feature requests, and you can feel free to link back to these forum posts. That can help enrich the discussion when the eng team reviews requests to prioritize them.

Cheers!