SharePoint 2013 Configure Automatic Sign-In with Mixed Authentication


This article is the final supplemental article in our “Configuration SharePoint 2013 with ADFS 3.0” series.In this article we will discuss a solution that we used in our environment to get around the authentication selector page.

Automatic Sign-In with Mixed Authentication

In this new series we discussed that both authentication methods are enabled on a single web application it may be desirable for some people to bypass the logon page.  Luckily someone had already done this and provided the needed solution online at  We used this solution because we didn’t want users having to select which authentication they were to use and have them inevitably chose the wrong one and get access denied messages.

The originally way the solution works is to isolate a user’s subnet and then guide them to the proper authentication based on that subnet.  So all requests from the subnet the SharePoint servers are on get directed to use NTLM and all other subnets would then be configured to use ADFS.  We modified the codeplex solution slightly for our own use, but I’ll discuss that at the end and just show the way it works as advertised in this post.


  • First obtain the solution from the codeplex site and put it in a directory on one of your SharePoint servers.
  • Using and elevated SharePoint Console Add the solution to the farm using the Add-SPSolution cmdlet


  • Deploy the Solution using the Install-SPSolution cmdlet


  • Verify the feature has deployed successfully.  In Central Administration navigate to “System Settings


  • Select “Mange Farm Solutions


  • Verify the solution has been deployed


  • Once the solution has been successfully deployed the PowerShell snappin assembly needs to be registered through the command line


  • One final thing after the installation is we need to move the custom login page that is created with this install.  Because this install was created for SharePoint 2010 it creates the login page under the 14 hive rather than 15.  Move the following file:

C:\Program Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\LOGIN\autosignin.aspx


C:\Program Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\IDENTITYMODEL\LOGIN\autosignin.aspx

This will ensure the login page is present when we need it.



Now that we have the solution installed we will have to go into the configuration and setup.  This is all covered in documentation on the codeplex page here, but I will add the quick and dirty to get us going.

  • Launch an elevated SharePoint Management Shell and add the snappin


  • Create/Import the current configuration for the web application we are doing the setup and display it


  • So we will be adding two subnets to the configuration.
    • SharePoint Servers
      • Windows Authentication
    • Lab Workstation
      • ADFS (or whatever your Trusted Provider might be named)
    • Use the following Powershell to add configurations.  the .update() method is what is used to commit the changes.


  • Now that the configuration is made, we just need to set the logon page that will do the redirection.  In Central Administration navigate to “Manage web applications


  • Select the “SharePoint Lab – SPT” web application and then “Authentication Providers


  • Select the “Default” zone


  • Scroll down to the “Claims Authentication Types section and make sure the NTLM and Trusted Identity Provider options enabled.


  • Scroll down a bit further to “Sign In Page URL“.  Here select “Custom Sign In Page” and enter in “_login\autosignin.aspx“.  Then scroll down and click “Save“.


  •  Now when we visit the page via the Workstation we should see that we bypass the multi-authentication selection page and are automatically directed to the adfs server for login


  • When we are finally presented the SharePoint site, we can see the UPN/Email Address in the upper right corner knowing we used our ADFS identity to authenticate


  • When we log onto the SharePoint site via one of the SharePoint servers we can see were logged in via NTLM


Additional Notes

One caveat to using this solution is that you will need to create a separate entry for each subnet you wish to manage using the login page.  There is no ‘default’ selection to allow you to kick over everyone that didn’t meet one of the entries.  This was our main concern since we had a large number of subnets we would have to manage.

Our solution was to modify the source code (available on codeplex) to have a DEFAULT entry.  This allowed the subnets the SharePoint servers were located on to continue to use NTLM, but everyone else would be defaulted ADFS.

We’re not going to go into great detail on what was done since we are not coders and don’t want any responsibility of what may happen to your environments should you chose to do a similar thing.  But here is the code that was added to the source code to allow this ability.  Its and ‘elseif’ added to the AutoSignin.cs file of the source code.

else if (config.ProviderMappings.ContainsKey("DEFAULT"))


writeLog("No specific provider mapping found for: " + ip + ". Using default: " + config.ProviderMappings["DEFAULT"]);

string targetProvider = config.ProviderMappings["DEFAULT"];

foreach (SPAuthenticationProvider provider in settings.ClaimsAuthenticationProviders)


if (string.Compare(provider.DisplayName, targetProvider, true, System.Globalization.CultureInfo.CurrentUICulture) == 0

|| string.Compare(provider.ClaimProviderName, targetProvider, true, System.Globalization.CultureInfo.CurrentUICulture) == 0)


writeLog("Matching AuthProvider Found: " + provider.DisplayName);

string url = provider.AuthenticationRedirectionUrl.ToString();

if (signinPageMappings.ContainsKey(provider.DisplayName))


url = signinPageMappings[provider.DisplayName];



if (provider is SPWindowsAuthenticationProvider)


components = EnsureReturnUrl(components);


writeLog("Provider: " + provider.DisplayName + " Redirect URL: " + url);

SPUtility.Redirect(url, SPRedirectFlags.Default, this.Context, components);






writeLog("No authentication provider is mapped to your request address, or no matching authentication provider could be found for " + ip);



This will allow you to add a DEFAULT entry for any of the authentication providers and any subnet that isn’t explicitly called out will be caught up in this exception:


Tagged with: , , , , ,
Posted in ADFS, SharePoint 2013
2 comments on “SharePoint 2013 Configure Automatic Sign-In with Mixed Authentication
  1. Dan says:

    Overall the Solution worked great as I was having issue with Search results and OWA documents. But there appears to be an issue when applying this to with Web Application for Apps Management, whereas the given exception is presented:

    [NullReferenceException: Object reference not set to an instance of an object.]
    OrbitOne.SharePoint.Claims.SignIn.AutoSignin.OnLoad(EventArgs e) +249
    System.Web.UI.Control.LoadRecursive() +94
    System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2951

    • whorn76 says:

      Hmmm…I’m not sure what might be the issue there. I have since found that I don’t need to use the Claims AutoSignIn solution unless I have the need for two Trusted Providers. You can simply set the Custom Login Page on the Web Application to: /_trust/ and it should automatically redirect to the trusted provider and still use NTLM for local farm stuff as needed. (i.e. Search)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: