This doesn’t apply for us since we have a “candid” server which has the users password already set in our local ActiveDirectory.
The controller “superuser”(s) just do “juju grant USER@corporate login” + "juju grant USER@corporate add-model
(The juju grant add-model isn’t documented btw )
… so, the superuser never gets a register command to send to a user (as this post initially described).
The process so far is something like this:
- Admin bootstrap the candid enabled controller.
- Admin does “juju grant USER@corporate login”
- Admin does “juju grant USER@corporate add-model” (For those users that has cloud-logins/credentials)
- Now, USER, needs to get relevant information which currently is:
- USER runs “juju” once to get .local/share/juju/ directory with defaults.
- copy a controller.yaml + cloud.yaml
- … or USER must modify/replace controller.yaml + clouds.yaml
- USER must run "juju switch somecontroller
- USER must run “juju add credential” corresponding to the contents of the yamls.
- USER must run “juju update-credentials …” (a few times if vsphere due to getting logged out all the time)
- USER must run “juju set-default-credentials …”
- USER must run “juju login -u USER@corporate”
- USER must run “juju switch somemodel” (or juju status will throw ERROR)
… I might miss out on some detail above, but consider a new user of juju. The experience so far from 2 experienced devopsers in our company needed significant assistance from me and @xinyuem to get going with this. I hope we are doing something horribly wrong.