Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved Lessons learned - switching LDAP server - changed UID

    BookStack
    3
    8
    223
    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.
    • luckow
      luckow translator last edited by luckow

      I've started with some users created wiki pages in bookstack. Yesterday I've switched to an external LDAP server, deleted the Cloudron LDAP users and added them with the exact same username to the external LDAP server. Most of the installed apps had no problem with the "new" user from the external LDAP server and served the content created from the "old" Cloudron LDAP user to the new external LDAP user. But not bookstack.
      Bockstack uses a UID as an identifier for the user.
      f5834ccc-5643-47e3-8819-5ad6ea07bef3-image.png
      Because of switching to a new LDAP server, the uid for the user switched. But because the username was the same, bookstack denied the new user (reason: same user with a different uid). Instead of reading the manual at https://www.bookstackapp.com/docs/admin/ldap-auth/ I've deleted the "old" user in bookstack and "created" a new one through a login to bookstack with the "new/old" username. Haha.The uid changed and all my former created content does not more belong to me. (Now it's labeled as: Deleted User updated page).

      The correct workflow has to be:

      • get the new uid from the "new/old" username
      • add the new uid to the user account in bookstack
      • every created content belongs to the "new" user

      The only question is: how to get the uid from the "new" user?
      The only place I know of is the UID form in Bookstack. But that is for the workflow the wrong place 😉

      Any hints where to find that kind of information?

      Pronouns: he/him | Primary language: German

      fbartels 1 Reply Last reply Reply Quote 0
      • girish
        girish Staff last edited by

        @fbartels Ah nice, I wasn't aware of LDAP_ID_ATTRIBUTE=uid . Looks like this was recent, I will fix the package to use username instead of uid.

        On a side note, we have migrated all the Cloudron packages to use username as the LDAP id attribute instead of the usual uid. This was done because the common case (for Cloudron) is to move an app between Cloudrons and it's easier to export/import when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

        fbartels 1 Reply Last reply Reply Quote 0
        • fbartels
          fbartels App Dev @luckow last edited by

          Hi @luckow,

          I don't know bookstack, but my guess would be that the uid is defined/retrieved in:

          # Set the property to use as a unique identifier for this user.
          # Stored and used to match LDAP users with existing BookStack users.
          # Prefixing the value with 'BIN;' will assume the LDAP service provides the attribute value as
          # binary data and BookStack will convert the value to a hexidecimal representation.
          # Defaults to 'uid'.
          LDAP_ID_ATTRIBUTE=uid
          

          Your chances are probably:

          • get a shell in an ldap enabled app and get the uid values for your users and add a new attribute to your external ldap which holds this value (which means manual maintenance for other users since you need to create this value as well)
          • see if you can update the database of bookstack to use the new uid instead of the old one per user.

          @luckow said in Lessons learned - switching LDAP server - changed UID:

          switched to an external LDAP server, deleted the Cloudron LDAP users

          better would probably have been to use the external ldap feature of Cloudron. Afaik it would not update existing users, but then at least all new users in Cloudron be retrieved from the external ldap.

          1 Reply Last reply Reply Quote 0
          • girish
            girish Staff last edited by

            @fbartels Ah nice, I wasn't aware of LDAP_ID_ATTRIBUTE=uid . Looks like this was recent, I will fix the package to use username instead of uid.

            On a side note, we have migrated all the Cloudron packages to use username as the LDAP id attribute instead of the usual uid. This was done because the common case (for Cloudron) is to move an app between Cloudrons and it's easier to export/import when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

            fbartels 1 Reply Last reply Reply Quote 0
            • fbartels
              fbartels App Dev @girish last edited by

              @girish said in Lessons learned - switching LDAP server - changed UID:

              when the LDAP id is the username and not a unique id since usernames will be same across different Cloudrons.

              While using the username as a unique attribute has its upsides, it has also it's downsides. Generally what is exposed to the user (name, email, username) has the potential to change over time.

              girish 1 Reply Last reply Reply Quote 0
              • girish
                girish Staff @fbartels last edited by girish

                @fbartels said in Lessons learned - switching LDAP server - changed UID:

                While using the username as a unique attribute has its upsides, it has also it's downsides. Generally what is exposed to the user (name, email, username) has the potential to change over time.

                Agreed. It's the main reason why we don't allow usernames to be changed on Cloudron. That said, we have hardly had people request usernames be changed. Usually, such things are never done in a corporate environment anyways. Existing email ids and user ids are maybe deactivated but not renamed.

                edit: email on cloudron can be changed just not the username.

                fbartels 1 Reply Last reply Reply Quote 1
                • fbartels
                  fbartels App Dev @girish last edited by

                  @girish ah. I've never noticed that you cannot change the username on cloudron. This is a good enough countermeasure 😄

                  1 Reply Last reply Reply Quote 0
                  • luckow
                    luckow translator last edited by

                    Thank's for releasing an updated version of bookstack. Will try it out next week.

                    Pronouns: he/him | Primary language: German

                    1 Reply Last reply Reply Quote 0
                    • luckow
                      luckow translator last edited by

                      BTW: kind of same behaviour for nextcloud.
                      There is a UID in the user settings, which you can only see with /app/code/occ user:setting in the terminal.

                      And because I switched from internal Cloudron LDAP to an external LDAP I got a new UID for all my users. The strange behavior from nextcloud is:
                      Login with user:pass works. (the schema is firstname.lastname as username).
                      But internally nextcloud adds a _RANDOMNUMBER to it.
                      In my case a stephan.luckow is internally changed to stephan.luckow_3096

                      Problem is: all my calendar entries are based on stephan.luckow_3096 and not on stephan.luckow.

                      Pronouns: he/him | Primary language: German

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Powered by NodeBB