Notatki z pracy inżyniera IT

W przeglądarkach opartych na silniku Chromium (przynajmniej) do 14 lipca 2021 roku, mają być udostępniane polityki ustawień zgodności wstecznej (Cookie Legacy SameSite Policies). 

Jak je zaaplikować na komputerach w przedsiębiorstwie? Prawie zawsze pierwszym wyborem będzie dystrybucja odpowiednich ustawień za pomocą ustawień zasad grup. 

W tym celu należy pobrać właściwe dla zarządzanej przeglądarki szablony administracyjne:

Microsoft Edge — do pobrania z witryny Edge for Business. 

Google Chrome — do pobrania z witryny Chrome browser for enterprise.

Mozilla Firefox — do pobrania z witryny  Policy templates for Firefox.

Pobrane szablony należy zainstalować w folderze PolicyDefinition magazynu szablonów (najlepiej centralnego). Nie ma sensu instalować niczego „na zapas”. Jeśli w danej chwili nie używacie i nie ma potrzeby konfiguracji ustawień dla jakiegoś programu, nie instalujecie też jego szablonów. 

W Edge i Chrome można użyć dwóch różnych opcji:

LegacySameSiteCookieBehaviorEnabled — Umożliwia globalne przywrócenie poprzedniego trybu obsługi SameSite dla plików cookie. Powoduje to, że pliki cookie, które nie określają atrybutu SameSite, są traktowane tak, jakby były ustawione z parametrem „SameSite = None”. Jednocześnie usuwa wymóg, aby pliki cookie „SameSite = None” nosiły atrybut „Secure” i pomija porównanie schematów podczas oceny, czy dwie witryny to ta sama witryna.

Ustawienie może przyjąć dwie wartości:

DefaultToLegacySameSiteCookieBehavior = 1 

Przywróć starsze zachowanie SameSite dla plików cookie we wszystkich witrynach.

DefaultToSameSiteByDefaultCookieBehavior = 2

Użyj domyślnego zachowania SameSite dla plików cookie we wszystkich witrynach.

LegacySameSiteCookieBehaviorEnabledForDomainList — Analogiczne ustawienie, ale aplikowane do witryn działających w określonych domenach. Zdecydowanie lepsza opcja, zawężająca stosowanie poprzednich ustawień do adresów wybranych aplikacji webowych. 

Ustawienia można skonfigurować w GPMC w „Administrative Templates/Microsoft Edge/Content settings” pod nazwami „Enable default legacy SameSite cookie behavior setting" oraz „Revert to legacy SameSite behavior for cookies on specified sites”. 

Technicznie ustawienia są mapowane na klucze rejestru LegacySameSiteCookieBehaviorEnabled w    SOFTWARE\Policies\Microsoft\Edge oraz 1 i kolejne pozycje z listy w    SOFTWARE\Policies\Microsoft\Edge\LegacySameSiteCookieBehaviorEnabledForDomainList.

Obecnie, Firefox nie dostarcza analogicznych ustawień w szablonach zasad grup. Ewentualne zmiany należy zaaplikować inną metodą (mozilla.cfg, policies.json, autoconfig) lub bezpośrednio w edytorze konfiguracji. 

Dodawanie konta i uzyskiwanie dostępu do zasobów szkolnych

W systemie Windows 10 możliwe jest trwałe połączenie z kontem szkolnym, co pozwala na uzyskiwanie bezproblemowego dostępu do takich zasobów jak poczta e-mail, dysk w chmurze, zespoły klasowe i innych. Powiązanie komputera z miejsce nauki umożliwia jednokrotne logowanie w ulubionych aplikacjach, przez co ich instalacja, logowanie i użytkowanie staje się prostsze, a dostęp do danych automatyczny.

Aby uzyskać dostęp do miejsca nauki, należy postępować zgodnie z poniższą instrukcją.  

1.     Z menu Start należy przejść do Ustawień, a następnie do grupy ustawień Konta i opcji Uzyskaj dostęp do miejsca pracy i nauki.

2.     Należy wybrać Połącz, aby uruchomić kreator logowania za pomocą konta szkolnego w usłudze Office 365.

3.     W kreatorze logowania należy podać identyfikator użytkownika w usłudze Office 365, najczęściej jest on zgodny z adres e-mail lub identyfikatorem stosowanym w e-dzienniku oraz poprawnie wprowadzić hasło.

4.     Zakończ pracę z kreatorem, klikając w przycisk Gotowe.

5.     Skonfigurowane konto powinno być widoczne na liście, będzie można z niego korzystać w sklepie Microsoft Store oraz aplikacjach Office.

Logowanie w sklepie Microsoft Store

Instalacja aplikacji bezpłatnych nie wymaga utworzenia ani logowania za pomocą konta. Logowanie w sklepie Microsoft Store jest opcjonalne, ale zalecane. Użytkownicy zalogowani zachowują historię zainstalowanych aplikacji, dzięki czemu możliwe jest przywracanie wcześniejszych aplikacji na nowych urządzeniach lub po świeżej instalacji systemu Windows. Możesz używać swojego dotychczasowego konta konsumenckiego, służbowego lub szkolnego albo użyć nowego konta skonfigurowanego we wcześniejszych krokach, w tym celu postępuj zgodnie z poniższymi krokami.

1.     Uruchom sklep Microsoft Store i rozwiń menu konta, klikając w przycisk w prawej części menu.

2.     Po zalogowaniu można kontynuować instalację zalecanego zbioru aplikacji.

Zalecany zbiór aplikacji[1]

Wyświetlaj, twórz i edytuj dokumenty, arkusze kalkulacyjne, prezentacje i nie tylko dzięki aplikacjom pakietu Office zaprojektowanym dla urządzeń przenośnych i tabletów z systemem Windows.

Word

Word Mobile[2]  pozwala przeglądać, edytować i tworzyć dokumenty.  

ms-windows-store://pdp/?ProductId=9wzdncrfjb9

Excel

Excel Mobile[3]  umożliwia przeglądanie, aktualizowanie i tworzenie arkuszy  kalkulacyjnych.

ms-windows-store://pdp/?ProductId=9wzdncrfjbh3

PowerPoint

PowerPoint Mobile[4]  to aplikacja do przeglądania, dostarczania i tworzenia prezentacji.

ms-windows-store://pdp/?ProductId=9wzdncrfjb5q

Outlook

Outlook Mobile[5]  ułatwia bieżącą kontrolę nad wiadomościami e-mail, zarządzanie harmonogramem  i pozostawanie w kontakcie z najważniejszymi osobami.

ms-windows-store://pdp/?ProductId=9wzdncrfhvqm

OneNote

OneNote[6]  to notes cyfrowy umożliwiający gromadzenie i porządkowanie dowolnych  informacji na wszystkich swoich urządzeniach.

ms-windows-store://pdp/?ProductId=9wzdncrfhvjl

OneDrive

OneDrive[7]  oferuje dostęp do swoich dokumentów, zdjęć i innych plików oraz udostępniaj  je z telefonu lub komputera, z których korzystasz.

ms-windows-store://pdp/?ProductId=9wzdncrfj1p3

Office Lens

Office Lens[8]  przycina i ule-psza obrazy tablic oraz doku-mentów, a także sprawia, że stają  się one czytelne. Skanowane obrazy możesz zapisywać w programie OneNote  lub usłudze OneDrive.

ms-windows-store://pdp/?ProductId=9wzdncrfj3t8

Whiteboard

Whiteboard[9] to  cyfrowa tablica, do pracy z czło-nkami zespołu nad pomysłami i interaktywną  zawartościom.

ms-windows-store://pdp/?ProductId=9mspc6mp8fm4

Instalacja aplikacji biurowych za pomocą Microsoft Store

Wskazany we wcześniejszej sekcji zbiór zalecanych aplikacji jest dostępny bezpłatnie dla użytkowników Windows, a jego instalacja w systemie Windows 10 odbywa się za pomocą sklepu Microsoft Store. Aby rozpocząć instalację, kliknij w odnośnik Zainstaluj pod opisem aplikacji na powyższej stronie, co otworzy kartę informacyjną aplikacji w sklepie Microsoft Store.

Poszczególne odnośniki prowadzą do kolejny kart informacyjnych, postępuj zgodnie z poniższą instrukcją dla każdej aplikacji, aby zainstalować wszystkie rekomendowane aplikacje. Pamiętaj, niektóre aplikacje mogą być już zainstalowane lub pochodzić z instalacji domyślnej.

1.     Wykorzystując przycisk instalacyjne z sekcji Zalecanego zbioru aplikacji, otwórz karty informacyjne kolejnych programów i przeprowadź ich instalację w sklepie Microsoft Store. Wszystkie instalowane programy można przypiąć do menu Start, dzięki czemu będzie je można łatwo uruchomić ze skrótów wyświetlanych w menu.

2.     Na karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu Word Mobile.  

3.     Na kolejnej karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu Excel Mobile.

4.     Na kolejnej karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu PowerPoint Mobile.

5.     Na kolejnej karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu Outlook Mobile.

6.     W aktualnej wersji Windows 10 nie trzeba instalować aplikacji OneDrive ze sklepu Microsoft Store. Zamiast tego należy wykorzystać aplikację OneDrive wbudowaną w systemie. W tym celu rozwiń listę aplikacji działających w tle za pomocą przycisku w zasobniku systemowym. Następnie wybierz ikonę programu OneDrive.  Wbudowana aplikacja jest nowsza i nie ma potrzeby instalacji z Microsoft Store.

W wersjach pozbawionych wbudowanego programu OneDrive oraz starszych wersjach systemu Windows instalację należy przeprowadzić z użyciem sklepu Microsoft Store lub instalatora dystrybuowanego na stronie programu OneDrive[10].

7.     Niektóre aplikacje mogą już być zainstalowane, np. OneNote. Wówczas należy upewnić się, czy posiadamy najnowszą wersję i w razie potrzeby zaktualizować oprogramowanie do najnowszej wersji, rozwijając przycisk opcji dodatkowych i wybierając Aktualizuj.  

8.     Na kolejnej karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu Office Lens.

9.     Na kolejnej karcie informacyjnej aplikacji, kliknij przycisk Pobierz, aby rozpocząć instalację programu Whiteboard.

Instalacja komunikatora i programu do pracy grupowej Teams

Microsoft Teams dla Windows jest dystrybuowany w postaci bezobsługowego pakietu instalacyjnego, wystarczy go pobrać z właściwej witryny i uruchomić, aby zainstalować aplikację. Poniżej opisano jak wykonać niezbędne kroki.

1.     W przeglądarce internetowe otwórz adres URL https://aka/ms/getteams.

2.     Pobrany plik można uruchomić z paska pobierania lub otwierając folder docelowy, zazwyczaj jest nim folder Pobrane.

3.     Po zakończeniu pracy instalator samodzielnie uruchomi zainstalowany program Teams, który poprosi użytkownika o zalogowanie się. Wskazówki dotyczące logowania zostały opisane w dalszej części poradnika. W tej chwili można zamknąć program Teams, a ikonę programu przypiąć do obszaru startowego w menu Start, co również opisano w dalszej części poradnika.

Instalacja przeglądarki internetowej Edge

Wszystkie aplikacje i usługi Office 365 dla Edukacji dostępne są także przez przeglądarkę internetową. Aby zapewnić najlepszą współpracę aplikacji webowych, zalecana jest instalacja najnowszej przeglądarki Microsoft dla Windows oraz urządzeń mobilnych z systemami Android i iOS. Poniższa instrukcja zawiera kroki niezbędne do instalacji najnowszej wersji Microsoft Edge w systemie Windows 10.

1.     W przeglądarce internetowe otwórz adres URL https://aka.ms/getedge.

2.     Pobrany plik można uruchomić z paska pobierania lub otwierając folder docelowy, zazwyczaj jest nim folder Pobrane. Proces instalacji przebiega automatycznie, a po jego ukończeniu uruchamiana jest nowo zainstalowana przeglądarka internetowa.

3.     Jeśli w systemie zainstalowano inne przeglądarki internetowe, warto ustawić Edge jako domyślną. W tym celu należy przejść do Ustawień, następnie Aplikacje i Aplikacje domyślne, gdzie można wskazać Przeglądarkę sieci Web.

Dzięki powyższym zmianom wszystkie strony i aplikacje webowe będą otwierane w przeglądarce Microsoft Edge.

4.     Microsoft Edge umożliwia zaimportowanie ustawień z poprzednio używanej przeglądarki[11], w tym zapamiętanych zakładek i haseł, a także historii przeglądanych witryn i pobranych plików czy otwartych kary, a nawet informacje dotyczące metod płatniczych.

Zorganizuj zainstalowane aplikacje w menu Start

Po zainstalowaniu nowych aplikacji zostaną one wyróżnione w menu Start, a na pulpicie pojawi się dodatkowe powiadomienie.

W zależności od preferencji użytkownika menu Start może prezentować programy jako listę wszystkich aplikacji oraz grupy aplikacji przypiętych. Przypinanie aplikacji do menu Start oraz paska zadań ułatwia dostęp w przyszłości, w szczególności, jeśli na komputerze zainstalowanych jest wiele aplikacji.   

Aby zminimalizować menu Start do własnych grup aplikacji i przypiąć zainstalowane wcześniej aplikacje należy wykonać następujące czynności.

1.     Z menu Start przejdź do ustawień za pomocą przycisku , a następnie w oknie Ustawień do Personalizacja i dalej do Start.

2.     Przypnij zainstalowane aplikacje do menu Start. W tym celu rozwiń listę aplikacji, znajdź pożądaną aplikację, np. OneNote i kliknij prawym przyciskiem myszy, następnie z menu opcji wybierz Przypnij do obszaru startowego. Operację powtórz dla wszystkich aplikacji.

3.     Przypinane aplikacje warto zorganizować w grupę, co dodatkowo wyróżni aplikacje związane z Office 365. W tym celu kliknij pustą belkę tytułową grupy i wprowadź nową nazwę, a następnie zatwierdź, wciskając klawisz Enter na klawiaturze.

Twoje wirtualne biurko zostało przygotowane, teraz możesz zacząć pracę z zainstalowanymi programami oraz używać zasobów szkolnych w ramach subskrypcji Office 365 dla Edukacji. W dalszej części poradnik znajdziesz instrukcje dotyczące pierwszego uruchomienia oraz logowania w zainstalowanych aplikacjach.

Logowanie kontem szkolnym w aplikacjach

Dostarczone przez szkołę lub uczelnię konto w usłudze Office 365, należy dodać na komputerze zgodnie z instrukcją zawartą we wcześniejszym rozdziale (patrz Dodawanie konta i uzyskiwanie dostępu do zasobów szkolnych). Dzięki zainstalowaniu konta będzie można je wskazać w aplikacjach z obsługą kont firmowych oraz szkolnych, bez konieczności indywidualnego logowania w poszczególnych aplikacjach. Poniżej znajduje się zestaw instrukcji, opisujących krok po kroku logowanie w zalecanych aplikacjach.

Logowanie w programie OneDrive

Zalogowanie się w programie OneDrive pozwoli na uzyskiwanie dostępu do osobistych i szkolnych zasobów plikowych przechowywanych lub współdzielonych pomiędzy użytkownikami usługi Office 365 w twojej szkole lub uczelni. Dodatkowo synchronizację wszystkich lub wybranych plików pomiędzy magazynem danych w chmurze oraz twoim komputerem i telefonem. Dzięki czemu w prosty i wygodny sposób można przenosić pliki i wgrywać je do notesów zajęć, załączać w zadaniach domowych czy w czasie spotkań lub czatów zespołowych.

Wszystkie inne programy usługi Office 365 korzystają z plików i folderów zmagazynowanych w usłudze OneDrive, dlatego logowanie i konfigurację aplikacji na komputerze warto rozpocząć właśnie od programu OneDrive. Poniżej znajduje się instrukcja przedstawiająca krok po kroku, jak zalogować się oraz skonfigurować program OneDrive.

1.     Z menu Start uruchom aplikację OneDrive, a następnie w kreatorze konfiguracji OneDrive wprowadź identyfikator logowania w usłudze Office 365. Podczas logowania program skorzysta z wcześniej przypisanego konta szkolnego (nie będzie wymagał powtórnego wprowadzenia hasła), a następie będzie wymagał zatwierdzenie położenia folderu usługi OneDrive na dysku.

Domyślnie folder usługi tworzony jest w profilu użytkownika i zawiera nazwę szkoły. Gwarantuje to prywatność plików, gdyż inni użytkownicy komputera nie mają dostępu do plików prywatnych w profilach innych kont. Jeśli z jakichś względów wymagana jest zmiana położenia folderu, należy kliknąć Zmień lokalizację i wskazać niestandardowy folder. W przeciwnym razie wystarczy kliknąć Dalej.  

2.     Bezpośrednio po zalogowaniu OneDrive wyświetli krótki przegląd funkcji oraz zaoferuje instalację aplikacji na telefonie (aby oba urządzenia były ze sobą zsynchronizowane i umożliwiały dostęp do danych).

3.     OneDrive poinformuje o zsynchronizowaniu plików, które przeglądać można bezpośrednio w Windows Explorerze.

Logowanie w przeglądarce internetowej Edge

Z wszystkich aplikacji i usług Office 365 można korzystać w przeglądarce internetowej. Połączenie profilu przeglądarki z kontem szkolnym włącza automatyczne logowanie w kompatybilnych witrynach, aplikacjach i portalach. Dodatkowo pozwala na synchronizację ustawień, dzięki czemu po zalogowaniu się na innym komputerze, np. w szkolnej pracowni informatycznej, użytkownik ma dostęp do swoich zakładek, haseł czy historii przeglądania. Aby powiązać profil przeglądarki z kontem szkolnym, należy wykonać następujące kroki w programie Microsoft Edge.

1.     Z menu głównego należy rozwinąć meny ustawień profilowych za pomocą przycisku i wybrać opcję Zaloguj.

2.     Po uruchomieniu powiązania profilu z kontem przeglądarka zaoferuje możliwość synchronizacji historii, ulubionych, haseł i innych danych przeglądarki. Decyzję o synchronizacji można odłożyć na później, wybierając Nie, dziękuję lub włączyć od razu.

3.     Włączenie w późniejszym terminie lub zmiana ustawień są możliwe po rozwinięciu menu i wyborze opcji Zarządzaj ustawieniami profilu.

4.     W dowolnym czasie można włączyć oraz zmienić zakres synchronizacji elementów profilu.

Logowanie w programie Teams

Microsoft Teams to platforma komunikacji i pracy grupowej, dzięki której nauczyciele oraz uczniowie mogą pozostawać w kontakcie poza murami szkoły oraz prowadzić zajęcia lekcyjne, kluby zainteresowań oraz spotkania grupowe i indywidualne w wybranych scenariuszach edukacji zdalnej. Aby rozpocząć pracę w programie, należy zalogować się za pomocą szkolnego konta użytkownika w usłudze Office 365. Poniższa instrukcja zawiera opis wymaganych kroków.  

1.     Uruchom aplikację Teams, korzystając ze skrótu na pulpicie, pasu zadań lub menu Start i wprowadź identyfikator swojego konta, kliknąć Zaloguj się, a następnie wprowadzić hasło i jeszcze raz Zaloguj.

2.     Po pierwszym zalogowaniu program może wymagać zastosowania zmian ustawień systemu, który należy zatwierdzić.

Logowanie w programie Poczta i Kalendarz

Poczta i Kalendarz umożliwiają łatwą obsługę szkolnej poczty i kalendarza w usłudze Office 365. Aby zalogować się w Poczcie i Kalendarzu należy wykonać następujące kroki.

1.     Uruchom aplikację Poczta, korzystając ze skrótu na pulpicie, pasu zadań lub menu Start. Program wyświetli kreatora dodawania konta pocztowego, w którym należy wybrać Office 365 i wprowadź identyfikator swojego konta.

2.     Następnie program zaoferuje użycie połączonego konta szkolnego.

3.     Program Kalendarz korzysta z tej samej konfiguracji, co Poczta, więc nie trzeba wykonywać kolejnego logowania. Warto zezwolić na dostęp do dokładnej lokalizacji, dzięki czemu do kalendarza zostaną dodane informacje właściwe dla kraju użytkownika (np. świata i dni wolne).

Logowanie w programie OneNote

OneNote to jeden z najważniejszych programów każdego ucznia i nauczyciela. Zapewnia dostęp do notesów zajęć oraz własnych notatek. Aby zalogować się w programie OneNote należy wykonać następujące kroki.

1.     Uruchom aplikację OneNote, korzystając ze skrótu na pulpicie, pasu zadań lub menu Start. Program automatycznie wykryje, że użytkownik ma powiązane konto, którym zalogowała się wcześniej w aplikacji OneDrive. Aby rozpocząć pracę jako automatycznie wykryty użytkownik, wystarczy kliknąć Rozpocznij.

2.     Aby załadować dodatkowe notesy, np. notes zajęć należy rozwinąć listę notesów i wybrać właściwy z listy Więcej notesów…

Logowanie w programach Word Mobile, Excel Mobile i PowerPoint Mobile

Mobilne wersje programów Word, Excel i PowerPoint pozwalają na realizację podstawowych czynności związanych z tworzeniem, edycją, zapisem i współdzieleniem dokumentów, arkuszy kalkulacyjnych i prezentacji. Instalacja we wszystkich programach przebiega w identyczny sposób. Poniżej zamieszczono opis kroków niezbędnych do zalogowania się w programach.

1.     Kolejno uruchom aplikacje Word Mobile, Excel Mobile i PowerPoint Mobile korzystając ze skrótów na pulpicie, pasu zadań lub menu Start. Programy wykryją skonfigurowane wcześniej konto szkole i zaoferują automatyczne logowania z jego użyciem.

2.     Logowanie za każdym razem będzie ograniczone do zatwierdzenia pracy w programie za pomocą wcześniej skonfigurowanego konta.

Logowanie w programie Office Lens

Office Lens pozwala na błyskawiczne kadrowanie, prostowanie i usuwanie niedoskonałości dokumentów za pomocą kamery laptopa lub telefonu. Dzięki programowi z łatwością można zamieścić rozwiązanie zadania domowego w Teams, OneDrive lub OneNote. Aby zalogować się w aplikacji, należy wykonać następujące czynności.

1.     Uruchom aplikację Office Lens, korzystając ze skrótu na pulpicie, pasu zadań lub menu Start, następnie rozwiń menu i przejdź do Ustawień.

2.     Skonfigurowane konto należy jeszcze zatwierdzić przyciskiem.

Logowanie w programie Whiteboard

Whiteboard pozwala na integrację cyfrowej tablicy interaktywnej w spotkaniach Teams, dzięki czemu uczestnicy mogą rysować i prowadzić burze mózgu wprost w spotkaniach i rozmowach. Whiteboard nie wymaga logowania.

Przyjemnej nauki zdalnej w środowisku Office 365!

Polski zespół Microsoft jest gotowy, by pomóc Państwu w jak najszybszym uruchomieniu Office 365 dla Edukacji.

Wspólnie z Kancelarią Prezesa Rady Ministrów i GovTech Polska pomagamy przedszkolom, szkołom i uczelniom w uzyskaniu bezpłatnego dostępu do Office 365 dla Edukacji. Jeśli potrzebujesz pomocy, skontaktuj się z nami pod adresem [email protected].

Materiały referencyjne i odnośniki

[1] Aplikacje Word Mobile, Excel Mobile, PowerPoint Mobile oraz Outlook Mobile przeznaczone są do używania na telefonach i tabletach z systemem Windows (z ekranami o przekątnej 10,1 cala lub mniejszej).

[2] Word Mobile – ms-windows-store://pdp/?ProductId=9wzdncrfjb9s

[3] Excel Mobile – ms-windows-store://pdp/?ProductId=9wzdncrfjbh3

[4] PowerPoint Mobile – ms-windows-store://pdp/?ProductId=9wzdncrfjb5q

[5] Outlook Mobile – ms-windows-store://pdp/?ProductId=9wzdncrfhvqm

[6] OneNote – ms-windows-store://pdp/?ProductId=9wzdncrfhvjl

[7] OneDrive – ms-windows-store://pdp/?ProductId=9wzdncrfj1p3

[8] Office Lens – ms-windows-store://pdp/?ProductId=9wzdncrfj3t8

[9] Whiteboard – ms-windows-store://pdp/?ProductId=9mspc6mp8fm4

[10] Strona programu OneDrive z klasycznym pakietem instalacyjnym – https://onedrive.live.com/about/pl-PL/download

Teams łączy w sobie elementy komunikacji i współpracy grupowej, przekazywania treści, oceniania prac uczniów oraz połączenia aplikacji edukacyjnych w jednym miejscu. Microsoft Teams to wirtualna platforma stworzona do budowania interakcji, a dzięki zastosowaniu ich funkcjonalności można w łatwo sposób przekazywać materiały dla studentów – niezależnie od lokalizacji. Teams pomaga również administracji i nauczycielom uczelni pozostać w kontakcie i na bieżąco dzielić się informacjami. Platforma umożliwia prowadzenie lekcji on-line, naukę w zintegrowanym notesie zajęć, realizację zadań i ćwiczeń.

Zainteresowanych tematem zachęcam do wejścia na stronę rozwiązania aka.ms/ZdalnaNauka. A także lekturę artykuł na temat zdalnej edukacji —  #MicrosoftMówi Ucz się, skąd chcesz.

 Na koniec dodam, że także przedsiębiorstwa mogą korzystać z części aplikacji Office 365 bezpłatnie:

Teams z nielimitowanymi czatami, wbudowanymi grupami i rozmowami audio i wideo jeden do jednego,10 GB miejsca na załączniki oraz pliki, nad którymi pracuje się indywidualnie lub grupowo w komunikatorze, a także 2 GB przestrzeni indywidualnej dla każdego użytkownika. Do tego wszystkie doliczyć może też przeglądarkowe wersje Word, Excel, PowerPoint i OneNote oraz obsługiwane przez nie formy pracy grupowej. 

Tożsamość jest wisienkom na wielkim torcie zabezpieczeń. Kiedy dochodzi do przechwycenia lub naruszenia zabezpieczeń tożsamości, niezwykle trudno jest zatrzymać i to na czas efekt domina i wywołane nim skutki. Szczególnie że statystycznej organizacji ponad 100 dni zajmuje wykrycie takiego procederu. 

Bardzo często główną słabością systemu są hasła – według różnych źródeł (np. Verizon Data Breach Investigations Report (DBIR), SelfKey – All Data Breaches in 2019 & 2020 – An Alarming Timeline), za  nawet 80% włamań odpowiadają złamane, słabe lub przechwycone hasła.  Stosowanie wieloskładnikowego logowania (Multi-Factor Authentication (MFA)) wymaga użycia co najmniej dwóch czynników weryfikacyjnych. Przełamanie zabezpieczeń logowania opartych na dwóch lub więcej składnikach logowania jest nie lada wyzwaniem dla atakującego i szacuje się, że obniża ryzyko o 99,9%. 

Właśnie z tego powodu, bieżące zalecenia wskazują na konieczności uruchomienia MFA w przedsiębiorstwach. Oto co działy bezpieczeństwa i osoby decydujące mówiły o swoich planach dotyczących MFA w tym roku. 

Hasła są główną metodą uwierzytelniania wskazywaną przez 83% organizacji. Niektóre organizacje wskazują stosowanie dodatkowej weryfikacji wieloskładnikowej, np. SMS lub kody jednorazowe – chociaż nie jest jasne jak szeroko stosowane są dodatkowe zabezpiecznia. 

Wraz z szybkim rozwojem technologii, idącymi w następstwie za tym scenariuszami i metodami ataków, rośnie chęć wdrażania wieloskładnikowego uwierzytelniania. Równocześnie ważna pozostaje prostato i wygoda logowania. 

Z dostępnych na rynku mechanizmów, które łączą w sobie bezpieczeństwo i wygodę, to biometria lub zewnętrzne klucze wskazywane są przez 11% respondentów, czemu sprzyja obecność czytników odcisków palcó czy kamery obsługuję rozpoznawanie twarzy lub siatkówkę oka w wielu nowych komputerach. 

Jednak to telefony, stosowane jako urządzenia uwierzytelniające np. za pomocą aplikacji Microsoft Authenticator, mają największy udział w bieżących oraz planowanych wdrożeniach. 

Nowy mechanizm ma na celu zapewnienie deweloperom możliwości negocjowania treści na podstawie identyfikatora User-Agent klienta, bez odsłaniania zbędnych informacji, które służą tworzeniu „odcisku palca” użytkowników i ograniczają prywatność.  

Co to w ogóle jest User-Agent?

Zanim wejdziemy w dalsze szczegóły, przypomnijmy, co to jest User-Agent (UA)? UA jest ciągiem znaków (tekst), jaki przeglądarki internetowe oraz inne oprogramowanie klienckie przesyła serwerowi w czasie inicjalnego połączenia z witryną lub aplikacją webową. User-Agent to swego rodzaju wizytówka, zawiera informacje o typie przeglądarki, silniku renderującym oraz systemie operacyjnym, przykładowo:

Powyższy zrzut ekranu wizualizuje identyfikację mojej przeglądarki za pomocą useraget v2.2.1 (na whatsmyua.info można zobaczyć wyniki useragent, ua-parser-js oraz platform.js). Rzućmy okien na wyniki z komunikatora Teams. 

Powyższa funkcjonalność może być użyteczna, gdy serwer oczekuje wykonania czynności, którą nie każde oprogramowanie klienckie potrafi zrealizować, dając tym samym możliwość obsługi wyjątków. Takimi funkcjonalnościami może być uwierzytelnianie zintegrowane z Windows, obsługa akceleracji 3D, obracanie ekranu lub odtwarzanie określonych formatów wideo. Wydaje się, że to dość użyteczne, prawda? 

Diabeł tkwi w szczegółach

Niestety (nader często) UA jest wykorzystywany do innych niż wskazane wcześniej cele, np. bardziej precyzyjnego śledzenia użytkowników lub blokowania konkurencji. Przed pierwszy bronią się użytkownicy, za pomocą opcji wbudowanych lub dostarczanych przez rozszerzenia, przed drugim „ograniczani” dostawcy oprogramowania i usług.

Vivaldi podobnie jako nowy Edge opiera się na kodzie Chromium. Jednak Google Search oraz Docs, Netflix Player, Facebook WhatsApp, a nawet Microsoft Teams, blokują możliwość korzystania lub robią to z umyślnymi błędami (które znikają, gdy tylko UA przeglądarki zostanie „sfałszowane”). Dlatego od grudnia 2019 r. Vivaldi maskuje swój UA, z wyjątkiem kilku witryn, z którymi otwarcie współpracuje (duckduckgo.com, ecosia.org, qwant.com i startpage.com).  Google blokuje używanie rozwojowych wersji Edge w Stadia Cloud Gaming Service oraz kilku innych usługach. 

Powiecie (zresztą słusznie, że to) dość skrajne przypadki. Jednak, gdy się przyjrzeć zachowaniu przeglądarek, okaże się, że wszyscy „kłamią” na swój temat, udając, że są wszystkimi. Im bardziej tak się dzieje, tym mniej użyteczne staje się wykrywanie User-Agent. 

Jaki jest plan Google?

Google planuje zaprzestać aktualizowania komponentu UA w Chrome nowymi ciągami (tekstem UA, który Chrome udostępnia stronom internetowym).

Plan długoterminowy polega na ujednoliceniu wszystkich ciągów znaków UA Chrome w ogólne wartości, które nie ujawniają zbyt dużej ilości informacji o użytkowniku. Oznacza to, że nowe wersje przeglądarki Chrome na nowe platformy, takie jak nowe modele smartfonów lub nowe wersje systemu operacyjnego, będą używać ogólnego identyfikatora UA, a nie takiego, który jest dostosowany do konkretnej platformy.

Na przykład w przyszłości witryna internetowa nie będzie w stanie stwierdzić, czy użytkownik korzystający z Chrome używa Chrome w systemie Windows 7 lub Windows 11, czy też użytkownik mobilny Chrome korzysta z telefonu Samsung Galaxy, iPhone czy Pixel.

Strony internetowe będą mogły stwierdzić, że użytkownik korzysta z Chrome na komputerze lub urządzeniu mobilnym i nic poza tym.

Ze względu wsteczną kompatybilność User-Agent w Chrome będzie nadal działać, więc nie uszkodzi to mechanizmów i skryptów w dotychczasowych witrynach i aplikacjach webowych. Z czasem jego znaczenie będzie jednak maleć. 

Oto aktualny plan Google dotyczący ograniczenia obsługi User-Agent:

Chrome 81 (połowa marca 2020 r.) - Google planuje wyświetlać ostrzeżenia w konsoli Chrome dla stron internetowych, które czytają ciąg znaków UA, aby programiści mogli dostosować kod swojej witryny.

Chrome 83 (początek czerwca 2020 r.) - Google zamrozi wersję przeglądarki Chrome w identyfikatorze UA i ujednolici wersje systemu operacyjnego.

Chrome 85 (połowa września 2020 r.) - Google ujednolici identyfikator UA dla desktopowych wersji przeglądarek. Podobne ujednolicenie spotka też wersje na systemy mobilne.

Poniżej przedstawiono przykładowy User-Agent dla mobilnej wersji Chrome  po zamrożeniu modyfikacji UA:

Mozilla/5.0 (Linux; Android 9; Unspecified Device) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/71.1.2222.33 Mobile Safari/537.36

Tak z kolei będzie się prezentować Chrome w wersji na desktopy po zamrożeniu UA:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36

Gdy użytkownik otworzy witrynę lub aplikację webową, jego żądanie będzie zawierać zamrożony identyfikator UA, a także specjalny nagłówek „Sec-UA”, który przekaże podstawowe informacje o kliencie, jak pokazano poniżej.

Sec-CH-UA: "Examplary Browser 73"

Jeśli serwer potrzebować będzie więcej informacji, poprosi o to w nagłówku odpowiedzi „opt-in”. Wówczas, zostanie poproszony o dostarczenie dodatkowych informacji, np. takich jak wersja pomocnicza i system operacyjny. Można to zrobić za pomocą następującego żądania w nagłówku HTTP:

Accept-CH: UA, Platform

Wówczas klienci, którzy będą kompatybilni i których ustawienia na to pozwolą, prześlą następującą odpowiedź na takie żądanie:

Sec-CH-UA: "Examplary Browser 73.3R8.2H.1" Sec-CH-Platform: "Windows 10"

Decyzja o wysłaniu informacji będzie należała do klienta, zatem indywidualni użytkownicy oraz organizacje będą mogły stosować własne reguły odpowiadania, udzielając dodatkowych informacji witrynom i aplikacjom z zaufanych adresów.

Aby skorzystać z Client Hints, witryna lub aplikacja webowa musi spełnić następujące wymagania:

Żądania opt-in serwera muszą być kierowane z adresu głównego poziomu witryny (top-level navigation request) przez bezpieczne połączenie (TLS).

Odpowiedzi są dostarczane tylko w odpowiedzi na oryginalne żądanie (inaczej niż w przypadku ciasteczek) w bezpiecznym połączeniu.

Jeśli odpowiedzi otrzymane przez witrynę lub aplikację webową otwartą przez użytkownika (własne, first-party) mają być dostarczane do określonych serwerów innych podmiotów (third-party hosts), należy je jawnie wydelegować.

Odpowiedzi są przekazywane z prefiksem Sec-, aby zapewnić większe bezpieczeństwo oraz uniknąć błędów z obsługą po stornie niekomatybilnych serwerów.

Uwzględniając powyższe, Google chce usunąć dostęp do właściwości navigator.userAgent za pomocą JavaScript w Chrome 81.

Co z implementacją w innych przeglądarkach?

Apple (Safari), Microsoft (Edge) oraz Mozilla (Firefox) w mniej lub bardziej oficjalny sposób potwierdził, że zaimplementują proponowany przez Google mechanizm wycofania obsługi User-Agent na rzecz Client Hints. Na szczegóły przyjdzie nam jeszcze poczekać. 

W mapie rozwoju Edge nie ma jeszcze informacji o nowym mechanizmie. 

Nie ma ich też w artykule Site compatibility-impacting changes coming to Microsoft Edge, gdzie w pierwszej kolejności informujemy o dużych zmianach, które wpływają na kompatybilność przeglądarki.

Jaki to ma wpływ na rozwiązania Microsoftu? 

Nie ulega wątpliwości, że zmiany te będą miały wpływ na witryny oraz aplikacje webowe uruchomione na ISS w Windows Server, a także Azure Web App oraz Azure Web Sites.

Zmiany dotkną także platformy uwierzytelniania w chmurze (Microsoft Online Services Sign-In, Microsoft Office 365 Identity Platform) oraz usług federacyjnych Active Directory Federation Services.

W tych drugich, w Windows Server 2016 i nowszych, istnieją dwa mechanizmy wykrywania zgodności klientów z mechanizmami logowania zintegrowanego z Windows. Aby się o tym przekonać, przyjrzyjmy się właściwości WiaEvaluationMethod zwracanej przez polecenie Get-AdfsProperties.

Ustawienie WiaEvaluationMethod może przyjąć dwie wartości: WiaCapabilityDetection oraz WiaUserAgentDetection. Domyślne ADFS posługuje się drugą wartością, co powoduje, że oferuje mechanizmy logowania zintegrowanego klientom (Kerberos, Single Sign-On (SSO)), których User-Agent znajduje się na liście kompatybilnych.

Oznacza to, że najpóźniej we wrześniu należy się spodziewać poprawki, która dostarczy obsługi żądań opcjonalnych przez serwer usług federacyjnych i tym sposobem pozyskiwane będą wymagane elementy identyfikujące klienta za pomocą Client Hints.

Zmiany dotyczące sposobu obsługi ciasteczek zostały opisane w dwóch artykułach:

Cookies default to SameSite=Lax Treat cookies as SameSite=Lax by default if no SameSite attribute is specified. Developers are still able to opt-in to the status quo of unrestricted use by explicitly asserting SameSite=None. Note: Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention ("Lax + POST") will be removed in the future.

Reject insecure SameSite=None cookies Deprecate and remove the use of cookies with the SameSite=None attribute but without the Secure attribute. Any cookie that requests SameSite=None but is not marked Secure will be rejected.

Ciasteczka bez atrybutu SameSite będą domyślnie traktowane jak te z wartością Lax. Co oznacza, że domyślnym zachowaniem będzie ograniczenie plików cookie tylko do własnych kontekstów. W okresie przejściowym (zanim nowe wymagania zostaną powszechnie zaadoptowane) będzie istniała obsługa opisana jako Lax + POST, dzięki której ciasteczka bez atrybutu SameSite przez 2 minuty od wystawienia będą załączane do nieidemopotentnych żądań między domenami najwyższego poziomu.  

Pliki cookie do użytku w różnych witrynach muszą zawierać SameSite=None; Secure, aby umożliwić włączenie w kontekście strony trzeciej.

Scenariusze użycia ciasteczek zewnętrznych lub pomiędzy stronami

Istnieje wiele typowych scenariuszy użycia i wzorców, w których pliki cookie muszą być wysyłane w kontekście strony trzeciej. Jeśli stosujecie takie rozwiązania, upewnijcie się, że wydawane lub przekazywane ciasteczka będą na czas zaktualizowane, aby zapewnić prawidłowe działanie usług.

Zawartość pływających ramek <iframe>

Zawartość z innych stron, wyświetlana w pływających ramkach <iframe> wyświetlana jest w kontekście zewnętrznym (third-party). Najczęściej są to następujące przypadki użycia:

Zagnieżdżenie współdzielonych z innych stron materiałów, takich jak wideo, mapy, fragmenty kodu źródłowego oraz wpisy z mediów społecznościowych.

Widżety z zewnętrznych usług, takich jak systemy mikropłatności, panele dyskusyjne i komentarze, kalendarze lub systemy rezerwacyjne.

Widżety w postaci przycisków do polecania lub systemy do ochrony przed oszustwami finansowymi. 

Ciasteczka mogą być w tych przykładach wykorzystane do, między innymi, utrzymania stanu sesji, przechowywania ogólnych preferencji, prowadzenia statystyk lub personalizowania treści dla użytkowników posiadających istniejące konta.

Dodatkowo, treści w ramach typu <iframes> są osadzane także w kontekście stron najwyższego poziomy lub własnym (first-party). Wszystkie ciasteczka dostarczane przez strony w ramkach będą traktowane jako zewnętrzne. Jeśli tworzycie strony, które z założenia mają być zagnieżdżane w innych, a ich funkcjonalność jest zależna od ciasteczek, musicie upewnić się, że są one skonfigurowane do użycia pomiędzy stronami (cross-site) lub opracować mechanizmy zastępcze, które pozwolą na obsługę zawartości bez ciasteczka załączonego w żądaniu.

„Niebezpieczne” żądania pomiędzy stronami

Określenie „niebezpieczne” budzi pewne obawy, ale odnosi się ono do każdego żądania, które może mieć na celu zmianę stanu. W większość przypadków będą to żądania realizowane metodą POST. Ciasteczka oznaczone jako SameSite=Lax będą przesłane bezpiecznie w żądaniach do stron najwyższego poziomu, np. przy kliknięciu w odnośnik przekierowujący do innej witryny. Jednak żądanie z formularza <form> przesłane metodą POST do innej strony nie będzie zawierać ciasteczek.

Scenariusz (z użyciem formularza), służy do przekierowania użytkownika do zdalnej usługi w celu wykonania pewnych operacji przed powrotem, na przykład przekierowania do zewnętrznego dostawcy tożsamości. Zanim użytkownik opuści witrynę, ustawiane jest ciasteczko zawierające token jednorazowego użytku, który można porównać z powrotnym żądaniem, aby zminimalizować ataki typu cross site request forgery (CSRF) (niezorientowanym polecam artykuł Czym jest podatność CSRF?). Jeśli takie żądanie, np. z formularza logowania za pomocą usług federacyjnych AD FS lub Azure (w następnej części cyklu przeanalizujemy przebieg logowania i zobaczymy jak instalowane są ciasteczka przez i po zastosowaniu styczniowych pakietów poprawek dla Windows Server 2016 (KB4534271) i Windows Server 2019 (KB4534273)), zostanie wysłane za pośrednictwem POST, ciasteczka będą musiały być oflagowane jako SameSite=None; Secure.

Zasoby zdalne

Żądanie dowolnego rodzaju zasobu zdalnego, przykładowo wczytywanego znacznikami <img>, <script> lub innymi, może być zależne od ciasteczek. Szczególnie popularne są tzw. „piksele” śledzące i personalizujące treści.

Dotyczy to również żądań inicjowanych skryptami JavaScript za pomocą funkcji fetch lub XMLHttpRequest. Wywołanie fetch() z parametrem credentials: 'include' jest idealnym przykładem żądania, w którym oczekujemy załączenia ciasteczka. Dla XMLHttpRequest powinniśmy poszukać wystąpień właściwości withCredentials ustawionych na true. W takich przypadkach, załączenie ciasteczka w żądaniu będzie oczekiwane. A co za tym idzie, takie ciasteczka muszą być skonfigurowane do użycia pomiędzy witrynami (w komunikacji typu cross-site).

Treści wyświetlane w WebView

WebView w Androidzie oraz WKWebView w iOS, umożliwiają zagnieżdżanie oraz natywną obsługę treści webowych w aplikacjach. Prędzej lub później nowe zasady obsługi ciasteczek zostaną zaimplementowane w bibliotekach WebView. Obecnie Android zezwala na bezpośrednią instalację ciasteczek za pomocą CookieManager API, a iOS za pomocą httpCookieStore. Ciasteczka są wystawiane w nagłówkach HTTP lub za pomocą skryptów JavaScript, wydaje mi się, że warto już teraz dodać atrybut SameSite=None; Secure jeśli mają być stosowane pomiędzy stronami lub zewnętrznymi komponentami osadzonymi w aplikacjach.

Jak już dzisiaj zaimplementować SameSite?

W przypadku plików cookie, w których są one potrzebne tylko w kontekście własnych, najlepiej oznaczyć je jako SameSite=Lax lub SameSite=Strict, w zależności od potrzeb. Słabszym rozwiązaniem jest zdanie się na implementacje domyślnych zachowań po stronie przeglądarek, bo stwarza to ryzyko niespójnego funkcjonowania aplikacji lub witryny webowej w różnych klientach oraz będzie generowało ostrzeżenia w konsoli.

Set-Cookie: ciastko_wlasne=wartosc; SameSite=Lax

Z kolei ciasteczka, które są potrzebne w kontekście zewnętrznych stron, najlepiej oznaczyć jako SameSite=None; Secure. Koniecznie użyjcie obu atrybutów. Jeśli wybierzecie None ale bez dodatkowego parametru Secure ciasteczko zostanie odrzucone. Pozostaje jeszcze kwestia niekompatybilności pomiędzy różnymi przeglądarkami, ale o tym w następnej sekcji.

Set-Cookie: ciasteczko_zewnetrzne=wartosc; SameSite=None; Secure

Obsługa niezgodnych ze standardem klientów

Zmiany dotyczące trybu None oraz domyślne zachowanie w przeglądarkach są stosunkowo nowe, co może generować niespójności w obsłudze. Na stronie chromium.org udostępniono (stale aktualizowaną) listę znanych problemów. 

Chociaż nie jest to idealne rozwiązanie, istnieją sposoby obejścia problemu braku obsługi nowego trybu w fazie przejściowej, w której niekompatybilne aplikacje zginą lub zostaną dostosowane. Ogólną zasadą jest traktowanie klientów niekompatybilnych jako szczególnego przypadku, nie na odwrót. Nie twórzcie wyjątków dla przeglądarek implementujących nowe zasady.

Pierwszym sposobem na obejście problemu jest równoległa instalacja ciasteczek w „nowym” i „starym” stylu:

Set-cookie: wazne_ciastko=wartosc; SameSite=None; Secure Set-cookie: wazne-ciastko-przestarzale=wartosc; Secure

Przeglądarki stosujące nowsze zachowanie pobiorą ciasteczko z wartością SameSite, podczas gdy niekompatybilne przeglądarki prawdopodobnie je zignorują. Jednak, te przeglądarki, powinny ustawić ciasteczko wazne-ciasteczko-przestarzale. Podczas przetwarzania dołączonych plików cookie witryna powinna najpierw sprawdzić obecność „nowego” ciasteczka, a jeśli nie zostanie znalezione, przełączyć się na „starsze”.

Poniższy przykład pokazuje, jak to zrobić w Node.js, korzystając z Express framework oraz metod cookie-parser.

const express = require('express'); const cp = require('cookie-parser'); const app = express(); app.use(cp()); app.get('/set', (req, res) => {  // Ustawienie ciasteczka nowa metoda  res.cookie('wazne-ciastko', 'wartosc', { sameSite: 'none', secure: true });  // Ustawienie ciasteczka z taka sama wartoscia stara metoda  res.cookie('wazne-ciastko-przestarzale', 'wartosc', { secure: true });  res.end(); }); app.get('/', (req, res) => {  let cookieVal = null;  if (req.cookies['wazne-ciastko']) {    // Najpier sprawdz wartosc nowego ciasteczka    cookieVal = req.cookies['wazne-ciastko'];  } else if (req.cookies['wazne-ciastko-przestarzale']) {    // Dopiero jesli nie istnieje sprawdz stare    cookieVal = req.cookies['wazne-ciastko-przestarzale'];  }  res.end(); }); app.listen(process.env.PORT);

Oczywistą wadą powyższego rozwiązania jest produkcja zbędnych plików cookie dla wszystkich przeglądarek, dodatkowo wymaga to wprowadzenia zmian zarówno w momencie ustawienia, jak i odczytu ciasteczka. Takie podejście pozwala obsłużyć wszystkie przeglądarki bez względu na ich zachowanie i zapewnić, że pliki cookie innych firm będą nadal działać tak jak poprzednio.

Alternatywnie można przed zastosowaniem instrukcji Set-Cookie wykryć używaną przeglądarkę za pomocą user agent string (UA). Na liście niekompatybilnych klientów znajdziemy większość popularnych aplikacji, wówczas wystarczy skorzystać z odpowiedniej biblioteki, trzymając się powyższego przykładu w Node.js może to być ua-parser-js. Lepiej zdać się na gotowe biblioteki do wykrywania UA, żeby nie musieć samodzielnie konstruować wyrażeń regularnych.

Zaletą tego podejścia jest to, że wymaga tylko jednej zmiany w momencie ustawienia pliku cookie. Niestety wykrywanie funkcjonalności po identyfikatorze UA pachnie Internetem 1.0 i w wielu wypadkach może być zawodne. Pamiętajcie też, że obecnie wszyscy udają wszystkich, zresztą sprawdźcie sami na What’s my UA.

Bez względu na wybraną opcję warto monitorować, jaki jest poziomo korzystania ze starszej metody. A nawet ustawić sobie przypomnienie, aby wycofać obejście, gdy poziomy te spadną poniżej akceptowalnego progu.

Obsługa SameSite=None w językach, bibliotekach i frameworkach

Większość języków i bibliotek obsługuje atrybut SameSite w ciasteczkach, jednak już SameSite=None jest stosunkowo nowe,co oznacza, że na razie może być konieczne obejście niektórych standardowych zachowań. Są one udokumentowane w repozytorium przykładów SameSite na GitHub-ie.

Gdzie szukać pomocy?

Nie przesadzę stawiając tezę, że ciasteczka są wszędzie. I rzadko zdarza się, aby jakakolwiek strona w pełni kontrolowała tryb ich instalacji i użycia, w szczególności na stronach zewnętrznych i w scenariuszach mieszanych. Jeśli już zderzycie się z problemem, proponuję zacząć poszukiwania pomocy w tych miejscach:

Zgłoszenie problemu w repozytorium przykładów SameSite na GitHub.

Pytanie pod tagiem "samesite" na StackOverflow.

Jeśli sądzicie, że trafiliście na problem wynikający z implementacji w przeglądarce możecie zgłosić problem na trackerze producenta lub społeczności, np. [SameSite cookies] issue.

Każde ciasteczko to para klucz=wartość wraz z szeregiem atrybutów kontrolujących kiedy i gdzie ciasteczko może być używane. Jeśli tworzycie lub administrujecie witrynami i aplikacjami webowymi, prawie na pewno używaliście już tych atrybutów, aby ustawić daty ważności lub wymusić przesłanie ciasteczka kanałem HTTPS. Serwery przesyłają ciasteczka używając nagłówka Set-Cookie w ramach odpowiedzi HTTP. Wszystkie szczegóły są opisane w RFC6265bis, ale poniżej znajdziecie skrótowe wyjaśnienia oparte na przykładach.

Powiedzmy, że macie bloga, na którym chcecie wyświetlić powiadanie "Co nowego" waszym czytelnikom. Użytkownicy mogą odrzucić powiadomienie, dzięki czemu nie zobaczą go ponownie przez jakiś czas. Ich wybór możemy przechować w ciasteczku, które będzie ważne przez miesiąc (na potrzeby tego przykładu, ustalmy, że miesiąc ma 2 600 000 sekund) i że będzie przesłane przez HTTPS. Wówczas nagłówek powinien wyglądać następująco:

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

Kiedy na blogu pojawia się czytelnik, który spełnia wskazane kryteria, trzymając się przykładu ma bezpieczne połączenie i ciasteczko ma nie więcej niż 1 miesiąc, jego przeglądarka prześle następującą informację w nagłówku żądania:

Cookie: promo_shown=1

Ciasteczka dla tej witryny można dodawać oraz odczytywać za pomocą JavaScript, używając właściwości document.cookie. Odpowiednia instrukcja document.cookie stworzy lub nadpisze ciasteczko ze wskazanym kluczem. Przykładowo, możecie wykonać poniższy kod w konsoli JavaScript waszej przeglądarki:

> document.cookie = "promo_shown=1; Max-Age=2600000; Secure" < "promo_shown=1; Max-Age=2600000; Secure"

Aby otworzyć konsolę należy wcisnąć F12 i wybrać kartę konsoli JavaScript. W oknie Console będą znajdowały się zdarzenia związane z wykonanie kodu JS w otwartej karcie, a dodatkowo będziemy mogli wykonać własny kod. Wykonajcie test i dodajcie ciasteczko.

Wprowadźcie przykładowy kod, który zainstaluje ciasteczko dla aktywnej sesji document.cookie="pfeacademy=favorite" lub użyjcie zaawansowanych opcji, document.cookie="username=Grzegorz; expires=Thu, 31 Dec 2020 12:00:00 UTC; path=/";.

Z użyciem document.cookie możliwe jest też odczytanie i przetworzenie ciasteczek w aktualnym kontekście i bezpośrednio po stronie klienta.

W konsoli wpiszcie document.cookies;, wynik będzie zawierał wszystkie ciasteczka oddzielone przecinkiem:

> document.cookie; < "promo_shown=1; username=Grzegorz; pfeacademy=favorite"

Większość witryn instaluje w pamięci podręcznej przeglądarki przynajmniej kilka ciasteczek. Ciasteczka te są następnie przesyłane przy każdym żądaniu klienta dla tej domeny, co ma kilka skutków. Przepustowość ruchu wychodzącego (upload) jest zwykle bardziej ograniczona niż przychodzącego (download), generuje to dodatkowy narzut dla wszystkich żądań wychodzących i skutkuje pewnymi opóźnieniami w zasadzie od pierwszego bajtu komunikacji. Zachowajcie ostrożność w liczbie i rozmiarze ustawianych plików cookie. Koniecznie stosujcie atrybut Max-Age, aby zapewnić ich przetwarzanie tylko tak długo jak to konieczne.

Co to są własne i zewnętrzne ciasteczka?

Jeśli przyjrzycie się ciasteczkom zainstalowanym podczas otwarcia przykładowej witryny, zauważycie, że przynajmniej część pochodzi z innych (niż aktualnie otwarta) stron. W konsoli przejdźcie na kartę Application, następnie do sekcji Storage i grupy Cookies.

Na moim blogu znajdziecie komponenty udostępnione z serwisów Linkedin i Twitter, własne dodatki wymusza także platforma, z której korzystam, czyli Tumblr. Wszystkie one zainstalowały pewną liczbę ciasteczek. 

Ciasteczka, których adres pasuje do domeny wyświetlanej witryny, to tak zwane ciasteczka “własne” (first-party), te instalowane z innych adresów nazywane są “zewnętrznymi” (third-party). Podział na ciasteczka własne i zewnętrzne nie jest absolutny i zależy od kontekstu użytkownika, to samo ciasteczko może być first-party lub third-party zależnie od witryny, na której znajduje się użytkownik w danym czasie.

Wasza przeglądarka na pewno daje możliwość zarządzania ciasteczkami oraz przeglądu wszystkich plików zapisanych w pamięci podręcznej.

Wróćmy na chwilę do przykładu promo_shown. Powiedzmy, że jeden z postów na blogu zawiera baner w pliku /blog/img/azure.png. Ponieważ to bardzo fajny obrazek, inni użytkownicy wyświetlają go używając odnośnika bezpośredniego. Jeśli czytelnik był na moim blogu i ma już ciasteczko promo_shown, wówczas kiedy wyświetla azure.png na innej witrynie, to ciasteczko zostanie załączone do żądania pobrania obrazka. Przyznacie, że nie jest to specjalnie użyteczne, bo promo_shown nie jest wykorzystywane nigdzie poza moją witryną, zwiększa tylko rozmiar żądania.

Jeśli efekt nie jest zamierzony, to po co w ogóle go wywoływać? Ciasteczka dostarczają witrynom i aplikacjom webowym możliwości zachowania stanu, w ich kontekście. Przykładowo, jeśli zagnieździcie wideo z serwisu YouTube, odwiedzający, którzy zdecydują się je uruchomić, będą mogli skorzystać z opcji “Zobacz później” w odtwarzaczu. Jeśli wasz czytelnik jest już zalogowany w YouTube, to jego sesja jest rozciągana do osadzonego odtwarzacza z użyciem zewnętrznego ciasteczka — co oznacza, że przycisk “Zobacz później” zapisze wideo na liście odtwarzania, bez konieczności przechodzenia przez logowania (co przekierowałoby użytkownika z bieżącej witryny do YouTube i wymagało jego powrotu).

Otwartość jest jedną z wbudowanych, immanentnych właściwości sieci WWW. Dzięki temu, wiele osób i organizacji tworzy własne treści i aplikacje. Otwartość podnosi również szereg obaw związanych z bezpieczeństwem i prywatnością. Ataki polegające na fałszowaniu żądań w różnych witrynach (cross-site request forgery, CSRF) polegają na tym, że ciasteczka są dołączane do każdego żądania do danego źródła, niezależnie od tego, kto je inicjuje. Przykładowo, kiedy odwiedzacie zlosliwa.strone, może ona wywołać żądanie do innej.strony, a wasza przeglądarka z przyjemnością załączy powiązane pliki cookies. Jeżeli nasza strona (lub zabezpieczenia przeglądarki), nie jest ostrożna w sprawdzaniu poprawności tych żądań, wówczas zlosliwa.strona może wykonywać czynności wynikające ze stanu przekazanego w ciasteczkach (np. usuwać artykuły lub dodawać treści na blogu).

Ostatnie lata znacznie poprawiły poziom świadomości użytkowników w temacie instalacji ciasteczek oraz tego jak mogą być wykorzystane do śledzenia ich aktywności w wielu witrynach. Jednak do tej pory nie było sposobu, aby jednoznacznie określić intencję czy zakres użycia ciasteczka. Raz jeszcze wróćmy do przykłady z ciasteczkiem promo_shown, które powinno być wysłane tylko w kontekście własnym (w komunikacji ze stroną, która go zainstalowała), podczas gdy sesyjne ciasteczko dla widżetu, który jest osadzony w innych witrynach, powinno funkcjonować jako zewnętrzne.

Wyraźne określenie możliwości użycia ciasteczka za pomocą atrybutu SameSite

Wprowadzenie atrybutu SameSite (zdefiniowanego w RFC6265bis) pozwala zadeklarować czy ciasteczko powinno być ograniczone do kontekstu strony, która go wydała lub tego określonego przez wartość same-site. Bardzo ważne jest, aby zrozumieć co oznacza "strona”. Strona jest połączniem sufiksu domenowego oraz podmiotu lub subdomeny w tej domenie. Przykładowo, witryna blog.pfe.academy jest częścią domeny pfe.academy.

Kluczowe pojęcie: Jeśli użytkownik otworzył blog.pfe.academy i zażądał obrazka z static.pfe.academy to jest to żądanie typu same-site.

Definiuje to lista publicznych sufiksów, nie jest to tylko lista domen głównych jak .com, ale także usług jak na przykład github.io. A to pozwala, aby moj-projekt.github.io i twoj-projekt.github.io były identyfikowane jako osobne strony.

Kluczowe pojęcie: Jeśli użytkownik na twoj-projekt.github.io zażąda obrazka z moj-projekt.github.io to jest to żądanie pomiędzy stronami (cross-site request).

Wprowadzenie atrybutu SameSite w ciasteczku dostarcza trzech sposobów kontrolowania zachowania użycia ciasteczka. Można nie ustawiać wartości, można użyć wartości Strict lub Lax, aby ograniczyć żądania do same-site.

Jeśli SameSite zostanie ustawione na Strict, takie ciasteczko zostanie przesłane tylko do witryny, która je zainstalowała (first-party context). W kategoriach użytkownika plik cookie zostanie wysłany tylko wtedy, gdy witryna dla pliku cookie jest zgodna z witryną aktualnie wyświetlaną na pasku adresu URL przeglądarki. Poniżej przykład, jak zainstalować ciasteczko promo_shown w ten sposób:

Set-Cookie: promo_shown=1; SameSite=Strict

Jeśli użytkownik jest na naszej stronie, ciasteczko zostanie przesłane w żądaniu. Jednak po kliknięciu linku do Twojej witryny, powiedzmy z innej witryny lub za pośrednictwem wiadomości e-mail od znajomego, na pierwsze żądanie plik cookie nie zostanie wysłany. To jest szczególnie ważne, kiedy pliki cookie powiązane są z jakąś funkcjonalnością (np. zmianą hasła lub zakupem), która zawsze będzie znajdować się poza początkową komunikacją, ale jest zbyt restrykcyjna dla promo_shown. Jeśli czytelnik podąża za linkiem z innej strony, chce, aby plik cookie został wysłany, aby można było zastosować wcześniejsze preferencje.

Wtedy właśnie zastosowanie ma SameSite=Lax, umożliwiając przesyłanie ciasteczek przy żądaniach kierowanych przez strony w tej samej przestrzeni domenowej. Raz jeszcze przyjrzyjmy się przykładowi z banerem, w którym inna witryna odwołuje się do naszej zawartości. Jeśli w witrynie osadzono grafikę bezpośrednio z odnośnikiem do artykuły.

<p>Panie! Tenanty prawie za darmo!</p> <img src="https://pfe.academy/blog/img/azure.png" /> <p>Czytaj <a href="https://pfe.academy/blog/azure.html">więcej</a>...</p>

A ciasteczko zostało ustawione następująco:

Set-Cookie: promo_shown=1; SameSite=Lax

Kiedy czytelnik jest na zewnętrznej (względem pfe.academy) witrynie ciasteczko nie zostanie wysłane wraz z żądaniem pliku azure.png. Jednak, kiedy zostanie uruchomiony odnośnik azure.html na naszym blogu, to żądanie będzie już zawierać ciasteczko. Z tej perspektywy wybór trybu Lax będzie dobry dla ciasteczek wpływających na wyświetlania jakiś elementów, a tryb Strict dla ciasteczek powiązanych z obsługą akcji użytkownika.

Uwaga: Ani Strict ani Lax nie są kompletnym rozwiązanie dla bezpieczeństwa naszej witryny. Ciasteczka są wysyłane jako część żądania użytkownika i należy traktować je tak samo, jak inne dane wejściowe użytkownika. W ramach dobrych praktyk, oznacza to sprawdzanie poprawności danych wejściowych. Nigdy nie używajcie plików cookie do przechowywania danych, które po stronie serwera uważacie za sekrety (np. hasło).

Na koniec zostawiliśmy możliwość nieokreślania wartości, co wcześniej było sposobem na niejawne stwierdzenie, że chcemy, aby plik cookie był wysyłany we wszystkich kontekstach. W RFC6265bis zmieniono podejście i teraz wymaga to zastosowania ustawienia SameSite=None. Oznacza to, że możecie użyć wartości None, aby zezwolić na wysyłanie ciasteczka w kontekście strony trzeciej.

Jeśli świadczycie usługę, z której korzystają inne witryny, taką jak widżety, osadzone treści, programy partnerskie, reklamy lub logowanie do wielu witryn (zwracam uwagę na usługi federacyjne Active Directory Federation Services lub w Azure), powinniście użyć wartości None, aby jawnie wskazać otwarty zakres użycia.

Zmiana domyślnego zachowania dla ciasteczek bez wartości SameSite

Chociaż atrybut SameSite jest szeroko obsługiwany, niestety nie został powszechnie zaadoptowany przez programistów. Domyślnie otwarte przesyłanie ciastek wszędzie działa bezobsługowo, ale naraża użytkownika na CSRF oraz niezamierzone wycieki informacji. Aby zachęcić deweloperów do określania jak przeglądarka powinna korzystać z ciasteczka, aby zapewnić bezpieczne korzystania z witryny lub aplikacji webowej użytkownikowi, IETF zaproponowało w Incrementally better cookies dwie kluczowe zmiany:

Ciasteczka bez atrybutu SameSite będą traktowane jak z wartością SameSite=Lax.

Ciasteczka z atrybutem SameSite=None muszą jednocześnie być instalowane w trybie Secure, co oznacza, że wymagają bezpiecznego kontekstu.

Chromium (i jego pochodne, w tym Google Chrome oraz nowy Microsoft Edge) implementuje zmiany od wersji oznaczonej numerem 80. Mozilla udostępniła je testowo w Firefoksie 69 i zamierza je włączyć domyślnie w przyszłości.

Podsumujmy dotychczasową dyskusję na ten temat.

SameSite=Lax

Default

Atrybut nie został ustawiony jawnie.

Set-Cookie: promo_shown=1

Jeśli ciasteczko nie zostało opatrzone żadnym atrybutem SameSite zostanie użyte domyślne dla przeglądarki zachowanie, równoznaczne z następującym.

Set-Cookie: promo_shown=1; SameSite=Lax

Przeglądarka potraktuje ciasteczko tak samo jakby wskazano SameSite=Lax.

Chociaż ma to na celu zastosowanie bezpieczniejszego ustawienia domyślnego, najlepiej ustawić jawny atrybut SameSite zamiast polegać na przeglądarce, bo różne aplikacje mogą to różnie realizować. Pamiętajcie też, że klientami waszej aplikacji mogą być też inne aplikacje, np. Outlook, Word, Excel, Teams (tutaj jest to aplikacja osadzona w Electrone i wyświetlana w silniku Chromium), prawie wszystkie aplikacje na Androidzie wykorzystują WebView, a jak zachowają się inne? Najlepiej jawnie wskazać bariery użycia ciasteczka, aby wszędzie były realizowane spójnie.

Uwaga: Domyślne zachowanie stosowane przez Chrome jest nieco bardziej liberalne niż jawne wskazanie SameSite=Lax ponieważ pozwoli na wysyłanie niektórych plików cookie na żądania POST najwyższego poziomu. Dokładne szczegóły można znaleźć w ogłoszeniu blink-dev. To tymczasowe rozwiązanie mające na celu złagodzenie objawów na niedostosowanych na czas witrynach i aplikacjach. Najlepiej jednak zezwolić na cross-site cookies za pomocą SameSite=None; Secure.

SameSite=None

Musi być instalowane w bezpiecznym kontekście z użyciem parametru secure.

Rejected

Set-Cookie: widget_session=abc123; SameSite=None

Instalacja ciasteczka bez Secure będzie odrzucona.

Accepted

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Musiecie upewnić się, że atrybut SameSite=None idzie w parze z Secure.

W przeglądarkach opartych Chromium w wersji 76 lub późniejszych można włączyć testowo nowe zachowanie włączając flagę pod adresem chrome://flags/#cookies-without-same-site-must-be-secure, w Edge  edge://flags/#cookies-without-same-site-must-be-secure, a w  Firefoksie 69 w about:config za pomocą ustawienia network.cookie.sameSite.noneRequiresSecure.

Wydaje mi się, że będziecie chcieli przełączyć wskazane ustawienia podczas instalacji nowych plików cookie i odświeżaniu istniejących ciasteczek, nawet jeśli nie zbliżają się one do ich daty ważności.

Jeśli korzystacie z usług dostarczających treści zewnętrznych pod waszą stroną, powinniście sprawdzić czy dostawca przygotował się do zmian. Konieczne może być zaktualizowanie zależności lub osadzonych fragmentów, aby upewnić się, że witryna rozpoznaje nowe zachowanie.

Obie zmiany są wstecznie kompatybilne z przeglądarkami, które poprawnie zaimplementowały poprzednią wersję atrybutu  SameSite lub po prostu go nie obsługują. Stosując te zmiany do plików cookie, wyraźnie zaznaczacie ich przeznaczenie, zamiast polegać na domyślnym zachowaniu przeglądarki. Podobnie każdy klient, który nie rozpoznaje SameSite=None na razie, powinien go zignorować i kontynuować tak, jakby atrybut nie został ustawiony.

Ostrzeżenie: Wiele starszych wersji przeglądarek, w tym Chrome, Safari i UC, jest niezgodnych z nowym atrybutem None i może zignorować lub ograniczyć użycie ciasteczek. To zachowanie jest ustalone w aktualnych wersjach, ale należy sprawdzić ruch, aby określić, na jaki odsetek użytkowników będzie to miało wpływ. Listę znanych niekompatybilnych klientów można zobaczyć na stronie projektu Chromium.

Ten artykuł otwiera serię, w następnej części napiszę trochę o tym jak konfigurować instalację ciasteczek w różnych scenariuszach, później o wpływie na logowanie za pośrednictwem usług federacyjnych Active Directory Federation Services (i zmianach w styczniowych poprawkach dla Windows Server) oraz w Azure, a na koniec o tym jak przygotować klientów za pomocą GPO, Intune i MDM 

Testy połączeń LDAP

Przetestujmy poszczególne rodzaje połączeń wykorzystując jednego z wcześniej opisanych klientów LDAP. Jeśli testy będą powtarzane, wówczas poszczególne konfiguracje połączeń najlepiej zapisać jako szablon, z którego będziemy mogli skorzystać w przyszłości. 

Logowanie anonimowe (Anonymous)

W oknie kreatora połączenia należy wprowadzić adres docelowego kontrolera domeny oraz port (domyślnie jest to port TCP 389) oraz wskazać Anonymous jako docelowy poziom zabezpieczeń dla połączenia. 

Połączenie do utwardzonego kontrolera domeny powinno zakończyć się niepowodzeniem. A to dlatego, że wymaga on poprawnego uwierzytelnienia, aby przeglądać zawartość katalogu LDAP. 

Pierwszy test zakończony sukcesem. Przeanalizujmy jeszcze ruch sieciowy, co będzie szczególnie użyteczne, gdy klient LDAP (w prawdziwym środowisku) nie oferuje obsługi błędów i wyświetla komunikat w stylu „Połączenie nie powiodło się, skontaktuj się z administratorem”. 

W przypadku dostępu anonimowego, klient bezpośrednio wysyła zapytanie (searchRequest) do wskazanego serwera LDAP. 

O tym nie może być jednak mowy. Uprawnienie odczytu informacji z katalogu (general read, GR) domyślnie posiadają tylko zalogowani użytkownicy.

Odpowiedź serwera może być tylko odmowna - choć informuje on od razu w czym rzecz (errorMessage 000004DC: LdapError: DSID-0C090A37). Większość monitorów sieciowych posiada wbudowane parsery, na załączonym zrzucie ekranu Wireshark dodaje komentarz (comment: In order to perform this operation a successful bind must be completed on the connection). 

Proste uwierzytelniania - Simple bind 

W kreatorze połączenia, ponownie wskazujemy utwardzony kontroler domeny jako cel, wykorzystując przy tym podstawowy port usługi LDAP TCP 389. Wybrany poziom bezpieczeństwa to User + Password, w kreatorze podajemy DN użytkownika oraz jego hasło. 

 I w tym przypadku spodziewamy się zobaczyć błąd połączenia. Klient zostaje poinformowany o konieczności zestawienia połączenia SSL\TLS, aby poświadczenia nie były przesyłane jawnym tekstem. 

Zobaczmy jak wygląda komunikacja zarejestrowana podczas próby połączenia w Wiresharku. 

Klient przesłał nazwę użytkownika oraz jego hasło jawnym tekstem, co pozwoliło na przechwycenie jego poświadczeń. 

Jeśli użytkownik posiada istotne uprawnienia w Active Directory lub firmowych aplikacjach, pozyskane w ten sposób poświadczenia mogą zostać wykorzystane bez jego wiedzy.

Serwer odrzucił żądanie oraz wskazał powód swojego zachowania (errorMessage: 00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integritychecking if SSL\TLS are not already active on the connection).  

Z tej perspektywy ważne jest, aby utwardzić nie tylko kontrolery domeny, ale także klientów. To, że serwer nie akceptuje połączeń, nie znaczy, że klienci nie będą próbować się nimi posługiwać i narażać poświadczenia na podsłuchanie i przechwycenie. 

Uwierzytelnianie w tunelu SSL/TLS  – LDAPS bind

Testy połączeń SSL/TLS zaczynamy od weryfikacji obecności poprawnych certyfikatów na kontrolerach domeny. W tym celu możemy posłużyć się skryptem Audit-DcTlsCertificate. Skrypt połączyć się z wszystkim dostępnymi kontrolerami domeny na porcie 636, pobierze certyfikaty oraz wyświetli listę w oknie wynikowym (OGV).  

.\Audit-DcTlsCertificate.ps1

Kluczowe jest, aby certyfikaty były poprawne (przede wszystkim, aby zgadzała się nazwa serwera, z którym będziemy się łączyć (FQDN) oraz nazwa podmiotu dla którego wystawiono certyfikat (CN) oraz okres ważności (Valid from i Valid to). Zwróćcie też uwagę, by certyfikat obsługiwał obsługę uwierzytelnienia serwera (Server authentication, 1.3.6.1.5.5.7.3.1).

Jeśli testy chcemy ograniczyć do pojedynczego serwera (np. tylko testowo utwardzonego kontrolera domeny), możemy użyć skryptu Retrieve-ServerCertFromSocket. Pozwoli pobrać certyfikat z wskazanego kontrolera domeny, a także zweryfikować bezpośrednio na kliencie. 

Retrieve-ServerCertFromSocket pfe-dc1.pfe.academy 636 | Export-Certificate -FilePath C:\temp\test.cer ; start c:\temp\test.cer

Test-Certificate $(Retrieve-ServerCertFromSocket pfe-dc1.pfe.academy 636)

Windows ufa tylko certyfikatom wydanym przez urzędy, których certyfikaty są zintegrowane z systemem (wbudowane lub zostały doinstalowane, na przykład w czasie dodawanie do domeny Active Directory). 

W naszym przypadku, certyfikat pochodzi z zaufanego, wewnątrzorganizacyjnego centrum certyfikatów oraz spełnia pozostałe kryteria. 

Możemy zatem przystąpić do testów połączeń w programie JExplorer. Tutaj jednak czeka nas rozczarowanie, bo aplikacje Java (oraz kilku innych bibliotek lub platform) nie wykorzystują systemowego magazynu certyfikatów. Zatem podczas próby połączenia zobaczmy błąd.

Wystarczy dodać certyfikat serwera (np. gdy ten jest samopodpisany (self-signed) lub całego urzędu certyfikatów (np. gdy wewnętrznie dostępne serwery używają certyfikatów wydanych przez organizacyjne CA). 

W tym celu należy przejść do Security > Trusted Servers and CAs, aby w pierwszej kolejności przekonać się o zaufanych certyfikatach (i braku tych związanych z usługą LDAP). 

A następnie dodać stosowny certyfikat (najlepiej root-ca).

Jeśli certyfikat pochodzi z zaufanego głównego lub podrzędnego urzędu certyfikatów, odpowiednia informacja znajdzie się w jego właściwościach. 

Teraz możemy przejść do właściwych testów połączeń LDAP. 

W kreatorze połączenia wskazujemy utwardzony kontroler domeny na porcie 636 oraz poziom zabezpieczeń SSL + User + Password. 

Nazwa użytkownika oraz hasło w dalszym ciągu przesyłane są tekstem, ale informacje są zenkapsulowane w bezpiecznym tunelu SSL/TLS, przez co nie da się ich podsłuchać w sieci. Połącznie dochodzi do skutku. 

Rzućmy jeszcze okien na przebieg komunikacji zarejestrowany w Wiresharku. 

W pierwszej kolejności zestawiane jest połączenie TLS. Klient żąda zestawienia sesji, którą należy uzgodnić. Przesyła więc komunikat Client Hello, a w nim pożądana wersję protokołu (TLS 1.2) oraz zestaw wspieranych przez siebie algorytmów kryptograficznych, w postaci uporządkowanej listy (od najbardziej preferowanego).

W odpowiedzi na żądanie, serwer wysyła odpowiedź Server Hello dostarczając klientowi klucz publiczny swojego certyfikatu. Pierwsza część komunikacji w tunelu TLS szyfrowana jest asymetrycznie (z wykorzystaniem pary kluczy, prywatnego oraz publicznego - komunikaty zaszyfrowane jednym mogą być odszyfrowane tylko drugim). 

Kiedy obie strony mogą wymienić się kluczem, sesja przechodzi na szyfrowanie symetryczne (co zmniejsza zużycie czasu procesora po obu stronach komunikacji). 

Dalsza część komunikacji odbywa się w przygotowanym tunelu SSL\TLS. 

Poświadczeń, zapytań oraz odpowiedzi LDAP nie da się podsłuchać. Integralność i poufność komunikacji są zapewnione dzięki opakowaniu połączenia protokołu LDAP w tunelu TLS.

Uwierzytelnianie z użyciem bibliotek SASL 

Simple Authentication and Security Layer (SASL) to metoda dodania warstwy uwierzytelniania użytkownika m.in. dla protokołu LDAP. Ciężar uwierzytelniania oraz zabezpieczania komunikacji LDAP przesuwa się na jeden z wspieranych przez SASL mechanizmów. 

W pierwszej kolejności sprawdźmy jakie mechanizmy SASL są obsługiwane przez Active Directory. 

Get-ADRootDSE | select rootDomainNamingContext,supportedSASLMechanisms |ft -AutoSize

Wygląda obiecująco, sprawdźmy, z czego może skorzystać klient. 

Generic Security Service Application Program Interface (GSSAPI, czasami nazywany też GSS-API) to interfejs programistyczny pozwalający aplikacjom uzyskiwać dostęp do usług bezpieczeństwa, za pośrednictwem których realizowane jest uwierzytelniania, np. z użyciem protokołu Kerberos.

Oznacza to, że nie musimy tunelować połącznia i używamy standardowego portu 389. 

Po wytypowaniu tego poziomu zabezpieczeń w kliencie, otrzymujemy pytanie o nazwę użytkownika oraz jego hasło. Posłużą one do pozyskania biletów kerberosowych. 

Utwardzony kontroler domeny bez problemowo obsługuje żądanie klienta.

Tutaj przebieg komunikacji sieciowej jest zdecydowanie najciekawszy, rzućmy okiem na ruch przechwycony za pomocą Wireshark. 

Na początek klient ustala właściwy serwer, który obsłuży uwierzytelnianie domenowe. W tym celu odszukuje za pomocą zapytań dns-owych właściwy dla swojej podsieci kontroler domeny (rekord SRV dla nazwy _kerberos._udp.pfe.academy). 

Następnie wysyła żądanie uwierzytelnienia użytkownika, co pozwoli pozyskać bazowy bilet kerberosowy (ticket granding tickets, TGT). 

Poświadczenia użytkownika nie są wysyłane tekstowo, zamiast tego (w dużym uproszczeniu) klient szyfruje skrótem swojego hasła informację, którą z użyciem tego samego skrótu zapisanego w bazie AD kontroler rozszyfrowuje. 

Jeśli użytkownik podał poprawne hasło (udało się z niego wyliczyć właściwy skrót do zaszyfrowania komunikatu), kontroler domeny wydaje tiket TGT.

To jednak dopiero połowa drogi, użytkownik jest uwierzytelniony w domenie. Tymczasem usiłuje dostać się do konkretnej usługi na kontrolerze domeny. W tym celu musi zażądać od kontrolera domeny tiketu TGS. 

W żądaniu klient jasno precyzuje nazwę usługi i serwer, co pozwala wydać poprawny bilet, zaszyfrowany skrótem hasła wskazanego serwera, tak aby tylko on mógł otworzyć jego zawartość.

Dopiero teraz klient jest uzbrojony i żąda uwierzytelnienia w usłudze LDAP z użycie posiadanego już biletu. 

Kontroler domeny poprawnie obsługuje żądanie, a nazwa użytkownika oraz członkostwo w grupach zabezpieczeń zawarte w tikecie TGS wyznaczają kontekst po stronie serwera LDAP.

Bilety kerberosowe pozyskane przez oprogramowanie, które wykorzystuje biblioteki systemowe można podejrzeć za pomocą programu klist. 

klist

Pamiętajcie, że raz otrzymane bilety mają określoną ważność i przy następnym połączeniu do tego samego serwera LDAP nie będzie konieczności ich ponownego pozyskania. 

Jeśli ominęły was poprzednie części z serii poniżej znajdziecie odnośniki. 

Zmiany w obsłudze komunikacji LDAP - część 1/5

Zmiany w obsłudze komunikacji LDAP - część 2/5

Zmiany w domyślnych ustawieniach komunikacji LDAP (PDF) - część 3/5

Zmiany w domyślnych ustawieniach komunikacji LDAP (wideo) - część 4/5

Ma href="https://blog.pfe.academy/post/190408395313/zmiany-w-obs%C5%82udze-komunikacji-ldap-cz%C4%99%C5%9B%C4%87-55">Zmiany w obsłudze komunikacji LDAP - część 5/5

The number of bytes of memory allocated for the ACL. The size of an ACL varies with the number and size of its ACEs. The maximum size of an ACL is 64K, or approximately 1,820 ACEs, depending on the size of the ACEs. However, for performance reasons, the maximum size is not practical, it will vary from 1820 to 2000. Źródło: How Security Descriptors and Access Control Lists Work  

The maximum size for an ACL, including its ACEs, is 64 KB (Reference: http://msdn2.microsoft.com/en-us/library/Aa374931.aspx ) It’s about the 64KB ACL size limit of Windows. It stands on every object supporting ACL Źródło: Maximum number of ACEs in an ACL 

Jeśli jest ograniczenie to trzeba się zastanowić nad dwiema rzeczami. Po pierwsze, czy da się przekroczyć opisany limit (a zatem czy jest on zablokowany i narzędzie zwróci błąd przy przekroczeniu rozmiaru) oraz co się dzieje, gdy zostanie przekraczony (jeśli narzędzie nie blokuje zmian powyżej limitu)? Po drugie czy i jak można monitorować wielkość list ACL?

Microsoft, a nie mógłbyś precyzyjnie określić liczbę wpisów w ACL? I ile to jest „w przybliżeniu 1820”? Nie da rady, bo poszczególne wpisy (access control entry, ACE) różnią się długością, w zależności od ustawień. 

Zastanówmy się, więc jak precyzyjnie zmierzyć rozmiar listy, we właściwościach obietków zobaczymy zinterpretowaną listę (nazwy podmiotów (użytkownicy, grupy, komputery) i ich uprawnienia). 

Jak zmierzyć rozmiar listy kontroli dostępu ACL?

Pomysł pierwszy, zrzućmy listę do pliku i sprawdźmy jego rozmiar. W tym celu zrzućmy ACL za pomocą programu icacls. 

icacls C:\Scripts /save C:\Temp\AclFile.txt /T

Następnie sprawdźmy rozmiar pliku. 

Write-Host((Get-Item "C:\Temp\AclFile.txt").length/1KB)

Przyznacie, że w przypadku plików i folderów sprawa jest nieskomplikowana i bez trudnu można by to zautomatyzować (jeśli zajdzie taka potrzeba). 

A co właściwie zapisało się w pliku? Jak wygląda lista i w jakim formacie icacls zapisał dane do pliku?

Powyższy format zapisu to Security Descriptor Definition Language (SDDL). Mało czytelny, ale skondensowany. I o to chodzi, gdy ma się „tylko” 64k miejsca. Rzućmy jeszcze okiem na ACE strings (jeden z formatów za pomocą których wyświetlane są listy ACL w PowerShell). 

(Get-Acl -Path "C:\Scripts\");(Get-Acl -Path "C:\Scripts\").Access

Następnie analogicznie dla obietków katalogu Active Directory. 

Get-Acl -Path "AD:CN=Domain Users,CN=Users,DC=pfe,DC=academy" | Format-List -Property PSPath,Sddl

Jeśli przyjmiemy, że przy kodowaniu Win-1250, jeden znak zajmuje 8 bitów, czyli 1 bajt, to możemy w prosty sposób przeliczyć wielkość ACL.

((Get-Acl -Path "AD:CN=Domain Users,CN=Users,DC=pfe,DC=academy").Sddl | Measure-Object -Character).Characters*8/1kb

Udanych pomiarów w waszych środowiskach! Na koniec jeszcze kilka odnośników do materiałów źródłówych:

What is 64k ACL limit. 

How Security Descriptors and Access Control Lists Work

ACL structure

Best practices and guidance for writers of service discretionary access control lists

Access Control Lists

Security Descriptor Definition Language