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

Prejšnji članki o povezovanju SharePoint 2016/2019 in ADFS strežnika (1. del, 2. del in 3. del) so vsebovali predvsem postopke konfiguracije strežnikov za uspešen proces avtentikacije. V tem delu, pa bi rad izpostavil 2 težavi, ki se pojavita ob vklopu »Trusted identity provider« avtentikacije in to sta predvsem:

• Izbirnik imen (People picker).
• Iskanje.

Izbirnik oseb

Izbirnik oseb je v tem primeru problematičen, ker SharePoint ne zna preverjati oseb proti ADFS strežniku in ta naprej v Aktivni imenik, temveč poskuša po “Claims rules”, ki smo jih navedli v konfiguraciji, predvidevati, za kakšen tip objekta gre. Iz slike je razvidno, da SharePoint izbirnik oseb uspešno prepozna objekt, ne glede na to kaj vpišemo v polje za osebe.

V izbirniku oseb tudi lahko vidimo, da je SharePoint prepoznal 3 različne zapise za vnos:

• Zapis kot »UPN«.
• Zapis kot »Role«.
• Zapis kot »Email«.

Število zapisov, ki jih tukaj vidimo, je odvisno od konfiguracije »TrustedTokenIssuerja«:

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

V »claims mappings« vidimo, da SharePoint dobi podatke o »roleClaim«, »UPN claim« in »Email claim«. Če si v izbirniku potem izberemo enega od zapisov, je to potem za SharePoint povsem sprejemljiv vnos, čeprav tak zapis/objekt ne obstaja.

Rešitev

Na našo srečo je odprava te težave enostavna z dodatno rešitvijo, ki jo namestimo na strežnik. Na spletni strani Codeplex je med community rešitvami tudi »LDAP/AD Claims Provider For SharePoint« (https://ldapcp.codeplex.com/). Namestitev dodatka na strežnik nam omogoča, da zna naš TrustedIdentityTokenIssuer prepoznavati uporabnike iz našega aktivnega imenika, čeprav se avtentikacija še vedno vrši prek ADFS strežnika.

Po namestitvi paketa WSP na SharePoint strežnik je pomembno, da »Claims provider« tudi uspešno registriramo z našim »TrustedIdentityTokenIssuerjem«, kar moramo seveda narediti v PowerShellu.

$tp = Get-SPTrustedIdentityTokenIssuer –Identity "ADFS30"
$tp.ClaimProviderName="LDAPCP"
$tp.Update()

Po konfiguraciji TrustedTokenIssuerja se v izbirniku oseb zapisi začnejo prikazovati drugače:

V tem primeru sedaj vidimo, da se pri vnosu npr.: Robi, izpišejo samo vrednosti, ki se uspešno razrešijo v aktivnem imeniku. S tem dodatkom potem ni več težav, da bi se v SharePointu razreševali uporabniki, ki ne obstajajo v vašem aktivnem imeniku.

Iskanje

Pri kakršnikoli konfiguraciji SharePoint strežnika, kjer se za default cono ne uporablja Windows avtentikacija ali pa se uporablja več načinov avtentikacije, je indeksiranje lahko problematično. Iskanje se namreč potem ne zna pravilno avtenticirati na SharePoint spletno mesto. V tem primeru se je potrebno poslužiti dodatnih nastavitev web aplikacije, in sicer je potrebno narediti »Extend«.

Kadar naredimo Extend web aplikacije je zelo pomembno, da »default« vedno ostane z Windows avtentikacjo, medtem ko lahko ostale instance uporabljajo druge metode, in sicer zaradi samega delovanja iskanja. Če tega ne naredimo tako in indeksiramo vsebino, ki ni na default AAM, potem se lahko pojavijo težave pri uporabi iskanja.

V našem primeru sem tako ustvaril novo instanco web aplikacije, izklopil Windows avtentikacijo in nastavil samo »Trusted Identity provider«.

Kar se pri »Extendu« zgodi je, da se ustvari nov »web site« v IIS-u, ki kaže na isto vsebinsko bazo.

Nato je potrebno spremeniti še »default« cono, ki ima trenutno vklopljena 2 načina avtentikacije, in sicer bomo na default coni izklopili »Trusted Identity provider« in pustili samo Windows avtentikacijo.

Pozabiti pa seveda ne smemo na konfiguracijo ADFS strežnika, saj je v konfiguraciji »Relying Party Trust« naveden URL, na katerega nas preusmeri ADFS strežnik po uspešni avtentikaciji.

Če je bila vsa konfiguracija uspešno izvedena, imamo sedaj polno delujoče SharePoint mesto, ki za avtentikacijo uporablja SAML. Tukaj se vam seveda odpre nešteto opcij, saj sedaj lahko uporabljate za dostop do vašega SharePoint portala tudi dvo-faktorsko avtentikacijo ali »MFA«.

S tem smo tudi prišli do konca serije člankov o povezovanju SharePoint in ADFS strežnika. Obstajajo sicer še določeni scenariji, ki jih tu nismo obravnavali in o katerih se seveda pogovorimo na tečajih, ki jih izvajamo na našem podjetju.