Pentru motorul de căutare, elemente de context:
- Schimb online
- Office 365 / Microsoft 365 --> Outlook particular --> outlook.office.com
- Aplicația Windows Mail și Calendar [HxTsr.exe, „microsoft.windowscommunicationsapps”]
- Redirecționarea domeniului Apex către www.~
- Cloudflare DNS
- Utilizarea lucrătorilor Cloudflare
- HSTS, de asemenea pentru subdomenii
- Accesul condiționat [Azure] blochează metodele de autentificare vechi. („autentificare de bază”.)
- cname of autodiscover.domain.tld a fost configurat către autodiscover.outlook.com. așa cum era de așteptat, trucurile lui Cloudflare au fost dezactivate pentru această înregistrare.
- Cloudflare oferă SSL pentru majoritatea domeniilor, cu excepția autodiscover.domain.tld.
Acum, comportamentul nedorit:
În acest caz, Autodescoperirea nu funcționa pentru „windowscommunicationsapps”, denumite de acum înainte „client cu probleme” sau „client”. Funcționa pentru cel mai recent Outlook pentru Windows, cel mai probabil din cauza metodelor de descoperire automată încorporate mai moderne, care omit peste cele vechi de descoperire automată.
Clientul cu probleme ar încărca și încărca și va solicita o parolă de autentificare de bază, iar după aceea, va solicita un nume de utilizator și un domeniu și după aceea va afișa o eroare cu opțiunea de a merge la avansat și de a introduce totul din nou, inclusiv serverul. După aceea, după ce mi-am adus aminte să intru outlook.office365.com ca server, a solicitat utilizatorului fereastra modernă de autentificare Microsoft.
Ce a mers prost:
Clientul a încercat să recupereze https://rootdomain.tld/autodiscover/autodiscover.xml. (Văzut în jurnalul firewall-ului cloudflare.)
A fost redirecționat către https://www.rootdomain.tld/autodiscover/autodiscover.xml. (Vazut in Instrumentul MS.)
Din cauza unei configurații complexe a lucrătorilor Cloudflare, clientul nu a primit un 404 înapoi în primă instanță. Pur și simplu a continuat să se încarce și să se încarce. În configurația variației, un lucrător dedicat Cloudflare a returnat o pagină 404; nu a rezolvat problema.
Problema era că se întâmplă prea multe.
- http a fost redirecționat către https.
- Root (apex) a fost redirecționat către www.domain.tld/$1 și
- autodiscover.~ ar trebui să rezolve autodiscover.outlook.com, dar din anumite motive nu a livrat xml. (Cu instrumentul Microsoft mi-a arătat:
Testarea portului TCP 443 pe gazda autodiscover.juramento.nl pentru a vă asigura că este ascultat și deschis.
Portul specificat este fie blocat, fie nu ascultă, fie nu produce răspunsul așteptat.
- Unul dintre următorii pași în căutarea Autodiscovery este căutarea de redirecționări la autodiscover.domain.tld și asta l-a făcut să găsească
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Presupunerea a fost că clientul problematic nu ajungea atât de departe și renunța prea devreme la căutarea sa de autodescoperire. Nu sunt sigur dacă cererea GET de la autodiscover.domiain.tld:443 ar trebui să furnizeze o eroare pentru Exchange Online, dar redirecționarea a funcționat după cum s-a dorit și de îndată ce instrumentul Microsoft a găsit https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml totul a devenit verde până la eroarea de autentificare de bază așteptată din cauza blocării metodelor de autentificare vechi în acces condiționat.
Întrebările:
- De ce acest client nu se poate conecta rapid la Exchange / Office 365?
- De ce solicită acest client autentificare de bază?
- De ce descoperirea automată nu funcționează pentru acest domeniu?
- Ce face de fapt descoperirea automată pas cu pas?
- Ce putem face pentru a scurta pașii de autodescoperire și pentru a ajuta clientul problematic inițial?
- Ce pot face pentru a remedia rapid descoperirea automată pentru Exchange Online?
