Office 365 – Limitările ID-ului alternativ de autentificare

Intune
Nu am prea multe informații despre acest lucru, în afară de faptul că a fost acolo încă de la lansarea inițială a funcției. Notele au spus întotdeauna: „Dacă sunteți un client Intune care utilizează conectorul SCCM, este posibil să fie necesară o configurație suplimentară”. Asta îmi spune că există un fel de problemă, dar poate că cineva mai implicat în Intune poate ajuta să completeze detaliile.
Exchange Hybrid Autodiscover: Domain Joined
Problema principală aici este nepotrivirea dintre acreditările care sunt valabile la fața locului și acreditările care sunt valabile în cloud. Într-un mediu Exchange Hybrid, înregistrările Autodiscover indică în continuare către Exchange on-premise, unde un utilizator se autentifică și apoi efectuează o căutare Autodiscover. Dacă utilizatorul are o căsuță poștală în cloud, acesta este apoi redirecționat către Office 365, unde se efectuează o altă căutare Autodiscover, cu autentificare, iar apoi este returnat răspunsul Autodiscover. Problema care apare este că sunt necesare acreditări diferite pentru on-premise (care nu știe nimic despre Alternate Login ID) și cloud (care așteaptă Alternate Login ID).
Pentru mașinile unite în domeniu, acreditările de autentificare sunt suficiente pentru a se autentifica la Exchange on-premise și apoi utilizatorul primește solicitarea unică obișnuită de autentificare la Exchange Online. Singura diferență pe care o veți observa aici este că promptul pentru Office 365 are acreditările greșite populate în caseta de autentificare și trebuie să introduceți ID-ul de autentificare alternativ.
Exchange Hybrid Autodiscover: Non-Domain Joined
Pentru mașinile non-domain joined, utilizatorului i se prezintă prompturi atât pentru on-premise, cât și pentru cloud, fără să știe pentru ce platformă este promptul. Rezultatul este că, deși este posibil din punct de vedere tehnic să navigați printre solicitările de conectare, este puțin probabil ca utilizatorii dvs. să știe ce credențiale să furnizeze în timpul cărei solicitări.
Unul în care devine cu adevărat dificil să știți ce cont să utilizați este atunci când aveți foldere publice on-premise pe care le-ați făcut accesibile de către utilizatorii căsuței poștale din cloud. Căsuța poștală proxy pentru folderele publice locale este returnată ca parte a răspunsului de autodescoperire în cloud și, la un moment dat, la deschiderea Outlook, se așteaptă să introduceți acreditările locale. Aș spune că această configurație este aproape inutilizabilă.
Exchange Hybrid Autodiscover: Mac
Când se utilizează noul „Outlook pentru Mac”, nepotrivirea acreditării ID-ului de conectare alternativ va face ca Outlook să eșueze în timpul configurării automate a contului. Utilizatorul va trebui să configureze manual Outlook pentru a utiliza ținta de „https://outlook.office365.com/EWS/Exchange.asmx”.
Office ProPlus
Comportamentul de aici este oarecum ciudat. Atunci când un utilizator folosește Alternate Login ID, Office ProPlus se va instala și se va afișa activat sub contul acelui utilizator în cloud, însă în aplicațiile locale, vă va afișa conectat sub UPN-ul dvs. local.
Rezultatul este că nu veți vedea legăturile către OneDrive for Business în cadrul aplicațiilor Office, iar OneDrive for Business Sync Client nu va fi configurat. Deși puteți să vă deconectați de la UPN-ul local și să vă conectați cu ID-ul de conectare alternativ, mă întreb dacă Office ProPlus ar intra în „modul de funcționalitate redusă” după o perioadă de timp dacă este lăsat conectat cu contul local.
Remote Connectivity Analyzer
Nu că aceasta ar fi o problemă critică, dar testul Remote Connectivity Analyzer Autodiscover nu știe cum să se ocupe de Alternate Login ID cu Exchange Hybrid din cauza solicitării de dublă autentificare.
Azure Application Proxy
După cum a observat comentatorul de mai jos, noul Azure Application Proxy are o notă de subsol care precizează:: „UPN-urile din Azure Active Directory trebuie să fie identice cu UPN-urile din Active Directory-ul dvs. local pentru ca pre-autentificarea să funcționeze. Asigurați-vă că Azure Active Directory este sincronizat cu Active Directory-ul dvs. local”. Aceasta înseamnă că Alternate Login ID nu este compatibil în această situație.
Furnizori de identitate terță parte (IDP)
Microsoft are un program pentru IDP-uri terțe testate numit „Works with Office 365 – Identity”. O parte a acestui program este o listă de furnizori testați împreună cu orice excepții care ar putea fi cunoscute cu aceste produse. În notele pentru acest program este listat faptul că „Utilizarea Sign-in by Alternate ID to UPN nu este, de asemenea, testată în acest program”. Deci, practic, kilometrajul dumneavoastră poate varia atunci când folosiți Alternate Login ID cu oricare dintre aceste IDP-uri terțe.