Office 365 – Omezení alternativního přihlašovacího ID

Intune
Nemám k tomu moc informací, kromě toho, že je to tam od původního vydání funkce. V poznámkách bylo vždy uvedeno: „Pokud jste zákazníkem služby Intune a používáte konektor SCCM, může být vyžadována další konfigurace“. To mi říká, že je tam nějaký problém, ale snad někdo, kdo se Intune zabývá více, pomůže doplnit podrobnosti.
Exchange Hybrid Autodiscover: Primárním problémem je zde nesoulad mezi pověřeními platnými v lokálním prostředí a pověřeními platnými v cloudu. V hybridním prostředí Exchange záznamy Autodiscover stále odkazují na místní Exchange, kde se uživatel ověří a poté provede vyhledávání Autodiscover. Pokud má uživatel schránku v cloudu, je pak přesměrován do služby Office 365, kde je provedeno další vyhledávání Autodiscover s ověřením a poté je vrácena odpověď Autodiscover. Problém, který nastává, spočívá v tom, že jsou nutná různá pověření pro lokální Exchange (který o Alternate Login ID nic neví) a pro cloud (který Alternate Login ID očekává).
U počítačů připojených k doméně stačí přihlášená pověření k ověření pro lokální Exchange a poté uživatel obdrží obvyklou jedinou výzvu k ověření pro Exchange Online. Jediný rozdíl, kterého si zde všimnete, je, že výzva pro Office 365 má v přihlašovacím poli vyplněna nesprávná pověření a je třeba zadat Alternate Login ID.
Exchange Hybrid Autodiscover: V případě počítačů nepřipojených k doméně se uživateli zobrazí výzvy pro lokální i cloudovou platformu, aniž by věděl, pro kterou platformu výzva platí. Výsledkem je, že ačkoli je technicky možné se v přihlašovacích výzvách orientovat, je nepravděpodobné, že by uživatelé věděli, jaké přihlašovací údaje mají během které výzvy zadat.
Kde je to skutečně obtížné, aby věděli, jaký účet mají použít, je situace, kdy máte lokální veřejné složky, které jste zpřístupnili uživatelům cloudových poštovních schránek. Proxy schránka pro on-premises veřejné složky je vrácena jako součást odpovědi cloudového Autodiscoveru a v určitém okamžiku při otevření aplikace Outlook se očekává, že zadáte přihlašovací údaje on-premises. Řekl bych, že tato konfigurace je téměř nepoužitelná.
Exchange Hybrid Autodiscover: Při použití nového „Outlooku pro Mac“ způsobí neshoda pověření Alternate Login ID selhání Outlooku při automatickém nastavení účtu. Uživatel bude muset ručně nastavit Outlook tak, aby používal cíl „https://outlook.office365.com/EWS/Exchange.asmx“.
Office ProPlus
Chování je zde poněkud zvláštní. Pokud uživatel používá alternativní přihlašovací ID, Office ProPlus se nainstaluje a zobrazí aktivovaný pod účtem tohoto uživatele v cloudu, nicméně v místních aplikacích se zobrazí přihlášený pod lokálním UPN.
Výsledkem je, že se v aplikacích Office nezobrazí odkazy na OneDrive for Business a synchronizační klient OneDrive for Business nebude nastaven. Můžete se sice odhlásit z lokálního UPN a přihlásit se pomocí svého alternativního přihlašovacího ID, ale ptám se, zda by Office ProPlus po určité době přešel do „režimu omezené funkčnosti“, pokud by zůstal přihlášen pomocí lokálního účtu.
Analyzátor vzdáleného připojení
Ne že by to byl kritický problém, ale test Remote Connectivity Analyzer Autodiscover neumí zpracovat Alternate Login ID s Exchange Hybrid kvůli dvojí výzvě k ověření.
Azure Application Proxy
Jak poznamenal komentátor níže, nový Azure Application Proxy má poznámku pod čarou, ve které je uvedeno: „Aby fungovalo předběžné ověřování, musí být UPN v Azure Active Directory shodné s UPN ve vaší lokální Active Directory. Ujistěte se, že je adresář Azure Active Directory synchronizován s lokálním adresářem Active Directory.“ To znamená, že Alternate Login ID není v této situaci kompatibilní.
Zprostředkovatelé identit třetích stran (IDP)
Microsoft má program pro testované IDP třetích stran s názvem „Works with Office 365 – Identity“. Součástí tohoto programu je seznam testovaných poskytovatelů spolu se všemi výjimkami, které mohou být u těchto produktů známy. V poznámkách k tomuto programu je uvedeno, že „Použití přihlášení pomocí alternativního ID k UPN není v tomto programu také testováno“. Takže v podstatě se váš postup může lišit při použití Alternate Login ID s některým z těchto IDP třetích stran.