Conditional Access w Microsoft 365 — 5 błędów konfiguracji które blokują użytkowników (i jak je naprawić)

TL;DR: Conditional Access ocenia wszystkie polityki równolegle — jeden błąd może zablokować cały tenant. Opisuję 5 konkretnych pułapek: blokadę rejestracji Intune przez "All cloud apps", niezablokowane legacy auth, problem z IPv6 w Named Locations, niewidoczne zależności między aplikacjami i brak testowania przez What-If. Każda z nich ma konkretne rozwiązanie, kody błędów i przykłady PowerShell.

Problem

Conditional Access to mechanizm który wygląda prosto — tworzysz politykę, określasz warunki, definiujesz co się dzieje przy niespełnieniu. W praktyce administratorzy M365 regularnie wpadają w pułapki których nie widać na etapie konfiguracji, a które wychodzą dopiero gdy użytkownicy zaczynają dzwonić z pytaniem "dlaczego nie mogę się zalogować."

Typowy scenariusz: nowy admin dostaje zadanie "zabezpiecz tenant, wdróż MFA i zgodność urządzeń". Tworzy politykę CA: wszyscy użytkownicy, wszystkie aplikacje chmurowe, wymagana zgodność urządzenia z Intune. Polityka ląduje w trybie enforced. Następnego ranka 30% pracowników nie może się zalogować — bo ich urządzenia nie są jeszcze zarejestrowane w Intune. Co gorsza, nie mogą ich zarejestrować, bo CA blokuje dostęp do portalu rejestracji. Klasyczne jajko i kura.

To nie jest wymyślony przykład. Powtarza się w różnych wariantach na forach Microsoft TechCommunity kilka razy w tygodniu. Problemem jest to, że CA nie jest systemem reguł sekwencyjnych — wszystkie aktywne polityki są oceniane jednocześnie, a dostęp jest przyznawany tylko gdy żadna z nich nie blokuje i wszystkie wymagania są spełnione.

Dodatkowy problem: wiele organizacji wdraża CA bez żadnej fazy testowej. Polityka przechodzi bezpośrednio z "Disabled" do "Enabled" bez tygodnia w Report-Only. Efekt: dopiero po fakcie, z logów, admin dowiaduje się kogo i dlaczego zablokował.

Dlaczego tak się dzieje

Conditional Access działa według modelu "zero domyślnego dostępu" — jeśli jakikolwiek aktywny CA policy mówi "zablokuj" albo wymaga spełnienia warunku którego nie można spełnić w danym kontekście, dostęp jest odmawiany. Nie ma tutaj priorytetu ani kolejności przetwarzania polityk. Wszystkie oceniane są równolegle, a wynik "Failed" z jednej polityki wystarczy do odmowy dostępu.

Drugi mechanizm który bije adminów z zaskoczenia to service dependencies. Gdy użytkownik otwiera Microsoft Teams, Teams żąda tokenów do: Exchange Online (kalendarz, mail), SharePoint Online (pliki i kanały), Office 365 (licencje). Jeśli CA policy blokuje dostęp do SharePoint Online, Teams przestaje działać — nawet jeśli polityka nie jest skierowana bezpośrednio na Teams. W logach logowania zobaczysz aplikację "Microsoft Teams", ale zasób zablokowany to "SharePoint Online" — co bez wiedzy o service dependencies wygląda jak anomalia.

Trzecia przyczyna problemów to IPv6. Entra ID nie potrafi geolokalizować adresów IPv6 — traktuje je jako "unknown location." Jeśli masz politykę blokującą dostęp z krajów spoza whitelist, użytkownik łączący się przez IPv6 (co jest coraz powszechniejsze przy ISP-ach w Polsce przechodzących na dual-stack) zostanie zablokowany, bo jego adres nie pasuje do żadnego dozwolonego kraju. To cicha pułapka — użytkownik siedzi w Warszawie, a CA widzi go jako "unknown location."

Rozwiązanie krok po kroku

Błąd #1 — "Wszystkie aplikacje chmurowe" blokuje rejestrację w Intune

To najczęstszy błąd przy wdrożeniu polityki wymagającej zgodności urządzenia. Konfiguracja problematyczna:

• Użytkownicy: Wszyscy
• Zasoby: Wszystkie aplikacje chmurowe
• Kontrola dostępu: Wymagaj zgodnego urządzenia z Intune

Problem: urządzenie może być "zgodne" dopiero po zarejestrowaniu w Intune. Rejestracja wymaga dostępu do portalu Microsoft Intune i Microsoft Intune Enrollment. Polityka "wszystkie aplikacje + wymagaj zgodności" blokuje właśnie te portale — urządzenie nie może się zarejestrować, więc nie jest zgodne, więc dostęp jest zablokowany. W logach zobaczysz błąd AADSTS53000 (DeviceNotCompliant).

Rozwiązanie: Wyłącz z polityki aplikacje Microsoft Intune (AppId: 0000000a-0000-0000-c000-000000000000) i Microsoft Intune Enrollment (AppId: d4ebce55-015a-49b5-a083-c84d1797ae8c). Znajdź polityki które mogą mieć ten problem:

# Sprawdź polityki CA które mogą blokować enrollment Intune
Connect-MgGraph -Scopes "Policy.Read.All"

$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($policy in $policies) {
    $apps = $policy.Conditions.Applications
    # Sprawdź polityki celujące w All lub bez wykluczeń Intune
    $allApps = $apps.IncludeApplications -contains "All"
    $intuneExcluded = $apps.ExcludeApplications -contains "0000000a-0000-0000-c000-000000000000"
    $enrollExcluded = $apps.ExcludeApplications -contains "d4ebce55-015a-49b5-a083-c84d1797ae8c"
    $grantControls = $policy.GrantControls.BuiltInControls

    if ($allApps -and ($grantControls -contains "compliantDevice") -and (-not $intuneExcluded -or -not $enrollExcluded)) {
        Write-Warning "Polityka '$($policy.DisplayName)' wymaga zgodności i może blokować rejestrację Intune"
        Write-Host "  - Microsoft Intune wykluczone: $intuneExcluded"
        Write-Host "  - Microsoft Intune Enrollment wykluczone: $enrollExcluded"
    }
}

Błąd #2 — Niezablokowane legacy authentication

Legacy authentication (IMAP, POP3, SMTP AUTH, Basic Auth, MAPI over HTTP, Exchange ActiveSync z Basic) nie obsługuje Conditional Access ani nowoczesnego MFA. Jeśli masz politykę "wszyscy użytkownicy muszą używać MFA" ale nie blokujesz legacy auth, atakujący może użyć IMAP albo POP3 do zalogowania się hasłem — bez żadnego challengu MFA. Polityki CA są wtedy zupełnie bezużyteczne dla tego wektora ataku.

Sprawdź ile aktywnych sesji legacy auth masz w ostatnich 30 dniach:

Connect-MgGraph -Scopes "AuditLog.Read.All"

$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
$legacyClients = @("IMAP4", "POP3", "MAPI", "Exchange ActiveSync", "Other clients", "Authenticated SMTP")

$signIns = Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and status/errorCode eq 0" -All -PageSize 500 |
    Where-Object { $legacyClients -contains $_.ClientAppUsed }

Write-Host "Aktywne sesje legacy auth w ostatnich 30 dniach: $($signIns.Count)"
$signIns | Group-Object UserPrincipalName, ClientAppUsed |
    Sort-Object Count -Descending |
    Select-Object -First 20 Name, Count |
    Format-Table -AutoSize

Przed zablokowaniem uruchom politykę w trybie Report-Only przez minimum 2 tygodnie i sprawdź wyniki. Typowe ofiary blokady: drukarki z mailem SMTP AUTH, legacy aplikacje CRM, skanery do maila, automation scripts z hardcoded hasłami. Dla urządzeń wielofunkcyjnych użyj SMTP relay Microsoft 365 (nie wymaga per-user auth) zamiast SMTP AUTH.

Błąd #3 — IPv6 w Named Locations

Jeśli tworzysz politykę opartą na lokalizacji (np. "zablokuj dostęp z krajów spoza EU"), Named Locations działają poprawnie dla IPv4. Przy IPv6 — Entra ID nie przypisuje adresów IPv6 do lokalizacji geograficznej i klasyfikuje je jako "Unknown location."

Efekt: polityka blokująca "wszystkie kraje z wyjątkiem PL/DE/CZ" zablokuje użytkownika który łączy się przez IPv6 od polskiego ISP. Ich adres IPv6 trafia do kategorii "Unknown" — i jeśli "Unknown" nie jest na whiteliście, dostęp jest odmówiony.

Trzy podejścia (od najlepszego):

1. Zmień warunek z lokalizacji na "Compliant Device" — urządzenie enrolled w Intune ma certyfikat; compliance nie zależy od IP. To właściwe rozwiązanie docelowe.
2. Dodaj zakresy IPv6 swojego ISP do Named Location — tymczasowe, wymaga aktualizacji przy zmianie dostawcy.
3. Włącz "Include unknown countries/regions" — ryzykowne, bo faktycznie nieznane lokalizacje też przejdą.

Błąd #4 — Niewidoczne zależności między aplikacjami

CA nie widzi "intencji użytkownika" — widzi jakie zasoby są żądane podczas sign-in. Teams, Outlook, SharePoint, OneDrive żądają tokenów do wielu zasobów backend.

Przykład: admin ustawia politykę "tylko użytkownicy z urządzeń zarządzanych mają dostęp do SharePoint." Użytkownik otwiera Teams z niezarządzanego urządzenia i Teams przestaje działać — nie może załadować plików z kanałów. W logach widzi błąd dla "SharePoint Online", nie dla "Teams." Użytkownik mówi "Teams się zepsuł."

Zawsze sprawdzaj Audience reporting w logach sign-in — dla każdego logowania Entra ID pokazuje wszystkie zasoby (audiences) które były żądane. Inne kluczowe pary:

• Exchange Online blokuje: Outlook, Teams (mail/kalendarz), Power Automate connectors
• Office 365 (grupa) blokuje: Teams, Word, Excel, OneDrive, tokeny licencji
• Azure Resource Manager blokuje: Azure Portal, Azure CLI, Terraform, PowerShell Az

Błąd #5 — Brak What-If przed wdrożeniem

What-If (Entra admin center → Conditional Access → Policies → What If) symuluje jak wszystkie aktywne polityki zostaną zastosowane dla konkretnego scenariusza. Możesz podać: użytkownika, aplikację, lokalizację, platformę, protokół — i zobaczyć które polityki by zadziałały.

Ważna różnica: What-If to snapshot dla jednego scenariusza. Report-Only to monitorowanie rzeczywistych logowań. Oba są potrzebne. Co ważne — What-If nie uwzględnia service dependencies. Symulacja logowania do Teams nie sprawdza polityk dla Exchange Online i SharePoint. Symuluj każdy zasób z osobna.

Workflow przed każdym wdrożeniem:

1. Tryb Report-Only minimum 5 dni roboczych
2. Codziennie przeglądaj Conditional Access Insights Workbook w Entra admin center
3. What-If dla kont serwisowych, break-glass i użytkowników z niestandardowymi rolami
4. Pilot na grupę 5-10% użytkowników przez 48h
5. Pełne wdrożenie

Typowe pułapki i edge cases

Token caching — zmiany nie działają natychmiast. Gdy zmienisz politykę CA, użytkownicy z aktywnymi tokenami nie odczują zmiany do wygaśnięcia tokenu (access token: ~1h, refresh token w ciągłej sesji: do 90 dni). Jeśli usuniesz blokującą politykę w czasie incydentu, niektórzy użytkownicy mogą być blokowani jeszcze przez kilka godzin. Nie wnioskuj z braku natychmiastowego efektu że coś nie działa — poczekaj na wygaśnięcie tokenów.

Break-glass musi być wyłączony ze WSZYSTKICH polityk CA. Admini często wyłączają konto awaryjne z polityk MFA, ale zapominają o politykach lokalizacyjnych, compliance, czy device platform. Jedna polityka która obejmuje break-glass i konto przestaje działać w kryzysie. Sprawdź regularnie:

$breakGlassUPN = "breakglass@twojadomena.pl"
$bgUser = Get-MgUser -Filter "userPrincipalName eq '$breakGlassUPN'"

$activePolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$bgExposedPolicies = $activePolicies | Where-Object {
    $_.Conditions.Users.ExcludeUsers -notcontains $bgUser.Id -and
    ($_.Conditions.Users.IncludeUsers -contains "All" -or $_.Conditions.Users.IncludeGroups.Count -gt 0)
}

if ($bgExposedPolicies) {
    Write-Warning "Break-glass NIE jest wyłączony z $($bgExposedPolicies.Count) aktywnych polityk!"
    $bgExposedPolicies | Select-Object DisplayName, State | Format-Table
}

Workload identities (service principals) nie podlegają standardowym CA. Polityki CA dotyczą użytkowników. Service principale, Managed Identity, aplikacje — wymagają osobnych "Workload identity policies" w Entra (dostępnych od Entra P2). Wiele organizacji zostawia service principale bez żadnych ograniczeń lokalizacyjnych czy IP.

Office 2013 i nieaktualne Office 2016 (poniżej build 16.0.7167) korzystają z legacy auth bez możliwości przełączenia na nowoczesne uwierzytelnianie. Przed blokowaniem legacy auth sprawdź wersje Office w parku maszynowym przez telemetrię M365 Apps lub Configuration Manager.

Propagacja zmian CA zajmuje ~5 minut do wszystkich datacenter Microsoft. Jeśli zmiana jest błędna, masz ~5 minut zanim problem dotrze do wszystkich użytkowników. Zawsze wprowadzaj zmiany CA poza godzinami pracy, najlepiej z osobą gotową do cofnięcia w razie problemów.

Jak my to rozwiązujemy w Evolit

W Evolit Conditional Access wdrażamy zawsze razem z zarządzaniem urządzeniami przez Intune. Używamy Nexmy do automatyzacji onboardingu nowych pracowników — gdy dział HR zatwierdza wniosek o dostęp, system automatycznie tworzy konto, przypisuje profil Autopilot i inicjuje enrollment urządzenia w Intune. Dzięki temu urządzenie trafia do stanu "compliant" zanim użytkownik wykona pierwsze logowanie, co eliminuje klasyczny problem jajka i kury przy politykach wymagających zgodności.

Nexma obsługuje też wnioski o dostęp do zasobów M365 — zamiast ręcznie zarządzać wykluczeniami z polityk CA dla poszczególnych użytkowników, dostęp warunkowy jest obsługiwany przez członkostwo w grupach, które Nexma zarządza automatycznie na podstawie zatwierdzonych wniosków. Alternatywnie można to samo osiągnąć przez Privileged Identity Management (PIM) w Entra, ale wymaga to licencji Entra ID P2 i ręcznej konfiguracji każdej roli. Więcej o automatyzacji onboardingu urządzeń na nexma.app.

Podsumowanie

• Conditional Access ocenia wszystkie polityki równolegle — nie ma priorytetu ani kolejności; jeden niespełniony warunek blokuje dostęp
• Polityka "All cloud apps + require compliant device" musi wyłączać AppId Intune enrollment — inaczej nowe urządzenia wpadają w pętlę niemożliwą do przerwania
• Legacy authentication nie obsługuje CA ani MFA — blokuj go osobną polityką, poprzedzoną minimum 2 tygodniami w Report-Only
• IPv6 jest niewidoczne dla Named Locations i trafia do "unknown location" — przejście na warunek "compliant device" zamiast geolokalizacji IP rozwiązuje problem trwale
• What-If nie zastępuje Report-Only i nie uwzględnia service dependencies — zawsze testuj logowanie do każdego zasobu z osobna