appRole defined in AzureAD application not being included for guest user of type "External Azure Active Directory" - azure-active-directory

Have AzureAD application for authentication with appRoles defined in the manifest. The roles are assigned to users and they are included in tokens of authenticated users as claims. This is the case with members of the current tenant as well as newly added guest users of type "Microsoft Account" for the source of authority. (The signInAudience of the application is set as AzureADandPersonalMicrosoftAccount in the manifest.)
But for an existing guest user of type "External Azure Active Directory" for the source of authority, the appRole is not coming through the token claims. Is it worth trying to delete the guest user account and try readding it? Wouldn't this particular feature/behavior of appRoles be the same whether the source of authority for the guest account is "Microsoft Account" or "External Azure Active Directory"?
Or wondering might there be some additional/complementary setting that needs to be set or adjusted for the "External Azure Active Directory"?
PS: the authorization endpoint used currently is https://login.microsoftonline.com/common, and it authenticates just it's not getting the appRole, and it works with the appRole for the "Microsoft Account" type of guest account. Should that be changed however..?

Yup that was it. Based on suspicion tried changing the authority to tenant based https://login.microsoftonline.com/contoso.onmicrosoft.com and it worked... yes because guest user of type "External Azure Active Directory" would of course authentication against their tenant if using https://login.microsoftonline.com/common, and get their roles. So by forcing to authenticate against specific tenant where they are registered as guest users (where the roles are defined), the roles are added to the claims. Of course guest users of type "Microsoft Account" don't have their own tenants so were being authenticated against the tenant anyway... ha ha. Just found out this morning worked. First time using AAD, but kind of makes sense when think about it... Thnks!

Related

Azure AD SSO Guest user can't login

On guest user login on redirect URI I got an error:
AADSTS1000031: Application {App name} cannot be accessed at this time. Contact your administrator.
I'm using multi-tenant approach. The authorization URL looks good and it redirects me with such an error.
But I can't find any description of the error or configuration in the azure related to this error.
Also, "normal" users can log in without any issues.
I have such configuration in my Azure App:
Could you please advise how can I enable guest accounts support here?
This error can occur if you have not granted admin consent.
Go to Azure Active Directory within the Azure portal.
Go to Application registrations.
Select the Application based on the App-Id.
Go to API Permissions.
Click Grant Admin consent.
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent
Has this SSO been setup as an Enterprise application?
Or are you just trying to get a guest user logged in to your tenancy as a guest?
If it is the later just create a new Guest user within your tenancy, make sure you have the rights to to do this first.
Then have the guest user accept the email invitation they receive.
Confirm within Azure they have accepted the invite.
Also make sure they are using the same email address as the invite was sent to and not an alias, which can cause confusion.

Azure AD Consent when adding a permission requiring Admin consent

I have a Desktop application using ADAL to authenticate to a multi-tenanted Azure AD v1 application.
Version 1 of my application only required delegated permissions that didn't require Admin consent:
Microsoft Graph - sign in and read user profile
Skype for Business online - Create skype meetings
Version 2 now requires an additional permission, which requires Admin consent:
Microsoft Graph - Access directory as the signed in user
I've updated the Azure AD app with this permission, and granted admin consent through the Azure AD portal using an admin user homed in the same tenant as the application.
Signing in as a non-admin user who had already consented to the Version 1 permission set (also homed in the same tenant as the application), I don't see the new permission in the "scp" property of the access token I receive - so I'm assuming this means I haven't been given the new permission.
I then try and re-consent as the user, using "prompt=consent", but receive
AADSTS90094: The grant requires admin permission
Implying that admin consent has not been set - although the portal is reporting that it has been set.
From all that i've read, it looks like this should work just fine, so I'm struggling to see what's going wrong. How can I get this working?
I think this is a configuration issue. First, check that your permission type is following the 'as an application' flow.
The clue here is how you described your permission: " Access directory as the signed in user"
That sounds to me like the 'on behalf of' flow, not the 'as an application' flow.

modify permissions of global administrator using graph explorer

I used Graph explorer->Logged in with Global administrator -> Modify Permissions-> chose User.ReadWriteAll,Group.ReadWriteAll,Directory.AccessAsUser.All and then select "access to your entire organization" and logged in again with global administrator
I get below error.
Selected user account does not exist in tenant 'Microsoft' and cannot
access the application 'de8bc8b5-d9f9-48b1-a8ad-b748da725064' in that
tenant. The account needs to be added as an external user in the
tenant first. Please use a different account.
How can I add permissions to global administrator user?
Since your account is a guest in the tenant, you could not use the account to query the tenant, even if you are a global admin.
For more details, refer to this post.
Credentials are only owned by a single tenant. The tenant is discovered by Graph Explorer based on domain. You cannot use Graph Explorer to query tenants your account is a guest on, it can only query the tenant that owns the account. The only way to use those creds with another tenant would be to force the OAuth uri to use that tenants ID instead of "common". This isn't supported by Explorer. You'd have to download the source an reengineer the auth process

Microsoft Graph Azure AD User Out Of Sync

When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,

NameIdentifier vs ObjectIdentifier

I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.

Resources