I have been trying to add a "virtual" claim provider (SAML 2.0 Identity Provider) in ADFS, I have another claim provider with same certicate. I get this error on ADFS2.0 in windows Server 2012
MSIS7600 Each Signing Certificate value for a claims provider Trust must be unique across all claims provider trusts in ADFS 2.0 configuration
Is there any workaround to avoid this issue?
No, I got the same thing here. Appearantly it must be unique. I tried to add 2 tenants (2 customers) coming from Windows Azure Active Directory where all claims of all tenants are signed with the same certificate.
The first one works perfectly but on the second one the MSIS7600 refuses to let me add the second Claims Party.
We had the same thing here and solved it by using this trick
We created a new Azure AD with the purpose that this is the one we are going to add in ADFS.
For each customer tenant we want users to be able to login, we asked asked for read permissions to this tenant; this way it it added in your own subscription. We then selected the users from the customer tenant and added it to the Azure AD we are going to use in ADFS.
We connected ADFS to this Azure AD
All our customers can now login to the ADFS using their own credentials. The only thing we have to do is adding the existing Azure AD users from their own tenant to our Azure AD.
This way it let's you to add as many customers or external Ad's if you want and also not "showing" all tenants in the list of the ADFS page. Because there is only one tenant in ADFS there is no complain of the error MSIS 7600 and you don't have to update all tenants seperately.
Philippe is right. You can use AzureAD B2B feature that allows you to login in any Azure AD user in any tenant to be able to login. This is done by invite. This feature is in preview. This is the simplest choice. However, from an ADFS perspective, policy is on only a single entity. Home realm discovery can be a little more tedious.
We've also fixed ADFS 2016 to relax this constraint for a few reasons. We now constraint it on "Cert + claims-provider-identifier". In this world you will be able to add any # of Azure AD tenants distinctly. This fix will be out in the next preview (should be out soon).
Related
I'm not able to access any tabs in AAD. What could be the issue?
Please check if below points can be worked around in your case.
Buttions or options being greyed out maybe because , you may not have had global admin rights/user administrator rights on the azure AD tenant. There are a few roles which can create users within the directory. You may not have any roles within the directory which permit the operations.
Reference: github issue.
Even in Azure AD free edition ,one should be able to create the users if you have proper roles .
On completion of the first 30 days of Microsoft Azure’s free trial,
your ‘Free Trial’ Azure Subscription will be disabled. To fix this,
the subscription needs to be changed to the ‘Pay-As-You-Go’ plan
instead of the ‘Free Trial’ plan which it is currently on.
For example :For applications under Enterprise application, one of the following roles: Global Administrator, Cloud Application
Administrator, Application Administrator, or owner of the service
principal.
You can check Azure AD built-in roles, and by checking the
description of role , assign the required one to manage identity .
You can Assign Azure AD roles to users to manage the identities
if you have global or role administrator rights. Approach the
admin to assign the roles .Also see custom roles in Azure AD
if needed.
Please check if this issue in - Microsoft Q&A can relate .
If issue still remains you can raise a support request in troubleshoot+support blade.
My problem is that we have 2 On-Premises Active Directory domains:
mycompany.com
mycompany-dev.com
Some people are present in both of these AD-s. I want to sync them with Azure Active Directory so that they are all represented once, and all have the #mycompany.com suffix (instead of #mycompany.onmicrosoft.com). I also don't want some users to have #mycompany-dev.com in their azure AD account login name, so I want to do some sort of mapping I guess.
Is this possible with Azure AD Connect, or do I have to implement a synchronization method manually?
You can sync multiple on-premises domain to Azure AD. Kindly check the link and you will get a detailed information about different topologies supported
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,
When RBAC was introduced in Azure Active directory, roles can be granted to users or collection of users (groups).We followed this blog post and added that functionality for our apps when it first got introduced. But now, we have to go for active directory premium to assign roles to groups and get roles in bearer token.Going with Azure Active directory is not a feasible solution for us as premium is gonna cost us $6 user/ month and we have lot of groups and each group has lot of users. Looking at the costs our IT team is not willing to go for this package. I was just wondering if there an alternative approach for mapping roles to groups. Or this is only doable using premium.
Using Azure Active Directory (Azure AD) with an Azure AD Premium or Azure AD Basic license, you can use groups to assign access to a SaaS application that's integrated with Azure AD( refer here about detail).
So if you want to manage the roles using the group, we need at least the Azure AD Basic license. If you were using the free edition, we can only assign the roles to the users one by one.
Instead using the role manage the access for the application, we can also use the group which also supports for the Azure AD free edition. You can check the code sample about authorization in a web app using Azure AD groups & group claims from here.
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.