Jak zarządzać obsługą parametru SameSite w ciasteczkach od strony przeglądarek internetowych?
Na początku tego roku w zwięzły sposób opisałem, o co chodzi w parametrze SameSite w ciasteczkach, a także o tym, jak skonfigurować atrybut SameSite w serwerach aplikacji webowych.
W zasadzie wszystkie przeglądarki uwzględniły zmiany w sierpniu. Jednak w wielu wypadkach dostawcy nie zaimplementowali tej funkcjonalności po stronie serwerów aplikacyjnych. Jeśli w waszym środowisku macie taką mieszankę zgodnych i niezgodnych rozwiązań, musicie zastanowić się, jak to obsłużyć po stronie klienckiej. W okresie zmian możecie zastosować obejście w postaci zaaplikowania odpowiednich ustawień po stronie klienta dla wszystkich lub wybranych witryn.
Proponuję posłużyć się ustawieniami zasad grup środowiska domenowego lub profilami ustawień Intune.
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.
Niektóre nazwy wbudowanych w Azure AD ról uległy zmianie zgodnie z zapowiedzią z 11 lipca, kiedy opublikowano ogłoszenie o identyfkatorze MC218295 w Message Center w M365 Admin Center.
Zmianami objęte są tylko nazwy wyświetlane, identyfikatory oraz uprawnienia pozostają bez zmian. W wyniku zmian nazwy wszystkich ról widocznych w Microsoft 365 admin center, Azure AD portal oraz Microsoft Graph API będą spójne.
Jeśli w waszych skryptach wybieracie role po nazwie, należy je zaktualizować przed 14 sierpnia 2020.
Lista zmienionych z uwagi na niespójność ról Azure AD.
Przygotowanie środowiska pracy Office 365 dla Edukacji
Office 365 dla Edukacji daje dostęp do unikalnych usług i oprogramowania wspierającego edukację na wiele sposobów. Dostarcza podstawowych aplikacji pakietu biurowego Microsoft Office oraz dedykowane scenariuszom edukacyjnym usługi w chmurze Microsoft. Jeśli jesteś nauczycielem lub uczeniem, ten przewodnik pomoże ci szybko przygotować środowisko pracy Windows za pomocą bezpłatnych dodatków i aplikacji.
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
[10] Strona programu OneDrive z klasycznym pakietem instalacyjnym – https://onedrive.live.com/about/pl-PL/download
[11] Co jest importowane z Google Chrome do Microsoft Edge – https://support.microsoft.com/pl-pl/help/4533249/microsoft-edge-whats-imported-from-google-chrome
Office 365 dla Edukacji jako rozwiązanie do zdalnego nauczania!
COVID-19 zatacza coraz szersze kręgi. Prace inżynierów Microsoft realizowane są prawie wyłącznie w trybie zdalnym, także coraz większa liczba klientów, z którymi pracuję, decyduje się na uruchomienie specjalnych procedur, głównie prac zdalnych (remote work) lub prac z domu (home office), a także realizację zaplanowanych wspólnie prac przez Teams.
Problem ten dotyka coraz większej liczby osób, nowych grup społecznych i zawodowych. Wiele szkół i uczelni zdecydowało się lub otrzymało rządowe polecenie zawieszenia zajęcia, mając na uwadze zdrowie i bezpieczeństwo uczniów, studentów, wykładowców oraz pracowników.
Microsoft wspiera obecną sytuację w szkołach w Polsce poprzez dostęp do zdalnej edukacji i umożliwienie nauczycielom za pomocą technologii zapewnienie ciągłości edukacji z zachowaniem współpracy między studentami.
W ofercie Microsoft od lat figuruje specjalna pozycja — Office 365 dla Edukacji. To przede wszystkim możliwość zorganizowania pracy zdalnej uczelni, bezpieczny dostęp do zasobów edukacyjnych oraz poufnych danych studentów i nauczycieli (zgodne z RODO).
Usługi i aplikacje udostępniane w planie Office 365 A1 są bezpłatnie, w tym:
Exchange — poczta e-mail dla każdej osoby w szkole
OneDrive — wirtualny dysk z możliwością wymiany plików z innymi osobami i synchronizacją różnych urządzeń (telefon, komputer domowy, komputer w szkole),
Office Online — przeglądarkowa wersja pakietu biurowego,
OneNote — notatnik z funkcją synchronizacji pomiędzy różnymi urządzeniami,
Teams — komunikator z obsługą pracy grupowej, czatu i rozmów audio i wideo.
Z perspektywy prowadzenia lekcji oraz utrzymywania relacji z członkami szkolnych i klasowych społeczności Microsoft Teams jest idealnym rozwiązaniem.
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.
Szczegóły dostępne są na stronie Get Microsoft Teams for free oraz na blogu w artykule Our commitment to customers during COVID-19.
Na początku marca, Alex Simons, poinformował o nowych opcjach brandowania ekranu logowania w Azure AD B2C, jakie trafiły do publicznej wersji zapoznawczej.
Rozpoznawalność marki czy logo jest dla większości dostawców aplikacji, czy treści bardzo ważna. W odpowiedzi na ich potrzeby udostępnione zostały nowe opcje związane ze zmianą wyglądu witryny logowania — zmiana logo oraz tła.
Do tej pory witryna logowania dla wszystkich organizacji byłą identyczna i wyglądała jak na poniższym zrzucie ekranu:.
Przykładowy wygląd, po zmianach pozwalających na zastosowanie własnego logo i tła, wygląda tak:
Co więcej, brandowanie można zastosować także do e-maili weryfikacyjnych. Oznacza to, że gdy użytkownicy logują się lub resetują hasło, wiadomość jaką otrzymają, może zostać dostosowana.
Obok zmian dotyczących wizualne prezentacji, administratorzy mogą teraz modyfikować ustawienia kodów weryfikacyjne, w tym długość, dozwolone znaki, długość ważności oraz liczbę wadliwych prób.
Szczegóły konfiguracji opisano w artykułach: Custom email verification in Azure Active Directory B2C oraz Customize the user interface in Azure Active Directory B2C. Zachęcam do lektury.
Dlaczego wieloskładnikowe logowanie powinno być priorytetem w twojej organizacji?
27 lutego, zespół Azure AD opublikowała ciekawą ikonografikę na blogu, Flash whitepaper: Why MFA is a top priority in 2020.
Warto wziąć na tapetę (choć nie dosłownie) przedstawione w dokumencie zalecenia. Całość zaczyna się chwytliwym sloganem: „Twoje hasło gwarantowało bezpieczeństwo wczoraj. Niestety jutro to nie wystarczy”. Ile w tym prawdy?
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.
Jeśli jeszcze nie wdrożyliście wieloskładnikowego logowania w organizacji, MFA zdecydowanie powinno znaleźć się na liście celów waszej organizacji w tym roku. Dodatkowo należy stale pracować nad rozszerzaniem możliwości jego zastosowania! Zarówno Azure AD Application Proxy, jak i AD FS, umożliwiają wam szybkie zintegrowanie Azure MFA z aplikacjami webowymi.
Zmiany w obsłudze User-Agent w przeglądarkach opartych na Chromium
Zgodnie z publikacjami na blogu projektu Chromium, w sierpniu 2019 r. w ramach Privacy Sandbox Project, został opracowany mechanizm Client Hints. Pod koniec ubiegłego miesiąca ponownie zrobiło się o nim głośno, a to za sprawą publikacji Mike Westa (Chrome Security Team) i Yoav Weissa (Chrome Developer Relations Team) na W3C Community Group i zapowiedzi jego implementacji przed końcem roku.
Zasięg zmian jest bardzo szeroki, bo obejmuje wszystkie zależne od Chromium przeglądarki, co sumarycznie przekłada się na ponad 75% użytkowników.
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:
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.
Z drugiej strony, może to być także dodatkowa motywacja dla grupy produktowej, aby wznowiono prace nad mechanizmami WiaCapabilityDetection oraz dostarczono ich publicznej dokumentacji.
W poprzedniej części serii poświęconej zmianom w obsłudze ciasteczek pokazałem, o co chodzi w SameSite w ciasteczkach, skrótowo wyjaśniając co to są ciasteczka, jak konfigurowane i instalowane są pliki cookies oraz jak są obsługiwane przez przeglądarki.
Dzisiaj chcę pokazać, w jaki sposób przeglądarki oparte na Chromium implementują wytyczne RFC6265bis oraz podzielić się przepisami na „udane ciasteczka”.
Zacznijmy od tego, że zmiany pojawią się w stabilnych wydaniach najpopularniejszych przeglądarek już za kilka dni. W Google Chrome w wersji 80 zaplanowanej na 4 lutego 2020. Microsoft Edge około tygodnia później (15 stycznia udostępniono pierwszą wersję stabilną, nie ma jeszcze oficjalnego terminarza wydań, ale dotychczasowa praktyka pokazuje przynajmniej kilkudniowe opóźnienie względem Chromium). W Firefoksie domyślne ustawienia raczej nie zostaną zmienione wcześniej niż wraz z wydaniem Firefox ESR 68.6, a więc 6 marca.
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.
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:
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.
Tekst jest częściowo oparty na artykule SameSite cookie recipes autorstwa Rowana Merewooda.
Ciasteczka są jedną z metod dodawania trwałych stanów do witryn i aplikacji webowych. Przez lata ich możliwości rozszerzały się i ewoluowały, jednocześnie ciągnąć przez cały ten czas pewne problemy platformowe. Aby je zaadresować, przeglądarki (włączając w to Chrome, Firefox, Edge i ich pochodne) zmieniają zachowanie tak, by domyślnie egzekwować bardziej rygorystyczne zasady zachowania prywatności.
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:
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:
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:
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.
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
Wpis jest w znacznej części oparty na artykule SameSite cookies explained.
Artykuł jest ostatnią częścią serii „Zmiany w obsłudze komunikacji LDAP”. Odnośniki do poprzednich części znajdziecie na końcu. Dzisiaj pokażę wam przykłady testowania połączeń z usługą LDAP, po jej utwardzeniu, zgodnie z docelowymi ustawieniami Windows Server po zastosowaniu poprawek zaplanowanych na marzec 2020.
Jakich aplikacji użyć, aby wydajnie weryfikować oraz testować stan zabezpieczeń komunikacji LDAP?
Podstawowa zasada brzmi, użyj znanego sobie oprogramowania, a to z kilku powodów. Prawie na pewno jest już zainstalowane i dozwolone w firmie. Używaliście go już nie raz, więc interfejs i możliwości są wam znane. Można skupić się na pracy, a nie narzędziu do jej wykonania.
Jeśli do tej pory nie wykonywaliście takich testów lub po prostu jesteście ciekawi, co polecam, zachęcam do zapoznania się z poniższą listą.
PowerShell – jeśli chcecie zrobić coś wsadowo lub uruchamiać automatycznie, np. z poziomu platformy do monitorowania, to wybór jest dość oczywisty. Koniecznie zapoznajcie się z dokumentacją ADSI adaptera oraz przestrzenią nazw System.DirectoryServices.
LdapAdmin – darmowy klient oraz narzędzie do administracji katalogami LDAP dla Windows. Pozwala na podstawowe operacje (przeglądanie, wyszukiwania, modyfikację, tworzenie i usuwanie obiektów) oraz bardziej zaawansowane operacje (takie jak kopiowanie i przenoszenie obiektów pomiędzy serwerami).
LDAPExplorerTool – wieloplatformowa przeglądarka i edytor LDAP z graficznym interfejsem użytkownika. Program jest testowany przez twórców w systemach Windows i kilku dystrybucjach Linuksa (m.in. Debian, Red Hat).
JXplorer – wieloplatformowy klient usługi i edytor LDAP napisany w Javie (wymaga JRE). Program jest testowany przez twórców w systemach Windows, Solaris, Linux i OSX, ale gotowe paczki dostępne są także dla HPUX, AIX, BSD i wszystkiego, co uciągnie JRE.
Jak wyglądają scenariusze testów?
Testy powinny być miarodajne (pokazywać, że coś działa (w ogóle lub w oczekiwany sposób) lub że nie działa). W przypadku naszego ćwiczenia, testowanie ma na celu potwierdzenie, że nowe utwardzone ustawienia kontrolera domeny pozwalają na bezpieczne oraz blokują niebezpieczne metody komunikacji LDAP.
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.
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.
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
Prezentacja na temat zakresu zmian w domyślnych ustawieniach zabezpieczeń komunikacji LDAP w systemach Windows Server, jakie dystrybuowane będą od marca 2020 w zbiorczych pakietach poprawek.
Maksymalny rozmiar listy kontroli dostępu (ACL) na obiektach katalogu Active Directory
Wszystkie obiekty w usłudze Active Directory i wszystkie dające się zabezpieczyć obiekty na komputerze lokalnym lub w sieci posiadają tzw. deskryptory zabezpieczeń, które pomagają kontrolować dostęp do obiektów. Deskryptory zabezpieczeń zawierają informacje o tym, kto jest właścicielem obiektu (owner), kto może uzyskać do niego dostęp i w jaki sposób oraz jakie są zasady audytowania dostępu.
Deskryptory zabezpieczeń obiektu zawierają listy kontroli dostępu (access-contol list, ACL) opisujące wszystkie uprawnienia zabezpieczeń, które dotyczą tego obiektu. Co do zasady deskryptory mogą zawierać dwa rodzaje list ACL:
Arbitralna lista kontroli dostępu (discretionary access control list, DACL), które identyfikuje użytkowników i grupy, którym zezwala się lub odmawia dostępu;
Systemowa lista kontroli dostępu (system access control list, SACL), która kontroluje sposób audytowania dostępu.
Ten model kontroli dostępu może być stosowany do zabezpieczania jednostkowych obiektów takich jak pliki i foldery, obiektów Active Directory, kluczy rejestru, drukarek i innych urządzeń, portów, usług, procesów i wątków. Granularności ustawień pozwala elastycznie dostosować zabezpieczenia do wymagań organizacji, wydeloegować uprawnienia do obiektów oraz ich atrybutów.
Nie ma różny bez kolców, mechanizm ma ograniczenia pojemnościowe oraz nie jest specjalnie wygodny w utrzymaniu. Dzisiaj na tapetę weźmy ograniczenia rozmiaru.
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.
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).
W Windows 10 oraz Windows Server 2016 i nowszych wykryto poważną lukę w zabezpieczeniach. Wykorzystanie luki umożliwia fałszowanie podpisów cyfrowych wydawców oprogramowania (szczególnie ważne podczas weryfikowania integralności binariów (np. plików exe lub dll) oraz certyfikatów dla ruchu HTTP over TLS.
W Windows Server 2016 i nowszych usługa serwera nazw (DNS) wspiera rejestrację rekordów SRV uwzględniając wielkość liter w nazwie hosta (case-sensitive). O czym wiele osób przekonało się wkrótce po wprowadzeniu nowej wersji systemu operacyjnego do środowiska Active Directory.
Kontrolery domeny działające pod kontrolą systemu Windows Server 2016 lub nowszych, których nazwy zawierają jedną lub więcej wielkich liter w nazwie, mogą rejestrować rekordy SRV zawierające tylko małe litery, gdy usługa serwera nazw, z której korzystają jest uruchomiona w systemie Windows Server 2012 R2 lub starszym, a dodatkowo rekordy zawierające mieszane lub wyłącznie wielkie literami, gdy serwer nazw jest uruchomiony na Windows Server 2016 lub nowszym.
Powodowane jest to obsługą rozróżniania wielkości liter w przesłanym w żądaniu rejestracji informacjach RDATA do serwera DNS.
Czy zduplikowane rekordy mogą być szkodliwe?
W większości wypadków nie będzie to miało większego wpływu na dostępność usługi ani wydajność kontrolerów domeny. Niemniej te kontrolery domeny, które zarejestrują lokatory usług podwójnie będą występować dwukrotnie częściej na liście serwerów przy zapytania klientów (więcej o mechniźmie DC Locator). To z kolei może oznaczać nadmierną utylizację serwerów z powielonymi rekordami, nierównomierny rozkład klientów oraz generować opóźnia w obsłudze żądań klientów domeny.
Poniższy zrzut ekranu prezentuje zduplikowane rekordy SRV _kerberos zarejestrowane przez kontroler domeny o nazwie PFE-DC1 (zawiera wielkie litery).
Kolejny przykład zawiera rekordy SRV _ldap zarejestrowane przez ten sam kontroler domeny.
Przyznacie, że sprawa wygląda nieciekawie? Co w tej sytuacji zrobić?
Powyższe zachowanie serwera DNS, na którym rejestrowany lub odświeżany jest rekord jest poprawnym zachowaniem dla Windows Server 2016 i nowszych. Zatem jest to “problem”, a nie problem. Klienci dysponujący wsparciem mogą otworzyć zgłoszenie i otrzymają prywatną poprawkę (private fix).
Docelowo, w marcowym zbiorczym pakiecie poprawek oraz towarzyszącym mu wydaniu szablonów administracyjnych zasad grup znajdzie się nowe ustawienie, które pozwoli zablokować rejestrację zdublowanych rekordów.
Nowe ustawienie dostępne będzie w następującej ścieżce:
Computer Configuration\Policies\Administrative Templates\System\Net Logon\DC Locator DNS Records\Use lowercase DNS host names when registering domain controller SRV records
I będzie stosowane domyślnie (czyli nawet wówczas, gdy nie będzie skonfigurowane (Not configured)).
Do tego czasu zalecana jest zmiana nazwy kontrolerów domeny, na taką która zawierać będzie tylko małe litery (tak, wspieramy to, choć w niektórych wypadkach należy pamiętać o dodatkowych czynnościach). Przy okazji warto zaznajomić się z dokumentacją, w pierwszej kolejności polecam artykuł Computer Naming, a następnie Naming conventions in Active Directory.
A co z pozostałościami? Jeśli zgodnie z rekomendacjami stosujecie automatyczne czyszczenie stref z przestarzałych rekordów (scavenging), rekordy zostaną usunięte automatycznie.
Jeśli nie stosujecie scavenging lub nie chcecie czekać na wyniki jego działania, możecie usunąć pozostałości samodzielnie. W dalszej części opiszę jak skryptowo wylistować oraz usunąć rzeczone zduplikowane rekordy.
Jak sprawdzić jakie oraz ile rekordów SRV w mojej domenie zarejestrowano dla kontrolerów domeny z nazwami zawierającymi wielkie litery?
Na potrzeby tego ćwiczenia przygotowałem skrypt PowerShell, który pozwala zidentyfikować rekordy SRV w strefie funkcjonalnej Active Directory (_msdcs). Skrypt można pobrać z mojego repozytorium lub skopiować poniżej.
<# .SYNOPSIS Get-UppercaseDomainSrvRecords_v1.ps1 - Finds SRV records with upper-case letters in name registered under _msdcs. .DESCRIPTION This script will locate your Active Directory integrated DNS servers and find SRV records with upper-case letters in name registered under _msdcs. .OUTPUTS Object, allows sorting, filtering and pipe output date. .COPYRIGHT Grzegorz Glogowski - Microsoft Corporation .NOTES This script is provided "AS IS" with no warranties and confers no rights. Change Log V1.00, 20200112 - Initial version #> #Clear screen, useful when run in ISE cls <# #Set up domain specification, borrowed from PyroTek3 #https://github.com/PyroTek3/PowerShell-AD-Recon/blob/master/Find-PSServiceAccounts if(-not $Domain) { $ADDomainInfo = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() $Domain = $ADDomainInfo.Name } #> #Get Active Directory forest and domain information $forest = Get-ADForest $domain = Get-ADDomain #Find all DCs/DNS servers $dns = (Resolve-DnsName $($domain.DNSRoot) -type NS | ? {$_.type -eq "A"}).Name <#Alternative way to get DNS servers (LDAP query) - Windows Server 2008 R2 and older #Find DNS servers #https://social.technet.microsoft.com/wiki/contents/articles/18996.active-directory-powershell-script-to-list-all-spns-used.aspx $search = New-Object DirectoryServices.DirectorySearcher([ADSI]"") $search.filter = "(servicePrincipalName=DNS*)" $searchbase = "OU=Domain Controllers,"+$($domain.DistinguishedName) $results = $search.Findall() | ?{ $_.path -like $searchbase } $results = $search.Findall() $dns = $results.Properties.dnshostname #> #$dcs = $domain.ReplicaDirectoryServers $rootzone = $domain.DNSRoot $msdcszone = "_msdcs." + $rootzone #Get filtered set of SRV records from _msdcs $dnsrecords = Get-DnsServerResourceRecord -ZoneName $msdcszone | Where-Object {$_.RecordType -ne "NS" -and $_.RecordType -ne "SOA" -and $_.RecordType -ne "CNAME" -and $_.RecordType -ne "A" } #Get filtered set of SRV records from _msdcs with upper-case letters #$dnsrecords = Get-DnsServerResourceRecord -ZoneName $msdcszone | Where-Object {$_.RecordType -ne "NS" -and $_.RecordType -ne "SOA" -and $_.RecordType -ne "CNAME" -and $_.RecordType -ne "A" -and $_.RecordData.DomainName -cmatch '[A-Z]' } #Initialize the array $OutputObj = @() ForEach ($rr in $dnsrecords) { $name = $rr.HostName $type = $rr.RecordType $ttl = $rr.TimeToLive $created = $rr.Timestamp #$data = $rr.RecordData.DomainName #$data = $rr.RecordData | select DomainName -ExpandProperty DomainName | Out-String $data = $rr.RecordData | select DomainName -ExpandProperty DomainName $uppercase = $data -cmatch '[A-Z]' $OutputObj += New-Object -TypeName PSobject -Property @{ Name = $name Type = $type TTL = $ttl Created = $created Data = $data CaseSensitive = $uppercase } } #Get Active Directory sites $sites = ([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites).Name #Divide output into generic and site-specific SRV records with upper-case letters foreach ($site in $sites) { $currentpath = "_tcp." + $($site) + "._sites.dc." + $($msdcszone) -replace " ","" #Write-Host "Records with UPPER-CASE in: " $currentpath.ToLower() "`r`n" -ForegroundColor DarkYellow Write-Host "Records with UPPER-CASE in" $site "site container `r`n" -ForegroundColor DarkYellow $OutputObj | where {$_.Name -match $site -and $_.Case -eq $true} | select Name,Data | Format-Table -AutoSize } Write-Host "Records with UPPER-CASE in generic containers `r`n" -ForegroundColor DarkYellow $OutputObj | where {$_.Name -notmatch "._Sites." -and $_.Case -eq $true}| select Name,Data | Format-Table -AutoSize #EOF
Powyższy skrypt automatycznie wyświetla wyniki z podziałem na kontenery, w których znajdują się wykryte rekordy z wielkimi literami w nazwie.
Jeśli na wynika potrzebujecie wykonać sortowanie, filtrowanie lub chcecie je przesłać na wejście kolejnego polecenia, należy użyć następującego kodu.
<# .SYNOPSIS Get-UppercaseDomainSrvRecords_v2.ps1 - Finds SRV records with upper-case letters in name registered under _msdcs. .DESCRIPTION This script will locate your Active Directory integrated DNS servers and find SRV records with upper-case letters in name registered under _msdcs. .OUTPUTS Object, allows sorting, filtering and pipe output date. .COPYRIGHT Grzegorz Glogowski - Microsoft Corporation .NOTES This script is provided "AS IS" with no warranties and confers no rights. Change Log V1.00, 20200112 - Initial version #> #Clear screen, useful when run in ISE #cls <# #Set up domain specification, borrowed from PyroTek3 #https://github.com/PyroTek3/PowerShell-AD-Recon/blob/master/Find-PSServiceAccounts if(-not $Domain) { $ADDomainInfo = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() $Domain = $ADDomainInfo.Name } #> #Get Active Directory forest and domain information $forest = Get-ADForest $domain = Get-ADDomain #Find all DCs/DNS servers $dns = (Resolve-DnsName $($domain.DNSRoot) -type NS | ? {$_.type -eq "A"}).Name <#Alternative way to get DNS servers (LDAP query) - Windows Server 2008 R2 and older #Find DNS servers #https://social.technet.microsoft.com/wiki/contents/articles/18996.active-directory-powershell-script-to-list-all-spns-used.aspx $search = New-Object DirectoryServices.DirectorySearcher([ADSI]"") $search.filter = "(servicePrincipalName=DNS*)" $searchbase = "OU=Domain Controllers,"+$($domain.DistinguishedName) $results = $search.Findall() | ?{ $_.path -like $searchbase } $results = $search.Findall() $dns = $results.Properties.dnshostname #> #$dcs = $domain.ReplicaDirectoryServers $rootzone = $domain.DNSRoot $msdcszone = "_msdcs." + $rootzone #Get filtered set of SRV records from _msdcs $dnsrecords = Get-DnsServerResourceRecord -ZoneName $msdcszone | Where-Object {$_.RecordType -ne "NS" -and $_.RecordType -ne "SOA" -and $_.RecordType -ne "CNAME" -and $_.RecordType -ne "A" } #Get filtered set of SRV records from _msdcs with upper-case letters #$dnsrecords = Get-DnsServerResourceRecord -ZoneName $msdcszone | Where-Object {$_.RecordType -ne "NS" -and $_.RecordType -ne "SOA" -and $_.RecordType -ne "CNAME" -and $_.RecordType -ne "A" -and $_.RecordData.DomainName -cmatch '[A-Z]' } #Initialize the array $OutputObj = @() ForEach ($rr in $dnsrecords) { $name = $rr.HostName $type = $rr.RecordType $ttl = $rr.TimeToLive $created = $rr.Timestamp #$data = $rr.RecordData.DomainName #$data = $rr.RecordData | select DomainName -ExpandProperty DomainName | Out-String $data = $rr.RecordData | select DomainName -ExpandProperty DomainName $uppercase = $data -cmatch '[A-Z]' $OutputObj += New-Object -TypeName PSobject -Property @{ Name = $name Type = $type TTL = $ttl Created = $created Data = $data CaseSensitive = $uppercase } } #Get Active Directory sites $sites = ([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites).Name #Divide output into generic and site-specific SRV records with upper-case letters foreach ($site in $sites) { $currentpath = "_tcp." + $($site) + "._sites.dc." + $($msdcszone) -replace " ","" #Write-Host "Records with UPPER-CASE in: " $currentpath.ToLower() "`r`n" -ForegroundColor Yellow Write-Host "Records with UPPER-CASE in" $site "site container `r`n" -ForegroundColor Yellow $OutputObj | where {$_.Name -match $site -and $_.CaseSensitive -eq $true} | select Name,Data | Format-Table -AutoSize } Write-Host "Records with UPPER-CASE in generic containers `r`n" -ForegroundColor Yellow $OutputObj | where {$_.Name -notmatch "._Sites." -and $_.CaseSensitive -eq $true}| select Name,Data | Format-Table -AutoSize #EOF
Wówczas, sami zdecydujecie o tym, co dalej zrobić z wykrytymi rekordami.
Uwaga: Do poprawnego działania Active Directory niezbędne są odpowiednie strefy oraz rekordy DNS. Zalecam dużą dozę ostrożności i proszę nie róbcie niczego pochopnie, aby nie musieć naprawiać lub odzyskiwać środowiska!
Synchronizacja tożsamości z rozłączonych środowisk AD do Azure AD
Na początku grudnia, Alex Simons opublikował wpis na Azure Active Directory Identity Blog opisujący aprowizację (Managed provisioning). Warto zwrócić uwagę na możliwości dostarczane w ramach nowej funkcjonalności i sugerowane scenariusze użycia.
Jeśli pracujesz w dużym środowisku, najprawdopodobniej wiesz jak wiele wyzwań stwarza zakup, połączenie lub przejęcie innej organizacji (oraz jej środowiska IT, w szczególności katalogu użytkowników oraz usług).
Rozważasz migrację lub (przynajmniej czasowe) współistnienie środowisk, zasady dostępu, przepuszczenia komunikacji sieciowej, kierunki relacji zaufania oraz licencjonowanie. To, co w lokalnych środowiskach on-premises może zająć nawet kilka lat, w chmurze udaje się osiągnąć w znacznie krótszym czasie i to z wielu powodów, z których najważniejszymi wydają mi się być:
większa (względem wieloletnich środowisk on-premises) homogeniczność oprogramowania;
konwergencja rozwiązań technologicznych oraz protokołów;
mniejszy rozmiar środowiska (statystycznie chmura w polskim przedsiębiorstwie to wciąż dodatek lub hybryda, a nie główne lub równoważne środowisko);
brak wymogu kompatybilności z przestarzałymi systemami (te zwykle zostają w on-premises i z czasem tracą na znaczeniu, aby ostatecznie zostać wygaszone).
Azure AD Connect od początku obsługuje możliwość synchronizacji kont z wielu lasów Active Directory, choć nie wszystkie scenariusze takiej synchronizacji są wspierane (z uwagi na możliwe problemy). Większość organizacji jest w stanie zsynchronizować wiele katalogów użytkowników do pojedynczego tenanta.
Dzięki usłudze aprowizacji, administratorzy mogą zaopatrywać katalogi AAD w użytkowników z katalogów AD z wielu lasów Active Directory ze środowisk, które z różnych względów są odizolowane od funkcjonującej infrastruktury usług synchronizacyjnych Azure AD Connect. Jednocześnie przesuwając ciężar synchronizacji z AD do Azure AD za pomocą lekkich agentów instalowanych w źródłowym środowisku.
Jakie z tego korzyści? Kiedy stosować aprowizację?
Aprowizacja z rozłączonych lasów AD do Azure AD – Rozłączone lasy mogą być pozostałością przejęć lub podziałów w przedsiębiorstwie, a nawet obsługi zewnętrznych lokacji i oddziałów. Niezależnie od powodu, aprowizacja w chmurze pozwala na szybką integrację katalogów z Azure AD.
Zmniejsza nakłady pracy i zużycie zasobów on-premises – Agent aprowizacji ma niewielkie wymagania i szerokie możliwości synchronizacji (konfiguracja i przetwarzanie w chmurze).
Wysoką dostępność – Można wdrożyć wielu agentów aprowizacji, aby zapewnić ich redundancję, w szczególności dla synchronizacji skrótów haseł (Password Hash Sync, PHS).
Czego nie załatwia aprowizacja? Kiedy nie stosować?
Aprowizacja nie może być stosowana równolegle z usługami synchronizacji Azure AD Connect – Konkretny las Active Directory może dostarczać użytkowników tylko jedną metodą. Nie jest wspierana synchronizacja za pomocą obu rozwiązań, podobnie z resztą, jak nie wspierane jest stosowanie dwóch lub więcej aktywnych serwerów Azure AD Connect.
Nie należy stosować aprowizacji jako zapasowe rozwiązanie w scenariuszach odzyskiwania (Disaster Recovery Procedure, DRP) lub utrzymania ciągłości działania dla usług synchronizacji – W celu zwiększenia dostępności usług synchronizacji powinno się wykorzystywać architekturę z serwerami działającymi w trybie zapasowym (staging mode) oraz wysokodostępnościową instancję serwera bazodanowego.
Aprowizacja nie nadaje się do testowania nowych reguł synchronizacji Azure AD Connect – Zmiany w konfiguracji katalogów oraz reguł synchronizacji najlepiej testować w dedykowanym środowisku lub na serwerze działającym w trybie staging.
Nie ma narzędzia, które automatyzuje migrację reguł z Azure AD Connect.
Jakie możliwości daje aprowizacja w chmurze?
Synchronizacja użytkowników, w tym filtrowanie po jednostkach organizacyjnych oraz członkostwie w grupie (pilot).
Koegzystencja z usługami synchronizacji Azure AD Connect Sync, przy czym użytkownik może przynależeć tylko do zakresu jednego narzędzia (synchronizacji albo aprowizacji).
Obsługa wielu modeli uwierzytelniania, w tym: synchronizacji haseł (PHS), federacji (AD FS) oraz bezproblemowego jednokrotnego logowania (Seamless SSO).
Podstawowe transformacje atrybutów z użycie Microsoft Graph API.
Jak skonfigurować aprowizację? I zainstalować agenta?
Uruchomienie cloud provisioningu jest procesem dwuetapowym. W pierwszym kroku instaluje się oprogramowanie agenckie na serwerze członkowskim w domenie. Następnie konfiguruje się opcje synchronizacji w portalu Azure.
Krok 1: Pobranie i instalacja agenta aprowizacji.
1. Przed instalacją agenta należy zweryfikować wymagania wstępne, w tym:
Dostęp do konta z uprawnieniami globalnego administratora w docelowym tenancie Azure AD.
Dostępność serwera w lokalnym katalogu AD z Windows Server 2012 R2 lub nowszym.
Dostęp do internetu (konfiguracja zapory ogniowej oraz serwerów pośredniczących).
2. Aby pobrać pakiet instalacyjny należy przejść do Azure AD Provisioning (Preview) i zaakceptować warunki użycia i licencję.
Instalacja rozpakowuje oprogramowanie i automatycznie uruchamia kreatora pierwszego uruchomienia.
W którym wskazujemy nazwę tenanta oraz zaopatrujemy agenta w odpowiednie uprawnienia w celu skonfigurowania komunikacji.
Krok 2: Konfiguracja aprowizacji.
1. W sekcji Azure AD Connect należy przejść do Manage provisioning (preview).
2. Następnie zainicjować nową konfigurację za pomocą opcji New configuration.
3. Wynikową konfigurację należy zatwierdzić przesuwając opcję w stan Enable.
Aprowizacja użytkowników będzie wykonywana co 2 minuty zgodnie z zachowaną konfiguracją. Dodatkowe informacje znajdują się w artykule Azure AD Connect cloud provisioning tutorials. Przed wdrożeniem zachęcam do zapoznania się z całą dokumentacją online, Azure AD Connect cloud provisioning.
Jeśli macie pomysły na ulepszenia lub marzy wam się jakaś niedostępna (jeszcze) opcja możecie przesyłać propozycje w ramach Azure AD UserVoice feedback forum.
Źródło i część zrzutów ekranu: Bring identities from disconnected ADs into Azure AD with just a few clicks!
Kilka ostatnich lat nauczyło mnie, że większość klientów stosuje domyślne opcje zabezpieczeń w zainstalowanych systemach i oprogramowaniu. Tymczasem domyślne opcje, dość często oznaczają konieczność zachowania wstecznej kompatybilności z systemami, które liczą sobie po kilkanaście lat i więcej.
Wiele środowisk przeszło utwardzanie, zwykle jednak było to wkrótce po ich wdrożeniu. Tymczasem dobre praktyki i rekomendacje w sferze zabezpieczeń zmieniają się zdecydowanie częściej. Wielu producentów odpowiada na nowo wykryte zagrożenia i scenariusze ataków na bieżąco i na różne sposoby, aby trafić do zróżnicowanych klientów, np. wydając poprawki zabezpieczeń (eliminujące wadliwie działający kod), publikując okresowe rekomendacje oraz instrukcje konfiguracji lub dostarczając usług przeglądów zabezpieczeń oraz usuwania lub minimalizacji wykrytych odstępstw od dobrych praktyk.
Jeśli jednak twoje środowisko Active Directory pamięta czasy Windows Server 2003 (lub nieco nowsze), w tym czasie zostało utwardzone, a później już tylko aktualizowane, to szansa, że twoje zabezpieczenia nie przystają do aktualnych zagrożeń, a może nawet pogarszają sprawy (nadpisując domyślne ustawienia nowszych wersji systemów), graniczy z pewnością.
Jak żyć? Przecież usługi przeglądów nie należą do najtańszych, a o bezpieczeństwo trzeba dbać.
Jeśli liczysz budżet jak góral dudki w sezonie, to Assessment for Active Directory Security zrób raz na rok lub dwa. A pomiędzy tymi okresami? Samodzielnie śledź zmiany i porównuj z ustawieniami zabezpieczeń w swojej organizacji.
Tutaj z pomocą przychodzą narzędzia takie jak Microsoft Security Compliance Toolkit (lub wiele wygodniejszy, choć nierozwijany Security Compliance Manager) oraz publikowane po każdym wydaniu półrocznym (Semi-Annual Channel, SAC) bazowe polityki ustawień zabezpieczeń.
Wersje robocze oraz końcowe polityk są ogłaszane na blogach i w sieciach społecznościowych. Polecam rozeznać się w pierwszej kolejności w publikacjach na Microsoft Security Baseline Blog.
Później przejść przez oficjalną dokumentację na aka.ms/baselines.
Kompletne materiały w wersjach finalnych są do pobrania z Microsoft Download Center (wraz z MSCT).
Polityki z bazowymi ustawieniami zabezpieczeń zawierają predefiniowane ustawienia zgodne z najnowszymi zaleceniami do ogólnego zastosowania na stacjach roboczych, serwerach członkowskich oraz kontrolerach domeny. Dodatkowo publikowane są również zestawy dla pakietu Office, BitLocker oraz Edge.
Ustawienia polityk można zaimportować do obiektów w swoim środowisku, co ułatwia ich wdrożenie i testy na “żywym organizmie”. Narzędzia w pakiecie pozwalają także zaaplikować ustawienia lokalnie na komputerach pilotażowych, przygotować porównanie z ustawieniami innych polityk oraz wygenerować raport z różnic w ustawieniach.
I ostatnia sprawa, obok polityk dostarczane są także dedykowane szablony administracyjne, które ułatwiają administrowanie niektórymi ustawieniami za pomocą Edytora zarządzania zasadami grupy (gpmc.msc).
Zachęcam do zapoznania się ze wskazanymi materiałami. Jeśli czas pozwoli, wrzucę nagranie lub notatkę na temat posługiwania się Microsoft Security Compliance Toolkit lub Security Compliance Manager.
