SharePoint / Guide 5

Single sign-on and authentication

Kerberos, SAML with AD FS, OpenID Connect, and Secure Store for reaching other systems.

"Single sign-on" means two different things in SharePoint, and it helps to keep them apart:

1. Users signing in to SharePoint once, without extra prompts (Windows authentication, AD FS, Microsoft Entra ID).
2. SharePoint signing in to other systems on a user's behalf (a database, an SAP system, a web service). This is what the old Single Sign-On service and today's Secure Store do.

How it progressed

Windows authentication done right: Kerberos

NTLM works out of the box but can't pass a user's identity on to another server (the "double hop" problem) and adds load on domain controllers. Kerberos gives true single sign-on for domain users and allows delegation to back-end systems.

Kerberos needs a Service Principal Name (SPN) for each web application URL, registered to the application pool account:

setspn -S HTTP/sharepoint.ravindran.in RAVINDRAN\sp-webapp-pool
setspn -L RAVINDRAN\sp-webapp-pool

Then set the web application's Windows authentication to Negotiate (Kerberos). Check it's working by opening the site from a client and running klist: you should see a ticket for HTTP/sharepoint.ravindran.in.

Common mistakes: duplicate SPNs (setspn -X finds them), using a CNAME in DNS for the site name (use an A record), and forgetting the SPN for every host name users actually type.

SAML sign-in with AD FS

For single sign-on with non-Windows sessions, partners, or a central identity provider, SharePoint trusts a SAML identity provider such as AD FS. The setup has three parts: trust AD FS's token-signing certificate, define which claims SharePoint accepts, and create the trusted identity provider.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Certs\adfs-token-signing.cer")
New-SPTrustedRootAuthority -Name "AD FS token signing" -Certificate $cert

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

New-SPTrustedIdentityTokenIssuer -Name "AD FS" -Description "Sign in with AD FS" `
    -Realm "urn:sharepoint:portal" -ImportTrustCertificate $cert `
    -ClaimsMappings $email, $upn -SignInUrl "https://adfs.ravindran.in/adfs/ls" `
    -IdentifierClaim $email.InputClaimType

Then add the provider to the web application's zone in Central Administration, and create a matching relying party trust in AD FS with the same realm.

Plan for the people picker. With SAML, SharePoint can't look users up by itself, so the people picker accepts anything typed. A custom claims provider fixes this; the community projects LDAPCP and EntraCP are widely used.

OpenID Connect in Subscription Edition

Subscription Edition can use OpenID Connect 1.0 with Microsoft Entra ID or AD FS. It's the modern choice for tying an on-premises farm to the same sign-in (and conditional access policies) as Microsoft 365. Follow Microsoft's current Subscription Edition documentation for the exact steps, as they have been refined in feature updates.

Moving old web applications to claims

Classic-mode web applications must be converted to claims before you can upgrade past 2013:

Convert-SPWebApplication -Identity https://sharepoint.ravindran.in -From Legacy -To Claims -RetainPermissions

Test on a copy first. Custom code and some third-party products that read user names directly may need changes because user names become claims (for example i:0#.w|ravindran\jane).

Secure Store: SharePoint signing in to other systems

Secure Store keeps encrypted credentials for target applications and hands them to services such as Business Connectivity Services at run time. A group target application maps a whole AD group to one set of credentials; an individual one stores credentials per user.

# One-time: generate the master key (Central Administration can do this too)
Update-SPSecureStoreMasterKey -ServiceApplicationProxy (Get-SPServiceApplicationProxy | Where-Object { $_.TypeName -like '*Secure Store*' }) -Passphrase 'Use-a-long-passphrase-and-store-it-safely'

# Create a group target application
$ta     = New-SPSecureStoreTargetApplication -Name "HRDB" -FriendlyName "HR database" -ApplicationType Group
$fUser  = New-SPSecureStoreApplicationField -Name "User name" -Type WindowsUserName -Masked:$false
$fPass  = New-SPSecureStoreApplicationField -Name "Password"  -Type WindowsPassword -Masked:$true
$admin  = New-SPClaimsPrincipal -Identity "RAVINDRAN\sp-admin" -IdentityType WindowsSamAccountName
$users  = New-SPClaimsPrincipal -Identity "RAVINDRAN\HR Readers" -IdentityType WindowsSecurityGroupName

New-SPSecureStoreApplication -ServiceContext https://sharepoint.ravindran.in `
    -TargetApplication $ta -Fields $fUser, $fPass -Administrator $admin -CredentialsOwnerGroup $users

Then set the stored credentials in Central Administration (Secure Store Service > the target application > Set Credentials).

Keep the passphrase. You need it to add new servers and to recover Secure Store. Store it in your password vault, not in a script.

SharePoint Online

Sign-in is Microsoft Entra ID. On-premises identities reach it through Entra Connect with password hash sync, pass-through authentication or federation. Use conditional access and multi-factor authentication, and manage external users through Entra B2B guest settings together with SharePoint sharing settings.