In AAD, one could
add new Users to the same Domain
add Guests:
from other AAD Tenancies, passing through credential verification to the other Tenancy
from Microsoft Account users, passing through credential checking to live.com
But I'm noticing today although it still accepts to invite MA users, when they sign in, they are asked to create a Password.
From then on, they are shown the usual "Do you want to use your personal account or org/school account".
Is this a new change?
Should be no longer be inviting personal accounts, and stick to only inviting users within other Tenancies (so they don't get asked whether to use Pers/Work account when signing in)?
What happens when they create a company around their own email...will they be able to wrest back resolution of the credentials -- or will it always stay with the first tenant that imported a personal account!?
Thanks for help understanding how this aspect of Azure AD works.
Related
Inviting a consumer user to Azure AD B2C has been covered by other Stack Overflow questions & answers, and AFAIK requires the use of custom policies that entail a signed JWT being created and used during invite redemption.
What I'm trying to figure out: In our application, we have differently permissioned user groups and different organisations managed by internal RBAC logic. We identify & authorize users based on their oid claim in the access token that's returned to msal-react/msal-browser and used to authenticate against our backend's API.
In Microsoft Graph, a user can be invited and the API will respond with the created user's oid. However, this is the wrong type of user and not appropriate for B2C scenarios.
With the custom policy route not creating the user object in AAD B2C at the time of invite, and therefore without knowing the user's oid at the time of inviting them to the application, what might be the best way to configure their in-app profile and have them identifiable to the application itself upon first login?
My thought at the moment is to have the application store the emails of users that are invited who have not yet redeemed/signed-in. We can configure the emails claim to be returned upon login, which is checked against the invited emails store when an oid claim is returned that isn't present in the database. This can then trigger a function to update the user's internal id with the oid in their first login's claim.
If this is inadvisable or if there's a better way, I'd be very grateful to hear it.
It would work, or just pre create the user up front via MS Graph API. Then you have an email and objectId available.
You could also put an extension attribute on the account indicating whether the user has redeemed their invite. That would allow you to monitor who has redeemed, and also be a way to provide a different experience depending on if the user has redeemed or not redeemed the link.
Is it just me who's finding AD group is very complex? ;-(
I have a web service that only allows a certain number of role groups to have access. Say we allow people within role group 'rGroupA' to have access.
At some point, a user logs on to our web server, and we have the user name. However, we would not like to ask the user to type in the password.
Is it possible for us to know if this user belongs to 'rGroupA' somehow?
Currently, I could logon our LDAP server with my username and password and see the list of groups I am in. However, I could not search for the groups for my colleagues.
I have searched google for a while but haven't found the answer. It could be that I don't understand LDAP mechanism very well.
Many thanks!
[I'm fairly new to Kerberos Protocol]
We have a customer, who back in 2020 was using a domain let's call it customdom.itm, which has a user account krb-test-cd setup for Kerberos delegation and this domain is part of a domain Active Directory forest itm.
Since they're a large corporation with many users across different countries, they also have another huge domain AD forest with many child domains (and domain controllers) as part of this forest let's call it top.abc. Here the domain relevant to us is aust.top.abc, which has krb-test-aust user account setup for Kerberos.
Since the forests itm and top.abc are different, the same servicePrincipalName for both krb users is safely set to HTTP/testloadbalancer.com, while their userPrincipalName is of course different, i.e.:
krb-test-cd uPN is HTTP/testloadbalancer.com#CUSTOMDOM.ITM
krb-test-aust uPN is HTTP/testloadbalancer.com#AUST.TOP.ABC
And since https://testloadbalancer.com is part of the intranet sites at the customer, their browsers do not challenge the users to enter their AD credentials.
Now here's the problem:
Last month the customer decided to migrate the users in customdom.itm to a new domain can.top.abc which is part of forest top.abc. The user krb-test-cd and some other accounts were not migrated, however, and customdom.itm still exists in its own forest.
Due to the migration, these users are now challenged everytime to enter their AD credentials and are granted access only with the old domain name, i.e.
customdom\michael and password
I have setup a new user account krb-test-can in the domain can.top.abc for Kerberos delegation with setspn and the SPN HTTP/testloadbalancer.com, and the first time, I got this error:
The operation failed because SPN value provided for addition/modification is not unique forest-wide.
Next, I tried ktpass with SPN HTTP/testloadbalancer.com#CAN.TOP.ABC, and I get another error:
Failed to set property 'servicePrincipalName' to 'host/<host name>' on
Dn 'CN=<CN Name>,CN=Users,DC=<DC Name>,DC=<DC Name>,DC=abc': 0x13.
WARNING: Unable to set SPN mapping data.
Later, I finally understood that the SPN is already set to user krb-test-aust.
My question is:
How can I still successfully assign the SPN HTTP/testloadbalancer.com and eventually UPN HTTP/testloadbalancer.com#CAN.TOP.ABC to the user krb-test-can without affecting Kerberos delegation to user krb-test-aust?
Or is there a workaround on how I can use only the user krb-test-aust to delegate Kerberos authentications to the users now residing in domain can.top.abc without the need for user krb-test-can at all?
Any help is highly appreciated.
Thanks in advance!
[Some background]
We have an Access Management software on our side where we have configured many Identity Providers, 2 Policy Enforcement Points and Kerberos authentication for SingleSignOn for each of the above 2 domains.
We only need to inject the uPN and the password of the krb users into the respective PEPs and the software doesn't require a keytab file.
We are identity providers and the customer uses some links like https://testloadbalancer.com/xyz/efg_idp/entityid to make an IdP initiated login and is redirected to the target application.
Taking a hint from Steve, I finally found the solution to my own problem:
Since the domains can.top.abc and aust.top.abc and other domains are part of the same forest top.abc, they SHOULD have a cross-domain trust (I'm not sure if the trust is default or needs to be setup separately).
Hence, I only need the user account krb-test-aust to delegate Kerberos authentications to the users residing in all domains under top.abc.
The uPN of krb-test-aust remains HTTP/testloadbalancer.com#AUST.TOP.ABC.
I am added to project collection administrator group in VSTS. Still not able to add a new user. I am added using my official email ID i.e. Microsoft work account.
Its says
Guest users are not allowed to perform this action.
I saw the reason on this link
I believe the primary reason for this error is because when a co-admin
with Microsoft account is added to a subscription, it gets added into
the subscription AD as Guest user type.
but since it is very old thread i like to know if there is an easy way to get myself ability to add new user or basically manage VSTS on behalf of client. I hate requesting client to add a new user in team. Also he is not tech savvy so I would like suggest him a simple solution (running Powershell might be annoying for him).
You are inviting users from outside directory. The user will be able to access the account and its resources, so you need the enough permission to add new user to the AD, but you are the Guest user, so it throws Guest Users are not allowed to perform this action.
You need to contact to the corresponding user (e.g. AD admin) to add users to AD or grant the enough role and permission to you to add user to AD.
No easy way to do this, because it is related to security.
Our application (referred to as "XYZ_App" below) is a multi-tenant SaaS application. We are in the process of making it available for Microsoft AppSource as a multi-tenanted "Web app / API" (referred to as "AppSourceXYZ_App" below).
We started our OpenID Connect implementation with endpoints pointing to “common” as per stated in the documentation when multi-tenancy is desired/required.
In XYZ_App, we added information in the system to know what AAD instance each XYZ_App tenant is associated with (using the GUID Microsoft assigned to this AAD instance, we are NOT using the "rename-safe.onmicrosoft.com" representation).
When using the “common” endpoints, we had to manually validate the issuer from the JWT to make sure it was the expected one: a user could access XYZ_App requesting access to XYZ_App’s tenant associated with contoso.onmicrosoft.com, get directed to “login.microsoftonline.com/common” to authenticate and then decide to authenticate with a user from another AAD instance (referred to as "anotherAADInstance.onmicrosoft.com" below). In this scenario, even though a user could successfully authenticate on anotherAADInstance.onmicrosoft.com, XYZ_App’s redirect URI must make sure the JWT issuer is the one from contoso.onmicrosoft.com. I’ll refer to this setup as Scenario_1.
With that scenario in mind, we thought about NOT using “common” and customize the requests going to login.microsoftonline.com on the fly; attempting to “jail” requests to be forced to authenticate against a specific AAD instance. We would still need to perform our validation in the redirect URI to make sure the issuer is the appropriate one, but we thought this approach might make our lives easier. I’ll refer to this setup as Scenario_2.
Do you envision Scenario_2 is viable in the long run or is it too short-sighted ? Based on my current knowledge of OpenID Connect, one limitation I can see with Scenario_2 is that it would become problematic to support “broker accounts” into our app.
Explanation of “broker accounts”: in our industry, some external users are allowed access to the system. Let’s say I have a company called “BrokerCo” (with their own brokerco.onmicrosoft.com AAD instance) who has 2 employees: Broker1 and Broker2. BOTH anotherAADInstance and contoso hired Broker1 and Broker2 to get broker services to perform tasks in XYZ_App; requiring XYZApp to grant them access. What is the ideal way for authentication from an OpenID Connect standpoint ? If XYZ_App were to use “login.microsoftonline.com/common” for authentication (like in Scenario_1; as opposed to “jailed” access like in Scenario_2), Broker1 and Broker2 could authenticate with brokerco.onmicrosoft.com (no AAD "External users" for anotherAADInstance nor contoso), but they would then get to redirect URI with an issuer that is different than what XYZ_App’s anotherAADInstance and contoso tenants are configured for... I feel like I’m back to square 1...
Do you have suggestions or pointers to solve this issue ?
Background context:
While playing with OpenID Connect issuers, I got the following error message:
AADSTS50020: User account 'testuser#anotherAADInstance.onmicrosoft.com' from identity provider 'https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/' does not exist in tenant 'XYZ Publisher' and cannot access the application 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Thanks in advance !
Your question has multiple layers, trying to address most of them:
AppSource is about trial experiences for new users: this mean that any corporate account around the globe can potentially be an user of your SaaS application - or at least to the trial experience of your application, therefore the first thing you need to think when integrating with AppSource is how easy it has to be for a potential user to experience your app for the first time.
With that in mind, AppSource recommends that the trial of application is build on such a way that allows any user from any organization to sign-in, and therefore a multi-tenant approach for your application is the recommended setup for any application.
The single-tenant approach requires more control on your side, and for a trial experience - it means that the user cannot try your application right away because the operation you have to do on your single-tenant application is to add the user to an Azure Active Directory tenant as a guest user. This guest account will need then to wait receiving an email to accept the invitation to join to this tenant you are adding the user to then sign-in to your application.
Therefore your scenario 1 is the best scenario thinking on a trial experience in general, and also in general require less management (as you'd not need to create/ manage each individual account that needs to access your application as guest users of your Azure AD instance).
However some concerns you listed - that this scenario bringing are valid: Because you are accepting the common endpoint, you are saying basically that any user can sign-in to any tenant to your application, and this may not be desirable. In addition, the scenario you listed that a user can generate a token for any application is also valid, however, you can add additional checks to make this more secure and that any token generated by another authentication is blocked:
You can validate the 'audience' claim to guarantee that the token was issued to your application
You can eventually check the 'tid'/'iss' claims against of a list of tenant Ids in your database to see if that the user's organization is a valid organization in your application -- this would be valid for non-trial users/ organizations.
More information in this article.
About scenario '2' and broker accounts:
This scenario could be interpreted in two different ways:
Broker accounts are guest accounts of a customers' Azure AD tenant
Broker accounts are third party accounts but are not actually added as a user of anotherAADInstance or contoso AD
If your case is '1' then you're right: if your application needs to authenticate guest users that belong to another Azure AD tenant, then common endpoint could not be used directly.
If your case is '2' then what you'd need to do is to continue using the common endpoint and somewhat after the user is authenticated ask them to choose the company. I am describing this on generic terms without fully understanding this scenario. Perhaps this is not simple as you want the remote company to control this and not the user - so some additional complexities may need to be handled here.
A note is that if your scenario is scenario 1. - in theory - you can still use an hybrid approach, where you'd ask user to type the username inside the application and the company that they want to sign-in, then check if you need to validate the user against common or tenant-id endpoint, preparing the request and then sending a login_hint argument when authenticating. More information here