Add MFA to Sharepoint SE using Fortified ID Access

This guide provide the steps to add login methods available in Fortified ID, such as MFA, to an existing SharePoint Subscription Edition environment.

This guide assumes that SharePoint Subscription Edition is already installed and in use, and that users already work in an existing portal such as:

• https://portal.sharepoint.se

The guide shows how to add OIDC with Fortified ID to SharePoint and how to prepare SharePoint for users coming from the OIDC provider.

1. Prerequisites

Before you begin, verify the following:

1. SharePoint Subscription Edition is already installed and working.
2. An existing SharePoint portal is already available over HTTPS, for example https://portal.sharepoint.se.
3. You have SharePoint farm administrator permissions.
4. You have a Fortified ID environment where you can create an OIDC provider and a relying party.
5. A nonce cookie certificate with private key is installed on every SharePoint server in the farm.
6. The SharePoint web application pool account has access to the private key of the nonce certificate on every SharePoint server.

2. Important identity note

SharePoint does not treat a Windows or AD user and an OIDC user as the same SharePoint principal, even if they represent the same human.

Example:

• Windows identity: SHAREPOINTSELAB\anders_bjork
• OIDC identity: i:0e.t|fortifiedid24|[email protected]

This matters for:

• permissions
• People Picker results
• migration from AD FS to OIDC

3. Decide the SharePoint URL strategy

Choose one of the following approaches before continuing.

3.1 Use a separate OIDC URL

Example:

• Existing portal: https://portal.sharepoint.se
• New OIDC URL: https://oidc.sharepoint.se

This is the approach used in this guide because it is the easiest way to:

• test OIDC without disrupting the existing portal
• migrate gradually from AD FS or Windows-based access
• isolate troubleshooting and permission changes

3.2 Use the existing portal URL

SharePoint claims-based web applications can support multiple authentication methods on a single zone, and Microsoft recommends using the default zone if you want the same URL for all users. Sources:

• Plan for user authentication methods in SharePoint Server
• Plan alternate access mappings for SharePoint Server

However, this guide does not use that model. It uses a separate OIDC zone and URL because that is simpler and safer for rollout and migration.

If you want OIDC on the same existing start URL, treat that as a design decision and test it separately before changing production access.

4. Create the OIDC SharePoint URL

If you use a separate OIDC URL, add it before configuring Fortified ID or SharePoint trust settings.

Example OIDC URL:

• https://oidc.sharepoint.se

Do the following:

This section creates the new OIDC URL and extends the existing SharePoint web application to a new zone.

This example assumes:

• Existing portal URL: https://portal.sharepoint.se
• New OIDC URL: https://oidc.sharepoint.se
• Target zone: Intranet

4.1 Create the DNS record

Run this on the DNS server.

$zoneName = "sharepoint.se" $recordName = "oidc" $ipv4Address = "10.42.0.10" Add-DnsServerResourceRecordA ` -Name $recordName ` -ZoneName $zoneName ` -IPv4Address $ipv4Address ` -TimeToLive 01:00:00

Verify:

Resolve-DnsName oidc.sharepoint.se

4.2 Import the SSL certificate into SharePoint

Run this in SharePoint Management Shell.

$pfxPath = "C:\Certs\oidc.sharepoint.se.pfx" $pfxPassword = ConvertTo-SecureString "PfxPasswordHere" -AsPlainText -Force $spCert = Import-SPCertificate ` -Path $pfxPath ` -Password $pfxPassword ` -Store EndEntity $spCert | Select-Object FriendlyName, Thumbprint, Subject

4.3 Extend the existing SharePoint web application to the OIDC URL

Run this in SharePoint Management Shell.

$wa = Get-SPWebApplication "https://portal.sharepoint.se" $winAp = New-SPAuthenticationProvider ` -UseWindowsIntegratedAuthentication ` -DisableKerberos:$true New-SPWebApplicationExtension ` -Identity $wa ` -Name "SharePoint OIDC" ` -Zone Intranet ` -HostHeader "oidc.sharepoint.se" ` -Port 443 ` -Url "https://oidc.sharepoint.se" ` -SecureSocketsLayer ` -UseServerNameIndication ` -Certificate $spCert ` -AuthenticationProvider $winAp

Det här steget skapar i praktiken den nya IIS-sajten och HTTPS-bindningen för zonen. Du behöver alltså normalt inte skapa IIS-bindningen separat om du gör det via New-SPWebApplicationExtension. Microsofts dokumentation för certifikat på webbapplikationer och extension stöder den modellen: Assign certificates to web applications

4.4 Verify the IIS website and HTTPS binding

Run this on the SharePoint server.

Import-Module WebAdministration Get-Website | Select-Object Name, State, PhysicalPath Get-WebBinding -Protocol https | Select-Object protocol, bindingInformation, sslFlags

Du ska se en HTTPS-binding för oidc.sharepoint.se:443.

4.5 Verify that the OIDC URL resolves and responds

Run this from the SharePoint server or a client that should reach the site.

Resolve-DnsName oidc.sharepoint.se Invoke-WebRequest ` -Uri "https://oidc.sharepoint.se" ` -MaximumRedirection 0 ` -ErrorAction SilentlyContinue

A 200, 302, or another valid SharePoint response is sufficient here. The important part is that:

• DNS resolves correctly
• TLS works
• SharePoint responds on the host name

Microsoft documents the zone and alternate access mapping model here:

• Extend claims-based web applications in SharePoint
• Plan alternate access mappings for SharePoint Server

5. Configure Fortified ID

Create an implicit OIDC provider for SharePoint.

5.1 Create the OIDC provider

Use at least the following settings:

• Flow: Implicit
• id_token TTL: 60 minutes

5.2 Add the UPN claim to the id_token

Add this claim:

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "${exports.subject}@sharepointselab.local"

This is important because SharePoint should use a standard UPN claim URI as the identifier claim.

5.3 Create the relying party for SharePoint

Create a relying party for the SharePoint OIDC URL, and bind it to the newly created OIDC Provider.

Use at least:

• Allowed redirect URI: the SharePoint OIDC URL, for example https://oidc.sharepoint.se

5.4 Verify the resulting id_token

Before configuring SharePoint, verify that the id_token contains:

• iss
• aud
• exp
• iat
• nonce
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

Example:

{
  "exp": 1776700343,
  "iat": 1776700043,
  "iss": "https://sdemo.fortifiedid.se/oidc/oidc_op_1",
  "aud": "Iab2JjtcqfSOVfrOQs4ThwCOKkwIGKvp",
  "sub": "anders_bjork",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "[email protected]",
  "nonce": "..."
}

6. Prepare the SharePoint OIDC trust values

Run the following commands in SharePoint Management Shell as administrator.

This example assumes:

• Existing SharePoint portal: https://portal.sharepoint.se
• OIDC SharePoint URL: https://oidc.sharepoint.se
• OIDC trust name: FortifiedID24

6.1 Define the base values

$waUrl = "https://portal.sharepoint.se"
$trustName = "FortifiedID24"
$metadataUrl = "https://sdemo.fortifiedid.se/oidc/oidc_op_1/.well-known/openid-configuration/"
$clientId = "Iab2JjtcqfSOVfrOQs4ThwCOKkwIGKvp"

6.2 Create the UPN claim mapping

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

7. Switch the target zone temporarily if needed

If the target SharePoint zone currently uses an earlier trusted provider, switch it temporarily to Windows authentication so the old trust can be removed cleanly.

Example for the Intranet zone:

$winAp = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos:$true
Set-SPWebApplication -Identity $waUrl -Zone Intranet -AuthenticationProvider $winAp

Verify:

Get-SPAuthenticationProvider -WebApplication $waUrl -Zone Intranet

8. Remove the old trust if it already exists

$existing = Get-SPTrustedIdentityTokenIssuer -Identity $trustName -ErrorAction SilentlyContinue
if ($existing) {
    Remove-SPTrustedIdentityTokenIssuer -Identity $trustName -Confirm:$false
}

9. Create the SharePoint OIDC trust

9.1 Create the trust

New-SPTrustedIdentityTokenIssuer `
  -Name $trustName `
  -Description "Fortified ID OIDC using AD UPN" `
  -ClaimsMappings $upnClaimMap `
  -IdentifierClaim $upnClaimMap.InputClaimType `
  -DefaultClientIdentifier $clientId `
  -MetadataEndPoint $metadataUrl `
  -Scope "openid profile"

9.2 Enable OIDC behavior on the trust

Set-SPTrustedIdentityTokenIssuer `
  -Identity $trustName `
  -UseStateToRedirect `
  -IsOpenIDConnect

10. Bind the SharePoint zone to the OIDC trust

$sptrust = Get-SPTrustedIdentityTokenIssuer -Identity $trustName
$trustedAp = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust
Set-SPWebApplication -Identity $waUrl -Zone Intranet -AuthenticationProvider $trustedAp

Verify:

Get-SPAuthenticationProvider -WebApplication $waUrl -Zone Intranet

Get-SPTrustedIdentityTokenIssuer -Identity $trustName |
  Select-Object Name, IdentityClaimTypeInformation, DefaultClientIdentifier, TrustedLoginMethod, UseStateToRedirect

The identity claim should point to:

• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

11. First sign-in

Browse to the OIDC SharePoint URL, for example:

• https://oidc.sharepoint.se

At first sign-in, SharePoint creates a trusted principal for the user.

Example:

• i:0e.t|fortifiedid24|[email protected]

If the user lands on AccessDenied.aspx, authentication has succeeded but the OIDC principal does not yet have permissions.

12. Build the correct SharePoint OIDC principal

Do not guess the encoded claims login name manually. Let SharePoint create it:

$principal = New-SPClaimsPrincipal `
  -Identity "[email protected]" `
  -TrustedIdentityTokenIssuer "FortifiedID24"

$principal.ToEncodedString()

Expected result:

i:0e.t|fortifiedid24|[email protected]

13. Grant permissions to the OIDC principal

$site = Get-SPSite "https://oidc.sharepoint.se"
$web = $site.RootWeb

$principal = New-SPClaimsPrincipal `
  -Identity "[email protected]" `
  -TrustedIdentityTokenIssuer "FortifiedID24"

$login = $principal.ToEncodedString()
$user = $web.EnsureUser($login)

$existing = $web.RoleAssignments | Where-Object { $_.Member.LoginName -eq $login }
if (-not $existing) {
    $role = $web.RoleDefinitions["Full Control"]
    $assignment = New-Object Microsoft.SharePoint.SPRoleAssignment($user)
    $assignment.RoleDefinitionBindings.Add($role)
    $web.RoleAssignments.Add($assignment)
    $web.Update()
}

$web.Dispose()
$site.Dispose()

14. Migrate existing users from AD FS to OIDC

If SharePoint previously used AD FS and now moves to OIDC, existing users in SharePoint still point to the old authentication provider.

That means:

• existing permissions still reference the old AD FS principal
• the new OIDC user signs in successfully
• but the user still gets access denied until permissions are rewritten

Use Move-SPUser to migrate the existing SharePoint user references.

Find the old and new login names

$site = Get-SPSite "https://oidc.sharepoint.se"
$web = $site.RootWeb

$web.SiteUsers |
  Where-Object { $_.LoginName -like "*anders_bjork*" } |
  Select-Object LoginName, Name

$web.Dispose()
$site.Dispose()

Build the new OIDC alias

$newAlias = (New-SPClaimsPrincipal `
  -Identity "[email protected]" `
  -TrustedIdentityTokenIssuer "FortifiedID24").ToEncodedString()

$newAlias

Move one user from AD FS to OIDC

$webUrl = "https://oidc.sharepoint.se"
$oldLogin = "i:05.t|adfs|[email protected]"
$newAlias = (New-SPClaimsPrincipal `
  -Identity "[email protected]" `
  -TrustedIdentityTokenIssuer "FortifiedID24").ToEncodedString()

$user = Get-SPUser -Identity $oldLogin -Web $webUrl
Move-SPUser -Identity $user -NewAlias $newAlias -IgnoreSid

Bulk-migrate users from AD FS to OIDC

Example CSV:

OldLogin,Upn
i:05.t|adfs|[email protected],[email protected]
i:05.t|adfs|[email protected],[email protected]

Example script:

$webUrl = "https://oidc.sharepoint.se"
$trustName = "FortifiedID24"
$mappings = Import-Csv "C:\Temp\adfs-to-oidc-users.csv"

foreach ($row in $mappings) {
    $newAlias = (New-SPClaimsPrincipal `
      -Identity $row.Upn `
      -TrustedIdentityTokenIssuer $trustName).ToEncodedString()

    $user = Get-SPUser -Identity $row.OldLogin -Web $webUrl -ErrorAction SilentlyContinue
    if ($user) {
        Move-SPUser -Identity $user -NewAlias $newAlias -IgnoreSid
    }
}

Always test with one user first.

15. Notes

Keep the following in mind:

1. Use a standard UPN claim URI as the SharePoint identifier claim.
2. Keep the id_token TTL at 60 minutes.
3. Assign permissions to the OIDC principal, not to the Windows principal.
4. If SharePoint is migrated from AD FS to OIDC, migrate the existing SharePoint user references as well.

16. References

• Set up OIDC authentication in SharePoint Server with Microsoft Entra ID
• New-SPClaimsPrincipal
• Move-SPUser
• Claims authentication doesn't validate user in SharePoint Server
• Plan for user authentication methods in SharePoint Server
• Plan alternate access mappings for SharePoint Server