Open wahyuen opened 3 years ago
Hey @wahyuen, can you run the following commands and share the output? Censored/PII removed of course:
get-azcontext get-aztenant
If there's more than one tenant in get-aztenant can you please share if the subscription from get-azcontext is from your primary/home tenant or a separate one?
@thefaftek
The subscription in question is NOT my primary/home tenant. I am a guest user in the tenant of the subscription. This is a common scenario for us given our company structure.
It's the name convention in AD. #Ext# is added when user is guest. You can check return properties of Get-AzADUser
.
If you are search the user in yourself tenant (not MSA), I believe UserPrincipalName should match to your account id.
Please let us know if you need further clarification.
@dingmeng-xue my issue isnt related to the fact that it is marked with #EXT#, we already have code that caters for this variation. Our issue is that the domain of the user does not match for the guest user at all, hence there is no way (that we can currently see) to marry up the logged in user, to a user in the given tenant.
To clarify,
Get-AzContext
returns an account UPN of type something@firstdomain.com
Get-AzADUser
for the same user, returns a value of something@adifferentdomain.com#EXT#anothervalue
because the domains do NOT match, we have no other correlating information from the Get-AzContext
call to programatically determine who the signed in is.
We ONLY have access to query against the current tenant that the script is running against, not the 'home' tenant of the guest user. These scripts are being executed as part of deployments into customer sites where our staff are doing the work for our clients.
The team feels alot of these issues would go away if the Get-AzContext
call simply returned the objectId
of the user which is currently signed in, instead of having to perform various amounts of string matching and filtering on subsequent calls.
@dingmeng-xue @wahyuen @thefaftek
Hello,
I have the same problem especially for a tenant whose user is considered as #EXT#. We can by a number of workarounds find the mail or the account id which often happens to be the mail too but not the UPN and even less the unique ObjectId. Whether it is by the Az.Resource or Az.Account modules when we connect or by AzureAD, it also does not work. Moreover, the type of DLLs behind it are not the same.
AzCli uses MSGraph as a backend for the -signed-in-user parameter (which is the /me for MSGraph by the way) but I didn't want to use two systems with additional context loads either.
Anyway, this is to say that I had the workaround solution in front of me, indeed we have access to the Access Token (which is now easier with the Get-AzAccessToken Cmdlet) and when you decode the JWT (quite easily since it's three strings in B64 to convert to JSON) which will give you a Powershell Object --Boom you have access to all the necessary information the oid is the ObjectId of the user in short you also have the unique_name which is the UPN and many other fields very useful for many reasons too.
I hope this will be useful for you while waiting for the updates and improvements of Az and AzureAD Modules but I think that playing with the Token would not be a bad idea anyway.
Have fun and have nice day.
yeah please fix this. if I do something like creating storage account and with a script, I would like to be able to assign myself an appropriate data plane role. But I cannot reliably find the "myself" object id, because ... I am probably not supposed to have if/else/else chains for multiple different kinds of users like guest vs member logging in from the home tenant, other tenant, from ms account, whatever.
Description
I'm currently attempting to resolve the currently logged in user of the Az Powershell context against the actual User object registered in Azure AD for the given tenant that I am in.
From documentation, I believe that
(Get-AzContext).Account.Id
should populate with the UPN of the given user that is logged in. However, the actual value here does not match any actual UPN in my current tenant.My user is a Guest user in the current tenant that I am performing the operations in, however, it appears that even if i remove the
#EXT#
string value in the UPN, the actual base domain value of the UPN doesn't match.Get-AzContext
returns in the forma@b.com
as the UPNGet-AzADUser
returns in the forma@c.com#EXT#
as the UPNSteps to reproduce
Environment data
Module versions