Does AzureCP work with On premise AD groups synced to Azure for authentication in Sharepoint 2013?
Closed this issue · 7 comments
Hi There,
Looking for some help with a Sharepoint portal and Azure SSO.
Background,
Our current Sharepoint 2013 portal uses a product called Ellucian Portal and has the permissions assigned to various sites using the AD groups that a Ellucian Identity Provider is giving us from ADFS authentication and the claims that are setup. The groups that the Ellucian Identity Provider and that ADFS is sending are coming from our On premise AD. We would like to switch the ADFS authentication to Azure SSO using the Azure CP to provide the claims info.
Azure SSO and AzureCP,
I've got the Azure CP setup and installed on our Sharepoint Portal and it goes out to authenticate to our Azure tenant and sends back the claims. I can see the claims with a SAML trace. The problem i have is that i can authenticate to Azure SSO fine,..but when i get redirected back to our Sharepoint Portal.. it seems to treat the user as a guest and it get a Access Denied page to request access. I'm not sure if i've got the claims setup correctly or what tried a lot of setups but can't get past that. The groups claim from Azure is sending back the Group ID,.. with the Role namespace. AzureCp is showing the group display name ok. The Azure tenant is setup to send back the user.localuserprincipalname
Maybe i'm missunderstanding how this is supposed to work? I was hoping that using AzureCP to match up the claims returned from Azure tenant to the same on premise AD groups so that the user would get permission to the sites that have been setup already. But i wonder if that is how this is supposed to work? Am i supposed to assign the AAD groups shown from AzureCp to my sites now for it to work? Also i'm not fully understanding if i'm supposed to use the mail claim or upn?
In AzureCP they have two identifiers, one for members and one for guests. Is the one for members just accounts in Azure or also our On premise AD? We are syncing our on Premise AD account into Azure and those are the ones i'm trying to login with. Should i be treating my on Premise AD accounts as guest in AzureCP?
Any help or guidance would be greatly appreciated. I've been struggling to get this to work for weeks now.
Regards Michael
In further testing I've confirmed that my permissions work if I assign a On premise AD synced user or group to a new AAD group and then assign that group to the Sharepoint site I want them to have access too. I see in Azure AD I can send the "On premise Security Identifier" and in the AzureCP Claims type Configuration I can select the OnPremiseSecurityIdentifier, but that doesn't seem to work and then I can't even see the results from AzureCP in the Sharepoint people picker like I can when it's set to Group ID,
Is what I'm trying to do even possible? or have I got something still misconfigured?
Any info would be greatly appreciated.
thanks Michael.
Further testing and checking off the "Return security-enabled groups only" now also return my On premise AD groups that have been synced into Azure, but in the People picker they naturally appear as a different group since I'm passing the Azure Group ID, and not the On premise sAMeAccountName or ObjectID. If I can't somehow use the On premise AD group passed with the AzureCP,.this will mean I have to go through our entire Sharepoint site and also assign the groups coming from AzureCP to every permission I have setup.?
@mdoherty29 AzureCP is not (really) involved during the authN: SPS computes the SAML token issued by AAD, and compares it with the permissions (claims) present on the target site.
AzureCP does mainly 2 things:
- It creates claims based on the user input in the people picker, that SPS uses to create permissions
- It may also get the group membership of the user who signs-in, to create claims based on those groups that SPS will include in the SAML token of the user. But if AAD is already doing it, it is a bonus for some scenarios that AzureCP does it as well, but not required.
In your scenario, what is important is that your on-premises groups are synced by AAD connect to AAD, so that AAD can include them in the SAML token it generates for the user.
You may also check the group membership of the users in the AAD console, or using the Graph Explorer and getMemberGroups.
Or even replay AzureCP queries using Postman.
Does that help?
We are syncing our on-premise groups to AAD, and I am including them in my SAML token as a "Role" type with the SamAccount Name. I'm just not sure in the Claim configuration of AzureCP am I supposed to pick that as the "Property to query, OnPremiseSamAccountName" to get it to match what I've done in SPS from the ADFS identity provider.
Hi Yvand,
Question I have from a novice Sharepoint administrator. In my scenario that I'm trying to setup. I can see I am passing the on premise SamAccountName for my groups from AAD in my claim tokens ok. but it is to a SPTrustedIdentityTokenIssuer called "AzureAD" I have another SPTrustedIdentityTokenIssuer called "Ellucian Identity Provider" that was setup with our on premise ADFS and we setup the permissions to our Sharepoint sites using the groups configured as claims/role type.
I'm starting to think that because I am using to different SPTrustedIdentityTokenIssuer that even though the SamAccountNames match,.. Sharepoint actually sees these as completely different groups and hence why my permissions to access a site are not working with I try to authenticate with AAD.
Am I correct on this? I would basically have to duplicate all my permissions I've setup in my Sharepoint sites to also have the groups provided by AAD with AzureCp.?
Any insight would be appreciated.
Michael.
@mdoherty29 there are many things here, I will try to clarify:
- If user signs-in in Azure AD, the only thing that matters is the group membership that exists in Azure AD. If the AAD user is member of an on-premises AD group synced; then this group should be added to the SAML token created by AAD
- In AAD you can configure if the value of the group is the name or the ID. I strongly recommend you choose the ID
- The choice of this value should be reflected in the AzureCP claim type mapping page, in the "property to query" for the main group claim type. So in your screenshot you should really update it to use the ID. Your current settings means that only AAD groups which have a OnPremisesSamAccountName may be added to the token, which of course excludes all "pure" AAD groups
- SharePoint will use the SPTrustedIdentityTokenIssuer that has the public key of the certificate used by AAD to sign the SAML token, and which you defined when you created the SPTrustedIdentityTokenIssuer
I hope this helps
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.