Microsoft AZ-801: Zarządzanie tożsamością i dostępem dla środowisk hybrydowych — Przewodnik do nauki

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Zarządzanie tożsamością i dostępem w środowiskach hybrydowych opiera się na spójnej płaszczyźnie sterowania obejmującej lokalne usługi Active Directory Domain Services (AD DS) i Microsoft Entra ID. Podstawowe elementy składowe to synchronizacja katalogów i monitorowanie kondycji, tożsamość urządzeń i logowanie jednokrotne, bezpieczna federacja lub publikowanie przez odwrotne proxy dla starszych aplikacji oraz zarządzanie just-in-time dla ról uprzywilejowanych i użytkowników zewnętrznych. Efektywne projekty wykorzystują Azure AD Connect (obecnie Microsoft Entra Connect sync), Azure AD Connect Health, Hybrid Azure AD Join z dyscypliną rozwiązywania problemów, Seamless SSO, AD FS, gdy wymagana jest federacja, Azure AD Application Proxy z Kerberos Constrained Delegation dla aplikacji lokalnych, silne zasady dostępu warunkowego (Conditional Access), Azure AD Password Protection na kontrolerach domeny oraz Microsoft Entra ID Governance, w tym PIM i zarządzanie uprawnieniami (entitlement management).

Azure AD Connect i Health w tożsamości hybrydowej

Azure AD Connect to autorytatywny silnik synchronizacji między AD DS a Microsoft Entra ID. Kluczowe jest prawidłowe określanie zakresu, transformowanie i zapisywanie atrybutów.

Zapisywanie zwrotne haseł (Password writeback) rozszerza funkcjonalność samoobsługowego resetowania hasła (SSPR) i zmiany hasła w chmurze z powrotem do lokalnego AD. Wymaga licencji Microsoft Entra ID P1/P2, włączonego SSPR w tenancie, wychodzącego ruchu HTTPS z serwera synchronizacji oraz konta usługi synchronizacji Azure AD Connect z odpowiednimi uprawnieniami do resetowania w AD. Po włączeniu, gdy użytkownicy resetują hasła w Entra, zmiana jest natychmiast egzekwowana w AD DS, z uwzględnieniem zasad haseł AD.

Zapisywanie zwrotne urządzeń (Device writeback) tworzy obiekty msDS-Device w AD DS dla urządzeń zarejestrowanych w Entra. Umożliwia to lokalny dostęp warunkowy w AD FS oraz niektóre scenariusze zaufania certyfikatów dla Windows Hello for Business. Wymagania obejmują schemat Windows Server 2012 R2 lub nowszy, uprawnienia administratora przedsiębiorstwa (Enterprise Admin) do utworzenia kontenera RegisteredDevices oraz skonfigurowany Azure AD Connect wskazujący na właściwy las i jednostkę organizacyjną (OU). Konto usługi synchronizacji otrzymuje delegowane uprawnienia do tego kontenera.

Zapisywanie zwrotne grup (Group writeback) synchronizuje grupy Microsoft 365 z powrotem do AD DS jako grupy z obsługą poczty dla lokalnych list adresowych i list ACL. Wersja v2 zapisywania zwrotnego grup pozwala na ograniczenie zakresu do określonej jednostki organizacyjnej (OU) i zachowuje członkostwo z większą wiernością. Dla funkcji pocztowych zalecany jest tryb hybrydowy Exchange. Administratorzy nie powinni modyfikować lokalnie atrybutów grup pochodzących z chmury; zapis zwrotny z Entra należy traktować jako autorytatywny.

Reguły synchronizacji określają zakres obiektów, połączenia i przepływy atrybutów. Użyj Edytora reguł synchronizacji (Synchronization Rules Editor), aby tworzyć niestandardowe reguły przychodzące lub wychodzące o wyższym priorytecie (niższa wartość numeryczna), zamiast modyfikować reguły wbudowane. Zdefiniuj filtry zakresu (np. synchronizuj tylko użytkowników z określonym atrybutem), reguły łączenia (jak obiekty chmurowe i lokalne są ze sobą powiązane — kluczowa jest spójność immutableId/sourceAnchor) oraz transformacje (normalizuj nazwy UPN, mapuj atrybuty rozszerzeń). Ogranicz synchronizację za pomocą filtrowania według domen/jednostek organizacyjnych (OU) lub filtrowania opartego na atrybutach, aby zminimalizować ekspozycję danych i zmniejszyć powierzchnię błędów.

Azure AD Connect Health zapewnia ciągłe monitorowanie dla AD DS, AD FS i AAD Connect. Zainstaluj agentów kondycji (Health agents) na kontrolerach domeny, serwerach AD FS/WAP i serwerze synchronizacji. Portal udostępnia:

Błędy i alerty synchronizacji: błędy eksportu (ConstraintViolation, ObjectTypeMismatch), zdarzenia odporności na zduplikowane atrybuty, błędy synchronizacji skrótów haseł, problemy z synchronizacją delta i kondycja harmonogramu.
Analityka AD FS: błędy wystawiania tokenów, wygasanie certyfikatów, aktualność metadanych zaufania, opóźnienia do jednostek uzależnionych (relying parties) oraz anomalie, takie jak duża liczba blokad ekstranetowych.
Analityka AD DS: zaległości w replikacji, kondycja ról FSMO, błędy bezpiecznego kanału oraz informacje dotyczące wycofywania NTLM. Systematycznie badaj błędy na etapie, na którym występują (import, synchronizacja, eksport), używając Menedżera usług synchronizacji (Synchronization Service Manager) i koreluj je z alertami Connect Health. Wykorzystaj analitykę użycia do odpowiedniego zwymiarowania infrastruktury oraz wykrywania nietypowych wzorców logowania lub wystawiania tokenów.

Tożsamość urządzenia i logowanie jednokrotne

Dołączenie hybrydowe do Azure AD (HAADJ) wiąże urządzenia dołączone do domeny z Entra, umożliwiając logowanie jednokrotne (SSO) oparte na PRT oraz dostęp warunkowy (Conditional Access) oparty na urządzeniach. Wymagania obejmują zweryfikowane domeny niestandardowe w Entra, konfigurację SCP w AD (Azure AD Connect może skonfigurować to dla każdego lasu), włączoną rejestrację urządzeń w Entra oraz dostęp wychodzący do punktów końcowych rejestracji urządzeń. Systemy Windows 10/11 i Windows Server 2016+ obsługują automatyczne dołączanie hybrydowe, gdy mają bezpośrednią widoczność kontrolera domeny lub odpowiednią osiągalność sieciową. Urządzenia starszych wersji historycznie wymagały AD FS/Workplace Join, ale nowoczesne wdrożenia standaryzują się na obsługiwanych wersjach klienckich systemów operacyjnych.

Proces dołączania polega na odnalezieniu dzierżawy przez urządzenie za pomocą SCP w partycji Konfiguracji, skontaktowaniu się z punktami końcowymi enterpriseregistration, uwierzytelnieniu za pomocą konta komputera i zarejestrowaniu obiektu urządzenia w Entra. Pomyślna rejestracja skutkuje uzyskaniem Primary Refresh Token (PRT), który umożliwia SSO do nowoczesnych aplikacji. Do rozwiązywania problemów użyj dsregcmd:

dsregcmd /status potwierdza AzureAdJoined = YES i DomainJoined = YES oraz pokazuje status PRT, TenantId i kody błędów.
Przejrzyj dziennik zdarzeń User Device Registration (w Applications and Services Logs) w poszukiwaniu błędów DRS i uwierzytelniania.
Sprawdź synchronizację czasu, wykluczenia proxy dla punktów końcowych rejestracji urządzeń, poprawność SCP oraz czy zapis zwrotny urządzeń (jeśli jest używany) utworzył kontener w AD z odpowiednimi uprawnieniami. W razie potrzeby polecenie dsregcmd /leave czyści rejestrację, aby umożliwić ponowną próbę dołączenia.

Azure AD Seamless SSO zapewnia zintegrowane uwierzytelnianie systemu Windows w Entra bez potrzeby użycia AD FS. Włączenie SSO w Azure AD Connect tworzy w AD konto komputera AZUREADSSOACC i ustawia odpowiednie nazwy SPN (HTTP/autologon.microsoftazuread-sso.com). Kontrolery domeny wystawiają bilet usługi Kerberos dla tej nazwy SPN, gdy przeglądarki uzyskują dostęp do punktu końcowego autologon; Entra weryfikuje bilet przy użyciu klucza współdzielonego, bezpiecznie przechowywanego w dzierżawie. Obsługiwani klienci to Microsoft Edge i Internet Explorer z punktami końcowymi Entra w strefie Lokalny intranet, Google Chrome z polityką Windows Integrated Authentication oraz Firefox z konfiguracją negotiate. Urządzenia muszą być dołączone do domeny i znajdować się w sieci firmowej (lub być połączone przez VPN), aby mogły przedstawić bilety Kerberos; tryby przeglądania prywatnego mogą wyłączyć WIA. Klucze na koncie AZUREADSSOACC są rotowane automatycznie; nie należy ich resetować ręcznie. Seamless SSO działa zarówno z Password Hash Sync, jak i Pass-through Authentication.

Federacja, publikowanie aplikacji i bezpieczny dostęp

Active Directory Federation Services pozostają istotne tam, gdzie organizacje potrzebują wzbogacania oświadczeń (claims), uwierzytelniania za pomocą kart inteligentnych lub certyfikatów, bądź mają istniejące umowy federacyjne. W AD FS, zaufanie dostawcy oświadczeń (claims provider trust) reprezentuje przychodzące źródło tożsamości (zazwyczaj Active Directory lub partnerski IdP). Zaufanie jednostki uzależnionej (relying party trust) reprezentuje aplikację polegającą na tokenach AD FS (na przykład Microsoft 365 w trybie federacyjnym lub aplikacja SAML). Reguły wystawiania oświadczeń przekształcają przychodzące atrybuty w tokeny oczekiwane przez jednostkę uzależnioną; użyj języka reguł oświadczeń lub szablonów reguł, aby tworzyć polityki z zasadą najniższych uprawnień. Utrzymuj w dobrej kondycji certyfikaty do podpisywania i odszyfrowywania tokenów i w miarę możliwości automatyzuj ich rotację. Web Application Proxy (WAP) publikuje AD FS na zewnątrz, weryfikuje zaufanie proxy AD FS i kończy sesję TLS na brzegu sieci; monitoruj kondycję WAP i upewnij się, że białe listy punktów końcowych oraz odnawianie certyfikatów są zautomatyzowane.

W celu modernizacji dostępu do lokalnych aplikacji internetowych, Azure AD Application Proxy zapewnia wstępne uwierzytelnianie w chmurze i integruje się z Conditional Access. Wdróż łączniki na hostach Windows Server dołączonych do domeny, z dostępem do usługi wyłącznie przez wychodzący ruch HTTPS. Używaj grup łączników do segmentacji aplikacji według strefy sieciowej, opóźnień lub rezydencji danych oraz do zapewnienia izolacji dla aplikacji wysokiego ryzyka. Wybierz wstępne uwierzytelnianie za pomocą Azure AD, aby wymusić MFA, zgodność urządzeń, ryzyko logowania i członkostwo w grupach, zanim ruch dotrze do centrum danych; wstępne uwierzytelnianie przekazywane (pass-through) powinno być zarezerwowane dla scenariuszy, w których aplikacja sama obsługuje uwierzytelnianie, a Conditional Access nie jest wymagany. Dla SSO do aplikacji korzystających z Integrated Windows Authentication, skonfiguruj Ograniczone delegowanie Kerberos (KCD) na koncie komputera łącznika do docelowej nazwy SPN (HTTP/app-server). Łącznik uzyskuje bilet Kerberos w imieniu użytkownika i przedstawia go aplikacji, umożliwiając bezproblemowe SSO z internetu przy jednoczesnym zachowaniu delegowania z najniższymi uprawnieniami. Zweryfikuj nazwy SPN, upewnij się, że łącznik ma dostęp do kontrolerów KDC i aplikacji backendowej, oraz ogranicz delegowanie tylko do wymaganych usług.

Conditional Access wymusza politykę uwzględniającą ryzyko i stan zabezpieczeń w aplikacjach chmurowych i opublikowanych aplikacjach lokalnych. Łącz sygnały, takie jak stan urządzenia (Wymagaj, aby urządzenie było oznaczone jako zgodne) i stan katalogu (Wymagaj urządzenia dołączonego hybrydowo do Azure AD), aby warunkować dostęp dla zarządzanych punktów końcowych. Wykorzystaj ryzyko logowania z Identity Protection, aby blokować lub wymagać MFA dla anomalnych logowań. Zastosuj politykę do aplikacji opublikowanych przez Azure AD Application Proxy z wstępnym uwierzytelnianiem Azure AD; dla aplikacji sfederowanych z AD FS, odtwórz zamierzone działanie za pomocą reguł oświadczeń AD FS lub zmigruj do wstępnego uwierzytelniania w chmurze. Wyklucz konta awaryjne (break-glass) i jednostki usługi (service principals), a przed wdrożeniem przetestuj politykę w trybie tylko do raportowania.

← Odzyskiwanie po awarii i ciągłość działania · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →