Solved User takeover (from an external directory provider)

[luckow]

In 7.1.x the new Directory Server feature has arrived in Cloudron. This is the first time that it is officially possible to share your users with applications / services that are not on the Cloudron instance. Or to share users across different Cloudron instances. #yippie

Everything works perfectly on the greenfield site. But the "old" users had to cope with the previous limitations to meet their needs. E.g. the need to distribute users to different instances. That was the time of the "external directory" feature and services like okto, jumpcloud or ucs (univention).

Now, if the "old" user wants to move completely to Cloudron, there is a task that consumes lifetime. Delete the users in okto, jumpcloud, ucs and in Cloudron (because they are an "external" user reference) and add them back to the Cloudron instance. Apart from the potential problems because of the UID change, it makes absolutely no sense to do monkey jobs in 2022. (I know what I am writing because I have migrated a few dozen users this way).

To save people lifetime: please add some kind of user takeover button next to user list (in dashboard) and transfer all attributes including uid from external directory to Cloudron. If this is too complex, a simple bash command will also work.

[girish]

I like this idea I think this is just a matter of changing the user source field internally but @nebulon knows best.

[nebulon]

yes this should be a very trivial feature. I think we can do this in 7.2

[nebulon]

While looking into this, I found that the current behavior is, that if a local user is found by username in the external ldap directory, that local user will be mapped to the one in the external ldap. So once we have the feature to make an ldap user local, it will be mapped to ldap again, as long as a user with the same username exists in ldap.

I am not sure why it was implemented with that mapping in mind, but we can now either keep this behavior or drop that automatic mapping. Are there any opinions about this?

Of course since your initial use-case already mentioned, that the user will be deleted in the external ldap directory, this will probably not be hit in your case then.

[nebulon]

This is now implemented and will be part of the next release.