1

We are planning migration from SharePoint 2013 to SharePoint 2016. Have checked all web applications with

Get-SPAuthenticationProvider -Zone "Default" -WebApplication https://teamstest.domain

All except one are like this

DisplayName                        : Windows Authentication
ClaimProviderName                  : AD
AllowAnonymous                     : False
UseBasicAuthentication             : False
DisableKerberos                    : False
UseWindowsIntegratedAuthentication : True
AuthenticationRedirectionUrl       : /_windows/default.aspx
UpgradedPersistedProperties        :

But one is set to this:

DisplayName                        : Windows Authentication
ClaimProviderName                  : AD
AllowAnonymous                     : False
UseBasicAuthentication             : True
DisableKerberos                    : True
UseWindowsIntegratedAuthentication : True
AuthenticationRedirectionUrl       : /_windows/default.aspx
UpgradedPersistedProperties        :

How can I convert this to the state of the other web applications?

I have found different aproaches by powershell like

$wa.MigrateUsers($true)

or

Convert-SPWebApplication

As I do not know anything about authentication I do not know if one of these fit this issue.

There are just 5 site collections on this web application. One of them got more than 200 sub sites. So I would not like to go the way of creating all the sites within a new web application with "DisableKerberos:False".

8
  • Do you only authenticate for ActiveDirectory users? Or do you also have a TrustedIdentityProvider configured (example here for Azure AD, but could also be other providers: samlman.wordpress.com/2015/03/05/…)
    – MHeld
    Commented Mar 14, 2018 at 15:13
  • No, we just have local users from Active Directory.
    – PhilFancy
    Commented Mar 14, 2018 at 15:41
  • do you use excel services or other service that requires credentials to be delegated to other servers or from other servers?
    – Mike
    Commented Mar 14, 2018 at 15:58
  • research if there's a service account using kerberos to authenticate to your server or from your server.
    – Mike
    Commented Mar 14, 2018 at 15:58
  • As I want to get rid of "Basic Authentication" used/set in one single web application which was configured by myself years ago I am sure "Basic Authentication" is configured for no reason. So I want to change it to "Negotiate - Kerberos" to have all web applications doing Kerberos. All other web applications are doing fine with Kerberos. To answer your question - we do not use Excel Services or Access Services and stuff. There is just a WopiBinding to our (already in 2016 version installed) Office Online Server. Office Online runs well from Kerberos and BasicAuthentication web applications.
    – PhilFancy
    Commented Mar 14, 2018 at 16:03

2 Answers 2

3

I think you mix up two things: Authentication and SharePoint token-handling. Authentication is the first step and describes the process, how a user tells SharePoint who he is. Here you have NTLM, Kerberos and Basic. Token-handling is the 2nd step after successful authentication. This is distinguishes between windows classic (domain\user) and claims format (i:0#.w|domain\user).

Your methods $wa.MigrateUsers($true) and Convert-SPWebApplication are only used to convert the user-schema inside the ContentDB (step2). Your question is about step1.

In SharePoint 2013 you already have a claims enabled WebApplication which only authenticates AD-Users. So the users should exist in the correct format. No conversion is necessary.

It's just important to configure your new SP2016 WebApplication correctly:

  • Set up the WebApplication with claims
  • Enable Integrated Windows Authentication with Negotiate (Kerberos)
  • Make sure Basic is disabled
  • Then move the contentDB from SP2013 to SP2016 with Mount-SPContentDatabase

Do all the steps as part of a test-migration first!

1

research if there's a service account or service using Kerberos authentication to log into your server

or if your sharepoint server requires kerberos authentication to delegate creadentials to another server.

normally you can go ahead and enable kerberos without problems, but there might be some things you have to look ahead

1.- If a service account in your SP farm is being allowed to delegate, then you have to enable kerberos for the service account in the new server (set spn and allow delegation)

2.- if your users have a lot of groups in your sp servers you might face a "request too long" error, to fix that you must increase the maxlengh.

Kerberos is not a way to authenticate users, is a way to allow credentials to be passed or delegate through servers.

What you want to do if you don't want to use basic authentication is to enable Claims authentication

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.