How get controllers.yaml from existing controller

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:

  1. Admin bootstrap the candid enabled controller.
  2. Admin does “juju grant USER@corporate login”
  3. Admin does “juju grant USER@corporate add-model” (For those users that has cloud-logins/credentials)
  4. 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.

This feels like something I need to try out… but wasn’t this related to the discussion with @hallback above (requires root privilegues for the user at the client side)?

No root required. We’ve done work in 2.6 for login so it should just work to get the user setup. They’ll be asked to trust the cert fingerprint during their first login but that’s it.

1 Like

Oh! I’ll try it out as soon as possible and get back to this once I’ve tried it out and revise the process above =)


I tried this method, and it “almost” succeeded.

On the controller, the admin issued: “juju grant USER@corporate superuser”

Then, I tried to login:

$ juju login -c iuba-vmware -u USER@corporate
Controller “” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y

ERROR cannot log into “”: invalid entity name or password (unauthorized access)

Hmm, it failed. Lets try with admin.

$ juju login -c iuba-vmware -u admin
Controller “” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y

Enter password:

Welcome, admin. You are now logged into “iuba-vmware”.

There are 2 models available. Use “juju switch” to select
one of them:

  • juju switch controller
  • juju switch default

So, now I logout admin:

juju logout

… and try login with the “normal” username (USER@corporate)

juju login -u USER@corporate
Opening an authorization web page in your browser.
If it does not open, please open this URL:
Couldn’t find a suitable web browser!
Set the BROWSER environment variable to your desired browser.
Welcome, USER@corporate. You are now logged into “iuba-vmware”.

There are 2 models available. Use “juju switch” to select
one of them:

  • juju switch admin/controller
  • juju switch admin/default

Seems that logging in, getting those cached credentials, is either me doing something wrong or isn’t working properly?

“juju version 2.6.6” (controller + client)

Hmm, the thing I think that is missing is getting the user account know in candid first. I wonder if @martin-hilton has any insight into that first load of the user into Candid and how we might seed that. Does the user need to make sure to first log into the Candid login webpage? Then would the juju login succeed?

1 Like

In the first example it doesn’t look like it is getting as far as talking to candid. It looks like juju (It doesn’t look like JIMM if it’s at 17070) is rejecting the user based on not knowing the username. If you repeat with --debug we might be able to tell where it’s getting stuck.

Ok, so @erik-lonroth can we try this:

I think the gap is that you have to make sure that the controller knows about the user so we have to run the add-user command with the @corporate (or actually external?) user.

So I think the steps need to be

juju add-user USER@external
juju grant USER@external login
juju grant USER@external add-model

Then the user can

juju login -c iuba-vmware -u USER@external

Let me know how that goes for you. I think we’re close! :slight_smile:


We’ll have a go on this. @xinyuem is also looking at this.

A question on the “external” - what is this for really as we are in fact using “scania” here instead of “corporate” and/or “external” as I just changed that to make it more general to the post. What would the meaning of that name be?

I’m not sure. I think at one point in time the idea was there would be users across federated identity back ends so you’d have rick@canonical and bob@scania. In the end, I think the @external is currently tied as a hint that “user that’s not a native juju account” so that we’re not trying to match the username/password in the local juju db but lean on the external identity provider.

Ah, I see. I think we’ll stay with “scania” then since this might go with your original thought and after all, we are authenticating with our company ActiveDirectory LDAP backend.


$ juju add-user USER@scania
ERROR failed to create user: invalid user name “USER@scania”

$ juju add-user USER@scania “Mr Smith” --debug --verbose
09:56:18 INFO juju.cmd supercommand.go:57 running juju [2.6.8 gc go1.10.4]
09:56:18 DEBUG juju.cmd supercommand.go:58 args: []string{"/snap/juju/8873/bin/juju", “add-user”, “KONSMH@scania”, “Mr Smith”, “–debug”, “–verbose”}
09:56:18 INFO juju.juju api.go:67 connecting to API addresses: []
09:56:18 DEBUG juju.api apiclient.go:1092 successfully dialed “wss://”
09:56:18 INFO juju.api apiclient.go:624 connection established to “wss://”
09:56:18 DEBUG juju.api monitor.go:35 RPC connection died
ERROR failed to create user: invalid user name “USER@scania”
09:56:18 DEBUG cmd supercommand.go:496 error stack:
failed to create user: invalid user name “USER@scania”

… so back at [1]

The add-user command is for dealing only with local users on a controller.

As @rick_h mentioned above, the idea was always for an identity provider to managage external users, like the @scania part. I had always thought that the part after the @ would be configurable. Not sure if that bit was implemented.

So, the way to get the USER@scania would be to use candid.

Local users can’t have the @ sign.

1 Like

Yes, we do have candid, integrated with AD, but the thing is that we’re trying to figure out how to get the juju client setup for a controller without having to copy or edit yaml files.

The ‘juju register’ way was super, but that doesnt work with candid.

I would have thought that the juju login command would work for that.

Given an unconfigured juju client?

Yes. The login command hits an unauthenticated endpoint to initiate download of the server CA Cert, and the user is authenticated. There are some caveats…

  • the machine needs to have routability to the controller
  • the controller should be configured with candid
  • the special user everyone@external should be granted login and add-model permissions

The external user should not be added as per @rick_h’s post above. everyone@external is a special user that exists for the purpose of configuring general perissions until Juju gets proper RBAC security.

NOTE: you should use “@external” here even though you use “@scania” for the candid entries because “everyone@external” is a hard-coded string in Juju just now.

1 Like

YES! Finally!

I can confirm that this works acceptably good.

So, admin or a superuser in the controller does this on the controller:

juju grant everyone@external login
juju grant everyone@external add-model

Then the “juju-client” does:

juju login controller-ip-or-hostname:17070 -c name-of-controller

Note! The client must not provide the username at login (will error) but instead uses the URL login provided by candid for that.

Login succeed!

After this, adding cloud and credentials is needed to be able to “juju add-model” as:

juju add-cloud … (cloud name must match exactly the cloud name in the controller)
juju add-credential …
juju update-credentials …
juju add-model …
… etc

As a follow up question: Is there a way to extract the cloud names from the controller since that is important for the subsequent “juju add-cloud” to make sure the name of the clouds are exactly the same on the client as on the controller…

This is by all means great news for the simplified way of adding in new users to a/the Juju infrastructure. Thanx alot for taking us there!

Nice! Glad you found a path. Can you give an example of what you mean by “the client must not provide the username at login”? Do you mean providing the username argument to the login command?

As for the clouds, you should be able to use something like

juju list-clouds --format=yaml

The one thing you’ll hit is a bug that I’ve asked @nammn to look into as part of his onboarding:

Clearly that’s going to be a pain point and we’re looking to have that adjusted for 2.7.