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 10.104.129.39:17070 -c iuba-vmware -u USER@corporate
Controller “10.104.129.39:17070” 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): yERROR cannot log into “10.104.129.39:17070”: invalid entity name or password (unauthorized access)
Hmm, it failed. Lets try with admin.
$ juju login 10.104.129.39:17070 -c iuba-vmware -u admin
Controller “10.104.129.39:17070” 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): yEnter 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:
https://candid.rnd.scania.com/login-legacy?did=d26af10c4064625960dc550f55b5966bfa16d00b9bc1dcf5b6b3a3e38e79ea34
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 10.104.129.39:17070 -c iuba-vmware -u USER@external
Let me know how that goes for you. I think we’re close! 
2 Likes
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: [10.104.129.59:17070 10.104.129.39:17070 10.104.129.138:17070]
09:56:18 DEBUG juju.api apiclient.go:1092 successfully dialed “wss://10.104.129.39:17070/api”
09:56:18 INFO juju.api apiclient.go:624 connection established to “wss://10.104.129.39:17070/api”
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”
/build/juju/parts/juju/go/src/github.com/juju/juju/api/usermanager/client.go:60:
https://github.com/juju/juju/blob/develop/api/usermanager/client.go#L39
… 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@externalshould be grantedloginandadd-modelpermissions
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.
Yes, it fails with en error if you do
juju login controller-ip-or-hostname:17070 -c name-of-controller -u USER@corporate
You must instead do:
juju login controller-ip-or-hostname:17070 -c name-of-controller
… and provide the username through the candid browser dialog.