I've installed RStudio connect on a CentOS VM which was originally configured for password authentication. An admin account was created, as part of the installation, and it's apparently only useable when the auth = password.
I'd like to change this to use LDAP, and have gotten that configuration working properly. I made all the necessary changes to the .gcfg and set auth = ldap, but now there's no way to login to the original admin account that was created.
When transitioning to LDAP in this way, how can I ensure I have an admin account available for admin needs?
Migrate the old admin / user accounts (or all content from the old admin account / user accounts) to the new authentication scheme. That is articulated in the article here:
NOTE that once all content owned by the old accounts has been removed or migrated to new accounts, you can also use the usermanager CLI to delete accounts. If you are using a SQLite database (the default), then you have to stop RStudio Connect in order to use the usermanager CLI.
I hope that helps! Please let us know if you have any follow-up questions on this topic! It is an area we are trying to actively improve our documentation, as many customers have run into this challenge!
EDIT: If you have not specified LDAP.UniqueIdAttribute and LDAP.GroupUniqueIdAttribute, we would definitely recommend doing so. It protects you against DN changes, which will require manual intervention otherwise.
Since you have LDAP authentication already working (and if you have it already working with DN), then you will want to use the usermanager alter --users --update-ids-using DN command after setting the UniqueIdAttribute in the rstudio-connect.gcfg file.
There are examples in the admin guide for all of this as well.
Thanks @cole! Funny enough I found the same thing and I'm working towards that now.
When I rune ./usermanager alter --username user --role administrator I get a "flag provided but not defined: -role" message followed by a list of all flags for this operation. Any suggestion on that...?
Yeah, you should be using --new-role I think Super close!
EDIT: Also, it is "best practice" to refer to users by --user-guid, since a future version of the product may decide be lax about referencing by username (i.e. allow multiple users with the same username) User GUIDs will always be unique
Super close!
User GUIDs will always be unique