Dzisiaj będzie z gatunku tecznicznego problemów rozwiązywania. I nie będzie użycia Network Monitor, chociaż kilka przykładów gdzie się przydał do rozwiązania problemu w międzyczasie się nazbierało.
… problem
W ramach jednego z projektów wdrożyliśmy u Klienta swoje rozwiązanie, mające na celu wprowadzenie porządku w ramach średniej farmy Sharepoint (ok 2.5tys "sajtów”). Cel projektu prosty i zdefiniowany:
- Zautomatyzować zarządzanie cyklem życia takiego “sajtu” od początku po jego archiwizację
- Zapanować nad uprawnieniami użytkowników, aby użytkownicy według określonych przez biznes reguł uzyskiwali dostęp do odpowiednich witryn.
Projekt miły, przyjemny, zagraniczny – zapewne o nim więcej niedługo pojawi się na stronach firmowych.
Ale ja nie o tym … jak wspomniałem powyżej, jednym z celów projektu było zapanowanie nad uprawnieniami użytkowników i automatyczne nimi zarządzanie. Już po wdrożeniu projektu na środowisku produkcyjnym, pojawił się problem na środowisku “przed produkcyjnym”, stejdżingiem popularnie zwanym.
*** mały wtrent ***
Tak z czystej ciekawości, ilu z czytelników posiada u siebie, albo jeżeli wdraża rozwiązania u Klientów to klient posiada środowiska osobne służące developmentowi, testowaniu i wdrażaniu rowiązania przed puszczeniem go na produkcję? Komentarze otwarte.
*******
Problem objawił się tym, że użytkownicy, pomimo członkostwa w odpowiednich grupach i przypisania tych grup do odpowiednich ról w ramach Sharepoint, nie mogli uzyskać dostępu do odpowiednich witryn, a przez to również niepoprawnie działały niektóre z umieszczonych tam web parts (czy na to jest polskie określenie?). Tutaj zaznaczyć należy, że oczywiście wcześniej wszystko działało – a jakże, inaczej na produkcję by nie poszło.
Stejdżing niby nie produkcja, ale służy testowaniu poprawek przed wdrożeniem i samego ich wdrożenia przed pójściem na produkcję, a zachowanie takie to testowanie skutecznie utrudniało. Nie pozostało nic jak tylko zakasać wirutalne rękawy, VPN, RDP … i do dzieła.
… analiza
Już przy pierwszych rozmowach sugerowałem potencjalną istotę problemu, głównie sugerując się tym że całe środowisko jest zwirtualizowane. A problem jak to problem, bez przyczyny nie powstaje.
Jeżeli wcześniej działało, użytkownik jest w dobrych grupach, które są przypisane do witryn Sharepoint poprawnie, a pomimo to nie działa to gdzieś musiało się coś zmienić lub musi gdzieś tkwić przyczyna.
Jedną z potencjalnych przyczyn, mógłby być rozmiar tokenu użytkownika, ale to w prosty sposób zostało zweryfikowane i wykluczone.
Więc co … jeżeli użytkownik jest w odpowiedniej grupie, a grupa przypisana do uprawnień w Sharepoint … to pytanie (parafrazując kabaret) czy moja grupa i grupa Sharepoint to my.
… eksperyment
Weźmy grupę SG1 w Active Directory, która została przypisana do uprawnienia w ramach witryny Sharepoint. W takim wypadku, grupa ta staje się członkiem odpowiedniej grupy istniejącej w Sharepoint (grupy w Sharepoint w zasadzie na nazwę grupy nie zasługują z perespetywy człowieka zajmującego się usługą katalogową, ale to może też temat na wpis na przyszłość). W takim wypadku, po stronie Sharepoint utworzony zostanie dla grupy SG1 odpowiedni obiekt SPUser, który zostanie przypisany do grupy. To że reprezentuje on odpowiednią grupę z AD możemy sprawdzić łatwo, wyświetlając SID z AD i z Sharepoint.
A teraz popsujmy to … na ten przykład usuńmy grupę SG1 z Active Directory i sprawdźmy co też wyświetli nam nasz SPUser przypisany do uprawnienia w ramach witryny.
Nic takiego się nie stało – w końcu tej grupy i tak już nie ma, a pozostał odpowiedni wpis na uprawnieniach – w ramach systemu plików mamy podobne zachowanie.
To teraz skomplikujmy rzecz trochę – załóżmy grupę SG1 ponownie w Active Directory, co też wygeneruje nam nowy SID. A teraz grupie SG1 przypiszmy ponownie uprawnienia w ramach tej witryny Sharepoint. Sprawdźmy …
… I mamy swojego winnego. Niby to samo, a jednak nie to samo.
… przyczyna
Jak widać SID w Sharepoint i SID w AD po takiej operacji się nie zgadzają. Dlaczego? Ano dlatego, że w chwili gdy dodajemy grupę po raz pierwszy do witryny Sharepoint w Sharepoint zostaje zapamiętany jej SID przypisany do danej grupy Sharepoint.
SID ten nie jest zmieniany, jeżeli zmieni się on w AD. I to jeszcze nie jest problem, bo w zasadzie dlaczego by się miał zmienić. Problemem jest to, że w przypadku, gdy taka grupa w AD zostanie utworzona od nowa i zmieni jej się SID, to nawet jeżeli usuniemy I dodamy ją ponownie do tej samej witryny, Sharepoint nie uaktualni SID po swojej stronie. Efektywnie więc będziemy mieli grupę, która ma taką samą nazwę, poprawnie rozwiązuje się we wszystkich wizualnych miejscach w Sharepoint, ale tak naprawdę reprezentuje inną grupę niż ta, która faktycznie istnieje w Active Directory.
Czy to samo dotyczy użytkownika – zobaczmy? Użytkownik istnieje w AD i posiada uprawnienia w Sharepoint.
Kasujemy użytkownika, usuwamy go z grupy Sharepoint, nadajemy uprawnienia Sharepoint ponownie i …
Dane które prezentuje Sharepoint, i którymi posługuje się przy ewalucji uprawnień pochodza z obiektu SPUser, który nie odświeża się w przypadku, gdy nadajemy uprawnienie kontu z AD o tej samej nazwie, ale z innym SID – czyli tak naprawdę innemu konto w AD.
Czyli jeżeli już mieliśmy użytkownika jkruk w organizacji, a następnie założyliśmy takiego samego, to pomimo że na uprawnieniach SP widziamy jego nazwę, to może niekoniecznie być ten sam użytkownik.
A rozwiązanie naszej zagadaki, czyli co wywołało problem? Po prostu grupy zostały usunięte z AD i ponownie założone, a informacja o tym nie została odświeżona na Sharepoint.
… rozwiązanie
A reszta to już skrypt w Powershell, który te obiekty SPUser skoryguje.
Lub odpowiednie rozwiązanie do zarządzania uprawnieniami w ramach Sharepoint … ale to już w ramach działan komercyjnych.
I kolejny problem rozwiązany.