locked
Issue with ADFS Trusted Provider and AD having 2 users with same email address. RRS feed

  • Question

  • Greetings,

    Forgive me if this is posted in the wrong location I wasn't able to find one specific to ADFS.  We currently us ADFS to authenticate to our SharePoint environment.  We use the user's email address as the identifying claim.  The problem that we have is that there are some users that have 2 accounts in active directory, but have the same email address for both accounts.  When ADFS provides the authorization back to SharePoint it is sending back the wrong account which has no access to the appropriate resources.

    I'm not an expert on ADFS so I'm not sure if there are any better options using incoming and outgoing claims or if Claims Rules are an option.  I just thought I would put this out here to see if anyone had similar issues or knew of an easy solution.  Ideally we'd use UPN, but the UPN is different from the email address and the email address is more conformed across the environment.

    Thanks.

    Monday, May 5, 2014 10:33 PM

Answers

  • I've not written anything about it in my blog, and i don't know of other articles offhand...

    but generally speaking here are the pieces:

    1. ADFS sends SID as claim (I also tend to like Groups as SIDs, for similar reasons, but groups are far less likely to change names/etc). Also, configure SharePoint to receive SID, and treat as primary ID (the last step will cause disruption). Script out the conversion of users from their former identity (email or UPN or whatever you're using) to their SID (creating a map file is pretty easy with PowerShell).

    2. custom claim provider for userinfo table population and people picker resolution... most implementations use ADSI/LDAP queries for people picker search results, though some have already created ADSI connections from SQL servers (using linked servers), and prefer to query via SQL instead... userinfo table is used for any account that DOESN'T exist in the UPS, which is generally any partner orgs.

    3. for LOCAL DOMAIN user profile sync, connect to AD, configure for claims, set SID as identifier... UPS populates from AD, and pushes out to userinfo lists... user logs in via ADFS, SID is matched against userinfo list, and against UPS.

    ---

    As far as the specifics...

    step 1 is pretty easy... lots of info about adding claims to ADFS, and configuring SP to receive claims.

    step 2 is where things get muddy... lots of people show SNIPPETS of custom claim providers... then most of then find the codeplex project and say "should've just used that!"... unfortunately, it ONLY supports ONE directory, so for partner logins would need some customization.

    step 3 is pretty easy, and since i've only needed to look up pieces here and there, I don't know offhand how many articles/etc exist.

    ---

    The bad pieces...

    since ADFS is not a queryable service, for lookups to occur for EXTERNAL domains, searching for accounts in the external domain requires some sort of directory. For the orgs I've dealt with that need external lookups, we usually did some sort of SQL table lookup (they would provide an import file)... occasionally, the external domains are related corps, and can do direct LDAP queries.

    If you need to provide UPS for multiple FORESTS, you need to change how the UPS imports, since only ONE connector can define the primary list of users (any others just provide supplemental metadata)... Microsofts' official answer is FIM, though you could use alternatives such as SQL. In the case of FIM, Microsoft also officially recommends that ADFS validate users against FIM (which is apparently how they do things internally), but I've yet to see this specific configuration in practice.


    Scott Brickey
    MCTS, MCPD, MCITP
    www.sbrickey.com
    Strategic Data Systems - for all your SharePoint needs

    • Marked as answer by Victoria Xia Monday, May 19, 2014 1:24 AM
    Thursday, May 8, 2014 3:36 PM

All replies

  • So all said and done, using email addresses is a pretty bad approach... I also tend not to prefer using UPNs (while better than an email address, still not ideal)... the BEST approach is to use the SID, which is the same thing Windows uses internally, and has been proven very effective for years. Unfortunately, to configure SP to use SIDs requires a bit of effort (and depending on how things are configured, may or may not be practical).

    Alternatively, you could configure ADFS to put some sort of prefix in the primary identifier, to indicate the source of the authentication (such as "LOCALDOMAIN|user@domain.com" and "PARTNERDOMAIN|user@domain.com")... I've seen some claim providers do this, to avoid any collection between external authentication providers (LiveID, GoogleID, etc).

    The biggest decision factors will be based on the usability of things like the People Picker... if you're using OOTB settings, changing to a SID is going to be a MASSIVE change... if you've already chosen some customizations, it might be much easier to adjust.


    Scott Brickey
    MCTS, MCPD, MCITP
    www.sbrickey.com
    Strategic Data Systems - for all your SharePoint needs

    Tuesday, May 6, 2014 1:32 AM
  • Scott,

    Thanks for your reply.  We are trying to stay OOTB as possible so moving to a SID based claim isn't really an option.  We'll need to find a way to solve the double email issue or switched to UPNs most likely.

    If using emails or UPNs are such a bad approach why are those the only examples you see of integrating ADFS and SharePoint?  Just because of the ease of setup?  I've never read any examples of using SIDs.

    Thanks.

    Tuesday, May 6, 2014 1:59 PM
  • So all in all, it's just about how you uniquely identify users, and how reliable they are over time.

    SIDs have been the backbone of NTLM / NT domains / Active Directory for decades, and are proven effective... that said, they're obnoxious to work with as a user, so generally speaking they're never used directly but rather as the raw storage behind other profile attributes (like the NetBIOS domain name, the AD qualified username, or the AD display name). This is the case with SP Classic authentication, NTFS ACLs, Exchange mailboxes, etc... proven.

    Claims Based Auth has two aspects... one is to use an attribute as a unique identifier, and the other is to use attributes for either simple profile data (such as email address or department) or for validation (such as 'member of group' or 'has claim [xyz]').

    Separately, SP provides support for claims, but does not address the extreme flexibility that ADFS provides... for example, ADFS provides AUTHENTICATION, but is not QUERYABLE... this means that on its own, the people picker can't SEARCH an ADFS provider... so out-of-the-box, SP just expects you to type things correctly (the "search results" will ALWAYS return the exact search term).

    Now, since fixing the people picker requires a third party or custom solution, and configuration for searching... people tend to PREFER to use something SIMPLE like username / email / UPN, since it's easy enough to understand and use.

    Separately, people tend not to give much consideration to the long term choice of identifier... it's assumed that a username is unique (and when using ADFS with other networks, this is a BAD assumption)... or assumed that the name won't change (also a BAD assumption, since marriage/divorce tends to cause name changes).

    Also, when it comes to ADFS, a common use case is to federate with external identities (LiveID, GoogleID, etc))... and when it comes to EMAIL addresses, they're even EASIER to run into issues.

    Some people will consider using the UPN (AD fully qualified login name), since it's guaranteed to be unique within the FOREST... and only another forest of the same AD name will allow a collision... but to ensure that NO other external users (LiveID/etc) can't POSSIBLY collide also requires special ADFS claim manipulation.

    Unfortunately, if the primary identification claim (email, UPN, etc) changes, nothing in SharePoint will match, and the user will be considered completely separate.. all permissions and item tracking (tasks assigned, user profiles, etc) will effectively belong to a different user.

    For all these reasons, I prefer to go back to the time tested approach of SIDs... they don't change when a persons' name changes, and they're effectively guaranteed across domains/forests (since they're randomly generated and fairly long).

    Unfortunately, this also requires a bit of effort on the custom dev / config side, to tell SharePoint how SIDs map to SharePoint user objects and their additional properties (name, title, department, etc).


    Scott Brickey
    MCTS, MCPD, MCITP
    www.sbrickey.com
    Strategic Data Systems - for all your SharePoint needs

    Tuesday, May 6, 2014 11:40 PM
  • FYI, Office 365 now allows you to use an alternate login ID, instead of the UPN... for some of these same reasons.

    http://blogs.office.com/2014/05/06/alternate-login-id-for-office-365-reduces-dependence-on-upn/


    Scott Brickey
    MCTS, MCPD, MCITP
    www.sbrickey.com
    Strategic Data Systems - for all your SharePoint needs

    Wednesday, May 7, 2014 2:35 AM
  • Thanks for the response, Scott.  Do you know of any resources that discuss using SIDs as the primary identifier and the various configurations needed?

    I've done a bit of searching today and I can't seem to find any documentation or resources that help explain this solution.

    Thanks.

    Wednesday, May 7, 2014 10:23 PM
  • I've not written anything about it in my blog, and i don't know of other articles offhand...

    but generally speaking here are the pieces:

    1. ADFS sends SID as claim (I also tend to like Groups as SIDs, for similar reasons, but groups are far less likely to change names/etc). Also, configure SharePoint to receive SID, and treat as primary ID (the last step will cause disruption). Script out the conversion of users from their former identity (email or UPN or whatever you're using) to their SID (creating a map file is pretty easy with PowerShell).

    2. custom claim provider for userinfo table population and people picker resolution... most implementations use ADSI/LDAP queries for people picker search results, though some have already created ADSI connections from SQL servers (using linked servers), and prefer to query via SQL instead... userinfo table is used for any account that DOESN'T exist in the UPS, which is generally any partner orgs.

    3. for LOCAL DOMAIN user profile sync, connect to AD, configure for claims, set SID as identifier... UPS populates from AD, and pushes out to userinfo lists... user logs in via ADFS, SID is matched against userinfo list, and against UPS.

    ---

    As far as the specifics...

    step 1 is pretty easy... lots of info about adding claims to ADFS, and configuring SP to receive claims.

    step 2 is where things get muddy... lots of people show SNIPPETS of custom claim providers... then most of then find the codeplex project and say "should've just used that!"... unfortunately, it ONLY supports ONE directory, so for partner logins would need some customization.

    step 3 is pretty easy, and since i've only needed to look up pieces here and there, I don't know offhand how many articles/etc exist.

    ---

    The bad pieces...

    since ADFS is not a queryable service, for lookups to occur for EXTERNAL domains, searching for accounts in the external domain requires some sort of directory. For the orgs I've dealt with that need external lookups, we usually did some sort of SQL table lookup (they would provide an import file)... occasionally, the external domains are related corps, and can do direct LDAP queries.

    If you need to provide UPS for multiple FORESTS, you need to change how the UPS imports, since only ONE connector can define the primary list of users (any others just provide supplemental metadata)... Microsofts' official answer is FIM, though you could use alternatives such as SQL. In the case of FIM, Microsoft also officially recommends that ADFS validate users against FIM (which is apparently how they do things internally), but I've yet to see this specific configuration in practice.


    Scott Brickey
    MCTS, MCPD, MCITP
    www.sbrickey.com
    Strategic Data Systems - for all your SharePoint needs

    • Marked as answer by Victoria Xia Monday, May 19, 2014 1:24 AM
    Thursday, May 8, 2014 3:36 PM