locked
Multiple domain authentication through Active Directory Trust RRS feed

  • Question

  • Hello everyone,

    My efforts to find documentation online regarding the steps I need to follow to configure Sharepoint for multiple domain access have been in vain.  The information I find is fairly outdated or not applicable.

    I have Sharepoint 2013 configured in a muli-server farm using claims authentication.  It is hosed on servers in DOMAIN1, runs using service accounts in DOMAIN1 and so far only users from DOMAIN1 log on to these web applications.  We have a new requirement to allow users from DOMAIN2, external to our systems, to log in for a while and access basic information.

    Firewall configuration has been set to allow access to DOMAIN2, and a 2 way trust has been established between DOMAIN1 and DOMAIN2.  A group has been created on DOMAIN1 for permissions management (eg DOMAIN1\externalperms), and some DOMAIN2 users have been added to that group.

    In my Sharepoint development environment, where everything runs using Network Service and Local System, the linkage to the new domain was automatic.  I could add DOMAIN2 users for permissions, and granting permissions on DOMAIN1\externalperms extended access to those DOMAIN2 users.

    In production, it has not been so automatic.  Production runs using service accounts rather than Network Service.  I can only find some DOMAIN2 users, not all of them.  I can give those users permissions and they can log in.  But, permissions applied to DOMAIN1\externalperms do not get applied to them even though they are members.  The users I can't find exist in different containers on DOMAIN2, so it seems like Sharepoint doesn't have access to some containers.

    I can't find a clear guide that lets me know what needs to be done to diagnose the problem. Why is there a difference between how it worked in Dev vs Prod?  Would it be related to the service accounts used in Prod?  Can anyone provide insight into why I would only be able to find some DOMAIN2 users, and why permissions aren't extending through the DOMAIN1\externalperms group?

    Thanks


    Monday, March 30, 2015 5:38 PM

Answers

  • Can you turn up the ULS logging (SharePoint Foundation -> Claims Authentication) to Verbose in the Trace log and search for/attempt to add a user from DOMAIN2 that isn't already in the SharePoint site and doesn't have an identical username to a user in DOMAIN1?

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Brad Timiney Thursday, April 9, 2015 2:40 PM
    Monday, March 30, 2015 11:05 PM

All replies

  • So a couple of requirements:

    1) SharePoint must have port access to the remote domain controllers (DOMAIN2).

    2) SharePoint must be able to add users/security groups directly from DOMAIN2. DOMAIN2 objects cannot be part of a DOMAIN1 security group as SharePoint is unable to use Foreign Security Principals.


    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Monday, March 30, 2015 7:00 PM
  • Hi Trevor,

    Thanks for your reply.  I've gone through the firewall port list and confirmed successful connection from the SP servers to each port.  I'm also not seeing any references in the logs or event viewer in regards to connection failure.

    I notice on both environments (dev and prod) that I can't add any security groups from DOMAIN2.  Both of them fail with this error in the logs: System.Runtime.InteropServices.COMException: The user does not exist or is not unique.  No other more specific error message has been found in the logs yet.

    Those environments are using Claims authentication.  In another SP 2010 environment using Classic authentication, I am not having any trouble adding permissions to groups from DOMAIN2.  Are there configuration steps specifically regarding Claims mode that I am missing?

    Thanks

    Monday, March 30, 2015 9:04 PM
  • Can you turn up the ULS logging (SharePoint Foundation -> Claims Authentication) to Verbose in the Trace log and search for/attempt to add a user from DOMAIN2 that isn't already in the SharePoint site and doesn't have an identical username to a user in DOMAIN1?

    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Brad Timiney Thursday, April 9, 2015 2:40 PM
    Monday, March 30, 2015 11:05 PM
  • I configured verbose logging on Claims Authentication as you suggested, but it didn't end up logging information for the DOMAIN2 username when I attempted to grant permissions for them or check their permissions.  This was the same result in my dev and prod environments.

    Interestingly, in prod, I am able to log into the site using DOMAIN2 users who have permissions granted through the DOMAIN1 security group.  AFTER logging in with that user, it will then find the user using the check permissions tool.  So, it looks like the environment is working and will let these users log in, things are just not totally checking out with the people picker tool.  I'd still like to get to the bottom of that.

    Tuesday, March 31, 2015 1:47 AM
  • Are these two forests, or parent/child domains? What type of trust is in place per Active Directory Domains and Trusts?

    Once a user logins in, their info is stored in the Site Collection's UIL and is persisted, so there is no need to go back to Active Directory to reference those users.


    Trevor Seward

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by star.wars Thursday, April 9, 2015 6:12 AM
    Tuesday, March 31, 2015 1:50 AM
  • We worked with Microsoft support to try to work through the issue.  We added DOMAIN2 to the User Profile Service and synched.  It created user profiles for all of the DOMAIN2 users, and we ran a user profile search index.  At that point I was able to assign permissions to users who had not yet logged in.  The last remaining effect was that the people picker itself didn't find the users to prompt in the UI, but still accepted them.

    Our testing was complicated by the fact that we had DOMAIN2 users in that site collection from many years back that I wasn't aware of.  When those users tried to log in after the new trust they were denied.  I removed all of the old DOMAIN2 users from the site collection and then they were able to log in and they received their permissions from the DOMAIN1\externalperms security group as they should.

    Thank you for your suggestions Trevor


    Thursday, April 9, 2015 2:40 PM