Office 365 – Ograniczenia alternatywnego identyfikatora logowania

Intune
Nie mam zbyt wiele tła na ten temat, poza tym, że jest tam od czasu oryginalnego wydania funkcji. W notatkach zawsze było napisane: „Jeśli jesteś klientem Intune używającym SCCM Connector, może być wymagana dodatkowa konfiguracja”. To mówi mi, że jest jakiś problem, ale może ktoś bardziej zaangażowany w Intune może pomóc wypełnić szczegóły.
Exchange Hybrid Autodiscover: Domain Joined
Podstawowym problemem jest tutaj rozbieżność pomiędzy poświadczeniami, które są ważne w siedzibie firmy a poświadczeniami, które są ważne w chmurze. W środowisku Exchange Hybrid rekordy Autodiscover nadal wskazują na lokalny Exchange, gdzie użytkownik uwierzytelnia się, a następnie wykonuje wyszukiwanie Autodiscover. Jeżeli użytkownik posiada skrzynkę w chmurze, zostaje on przekierowany do Office 365, gdzie wykonywany jest kolejny Autodiscover lookup z uwierzytelnieniem, a następnie zwracana jest odpowiedź Autodiscover. Problem jaki się pojawia to fakt, że różne dane uwierzytelniające są potrzebne do uwierzytelnienia on-premises (który nie wie nic o Alternate Login ID) i do chmury (która oczekuje Alternate Login ID).
W przypadku maszyn połączonych domenowo, dane zalogowanego użytkownika są wystarczające do uwierzytelnienia do on-premises Exchange, a następnie użytkownik otrzymuje zwykły pojedynczy monit do uwierzytelnienia do Exchange Online. Jedyną różnicą jaką można zauważyć jest to, że w przypadku Office 365 w polu logowania wpisane są nieprawidłowe dane i użytkownik musi podać swój Alternate Login ID.
Exchange Hybrid Autodiscover: Non-Domain Joined
W przypadku maszyn niepołączonych domenowo użytkownik otrzymuje monity zarówno dla maszyn w siedzibie firmy, jak i w chmurze, nie wiedząc, dla której platformy są one przeznaczone. Rezultat jest taki, że podczas gdy jest technicznie możliwe poruszanie się po monitach logowania, jest mało prawdopodobne, że użytkownicy będą wiedzieli jakie poświadczenia podać podczas jakiego monitu.
Gdzie to naprawdę staje się trudne, aby wiedzieć jakiego konta użyć jest, gdy masz on-premises Public Folders, które udostępniłeś użytkownikom skrzynek w chmurze. Skrzynka proxy dla folderów publicznych w chmurze jest zwracana jako część odpowiedzi Autodiscover w chmurze i w pewnym momencie przy otwieraniu Outlooka oczekuje się, że użytkownik wprowadzi dane uwierzytelniające z chmury. Powiedziałbym, że taka konfiguracja jest prawie bezużyteczna.
Exchange Hybrid Autodiscover: Mac
W przypadku korzystania z nowego „Outlook for Mac”, niedopasowanie poświadczeń Alternate Login ID spowoduje, że Outlook nie powiedzie się podczas automatycznej konfiguracji konta. Użytkownik będzie musiał ręcznie skonfigurować Outlooka, aby używał celu „https://outlook.office365.com/EWS/Exchange.asmx”.
Office ProPlus
Zachowanie w tym przypadku jest nieco dziwne. Jeśli użytkownik korzysta z alternatywnego identyfikatora logowania, program Office ProPlus zostanie zainstalowany i wyświetlony jako aktywowany pod kontem tego użytkownika w chmurze, jednak w aplikacjach lokalnych zostanie wyświetlony jako zalogowany pod lokalnym numerem UPN.
W rezultacie w aplikacjach pakietu Office nie będą widoczne łącza do usługi OneDrive for Business, a klient synchronizacji usługi OneDrive for Business nie zostanie skonfigurowany. Chociaż można wylogować się z lokalnego numeru UPN i zalogować się za pomocą alternatywnego identyfikatora logowania, zastanawiam się, czy po pewnym czasie pakiet Office ProPlus przejdzie w tryb „ograniczonej funkcjonalności”, jeśli pozostanie zalogowany na koncie lokalnym.
Remote Connectivity Analyzer
Nie jest to krytyczny problem, ale test Remote Connectivity Analyzer Autodiscover nie wie, jak obsługiwać Alternate Login ID z Exchange Hybrid z powodu monitu o podwójne uwierzytelnienie.
Azure Application Proxy
Jak zauważył komentujący poniżej, nowy Azure Application Proxy ma przypis stwierdzający: „Numery UPN w usłudze Azure Active Directory muszą być identyczne z numerami UPN w lokalnej usłudze Active Directory, aby wstępne uwierzytelnianie działało. Upewnij się, że Twoja Azure Active Directory jest zsynchronizowana z Twoją lokalną Active Directory.” Oznacza to, że Alternate Login ID nie jest kompatybilny w tej sytuacji.
Third-Party Identity Providers (IDPs)
Microsoft ma program dla przetestowanych IDPs innych firm o nazwie „Works with Office 365 – Identity”. Częścią tego programu jest lista przetestowanych dostawców wraz z wszelkimi wyjątkami, które mogą być znane w przypadku tych produktów. W uwagach do tego programu znajduje się informacja, że „Używanie logowania za pomocą alternatywnego identyfikatora do UPN również nie jest testowane w tym programie”. Więc w zasadzie twój przebieg może się różnić, gdy używasz Alternate Login ID z którymkolwiek z tych zewnętrznych IDP.