FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    LDAP connector resets User Registrations

    Scheduled Pinned Locked Moved
    Q&A
    3
    7
    2.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Y
      yb98
      last edited by 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.

      1 Reply Last reply Reply Quote 0
      • J
        jared
        last edited by

        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.

        danD 1 Reply Last reply Reply Quote 0
        • danD
          dan @jared
          last edited by

          @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.

          --
          FusionAuth - Auth for devs, built by devs.
          https://fusionauth.io

          J 1 Reply Last reply Reply Quote 0
          • J
            jared @dan
            last edited by

            @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.

            danD 1 Reply Last reply Reply Quote 1
            • danD
              dan @jared
              last edited by

              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.

              --
              FusionAuth - Auth for devs, built by devs.
              https://fusionauth.io

              J 1 Reply Last reply Reply Quote 0
              • J
                jared @dan
                last edited by

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

                danD 1 Reply Last reply Reply Quote 0
                • danD
                  dan @jared
                  last edited by

                  @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!

                  --
                  FusionAuth - Auth for devs, built by devs.
                  https://fusionauth.io

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post