locked
Cross-domain claims authentication to SharePoint w/ADFS 2.0 and Active Directory RRS feed

  • Question

  • In a nutshell, I'm trying to authenticate to SharePoint 2010 using Claims-Based Auth and ADFS 2.0 with a user in a different domain than SharePoint.  I already have it working fully within the SharePoint domain from every machine in the farm (6 seperate servers), and I'm very close to getting it working across domains, but this error is where I'm stuck:

    "An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm.."

    Here is my setup (all servers in the farm are Windows Server 2008 R2):

    Host: Windows Server 2008 R2 w/Hyper-V. Acts as a client and is joined to Domain A

    Domain A: SharePoint (all VHDs)

    1) DC/DNS

    2) SQL

    3) SP2010-App

    4) SP2010-WFE

    5) STS-A

    This entire farm is working with Kerberos, SSL, Windows Auth, and Claims on my Claims web application in SharePoint 2010.  AD is my provider for claims.

    Domain B: All VHDs

    1) DC/DNS

    2) STS-B

    3) Win7 64-bit client machine

    I have set up the claims architecture like this:

    1) STS-B has AD-B as a provider and STS-A as an RP

    2) STS-A has AD-A and STS-A as providers. STS-A

    3) My Claims-aware SharePoint web app is an RP and has STS-A as a provider

    Now, after much configuration and fixing, I got it to where my STSs are talking nicely, and my clients in Domain B can get straight to the STS login page where they get to choose between STS-A or STS-B.  If they choose STS-B, then they are prompted for Windows Auth, which works if I put in valid credentials of a user in AD-A.  However, if I chose STS-B in the dropdown, then it does some work and appears to start authenticating but then ends up at a SharePoint 2010 error dialog screen saying, "Error - An unexpected error has occurred."

    I see good Kerberos tickets in STS-B for my client passing through to the other domain.  STS-A doesn't show any activity.  SP2010-WFE shows one error stating the error I gave at the beginning.  It's pretty clear that I'm getting all the way to SharePoint, but then SharePoint does not accept the token given by my login provider.  I assume that STS-A is my "login provider," but I don't have any other clues to go on from event logs and such.

    Ideas?


    SharePoint Architect || My Blog
    Tuesday, March 23, 2010 5:36 AM

Answers

  • Hi Clayton, glad the information was useful!

    This is the way I have configured our solution and it appears to be working quite well.

    On the IDP side
    • Make sure the user has a value in the mail property in Active Directory (the existance of an actual mailbox is irrelevant in this case)
    • Define a "LDAP properties as claims" rule on your RP federation partner under Trust Relationships/Relying Party trusts on the ADFS Server. Select Active Directory as the attribute store, mail as the LDAP attribute and E-Mail Address as the outgoing claim type.

    on the RP side (Sharepoint side)
    • Define a "Pass through or filter incoming claim rule" on your IDP federation partner under Trust Relationships/Claims Provider trusts on the ADFS Server. Select E-Mail Address as the Incoming claim type and ideally you select the option to only allow certain email suffixes to pass through this filter. For debugging purposes you might as well pass through any claim value.
    • Define a "Pass through or filter incoming claim rule" on your Sharepoint web under Trust Relationships/Relying trusts on the ADFS Server. Select E-Mail Address as the Incoming and Outoing claim type, select pass through all claim values.

    On the Sharepoint server
    • Make sure that E-Mail Address is configured as an accepted claim as discussed earlier in this thread
    To enable trace logs on an ADFS2 Server see this blog post: http://blogs.msdn.com/card/archive/2010/01/21/diagnostics-in-ad-fs-2-0.aspx


    • Marked as answer by Clayton Cobb Wednesday, March 24, 2010 4:00 PM
    Wednesday, March 24, 2010 3:57 PM

All replies

  • Anyone have a clue?


    SharePoint Architect || My Blog
    Wednesday, March 24, 2010 3:28 AM
  • Hi Clayton,

    We have pretty much an identical setup (Sharepoint 2010 in one domain and multiple IDPs spread over different domains and organizations). The identity claim in our case is emailAddress. Whenever a user tries to access Sharepoint 2010 without an email claim being present the http://sharepointserver/_trust application will throw the error you mentioned.

    Check which claim is the configured identity claim for your authentication provider in Sharepoint with the Get-SPTrustedIdentityTokenIssuer command. Then make sure that the authenticating user actually has such a claim. In our scenario that would mean adding an email address to the users account in a customer domain.

     

    Hope that helps!

    Wednesday, March 24, 2010 11:45 AM
  • Fredrik, thanks for that info.  That definitely DOES give me a clue.  I already have the claims piece working with Email Address and Windows Account Name for my internal domain users when going to SharePoint, so I think it's setup right on the SharePoint side.  However, perhaps my configuration of claims rules going from one STS to the other isn't properly passing the email address?  I can tell you that on the IP-STS in Domain B, I am using "Send LDAP Attributes" from Active Directory an am using the same claim types that I mapped in my internal domain.  On the RP-STS in Domain A, I am using Passthrough to simply pass through the claims.  Should I transform instead?  I've tried so many combos that I don't know exactly the ones I've tried, but I thought passing the email through would work as the claim.

    My user in Domain B has an email address defined in Active Directory but no actual email box...I thought that was sufficient.

    Is there a way to see the claims that are being passed...maybe seeing the contents of the token?


    SharePoint Architect || My Blog

    Wednesday, March 24, 2010 2:39 PM
  • Hi Clayton, glad the information was useful!

    This is the way I have configured our solution and it appears to be working quite well.

    On the IDP side
    • Make sure the user has a value in the mail property in Active Directory (the existance of an actual mailbox is irrelevant in this case)
    • Define a "LDAP properties as claims" rule on your RP federation partner under Trust Relationships/Relying Party trusts on the ADFS Server. Select Active Directory as the attribute store, mail as the LDAP attribute and E-Mail Address as the outgoing claim type.

    on the RP side (Sharepoint side)
    • Define a "Pass through or filter incoming claim rule" on your IDP federation partner under Trust Relationships/Claims Provider trusts on the ADFS Server. Select E-Mail Address as the Incoming claim type and ideally you select the option to only allow certain email suffixes to pass through this filter. For debugging purposes you might as well pass through any claim value.
    • Define a "Pass through or filter incoming claim rule" on your Sharepoint web under Trust Relationships/Relying trusts on the ADFS Server. Select E-Mail Address as the Incoming and Outoing claim type, select pass through all claim values.

    On the Sharepoint server
    • Make sure that E-Mail Address is configured as an accepted claim as discussed earlier in this thread
    To enable trace logs on an ADFS2 Server see this blog post: http://blogs.msdn.com/card/archive/2010/01/21/diagnostics-in-ad-fs-2-0.aspx


    • Marked as answer by Clayton Cobb Wednesday, March 24, 2010 4:00 PM
    Wednesday, March 24, 2010 3:57 PM
  • And there we have it!!  I had everything set up that way except for my relying partner claims on the STS in Domain A.  I was not passing through to my SP2010 trust, but rather was doing the regular "Send LDAP Attribute as Claims," because that's how I originally set it up to work within the domain.  As soon as I created a Passthrough claim rule going from the RP-STS to SharePoint, it worked instantly.  Also, my internal clients can still connect despite this change, so I'm now all set.  What i can do is tweak the settings to not be so wide open like you mentioned, which will be no problem, because now I _know_ it works.

    Thanks a million for being detailed in your response, because that was the key part I needed.  I had actually forgotten that I had that other RP trust set for SharePoint and had never gone back to set a passthrough rule.


    SharePoint Architect || My Blog
    Wednesday, March 24, 2010 4:04 PM
  • I had exactly the same problem a few weeks ago, glad I could help :)

    One further thing I did was removing any "LDAP Attribute as Claim" rules from the SP2010 trust and moving them to the Active Directory Trusted Claims Provider instead. That way those rules aren't triggered when users login from external IDPs and from a configuration standpoint the internal Active Directory identity store is configured as just another IDP. Furthermore the SP2010 trust contains no IDP specific rule and will work with pretty much anything.

     

    Wednesday, March 24, 2010 5:20 PM
  • I've done that change and am backing out or removing things one at a time to clean up all my troubleshooting attempts.  I want to find the minimum configuration to keep it working, and then I want to squeeze it down to be more secure than "pass through all claims."  Hopefully, in doing this exercise, I'll have a better understanding of exactly how the claims process works.  For now, my attempt at getting Windows Account Name to work as a claim is not being successful, so I know I'm not fully-understanding the process yet.
    SharePoint Architect || My Blog
    Wednesday, March 24, 2010 5:26 PM
  • Hi,

    Your post seems to be the closest I can find to the issue we are facing.  We have an situation that users are able through ADFS to be added to the site, authenticate and log on.  Unfortunately, we are having an issue where with the email address of the user does not get populated in Sharepoint.  

    So when start a built-in workflow, it fails because it can not find an associated email address for the user.  We used powershell to add an email address to the account, but the email address does not show up in the user's properties box in the GUI.  We are also unable to edit the user's properties in the GUI. 

    After looking at your post, I am thinking that perhaps we need to look again at the ADFS setup to allow these properties to come through when the user is first added.

    No beta involved in this sharepoint setup.  ADFS 2.0

    Any help is much appreciated, thanks!

    Tim

    Friday, June 11, 2010 11:33 PM
  • Tim, did you do a profile sync?  That's what would populate the user's profile information into the user profile database, not just logging in through claims.  When I got CBA working, I also got the user profile sync working with the external forest so that I was able to retrieve the external users' profile info.  I don't have that farm fired up right now, since my RTM farm is running, so I can't check the details at the moment.  I figured I'd ask if you had done the user profile sync yet, though.
    SharePoint Architect || Microsoft MVP || My Blog
    Friday, June 11, 2010 11:43 PM
  • Hi Clayton,

    Thanks for the quick post.  This is an inherited project and I am trying to come up to speed as quickly as possible.  After a quick look into your suggestion, I believe you have pointed me in the right direction.  I have found some of your other posts on profile sync and will investigate further.

    Cheers,

    Tim

    Saturday, June 12, 2010 4:26 PM
  • Good stuff - let us know.
    SharePoint Architect || Microsoft MVP || My Blog
    Saturday, June 12, 2010 4:45 PM
  • Fredrick, how did you get the 'mail' attribute in the LDAP side of IDP?  I go in there to set it to mail but I only see E-Mail Address.  I want mail because its the attribute that will allow users to have other domains specified.  I have Active Directory selected as the attribute store and this is all in the LDAP pass through claims rule editor.

    Thanks!

    Tuesday, June 22, 2010 5:59 AM
  • Hello Clayton

     

    i am having an issue when i am trying to connect my domain B(IDP) to domain A (RP) sharepoint server. i have all the claims setup

    as this post has mentioned.the error i am seeing is Event ID 40961.

    Event ID 40961 - The Security System could not establish a secured connection with the server ldap/ Computername.domain.com . No authentication protocol was available.

    i will appreciate any insight.

    PS: the share point access within domain A is working fine.

    Tuesday, October 12, 2010 6:13 PM
  • Hi Clayton,

    I succeeded in setting up claim-based authentication. Now I want to run an user profile sync to fetch user profiles via my ADFSv2 authentication provider - just as you suggested to Tim.

    It's possible to run a sync via ADFSv2 instead of AD DS, I assume. Or did you mean you synchronized with the external forest directly?

    I haven't found any docu/guide to lead me through the configuration for this scenario (filling the user profile properties of the profile database by using the claims provided by my ADFS server). May you post a link or post a brief checklist how to achieve this, please?

    I'd be very glad if you pointed me in the right direction.

    Regards,

    Simon

    Wednesday, October 20, 2010 3:39 PM
  • I don't remember all the steps, and there was no documentation to follow.  I just created a profile sync to the external forest and performed the import.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, October 20, 2010 3:45 PM
  • Hi Clayton, glad the information was useful!

    This is the way I have configured our solution and it appears to be working quite well.

    On the IDP side
    • Make sure the user has a value in the mail property in Active Directory (the existance of an actual mailbox is irrelevant in this case)
    • Define a "LDAP properties as claims" rule on your RP federation partner under Trust Relationships/Relying Party trusts on the ADFS Server. Select Active Directory as the attribute store, mail as the LDAP attribute and E-Mail Address as the outgoing claim type.

    on the RP side (Sharepoint side)
    • Define a "Pass through or filter incoming claim rule" on your IDP federation partner under Trust Relationships/Claims Provider trusts on the ADFS Server. Select E-Mail Address as the Incoming claim type and ideally you select the option to only allow certain email suffixes to pass through this filter. For debugging purposes you might as well pass through any claim value.
    • Define a "Pass through or filter incoming claim rule" on your Sharepoint web under Trust Relationships/Relying trusts on the ADFS Server. Select E-Mail Address as the Incoming and Outoing claim type, select pass through all claim values.

    On the Sharepoint serve r
    • Make sure that E-Mail Address is configured as an accepted claim as discussed earlier in this thread
    To enable trace logs on an ADFS2 Server see this blog post: http://blogs.msdn.com/card/archive/2010/01/21/diagnostics-in-ad-fs-2-0.aspx



    You cannot vote on your own post

    Hi,

    I am getting error when I am trying to login as Trusted different domain User, which I had added in user policy with full Access as below :Token validation failed. See inner exception for more details.

    Additional Data

    Exception details:
    MSIS3111: Non domain user is not supported by AD FS 2.0.

    This request failed.

    And also..

    Encountered error during federation passive request.

    Additional Data

    Exception details:
    Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: ID3242: The security token could not be authenticated or authorized.
       at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
       at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
       --- End of inner exception stack trace ---
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSecurityToken(SecurityToken securityToken, WSFederationMessage incomingMessage)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolRequest(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)

    System.ServiceModel.FaultException: ID3242: The security token could not be authenticated or authorized.
       at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
       at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
       at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)

    Please let me know what things I am Missing ?

    I had followed from links :

    http://shannonbray.wordpress.com/2010/10/02/claims-based-authentication-made-simple/


    Thanks n Regards, RB. Twit me @ranjeetbhargava Follow me @Bhargavablog.wordpress.com, www.assigncorp.com, www.assigninfo.com, Assign Lab India
    Friday, February 4, 2011 9:51 AM
  • Has anyone been able to get the profile Sync to caccounts to the ADFS if the ADFS in in a defferant domain from the Sharepoint server.

    I can get it to connect and I can read the OU structure of ADFS but cannot get the imoprt to work

     

    Wednesday, August 24, 2011 3:59 PM
  • Sending LDAP claims as attributes only works if there is a user for the identity property located in the attribute store that the query runs against.. This is most often used on the IDP to pull items from the Directory to send along with the claim -- or on the RP to lookup a "shadow" that exists in the attribute store to augment the inbound claim.. The only things that travel over the wire are CLAIMS..  LDAP values have to come from an LDAP query against your attribute store. If there are no entities in the attribute store that match the "identity claim" then there will be no claims issued for that particular invocation of the rule.


    All science is either physics or stamp collecting

    Friday, March 21, 2014 5:43 PM