Outlook pyta o hasło po migracji skrzynki: DNS, Autodiscover i SCP — co naprawdę psuje profil

TL;DR: Po przeniesieniu poczty (lift-and-shift, zmiana IP farmy Exchange albo „wyczyszczenie” starych rekordów DNS) część użytkowników dostaje losowe okno „Windows Security” w Outlooku mimo że poczta chodzi. Najczęściej winny jest łańcuch Autodiscover: stary rekord A/CNAME, SCP w AD wskazujący na martwy endpoint albo root-domain probe trafiający w nie ten serwer. Ten artykuł rozbija to na kroki diagnostyczne z PowerShell i mówi, czego nie zrobisz pięciominutowym googlowaniem — bo objawy są tak samo „losowe”, jak kolejność, w jakiej Outlook próbuje kolejnych URL-i Autodiscover.

Problem

Scenariusz z życia MSP i działów IT: migracja Exchange do nowego DC, zmiana publicznego adresu front door, albo wyłączenie starych VIP-ów na load balancerze. Helpdesk melduje: „Outlook co godzinę pyta o hasło, ale jak anulujesz — dalej przychodzi poczta”. Albo gorzej: prompt pojawia się tylko u ~10% ludzi, na losowych laptopach, więc nie da się tego odtworzyć na jednej maszynie w labie.

Z perspektywy użytkownika to wygląda jak „Windows się zepsuł”. Z perspektywy admina to zazwyczaj jedna z trzech rzeczy: (1) Outlook nadal skanuje root domeny https://twojadomena.pl/autodiscover/autodiscover.xml i dostaje odpowiedź 200 z hostingu WWW, która nie jest Exchange’em, ale Outlook ją traktuje jako „skuteczny” wynik Autodiscover i próbuje się tam uwierzytelnić; (2) w AD nadal istnieje SCP (Service Connection Point) wskazujący na stary URL https://mail.staryhosting.pl/autodiscover/autodiscover.xml, który odpowiada certyfikatem niepasującym do SMTP address użytkownika; (3) hybryda / współistnienie M365 i on-prem: OAuth2ClientProfileEnabled jest OK w chmurze, ale lokalny profil ma zmixowane tokeny WAM i „wisi” na starym resource owner flow.

Redditowy wątek o credential prompt po lift-and-shift (r/sysadmin, 2025) dokładnie to opisuje: mail leci, bo połączenie do „prawdziwego” endpointu M365/Exchange nadal działa, ale równolegle Outlook co jakiś czas odpala drugą ścieżkę Autodiscover i wpada w pętlę MFA/basic — stąd wrażenie losowości.

Dlaczego tak się dzieje

Outlook (klasyczny Win32) nie ma jednego „prawdziwego URL-a” do konfiguracji. Microsoft dokumentuje kolejność prób Autodiscover m.in. z SCP w lesie AD (dla maszyn domain-joined), potem HTTPS na hostach typu https://autodiscover.contoso.com/..., potem HTTP redirect, potem „root domain” probe https://contoso.com/autodiscover/... (tak, to jest realna ścieżka ataku i realna ścieżka awarii, jeśli hosting odpowie 200 z XML-em lub HTML-em udającym XML).

Jeśli po migracji zmieniłeś tylko rekord MX, ale zostawiłeś stary publiczny A na mail.firma.pl albo wildcard na *.firma.pl, Outlook może nadal wyciągać stary certyfikat albo stary hostname z cache DSN w profilu. Drugi mechanizm: SCP w AD — dopóki obiekt w CN=Autodiscover,CN=... wskazuje https://2010-exchange/autodiscover..., Outlook będzie wracał do tego URL-a nawet wtedy, gdy skrzynka jest już w Exchange Online, bo SCP ma pierwszeństwo przed „zgadywaniem” chmury (dokładna kolejność zależy od wersji Outlooka i trybu konta, ale SCP jest na początku listy dla domenowych maszyn — i to jest feature, nie bug).

Trzeci mechanizm to tokeny: Office 2016 z MSI + stary profil + mieszanka „EnableADAL”/WAM czasem zostawia w Credential Manager wpis virtualapp/didlogical i równolegle próbuje basic do złego hosta. Objaw: okno logowania, anulujesz — Outlook wraca do działającego tokenu chmurowego.

Rozwiązanie krok po kroku

Krok 1 — ustal, dokąd naprawdę strzela Autodiscover (DNS + certyfikat)

Na stacji problemowej (nie na serwerze Exchange) odpal:

Resolve-DnsName autodiscover.firma.pl -Type A,CNAME,TXT -ErrorAction SilentlyContinue |
  Select-Object Name,Type,IPAddress,NameHost
Resolve-DnsName mail.firma.pl -Type A,CNAME -ErrorAction SilentlyContinue |
  Select-Object Name,Type,IPAddress,NameHost

Szukasz trzech rzeczy: (a) czy autodiscover.firma.pl CNAME wskazuje na outlook.office365.com (typowy scenariusz M365), czy wisisz jeszcze na starym LB; (b) czy masz split-brain DNS — wewnątrz sieci inny rekord niż z publicznego resolvera 1.1.1.1; (c) czy wildcard *.firma.pl nie łapie autodiscover.firma.pl do parking page.

Następnie TLS (to już nie PowerShell, ale wartość diagnostyczna):

# Prosty test SNI — zwróć CN/SAN certyfikatu serwera front
$tcp = New-Object System.Net.Sockets.TcpClient('autodiscover.firma.pl',443)
$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(),$false,({$true}))
$ssl.AuthenticateAsClient('autodiscover.firma.pl')
$ssl.RemoteCertificate.Subject
$ssl.Dispose(); $tcp.Close()

Jeśli Subject to CN=parking.oldprovider.net, a użytkownik ma adres jan@firma.pl, Outlook dostanie mismatch i zacznie kręcić promptami — nawet jeśli „główny” kanał do outlook.office365.com działa przez inny wpis w profilu.

Krok 2 — SCP w Active Directory (tylko jeśli masz AD + domenowe PC)

Na serwerze z RSAT:

# Lista SCP dla Exchange w lesie (uproszczony filtr po nazwie)
Get-ADObject -SearchBase (Get-RootDSE).configurationNamingContext `
  -LDAPFilter "(objectClass=serviceConnectionPoint)" -Properties keywords |
  Where-Object { $_.Name -match 'Autodiscover' } |
  Select-Object Name,DistinguishedName,@{n='Keywords';e={$_.keywords}}

Jeżeli w keywords widzisz URL do wyłączonego frontu on-prem — musisz albo zaktualizować SCP (Set-ClientAccessService / reinstall autodiscover virtual directory — zależnie od wersji Exchange), albo świadomie wyłączyć SCP lookup na stacjach (GPO / rejestr), jeśli jesteś już w 100% cloud-only i SCP tylko szkodzi. Microsoft dokumentuje kontrolę polityką: ExcludeScpLookup pod HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover (16.0 = Office 2016/2019/365 — wersja zależy od buildu). Użyj tego tylko gdy rozumiesz skutek: Outlook przestanie brać pierwszeństwo z AD i może szybciej trafić w ścieżkę HTTPS — ale też możesz maskować inny problem.

Krok 3 — wyczyść profil z „złych” cache Autodiscover (ostrożnie)

Najpierw Remote Connectivity Analyzer (Outlook → Microsoft 365) — zapisz, który hop zwraca błąd. Dopiero potem na końcówce:

# Zamknij Outlook. Potem usuń tylko pliki autodiscover.xml z lokalnego cache użytkownika
Remove-Item "$env:LOCALAPPDATA\Microsoft\Outlook\*.xml" -Force -ErrorAction SilentlyContinue

To nie jest „magiczny fix” dla każdego przypadku — czasem niszczysz jedynie dowód dla supportu. Ale jeśli masz podejrzenie, że Outlook zapisał zły Last Known Good URL, reset cache + nowy profil Outlook (nie nowy Windows user) bywa tańszy niż tygodniowe polowanie.

Krok 4 — Exchange Online / hybryda: sprawdź, czy to w ogóle nie jest „feature” MFA

W Exchange Online PowerShell:

Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled, DefaultAuthenticationPolicy

OAuth2ClientProfileEnabled = $false w 2026 roku to rzadkość, ale spotykam w tenantach po „twardym” hardeningu CIS. Jeśli jest wyłączone, nowoczesny Outlook będzie się dławił z tokenami. Równolegle w Entra Sign-in logs filtruj użytkownika + aplikację „Office 365 Exchange Online” i szukaj interrupted przez CA (np. wymóg compliant device na tokenach, który nie dotyczy IMAP, ale dotyczy REST).

Krok 5 — root-domain Autodiscover i hosting WWW

Jeśli publiczny https://firma.pl/autodiscover/autodiscover.xml zwraca cokolwiek innego niż kontrolowany 404/redirect wg wytycznych Microsoft, napraw to po stronie web team, nie Exchange team: typowe rozwiązanie to wystawienie kontrolowanego 404 lub prawidłowego redirect chain — nie lekceważ tego, bo Outlook traktuje pierwszą sensowną odpowiedź jako kandydatę do logowania.

Typowe pułapki i edge cases

1. Split DNS: wewnętrzny DNS kieruje autodiscover.firma.pl na stary VIP, publiczny — na Microsoft. Objaw: „w biurze źle, w domu dobrze”. Resolve-DnsName na laptopie VPN vs bez VPN pokaże rozjazd w 30 sekund.

2. SCP zostaje po wyłączeniu Exchange Server: fizycznie wywaliłeś serwer, ale obiekty SCP w AD nikt nie sprzątnął. Outlook nadal próbuje LDAP → timeout → retry → użytkownik widzi „losowe” okna.

3. Wildcard certyfikat + zły SNI: front nginx zwraca default vhost z certem *.cdnprovider.com, a Ty testujesz tylko MX. TLS handshake wygląda „OK”, ale CN nie pasuje do autodiscover.firma.pl — Outlook kręci MFA w kółko.

4. Credential Manager z duplikatami: po migracji zostają wpisy Outlook i Exchange wskazujące na stary host. Czasem trzeba usunąć wszystkie wpisy Office dla użytkownika i pozwolić WAM zbudować je od zera (wiem, że boli — ale ta pułapka jest w Q&A Microsoftu przy „password is right but still prompts”).

5. Outlook Click-to-Run vs MSI: inne ścieżki rejestru (16.0 vs 15.0) i inne domyślne zachowania Autodiscover. Dokumentujesz GPO pod jedną wersję — a 30% firmy ma drugą.

Podsumowanie

• MX ≠ koniec pracy: Autodiscover żyje osobnym życiem w DNS, SCP i cache profilu.
• Zaczynaj od Resolve-DnsName + test certyfikatu SNI na autodiscover. — to daje twardy dowód, nie „wydaje mi się”.
• SCP w AD to pierwsze podejrzenie na domenowych laptopach po migracji on-prem → cloud.
• OAuth / CA w Entra odfiltruj zanim zrobisz format C: użytkownikowi.
• Root-domain probe to klasyk — dogadaj się z webem, zanim Exchange weźmie winę.

Krok 6 — logi po stronie klienta (kiedy już wiesz, że DNS jest OK)

Jeśli masz podejrzenie, że to nie DNS, tylko Outlook sam w sobie, włącz na chwilę diagnostykę synchronizacji (nie zostawiaj na stałe w produkcji bez polityki):

HKCU\Software\Microsoft\Office\16.0\Outlook\Options\Mail — DWORD: EnableLogging = 1

Ścieżki logów są opisane w dokumentacji Outlook — szukaj wpisów Autodiscover i kolejności URL. Alternatywnie: Outlook /sr resetuje formularze i czasem czyści zawieszone add-iny, ale to już strzał z armaty w ptaka.

Krok 7 — „ostatnia deska”: nowy profil vs całkowita reinstalacja Office

Zasada którą stosuję w Evolit przy ticketach klasy enterprise: jeden nowy profil Outlook zanim ktoś zaproponuje „przeinstaluj Office”. Nowy profil wymusza pełny przebieg Autodiscover od zera i usuwa z cache stare redirecty HTTP 302 z hostingu sprzed pięciu lat (tak, widziałem 302 chain zapisany w lokalnym XML — użytkownik zmieniał WWW pięć razy, a Outlook pamiętał pierwszy).

Jeśli po nowym profilu problem znika u 9/10 użytkowników, zostaje Ci GPO z poprawnymi kluczami Exclude* (patrz Microsoft Learn „How to control AutoDiscover via Group Policy”) — wtedy wdrażasz masowo, a nie ręcznie per ticket.

Dodatkowe narzędzie: Test-OutlookConnectivity (Exchange on-prem)

Jeśli jeszcze trzymasz hybrydę z serwerem Exchange 2016/2019:

Test-OutlookWebServices -Identity:'CN=Mailbox Database,CN=Databases,...' -ClientAccessServer 'cas01.firma.local'

To nie zastępuje analizy DNS z końcówki, ale pokazuje, czy serwer nadal wystawia poprawny WebServicesUrl i OABUrl zgodny z namespace po migracji.

Na koniec: jeśli po wszystkich krokach nadal widzisz prompt, ale tylko na Wi-Fi gościa w biurze, sprawdź SSL inspection na firewallu — niektóre modele podmieniają certyfikat tylko dla wybranych SNI, co daje identyczny objaw jak zły Autodiscover, ale Wireshark na laptopie pokaże inną CA chain niż z domu użytkownika.