SOLVED

SP 2016 ADFS 4.0 Federated Partner Authenticates, but doesn't Authorize

%3CLINGO-SUB%20id%3D%22lingo-sub-1351313%22%20slang%3D%22en-US%22%3ESP%202016%20ADFS%204.0%20Federated%20Partner%20Authenticates%2C%20but%20doesn't%20Authorize%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1351313%22%20slang%3D%22en-US%22%3E%3CP%3EResource%20Domain%2FForest%20(resource.local)%3C%2FP%3E%3CP%3ESP%202016%20Farm%20in%20Resource%20Domain%20webapp.resource.local%3CBR%20%2F%3EADFS%204.0%20configured%20on%20internal%20network%20of%20resource.local%3CBR%20%2F%3EWAP%20configured%20in%20DMZ%20publishing%20adfs.resource.local%20and%20webapp.resource.local%3CBR%20%2F%3E%3CBR%20%2F%3EUser%20Domain%2FForest%20(users.local)%3CBR%20%2F%3EADFS%204.0%20configure%20on%20internal%20network%20of%20users.local%3CBR%20%2F%3EWAP%20configured%20in%20DMZ%20publishing%20adfs.users.local%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EFederated%20trust%20has%20been%20created%20between%20the%20two%20ADFS%20instances.%3CBR%20%2F%3EWe%20can%20successfully%20authenticate%20against%20either%20ADFS%20individually%2C%20and%20we%20can%20also%20authenticate%20across%20the%20federated%20trust%20using%20the%20idpinitatedsignon.aspx%20to%20test.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20Issue%3A%20When%20we%20attempt%20to%20login%20to%20webapp.resource.local%20(tested%20externally%20because%20we%20have%20no%20need%20to%20test%20this%20internally)%20we%20can%20see%20the%20trust%20being%20traversed%20and%20we%20authenticate%2C%20however%2C%20we%20get%20the%20%22Sorry%2C%20the%20site%20hasn't%20been%20shared%20with%20you.%22%20page.%26nbsp%3B%20The%20users%20in%20the%20resource%20domain%20don't%20have%20issues%20authenticating%2Fauthorizing%20to%20the%20sites%20externally%20through%20the%20resource%20ADFS.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20not%20sure%20what%20we're%20missing%20here.%26nbsp%3B%20Any%20help%20would%20be%20greatly%20appreciated.%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F130%22%20target%3D%22_blank%22%3E%40Trevor%20Seward%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1351313%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3E2016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Eadfs%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1351367%22%20slang%3D%22en-US%22%3ERe%3A%20SP%202016%20ADFS%204.0%20Federated%20Partner%20Authenticates%2C%20but%20doesn't%20Authorize%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1351367%22%20slang%3D%22en-US%22%3EWhat%20claims%20are%20you%20passing%20over%20the%20fed%20trust%20and%20what%20is%20the%20identity%20claim%20configured%20in%20SharePoint%2Fsent%20by%20the%20RP%20from%20the%20resource%20domain%20ADFS%3F%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1351407%22%20slang%3D%22en-US%22%3ERe%3A%20SP%202016%20ADFS%204.0%20Federated%20Partner%20Authenticates%2C%20but%20doesn't%20Authorize%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1351407%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F130%22%20target%3D%22_blank%22%3E%40Trevor%20Seward%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUser%20ADFS%20Issuance%3C%2FP%3E%3CP%3EUPN%20-%20passthrough%3C%2FP%3E%3CP%3EPrimary%20Sid%20-%20passthrough%3C%2FP%3E%3CP%3EPrimary%20group%20SID%20-%20passthrough%3C%2FP%3E%3CP%3EName%20-%20passthrough%3C%2FP%3E%3CP%3EUPN%20--%26gt%3B%20emailAddress%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EResource%20ADFS%3C%2FP%3E%3CP%3EUPN%20-%20passthrough%3C%2FP%3E%3CP%3EPrimary%20Sid%20-%20passthrough%3C%2FP%3E%3CP%3EPrimary%20group%20SID%20-%20passthrough%3C%2FP%3E%3CP%3EName%20-%20passthrough%3C%2FP%3E%3CP%3EEmail%20-%20passthrough%3C%2FP%3E%3CP%3EUPN%20--%26gt%3B%20emailAddress%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESharePoint%20Identifier%20Claim%20%3D%20email%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1363960%22%20slang%3D%22en-US%22%3ERe%3A%20SP%202016%20ADFS%204.0%20Federated%20Partner%20Authenticates%2C%20but%20doesn't%20Authorize%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1363960%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F130%22%20target%3D%22_blank%22%3E%40Trevor%20Seward%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20Trevor%20...%20although%20the%20claim%20itself%20wasn't%20necessarily%20the%20resolution%2C%20it%20DID%20point%20me%20in%20the%20direction%20that%20seems%20to%20have%20resolved%20the%20issue.%3C%2FP%3E%3CP%3EI%20went%20to%20the%20claims%20provider%20in%20sharepoint%20(LDAPCP)%20and%20added%20another%20connection%20for%20the%20federated%20domain.%26nbsp%3B%20Although%20in%20a%20typical%20federated%20scenario%2C%20I%20question%20the%20feasibility%20of%20this%20as%20a%20solution%2C%20for%20OUR%20environment%20this%20works%20and%20users%20from%20the%20federated%20ADFS%20forest%20are%20now%20able%20to%20be%20added%20into%20a%20site%20with%20permissions%2C%20and%20thus%20are%20authorized%20after%20authenticating.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Occasional Contributor

Resource Domain/Forest (resource.local)

SP 2016 Farm in Resource Domain webapp.resource.local
ADFS 4.0 configured on internal network of resource.local
WAP configured in DMZ publishing adfs.resource.local and webapp.resource.local

User Domain/Forest (users.local)
ADFS 4.0 configure on internal network of users.local
WAP configured in DMZ publishing adfs.users.local

Federated trust has been created between the two ADFS instances.
We can successfully authenticate against either ADFS individually, and we can also authenticate across the federated trust using the idpinitatedsignon.aspx to test.

 

The Issue: When we attempt to login to webapp.resource.local (tested externally because we have no need to test this internally) we can see the trust being traversed and we authenticate, however, we get the "Sorry, the site hasn't been shared with you." page.  The users in the resource domain don't have issues authenticating/authorizing to the sites externally through the resource ADFS.

 

I'm not sure what we're missing here.  Any help would be greatly appreciated.

@Trevor Seward 

3 Replies
Highlighted
Best Response confirmed by Matt_Paleafei (Occasional Contributor)
Solution
What claims are you passing over the fed trust and what is the identity claim configured in SharePoint/sent by the RP from the resource domain ADFS?
Highlighted

@Trevor Seward 

User ADFS Issuance

UPN - passthrough

Primary Sid - passthrough

Primary group SID - passthrough

Name - passthrough

UPN --> emailAddress

 

Resource ADFS

UPN - passthrough

Primary Sid - passthrough

Primary group SID - passthrough

Name - passthrough

Email - passthrough

UPN --> emailAddress

 

SharePoint Identifier Claim = email

 

Highlighted

@Trevor Seward 

Thanks Trevor ... although the claim itself wasn't necessarily the resolution, it DID point me in the direction that seems to have resolved the issue.

I went to the claims provider in sharepoint (LDAPCP) and added another connection for the federated domain.  Although in a typical federated scenario, I question the feasibility of this as a solution, for OUR environment this works and users from the federated ADFS forest are now able to be added into a site with permissions, and thus are authorized after authenticating.