Tuesday, January 22, 2013 4:19 PM
So, I've configured SharePoint 2013 to consume claims coming from ADFS in my domain. I can log in via claims to my SharePoint application and everything is working fine for domain local users.
I have an external domain I'd like to use, which is throwing a "The user name or password is incorrect" every time one of the users tries to log in and I'm not sure what the problem is.
Let's call my internal farm, Farm A and my external farm Farm F.
Farm A has a relying party trust setup to send claims to SharePoint (this is all configured in SharePoint and, as far as I can tell, working like it's supposed to. Local logins can access the farm) with the expected claims rules (SAM-Account-Name/E-Mail Address, Token-Groups - Unqualified Names/Role, User-Principal-Name/UPN) and then a second pass through or filter rule to send over the Primary SID.
Farm A has a Claims Provider Trust to the external endpoint of Farm B's public ADFS URL. Everything looks normal. It updates, doesn't throw any errors, and the certificates look right. My claims rules here are the same as I have on my relying party trust (SAM-Account-Name/E-Mail Address, Token-Groups - Unqualified Names/Role, User-Principal-Name/UPN) and then a second pass through or filter rule to send over the Primary SID. The Attribute Store on this CPT is Active Directory - if that matters.
Farm B, the external domain, has a relying party trust to the ADFS endpoint of Farm A (with the normal settings, certificate, etc). It's got a rule to Send LDAP Attributes as Claims and sends over the same set (SAM-Account-Name/E-Mail Address, Token-Groups - Unqualified Names/Role, User-Principal-Name/UPN) and a second rule to pass through or filter the Primary SID.
Farm B has a second Relying Party Trust to the SharePoint web address (whatever.com/_trust) with the same rules applied (SAM-Account-Name/E-Mail Address, Token-Groups - Unqualified Names/Role, User-Principal-Name/UPN) and Pass Through or Filter Primary SID.
What am I missing here? After typing this out, it seems like the RPT on Farm A is only passing over AD credentials and not looking into Farm B to validate the claim. Is there somewhere I need to set that to happen? I'm at a loss...
Any help would be greatly appreciated. Thanks!
Tuesday, January 22, 2013 8:02 PM
I'm a little confused so let me see if I have this straight.
Farm A and Farm B are ADFS farms, trusted by each other through claims provider and relying party trusts.
Each farm has matching claim rules.
Each farm has a relying party trust with SharePoint.
Farm A authn works fine for SharePoint, Farm B fails authn.
Now my questions: does the authn failure occur in Farm B, or does it fail in SharePoint?
Why do both farms have trusts to SharePoint? It seems like the preferred configuration is Farm A has a trust to SharePoint, and Farm B ONLY has a trust to Farm A. All authentication requests pass through Farm A, and its up to Farm A to decide whether to authn locally or redirect to Farm B (e.g. through home realm discovery).
I'm not sure I follow the bit about Farm A looking into Farm B for validating claims. ADFS never looks into another provider, ADFS simply accepts the token from the provder assuming its signed by a trusted party, regardless of whats actually in the token (well, thats not quite right, but thats the gist).
Developer Security MVP | www.syfuhs.net
Wednesday, January 23, 2013 4:40 PM
Man, I'm sorry, I have too much SharePoint on the brain. When I said Farm above, I meant domain.
Domain A is hosting the SharePoint Farm. It can connect via AD credentials or through the claims provider (when I'm prompted to pick my authentication provider when I hit SharePoint).
Domain F is the one I want to be able to log into the farm.
Domain A has a CPT to consume from Domain B. (and the RPT to SharePoint)
Domain B has a RPT to Domain A and a RPT to SharePoint.
Is that more clear or less clear? Sorry about that initial post.
Wednesday, January 23, 2013 6:19 PM
Well, this is still a pretty confusing description. I agree with Steve S. that Sharepoint should only need to know about / trust a single STS, and likewise, only that STS needs to know anything about Sharepoint as a relying party.
Sharepoint should send all unauthenticated users to STS1. Then STS1 has to figure out what to do with them... Windows authentication (against a domain that has a Windows trust with the domain where STS lives)? Ask them where they're from, so it can forward them to another Identity Provider, or maybe check the "whr" parameter or follow some other logic to send them to the proper claims provider straightaway?
Sharepoint <-> STS1 <--> (ForeignSTS1, ForeignSTS2)
From STS1's perspective, ForeignSTS1 and ForeignSTS2 are claims providers. From the perspective of ForeignSTS1 and ForeignSTS2, STS1 is a relying party.
Again, Sharepoint has no idea about ForeignSTS(1,2) and they don't know about Sharepoint... Sharepoint only has to trust incoming claims with STS1's signature on them.
- Marked As Answer by bafadam Monday, January 28, 2013 3:47 PM
Monday, January 28, 2013 3:48 PM
Yep. After spending some time with it this weekend, I was off in the way I was looking at this. Taking what you said and a bunch more research, this all makes sense now.
My issue wasn't this at all. I wasn't passing the claims rules on explicitly one by one - instead, I was just doing the Send LDAP Claims...
Thanks for the point in the right direction!