Povezovanje SharePoint 2016/2019 in ADFS strežnika – 3. del

V prejšnjem članku sem opisal, kaj je potrebno narediti na strani ADFS strežnika za uspešno avtentikacijo SharePoint strežnika. V tokratnem članku bomo zgodbo nadaljevali s postopkom konfiguracije na SharePoint strežniku.

Vzpostavitev zaupanja

Za uspešno vzpostavitev zaupanja med ADFS strežnikom in SharePoint strežnikom moramo na SharePoint strežnik uvoziti certifikat, ki ga ADFS uporablja za podpis avtentikacijskih žetonov. Če gre za javno overjene certifikate, navadno ni treba uvoziti tudi root certifikata, v primeru, da gre za self-signed certifikat, pa je potrebno uvoziti isti certifikat še kot root certifikat.

Skripta za uvoz certifikatov je naslednja:

$adfsLogon="https://sts.kompas-xnet.si/adfs/ls/"
$signCertPath="C:\Users\sp13_farm_admin\Desktop\Certi\ADFS-TokenSigning.cer"
$rootCertPath="c:\temp\rootCert.cer"
$webAppName="adfslogin"


$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($rootCertPath)
New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$signingCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($signCertPath) 

Mapiranje »claimov«

Pri mapiranju »claimov« je potrebno biti pozoren na konfiguracijo, ki smo jo izvedli na ADFS strežniku. Preveriti moramo, katere claime nam bo ADFS strežnik poslal in jih tudi ustrezno navesti v naši konfiguraciji. Edini način kako to narediti je seveda s PowerShellom:

# Claim type mapping
$roleClaim = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$EmailClaim = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName "Email Address" –SameAsIncoming

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

Kreiranje novega »Trusted token issuerja«

Da bi SharePoint vedel, da ima na voljo tudi nov način avtentikacije, moramo ADFS login tudi registrirati. Skripta, ki jo bomo uporabili, se v veliki meri navezuje tudi na prejšnje ukaze, ki smo jih že izvedli.

$defaultRealm = "urn:sharepoint:$webAppName"
$signinurl = $adfsLogon
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS30" `
                    -Description "ADFS 3.0 Federated Server" `
                    -Realm $defaultRealm `
                    -ImportTrustCertificate $signingCert `
                    -ClaimsMappings $roleClaim, $EmailClaim, $upnClaimMap `
                    -SignInUrl $signinurl `
                    -IdentifierClaim $upnClaimMap.InputClaimType

Ko izvedemo ukaz za ustvarjanje novega »Trusted Identity Token issuerja«, lahko novo konfiguracijo že preverimo v PowerShellu.

Get-SPTrustedIdentityTokenIssuer

Get-SPTrustedTokenIssuer nam vrne konfiguracijo našega authentication providerja, kjer lahko tudi razberemo katere »Claime« bomo uporabili za identifikacijo uporabnika. V našem primeru je to »UPN«, »Role«, »Email Address«.

Iz slike lahko razberemo, da nimamo registriranih nobenih »ProviderRealms«, se pravi nimamo registriranih nobenih »Web Appov«, ki bi lahko izkoriščali ADFS za avtentikacijo. V tem primeru se vsi Web Applicationi, ki imajo vklopljeno avtentikacijo z ADFS, predstavijo kot »urn:sharepoint:adfslogin«. Če bi želeli imeti bolj podrobno kontrolo nad našimi web aplikacijami, lahko vsako web aplikacijo posebej registriramo, v tem primeru pa moramo biti pozorni tudi na to, da na ADFS strežniku ustrezno ustvarimo/nastavimo pravila.

Registracija »Web Application«

Za uspešno registracijo web aplikacije, moramo izvesti še nekaj vrstic PowerShell kode. Navesti moramo spletni naslov naše web aplikacije in navesti še, na kakšen način se bo ta web aplikacija identificirala na ADFS strežniku.

#Add URL and REALM to token issuer
$tp = Get-SPTrustedIdentityTokenIssuer –Identity "ADFS30"
$uri = new-object System.Uri("https://adfslogin.kompas-xnet.si")
$tp.ProviderRealms.Add($uri, "urn:sharepoint:adfslogin")
$tp.Update()

Po izvedenem ukazu, lahko ponovno poženemo ukaz:

Get-SPTrustedIdentityTokenIssuer

Rezultat se sedaj izpiše v naslednji obliki:

Nastavitev Authentication Providerja

V Centralni Administraciji lahko sedaj na naši web aplikaciji vklopimo tudi avtentikacijo z ADFS.

Označimo web aplikacijo in na traku kliknemo Authentication Providers:

V tem primeru imamo na izbrani web aplikaciji samo »Default« cono. O tem kaj to pomeni oz. kakšne omejitve nam to predstavlja, bom več povedal v naslednjem članku. Izberemo »Default« in vklopimo »Trusted Identity Provider« in »ADFS30«.

Potrdimo z OK.

Preizkus delovanja

Ker imamo v našem primeru možnost avtentikacije na 2 različna načina, nam tudi pri odpiranju strani ponudi avtentikacijo s sistemom Windows ali pa naš ADFS30.

Če izberemo ADFS30, nas SharePoint preusmeri na ADFS strežnik, kjer lahko vpišemo svoje poverilnice in se avtenticiramo. Če si dobro pogledamo URL naslov, na katerega smo bili preusmerjeni, bomo opazili, da je kot parameter definiran tudi »realm« v obliki: »wtrealm=urn%3asharepoint%3aadfslogin«.

Uspešno smo se avtenticirali s pomočjo ADFS strežnika na SharePoint. Žal pa to še ni vse, kar moramo urediti, da bodo vse stvari delovale in da bodo uporabniku prijazne. Kar moramo popraviti so še nastavitve iskanja in pa izbirnik oseb. Zato ne spreglejte naslednjega članka!