Connect-vRAServer - Usecase issue where UPN used as Username

[Stevio54]

The recent update to the Connect-vRAServer commandlet to add advanced authentication login functionality helped me locate a new issue.

If an environment sets the UPN (userPrincipalName) as the userName for vRealize Automation, they will not be able to authenticate. This is because the UPN often takes the form of a domain login (e.g. scarnes@my.local) and so the advanced login is used, by splitting this into its two parts (username = scarnes, and domain = my.local).

However, in that case, the login will fail as the server is expecting it to come through as such: (username=scarnes@my.local, and domain = my.local).

We need to address this login use-case, and my proposal is to add a $Domain parameter to the login, and infer an advanced login when this is provided, or simply use the simple login process.

As an alternative, I also suggest in addition to this to also provide a flag such as "-Advanced" in order to force the use of the advanced login as well. (and in this case, it can infer the domain from the username supplied)

[Stevio54]

After some thought, introducing a Domain parameter and supplying a LoginType with a default value of "Simple" and an optional value of "Advanced" may be a cleaner approach

[martin9700]

Maybe even getting more granular in the login type: Simple, DomainUser, UPN, etc. Approach it as someone who's never looked at the code and won't know what "Advanced" means.

[Stevio54]

so, I researched a little more into the logins and the types. I don't actually see why we care which login you use.... In either case we are currently not allowing the user of a cspAuthToken as that does not work for the API calls we make. Also, I tested, and when we send login payloads to either place (i.e. /csp/gateway/am/idp/auth/login or /csp/gateway/am/api/login) the payload to send is the same schema:

As seen we have the option to send the domain or not. I tried all types of logins on both URL's and all work fine without the need to "infer" a domain after the @ symbol.

{
  "username": "Administrator",
  "password": "REDACTED",
  "domain": "System Domain"
}

{
  "username": "scarnes@kpsc.io",
  "password": "REDACTED"
}

{
  "username": "scarnes",
  "password": "REDACTED",
  "domain": "kpsc.io"
}

Even this

{
  "username": "scarnes@kpsc.io",
  "password": "REDACTED",
  "domain": "kpsc.io"
}

All of the above worked, and the payload we get back is always the same, here is an example (all tokens have expired at this point).

{
    "scope": "openid profile user email",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjE3ODE3NjI3MjMxODg4MjcyMDkwIn0.eyJpc3MiOiJDTj1QcmVsdWRlIElkZW50aXR5IFNlcnZpY2UsT1U9Q01CVSxPPVZNd2FyZSxMPVNvZmlhLFNUPVNvZmlhLEM9QkciLCJpYXQiOjE1OTUyODg2NzIsImV4cCI6MTU5NTMxNzQ3MiwianRpIjoiZTc5NTQxMmItOTY4NC00NGU0LTlmMTUtYWQzZTkzNzJmMzdlIiwiY29udGV4dCI6Ilt7XCJtdGRcIjpcInVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0XCIsXCJpYXRcIjoxNTk1Mjg4NjcyLFwiaWRcIjoxNX1dIiwiYXpwIjoicHJlbHVkZS11c2VyLVNDVEJwSVZ4YkEiLCJzdWIiOiJTeXN0ZW0gRG9tYWluOjk0YjBjNWMzLTRiNzYtNDcxYy1iZTYwLWMzMTc3Nzc0YTA4YSIsImRvbWFpbiI6IlN5c3RlbSBEb21haW4iLCJ1c2VybmFtZSI6IkFkbWluaXN0cnRvciIsInBlcm1zIjpbImNzcDpvcmdfb3duZXIiLCJleHRlcm5hbC9mOGRiZmQ0Zi0yZTJkLTRlZjEtOTdjNS0wNDBiMGU1YmQwZDIvYXV0b21hdGlvbnNlcnZpY2U6Y2xvdWRfYWRtaW4iLCJleHRlcm5hbC9hMDJhMDgyMi1lMjg0LTRhNTMtOTYzMi1jMzA0NWFiY2NjM2QvY2F0YWxvZzphZG1pbiIsImV4dGVybmFsLzBlM2E4MWY2LWU0ZjMtNDM4MC1hNDZkLTVjYWVlMmZkNWRhMS9taWdyYXRpb246YWRtaW4iLCJleHRlcm5hbC9kYzQwYjAwYi04MzYxLTQ3ZWYtYWEzMi05OGZlNGNhZWE3OTgvQ29kZVN0cmVhbTphZG1pbmlzdHJhdG9yIiwiZXh0ZXJuYWwvN2VjMTA2NjYtN2M3Ny00OTUyLWJkMjctYzhiZjUyYjkzZTQxL29yY2hlc3RyYXRpb246YWRtaW4iLCJleHRlcm5hbC83ZWMxMDY2Ni03Yzc3LTQ5NTItYmQyNy1jOGJmNTJiOTNlNDEvb3JjaGVzdHJhdGlvbjpkZXNpZ25lciIsImV4dGVybmFsL2RjNDBiMDBiLTgzNjEtNDdlZi1hYTMyLTk4ZmU0Y2FlYTc5OC9Db2RlU3RyZWFtOmRldmVsb3BlciJdLCJjb250ZXh0X25hbWUiOiJjZjNmMWE4ZS1lMGNjLTQ3YWItYTJlMS0xZDRmMTFkZDYyYzMiLCJhY2N0IjoiQWRtaW5pc3RydG9yIn0.nnyRGrkAhFTDPIjS0T-Pczy31R-3LAG9zXg77E_x_VBFjNLFl9wr5eNhywnei5SCXdL22fukzhkwyXqa0uhr203ezL2WfsFeGBMDEfv2ULqZnPgZc0xu5AOquY65_3YpkuXyVv2_3r7bN8b1o5g8Fu3fiPszNXPPmi4r5TEdPwDfzKHWnXE7x36z75L256mcofH6bhpeRZ13_7H7WOoHlB5YvJgr9JfBkopWA565qLbGsVRr76fAZmsI9yexZqHZSpRNZn6pIKQTHph1wzmNYOCxYnpmYt18idWC0oaLtmIL3ruMKaKWGhpU5hmsxcRK_9bmJ7l21qZ3SdTAVgCTYg",
    "refresh_token": "6aFq2JOYr22M6JwnyhpDU8AwI7wCD2ei",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjE3ODE3NjI3MjMxODg4MjcyMDkwIn0.eyJzdWIiOiJTeXN0ZW0gRG9tYWluOjk0YjBjNWMzLTRiNzYtNDcxYy1iZTYwLWMzMTc3Nzc0YTA4YSIsImlzcyI6IkNOPVByZWx1ZGUgSWRlbnRpdHkgU2VydmljZSxPVT1DTUJVLE89Vk13YXJlLEw9U29maWEsU1Q9U29maWEsQz1CRyIsImF1ZCI6InByZWx1ZGUtdXNlci1TQ1RCcElWeGJBIiwiZXhwIjoxNTk1Mjg4NzkyLCJpYXQiOjE1OTUyODg2NzIsImF1dGhfdGltZSI6MTU5NTI4ODY3MiwiZ2l2ZW5fbmFtZSI6IkFkbWluaXN0cnRvciIsImZhbWlseV9uYW1lIjoiQWRtaW5pc3RydG9yIiwiZW1haWwiOiJjb25maWd1c2VyQHZtd2FyZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZ3JvdXBfbmFtZXMiOlsiQUxMIFVTRVJTIl0sImdyb3VwX2lkcyI6WyJjNjI3ZDUzNS1lODNhLTRiYjItYTk2YS1jYWJkYjUyMzljZGEiXSwiY29udGV4dF9uYW1lIjoiY2YzZjFhOGUtZTBjYy00N2FiLWEyZTEtMWQ0ZjExZGQ2MmMzIiwidXNlcm5hbWUiOiJBZG1pbmlzdHJ0b3IiLCJhY2N0IjoiQWRtaW5pc3RydG9yIiwiZG9tYWluIjoiU3lzdGVtIERvbWFpbiJ9.aDgJSgbntxZF-HRJQGBx4pV_B2lG_x6i7hCRiDBjt_DXRFo2ZJTTeHSu5U3y1ugkkd5cSlqmabcpr1m1ONcnW3p6iHD7Zg5vT-nJJz62C8fKqPoqQOiZs-xDP8Y1nNrQOaeokY-RcV0iCWoKd17xLEdZi3m5JydBiMvBuLWcPURj1k0zSsoGqt6X6XrJ-Yj1_Ag71EQ3RLL38zIJ-lxGuR-vzGVYCUhrAcqhB5u-dgr4kWK42MZWAcfyircX0z7NNhHeg8EitQO4N-tvemnqD0dSSZL2E1dCX2qsocWfHmebJF1MLOVyJ0rdzsS9PwqVm32HjSGFvrGo_tncNhAd_w",
    "token_type": "Bearer",
    "expires_in": 28799
}

So, my thought is to just reverse the last change to the login, and choose a method to use. The Doc's do call one of the logins "Enhanced" but I fail to see how it is.

What are others thoughts on this?

[Stevio54]

One last thought, there is one scenario I forgot to test and that is when the user is set to the SAMAccountName and the username in the payload includes the domain. If that doesn't check out it's back to the drawing board but unfortunately I have some personal errands for the rest of tonight until I can get back at it.

[Stevio54]

After further investigation this morning, I found that if the IDM is set to use SAM instead of UPN, it does require a specific syntax to login, so I will continue with my pull request.

[Stevio54]

About to link a pull request. Kept this simple and just added a parameter called UserAttribute, which takes (UPN,SAM,sAMAccountName, or userPrincipalName) as values, and defaults to SAM. For more information please take a look at the pull request that is incoming.

[jonathanmedd]

@Stevio54 Nice work on this one, appreciate the thorough effort to test the different scenarios.