Pri delu s strankami se veliko pogovarjam in ukvarjam z načrtovanjem ter uvajanjem naprednih SharePoint funkcij in izvedenih rešitev. Danes se bom dotaknil stare teme, ki se je nedavno izkazala za še vedno zelo perečo (isto vprašanje iz dveh različnih naslovov v enem tednu je zame dovolj velik vzorec) in si kot taka zasluži svoj zapis.

Predstavljajte si naslednji scenarij. V podjetju opravljate delo IT-administratorja in pravkar ste dobili zahtevo, da Jože iz oddelka Poslovno poročanje potrebuje uredniški dostop do prodajnega portala. Jože bo namreč odgovoren za pripravo naprednih analiz »What-if« za izbrani produkt na izbranem trgu, zato potrebuje takojšen dostop do vse dokumentacije. Naj omenim še dvoje, in sicer da je zahtevo oddal direktor oddelka Prodaje, spletno mesto z dokumentacijo pa je postavljeno na platformi SharePoint.

»Enostavno«, si mislite, »vse, kar moram narediti, je umestiti Jožeta v skupino v aktivnem imeniku (Active directory) PORTAL – SALES – EDITOR, za vse ostalo bo poskrbel SharePoint«. To seveda storite takoj in zadovoljni, ker ste opravili delo dobro, označite zahtevo kot zaključeno…

Preseneti opis o pomanjkanju dostopa

Informacija o urejenem dostopu hitro zaokroži do Jožeta, ki se – neučakan kot Jože je – hiti prijaviti na prodajni portal. Namesto dokumentov ga preseneti znano SharePointovo okno, ki naznanja, da uporabnik nima pravice dostopanja do želenih vsebin: Let us know why you need access to this site.

Jože debelo pogleda, nato prekolne nesposobne IT-jevce, po nekaj trenutkih pa zavrti telefon in pokliče direktorja oddelka prodaje, da zadeve ne štimajo in da še vedno nima dostopa. Direktor seveda takoj urgira in pošlje odgovor na zahtevo, pri čemer ne pozabi dodati vsaj štirih klicajev, rdeče obarvanega besedila z rumenim ozadjem ter besede URGENTNO. Naj zgodbico na tej točki ustavim, saj orošeno čelo IT-administratorja ni nekaj, kar potrebuje dodatno razlago.

Kaj je šlo narobe?

Dobra praksa pravi, da je urejanje pravic uporabnikov najbolje izvajati preko skupin aktivnega imenika in tega se večina drži. Kot vsaka stvar v življenju ima tudi ta praksa svoje posebnosti, ki so zavedene v t.i. »small printu«. V primeru SharePointa in dodeljevanja pravic skozi skupine aktivnega imenika (AD) je potrebno vedeti sledeče:

  • Članstvo uporabnika v AD skupinah se posodobi, ko se uporabnik prijavi v računalnik, ki je del AD domene.
  • SharePoint privzeto osvežuje varnostne žetone na vsakih 10 ur. Žeton vsebuje informacije o članstvu uporabnika v AD skupinah. SharePoint oziroma natančneje Security Token Service hrani varnostne žetone v predpomnilniku prvih deset ur.  

Nepoznavanje teh dveh omenjenih točk povzroči zadrego, ki se je zgodila Jožetu iz našega primera. Ker želimo Jožetu takoj omogočiti dostop do dokumentacije, se po navadi zatečemo k rešitvi, ki preverjeno deluje. Jožetu dodelimo uredniške pravice neposredno, s tem pa zavedno obidemo dobro prakso – ki ji sicer želimo slediti. En Jože še ni problem, predstavljajte pa si, kako bo izgledala vaša varnostna shema na SharePointu po ugoditvi dostopov stotim Jožetom.

Rešitev

K sreči je mogoče čas trajanja veljavnosti varnostnega žetona zmanjšati. V ta namen je potrebno ustrezno konfigurirati Security Token Service preko SharePoint Management Shell konzole. Ukazi, ki si sledijo so:

$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = (New-TimeSpan -minutes <število minut, npr. 5>)
$sts.WindowsTokenLifetime = (New-TimeSpan -minutes <število minut, npr. 5>)
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes <število minut, npr. 1>)
$sts.Update()
iisreset

Pri tem bodite ekstremno pozorni, da sta vrednosti FormsTokenLifetime in WindowsTokenLifetime večji od LogonTokenCacheExpirationWindow. V kolikor nista, bo žeton postal neveljaven takoj po njegovi osvežitvi, posledično pa bo prijava prenehala delovati za vse uporabnike SharePointa. Če se to zgodi, mi lahko verjamete,  da direktor prodaje ne bo edini, ki bo prijel telefon v roke 🙂

AVTOR
Žarko Višekruna

Žarko Višekruna

Solution Delivery Manager
OCENITE ZAPIS