Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS
SharePoint

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Posted by on Wednesday, March 4th, 2015  

 

Well, we’ve installed and configured AD FS 3.0 and we have created the first relying party trust for our SharePoint 2013 farm. All that remains now is to complete the configuration of our new Trusted Identity Token Provider and configure SharePoint to use it, which we will be doing in this article.

Before we begin: want to read the full series from start to finish?

Part 1: The Beginning
Part 2: Installing and Configuring AD FS 3.0
Part 3: Configuring SharePoint 2013 for AD FS
Part 4: Troubleshooting
Part 5: Authentication Across Multiple Forests

To finish the configuration of our new Trusted Identity Provider, we need to complete 4 steps. When these steps are completed, we will be able to log into our test SharePoint farm using claims-based authentication.

In this article we will perform the following tasks:

  1. We will add the *.s7gears.com SSL certificate that we exported in my last post to the Trusted Root Certification Authorities certificate store on all the servers in the farm.
  2. We will add the certificate to the SharePoint Trusted Root Store using PowerShell.
  3. We will create the Trusted Identity Provider within SharePoint using PowerShell.
  4. We will configure our SharePoint web application to accept our Trusted Identity Provider as its authentication source.
  5. We will configure the trusted Identity Provider for multiple URLs.

Along the way I will try and add some of the lessons I have learned in the field and the lab that you may find helpful.

Import the SSL Certificate

Please remember the reason for this step is that I am doing this in a test/development environment and do not have access to certificates issued by a commercial CA (Digicert, Verisign, etc). I have created self-signed SSL certificates for use in this test environment and to avoid certificate errors am deploying these certificates to the Trusted Root Authorities store. Could I PowerShell this? Yes, I am sure I could figure it out if I had to 🙂

I have saved the exported .cer file on a network share that is available to all the servers in my SharePoint farm. I’m going to access the file share through Windows Explorer and open the .cer file from there and click the “Details” tab. Before I do that I want you to take a look at the following screenshot, as you can see in the Certificate Information section at the top there is a red “X” and a message indicating that the certificate is not trusted. We are about to address that error message in the next step.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

To start the process we will click the “Install Certificate” button, which starts the Certificate Import Wizard, then select “Local Machine” as the Store Location.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

On the next panel of the wizard we will manually select what certificate store we want to use for this certificate import. First we will select the radio button for “Place all certificates in the following store” and then click the “Browse” button to open the Select Certificate Store dialog. In that dialog, we’ll select the certificate store we want to use for this import and then click Next to continue.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

On the Completing the Certificate Import Wizard click the “Finish” button to complete the wizard. If the import has been successful you will see a popup message stating that the import succeeded. As you can see in the following screenshot, however, there is still an error message in the Certificate Information section.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

If you close and reopen the certificate you will see that the error message is now gone.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Configure the SharePoint Trusted Root Authority

You’ve seen the word “trust” mentioned throughout this series of blog posts. Remember that the whole premise of claims-based authentication is the underlying trusts that have to be established for it to work. If any one part of the trust is not working then authentication will fail.

In this section we will add our SSL certificate to the SharePoint Trusted Root Authorities using PowerShell.

  1. First we are going to assign a variable to the identity of the certificate we want to import. This certificate must be in a .cer format and can be stored locally or on the network. In our case the .cer file is stored on the network.

$cert = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2 ("\\adfs01\sp2013\adfscert.cer")

  1. Next we will create the SharePoint Trusted Root Authority with the identified certificate.

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert
Once the PowerShell command has completed you can run Get-SPTrustedRootAuthority to see a list of the available Trusted Root Authorities. By default you will see an authority named “local” and any others you have created including the “Token Signing Cert” we just created, that screen should look something like the following:

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Create the SharePoint Trusted Identity Token Issuer

Now that we have established the certificate trusts the next step is to create the SharePoint Trusted Identity Token Issuer. This involves creating claim type mappings, assigning a realm, and identifying the signin URL to be used.

There are a number of different incoming claim types, plus you can create custom claim types. For this exercise, we are using the CommonName and UPN claim types.

We will create our two claim type mappings with the following lines of PowerShell (all on one line please).

The first line of PowerShell will create the UPN claim mapping type.

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
-IncomingClaimTypeDisplayName "UPN" -SameAsIncoming

The second line of PowerShell will create the CommonName claim mapping type.

$cnNameMap = New-SPClaimTypeMapping -IncomingClaimType
"http://schemas.xmlsoap.org/claims/CommonName"
-IncomingClaimTypeDisplayName "Display Name" -SameAsIncoming

Now that we have created the Claim Type Mappings we will configure the trusted identity token issuer to work with the “realm” we created when we created the relying party trust. I know you don’t remember doing that because we didn’t call it a realm at the time.

The realm is the name of the relying party trust identifier we specified when we created our relying party trust. To refresh your memories, that identifier is the Uniform Resource Name (URN) we specified; urn:portal:sp2013.

VERY IMPORTANT: the relying party trust identifier MUST be entered EXACTLY as it is displayed in the AD FS Manager. That means the identifier is CASE SENSITIVE, if the two do not match SharePoint and the trusted identity provider will NOT communicate.

To configure our SharePoint farm to talk to the trusted identity token issuer we proceed by configuring the realm in PowerShell. To do that we start by assigning the realm to a variable, that variable being the Relying Party Trust Provider Identifier we were just talking about.

$realm = "urn:portal:sp2013"

Next we have to tell SharePoint what URL will be responding to authentication requests. The value for this URL is the federation service name that we identified when we ran the AD FS Services Configuration Wizard.

$signInURL = https://sts.s7gear.com/adfs/ls

Now we are ready to complete the configuration of the trusted identity token issuer. To do this we will run the following script.

$ap = New-SPTrustedIdentityTokenIssuer
-Name "SAML Provider for SharePoint" -description “SAML secured SharePoint"
-realm $realm
-ImportTrustCertificate $cert
-ClaimsMappings $upnClaimMap, $cnNameMap
-SignInURL $signInURL -IdentifierClaim $upnClaimMap.InputClaimType

A few explanations about this section of script:

  • The “Name” value is what you will see in your SharePoint web application as the Trusted Identity Token Issuer.
  • The realm is the relying party trust identifier we want to use with this particular provider. Note that each web application or host named site collection you create will have its own realm.
  • The “ImportTrustCertificate” parameter is where the token signing certificate we copied off of the AD FS server is passed to the application.
  • The “SignInURL” is the URL end users should be redirected to in order to authenticate to the IP-STS.
  • The “IdentifierClaim” parameter tells SharePoint which of the claims being submitted by the user is the one that will be used for identification of end users.

So the PowerShell script to complete the configuration of the trusted identity token issuer will look like the following. For your environment you will need to replace the values for the path to the certificate you are going to use.

$cert = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2 ("\\adfs01\sp2013\adfscert.cer")
New-SPTrustedRootAuthority –Name "Token Signing Cert" –Certificate $cert
$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming
$cnNameMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/CommonName" -IncomingClaimTypeDisplayName "Display Name" -SameAsIncoming
$realm = “urn:portal:sp2013”
$signInURL = https://sts.s7gear.com/adfs/ls
$ap = New-SPTrustedIdentityTokenIssuer –Name “SAML Provider for SharePoint” –description “SAML secured SharePoint” –realm $realm -ImportTrustCertificate $cert –ClaimsMappings $upnClaimMap, $cnNameMap –SignInURL $signInURL -IdentifierClaim $upnClaimMap.InputClaimType
Now that we have the trusted identity token issuer created, we will repeat the process (although I’m not going to show it again) to create a relying party trust for the MySites web application.

Once the relying party trust has been created we will need to add the realm for that trust to the SharePoint Trusted Identity Token Issuer. To do that we go back to PowerShell!

First we’ll set the variable identifying the specific trusted identity token issuer we are going to use.

$ap = Get-SPTrustedIdentityTokenIssuer "SAML for SharePoint"

Next we set the variable for the endpoint URL.

$uri = https://myportal.s7gear.com

Next we set the variable specifying the identity of the relying party trust we are connecting to. Remember, this entry is case sensitive.

$id = "urn:myportal:sp2013"

Finally we tell the authentication provider to add the variables defining the new realms.

$ap.ProviderRealms.Add($uri, $id)
$ap.update()

NOTE: when you areauthenticating against ADFS every time you add a web application, OR a host named site collection to the farm, you will have to create an associated relying party trust for that new object.

Now when you run the Get-SPTrustedIdentityTokenIssuer cmdlet you should see something similar to the following screen.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

As you can see, the command outputs the configuration information for the trusted identity token issuer including:

  1. Provider URI: these are unique identifiers used to identify configuration objects in this case the claim type.
  2. Default provider realm: this was the first of the two realms we created.
  3. Provider realms: these are any additional realms you may have configured for your environment. REMEMBER: you MUST have a realm and an associated relying party trust for every web application or host named site collection in your farm.
  4. ClaimTypes: these are the claims types this trusted identity provider supports.
  5. ClaimTypeInformation: the attributes the claim types are mapped to.
  6. Thumbprint: this is the certificate thumbprint of the signing certificate. This can be a good place to start if you think you are having certificate issues.
  7. Name: the name of the trusted identity provider.
  8. DisplayName: This is what you will see in SharePoint when you configure a web application to use a trusted identity provider.

That’s a lot of work so far, and we still haven’t configured SharePoint to use our trusted identity provider. We’ll take care of that and then see if all of this work has been worth the effort!

Configuring SharePoint to use the SAML for SharePoint Trusted Identity Provider

At long last we have arrived at our SharePoint destination and are finally ready to see if our SharePoint farm will talk to our AD FS server and authenticate our users. We’ll start that process by navigating through Central Administration > Application Management > Manage web applications. Once there we’ll select the portal web application and open the “Authentication Providers” control as shown below.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

In the “Edit Authentication” dialog box that pops up you will see a section for “Claims Authentication Types.” Inside that section, we will uncheck the “Integrated Windows authentication” checkbox and check both the Trusted Identity Provider and SAML for SharePoint checkboxes. Click save to continue.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Just a couple of more things to do before we can access our SharePoint site!

First we have to change the site collection administrator’s accounts to claims-based accounts that will be accepted by the trusted identity provider.

Before we get to that let’s look at something else first: the default value of the user-principal-name (UPN). To do this we’ll open the Forefront Identity Manager console (miisclient.exe) on my App server and look at the properties of the profiles being imported by my user profile service.

As you can see in this screenshot the value of the userPrincipalName attribute is my email address. This is important because this impacts how we add users to SharePoint. In the past we have searched for users in the people picker using a domain\username format. Because I have identified the userPrincipalName (UPN) attribute as my identity claim we will now use username@s7gear.com to add users to SharePoint (users will still login using the domain\username format).

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Before we change site collection administrators, here’s an important word about claims and the people picker. By default the people picker will validate ANY value that you type into it and search for. Kirk Evans has a great blog post on how to address this over at MSDN that is far beyond anything I can even attempt to do: Fixing People Picker for SAML Claims Users Using LDAP

For now we’ll focus on making sure that anyone we try and add to SharePoint actually exists and we get their email correct.

Now let’s add a new site collection administrator to my portal web application. To do this we’ll navigate to Central Administration > Application Management > Site Collections > Change site collection administrators and add a new site collection administrator. The first thing you’ll notice is that the people picker looks a little different and contains 3 additional fields on the left hand side, including not only our trusted identity provider but the individual claim as well.

I am going to add the S7Gear administrator account as a site collection administrator so I’ll type in the email address administrator@s7gear.com and click search. As you can see in the following screenshot my search returned two results: one is my organizational display name (Common Name anyone?) and the other is my UPN, which displays as my email address.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

We can’t give permissions using the display name so we will select the SAML for SharePoint group on the left, and then in the display field the administrator@s7gear.com account.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

We click OK to finish adding the administrator account and, as you can see, the primary site collection administrator of the portal site collection is now administrator@s7gear.com.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

 

Wow! Finally we are ready to test our web application and see if we can authenticate successfully and access our SharePoint site. We’ll start by opening Internet Explorer and going to https://portal.s7gear.com, where we are immediately redirected to the default SharePoint signin page. As you can see on this page there is a drop down menu that lists the available authentication providers. In this case Windows Authentication and our trusted identity provider “SAML for SharePoint” both appear

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

Selecting the SAML for SharePoint authentication provider brings up the Windows Security login box. It is VERY IMPORTANT when you enter your credentials here that you enter them in the traditional domain\username format.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

If you watch the address bar you will see that after submitting your credentials you are redirected back to the trusted identity provider to request the SAML token. The trusted identity token issuer looks up the identifier (the URN) of the web application the request is coming from and then passes the identifier to the external token issuer in the wtrealm parameter seen in the screenshot below.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

The external token issuer returns the SAML token and the SharePoint trusted identity token issuer verifies the signature, applies any mapping rules, and drops the SAML token into the SharePoint token cache. SharePoint checks if a user has a valid SAML token, then uses the claims in that token to perform any authorization validation.

Now if we have successfully been authenticated by AD FS and authorized by SharePoint we should see the portal home page.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

I hope you found this useful. As always, if you have any questions please leave them in the comments section.

In my next post I’ll give you some tips on troubleshooting AD FS as well as some insight into some of the issues I have run into and the solutions I found.

Thanks for reading….

Quick Reference:
Part 2: Installing and Configuring AD FS 3.0

Part 1: Claims Based Authentication, AD FS 3.0 and SharePoint 2013 Beginners Guide

Posted by on Wednesday, March 4th, 2015  

Subscribe to RSS Feed

Sign Up for Newsletter

21

21

comments

    Jun 12
    2015

    Sahil Verma

    Must say, amazing blog!

    I have two SP web applications which I need to put in Single Sign In mode using Claim Based Authentication with ADFS Issuer.

    Issue is that these web applications are in production, up and running. Main Intranet web application has 100’s of site collections and complex permission management. Will an implementation like this effects the permissions over the site since the existing permissions are there with USers from default provider? Do I need to define the permissions again everywhere?

    Could you please suggest?

    Thanks,
    Sahil

    Reply
    Aug 04
    2015

    Jasmine

    superb post. Loved it.. thanks for finding time to write this.

    Reply
    Aug 25
    2015

    Nicolas

    Can the default ADFS login page be used instead of the “windows security” classic login prompt? Its strange we still have to use DOMAIN\user instead of using the email address in the default ADFS login page.

    Reply
      Feb 05
      2016

      Verona

      This is great article. Have same question as Nicolas, just wondering if we can use login page instead of windows credentials popup. In ADFS 2.0, the people suggested to change .config file for this purpose. However ADFS 3.0 doesn’t have IIS Web Application, and just wondering how we can do that. somehow a login page with remember password can help the user login from device browser.

      Thanks

      Reply
    Sep 18
    2015

    Richard Phung

    After setting this up, Authentication Works great…. but I get directed to:
    https://mysp2k13/_trust

    Which results in a Runtime Error

    Reply
    Sep 21
    2015

    Ryan

    Like Sahil, I have the same question…

    We’ve tried migrating to ADFS in the past, but there are always HUGE issues, like ignoring permissions on AD Groups, and UPS becoming totally borked. Your post seems to totally circumvent the whole idea of having to change the user account prefixes in sharepoint(from i:0#.w|domain\user to i:05.t|ADFSTrustedProvider|user@mail.com), while others say this is a necessary step.

    My farm has over 800 site collections, and 150k users. We use TMG which works great when it stays up.

    I don’t want to put in the effort for this if it’s going to to totally hose all my EXISTING permissions.

    -Ryan

    Reply
      Jan 12
      2016

      Jay Simcox

      Hey Ryan,

      The steps in the series are to implement ADFS in a test environment. It wasn’t my intention to address all of the decision points around implementing ADFS in a production environment. That in itself could be a number of articles because there are a great many decision points and potential roadblocks that have to be addressed. I cover some of those in the final post in this series but that particular article is by no means exhaustive and there are points that will need to be addressed that will be different based on the organization doing the implementation and their specific requirements.

      Short answer is yes, if you just go out and do this it could potentially have a negtive impact on your existing security structure. That is why I always recommend doing things like this in a test/dev environment (you could use the same ADFS server(s) for both).

      Thanks for reading!

      Reply
    Dec 17
    2015

    Guillermo

    Hello,

    I have configured SharePoint following the steps and now I am having the following error:

    Application error when access /PWA, Error=The issuer of the token is not a trusted issuer.

    Any idea on this?

    Thank you very much in advance.

    Reply
      Jan 03
      2016

      Jay

      Hello Guillermo,

      The first thing I would do is make sure that you have added the certificates from the ADFS server to the Manage Trust store in your SharePoint farm. That is usually the cause of this particular error.

      Hope that helps!

      Thanks,

      Jay

      Reply
        Jan 12
        2016

        Guillermo

        Hi Jay,

        Thank you so much for your response.

        Yes, I have added the certificate generated on ADFS server in my SharePoint Server (Trusted Root Certification Authorities).

        I found a mistake in ADFS side, the WS-Federation Passive protocol URL didn’t have /_trust/ and the end of the string. I have added that part and now I am having an Application Error. I have found this issue at Part IV – Troubleshooting / Server Error in ‘/’ Application but I don’t know how to solve that…

        What can I do? I am sure that I am using the certificate and it is added to Trusted Root Certification Authorities.

        Thanks in advance.

        Reply
          Jan 12
          2016

          Guillermo

          That is my error

          Application error when access /_trust/, Error=ID4220: The SAML Assertion is either not signed or the signature’s KeyIdentifier cannot be resolved to a SecurityToken. Ensure that the appropriate issuer tokens are present on the token resolver. To handle advanced token resolution requirements, extend Saml11TokenSerializer and override ReadToken.
          at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
          at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
          at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
          at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
          at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
          at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
          at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
          at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

          Reply
            Jan 12
            2016

            Jay Simcox

            Hey Guillermo, are you sure that you exported the Token-SIGNING certificate and not the Token-DECRYPTING cert? I’ve seen this error before when you export the incorrect certificate and use it to create your trusted identity provider. I’d go back into ADFS, export the signing certificate (even if all your certificates are the same), delete your trusted identity provider and then start over with the newly exported certificate.

            Let me know how it goes!

        Jan 13
        2016

        Guillermo

        hey Jay, thanks for your reminder, Token-SIGNING is the correct one. We exported again this certificate and it looks like that is working correctly 🙂

        My issue now is with the people picker, I am trying to find users from ADFS but I am not finding real users. If I type a real account people picker returns me 1 result under SAML for SharePoint/UPN but if I type an unreal user I have the same result so I can write anything and it is returning a result but the result is not a real user. Do you know if I must do something with User Profile Service or something like this?

        Thanks again… Your help is much appreciated.

        Reply
          Jan 28
          2016

          Jay Simcox

          Hey Guillermo, what you’re seeing is a well known shortcoming of using SAML claims for authentication. There is a codeplex solution that is referenced in the following link that you might find helpful. I will warn you that I have not tested that solution and can’t attest to how it’ll work or if it will work at all. I strongly recommend playing with it in an isolated test domain before putting it into a production environment.

          SharePoint 2013 Configure People Picker to Resolve ADFS Identities

          Hope this helps!

          Reply
    Jan 06
    2016

    Roland Catubig

    Can external ADFS Client be autrhenticate via our ADFS sharepoint 2013? What attributes should we check and vallidate prior to giving access to our own Sharepoint?

    Reply
      Jan 12
      2016

      Jay Simcox

      Hey Ronald, I’m not sure exactly what you’re asking, can you elaborate a little?

      Thanks!

      Reply
        Apr 11
        2016

        Jelienne

        I have a similar question about external ADFS and Oracle Access Manager. Currently at our company, we have a corporate Active Directory for our internal staff and we use an Identity Management system (OAM) for our external customers using SAML with our third party apps. If I am reading your article correctly, the Active Directory you are referring to is explicit to SharePoint. If we were to provide shared access to a document on SharePoint where both an employee and external partner/customer could access ,is SharePoint configurable to authenticate and authorize using our existing SAML and ADFS and not use the SharePoint active directory?

        Reply
    Feb 14
    2016

    Roy Kim

    I configured “SAML for SharePoint” in Manage Web Application – Edit Authentication,
    but I can’t select “SAML for SharePoint” on login site.
    This authentication type is not visible on the menu.
    Why do these problems occur?

    Reply
    Jun 02
    2016

    Andrew

    Hi, is it possible to configure SharePoint 2013 to authenticate using ADFS but not SAML? As I know ADFS 3.0 support non-claim aware.
    I want to do this because I want to have Azure Multi factor authentication and a typical way is to configure Sharepoint 2013 to use ADFS for authentication then secure the ADFS server for MFA.

    Thanks

    Reply

Leave a Reply