Office 365 – Az alternatív bejelentkezési azonosító korlátai

Intune
Nincs sok háttérinformációm erről, kivéve, hogy az eredeti funkció kiadása óta ott van. A jegyzetekben mindig is ez állt: “Ha Ön az SCCM Connector-t használó Intune-ügyfél, további konfigurációra lehet szükség”. Ez azt mondja nekem, hogy valamilyen probléma van, de talán valaki, aki többet foglalkozik az Intune-nal, tud segíteni a részletek tisztázásában.
Exchange Hybrid Autodiscover: Domain Joined
Az elsődleges probléma itt a helyben érvényes hitelesítő adatok és a felhőben érvényes hitelesítő adatok közötti eltérés. Egy Exchange Hybrid környezetben az Autodiscover rekordok továbbra is a helyben lévő Exchange-re mutatnak, ahol a felhasználó hitelesíti magát, majd elvégzi az Autodiscover keresést. Ha a felhasználó felhőalapú postafiókkal rendelkezik, akkor a felhasználó átirányításra kerül az Office 365-re, ahol újabb Autodiscover-keresés történik, hitelesítéssel, majd visszaküldésre kerül az Autodiscover-válasz. A felmerülő probléma az, hogy különböző hitelesítő adatok szükségesek a helyben lévő (amely nem tud semmit az Alternatív bejelentkezési azonosítóról) és a felhő (amely elvárja az Alternatív bejelentkezési azonosítót) esetében.
A tartományhoz csatlakozott gépek esetében a bejelentkezett hitelesítő adatok elegendőek a helyben lévő Exchange-en történő hitelesítéshez, majd a felhasználó a szokásos egyetlen felszólítást kapja az Exchange Online-on történő hitelesítéshez. Az egyetlen különbség, amit itt észrevehet, hogy az Office 365-hez tartozó promptban a bejelentkezési mezőben rossz hitelesítő adatok vannak kitöltve, és meg kell adni az Alternatív bejelentkezési azonosítót.
Exchange Hybrid Autodiscover: Nem tartományhoz csatlakozott
A nem tartományhoz csatlakozott gépek esetében a felhasználónak a helyben és a felhőben is megjelenik a felszólítás anélkül, hogy tudná, melyik platformra vonatkozik a felszólítás. Ennek az az eredménye, hogy bár technikailag lehetséges a bejelentkezési felszólítások között navigálni, nem valószínű, hogy a felhasználók tudják, hogy melyik felszólítás során milyen hitelesítő adatokat kell megadniuk.
Ahol ez igazán nehézzé válik, hogy melyik fiókot kell használni, az az, ha vannak olyan helyhez kötött nyilvános mappák, amelyeket a felhőposta-felhasználók számára elérhetővé tettünk. A helyben lévő nyilvános mappák proxy postafiókja a felhő automatikus felismerési válaszának részeként kerül vissza, és az Outlook megnyitásakor egy bizonyos ponton elvárják, hogy megadja a helyben lévő hitelesítő adatokat. Azt mondanám, hogy ez a konfiguráció szinte használhatatlan.
Exchange Hybrid Autodiscover: Mac
Az új “Outlook for Mac” használatakor az Alternatív bejelentkezési azonosító hitelesítő adatainak eltérése miatt az automatikus fiókbeállítás során az Outlook meghiúsul. A felhasználónak manuálisan kell beállítania az Outlookot a “https://outlook.office365.com/EWS/Exchange.asmx” célpont használatára.
Office ProPlus
A viselkedés itt kissé furcsa. Ha egy felhasználó Alternatív bejelentkezési azonosítót használ, az Office ProPlus telepíti és az adott felhasználó fiókja alatt aktiválva jelenik meg a felhőben, azonban a helyi alkalmazásokban a helyi UPN-je alatt bejelentkezve jelenik meg.
Az eredmény az, hogy az Office alkalmazásokban nem látja a OneDrive for Businessre mutató hivatkozásokat, és a OneDrive for Business szinkronizálási ügyfél nem lesz beállítva. Bár Ön lejelentkezhet a helyhez kötött UPN-ről, és bejelentkezhet az Alternatív bejelentkezési azonosítóval, kérdéses számomra, hogy az Office ProPlus egy idő után “csökkentett funkcionalitású üzemmódba” kerül-e, ha a helyhez kötött fiókkal bejelentkezve marad.
Remote Connectivity Analyzer
Nem mintha ez kritikus probléma lenne, de a Remote Connectivity Analyzer Autodiscover tesztje nem tudja, hogyan kezelje az Alternate Login ID-t az Exchange Hybriddel a kettős hitelesítési kérés miatt.
Azure Application Proxy
Amint azt az alábbi hozzászóló megjegyezte, az új Azure Application Proxy lábjegyzetben szerepel a következő: “Az Azure Active Directoryban szereplő UPN-eknek meg kell egyezniük a helyi Active Directoryban szereplő UPN-ekkel ahhoz, hogy az előzetes hitelesítés működjön. Győződjön meg róla, hogy az Azure Active Directory szinkronizálva van a helyben lévő Active Directoryval”. Ez azt jelenti, hogy az Alternate Login ID ebben a helyzetben nem kompatibilis.”
Harmadik féltől származó azonosítószolgáltatók (IDP-k)
A Microsoftnak van egy programja a harmadik féltől származó IDP-k tesztelésére “Works with Office 365 – Identity” néven. Ennek a programnak része a tesztelt szolgáltatók listája, valamint az adott termékekkel kapcsolatban ismert kivételek. Ennek a programnak a megjegyzései között szerepel, hogy “A “Sign-in by Alternate ID to UPN” használata szintén nem tesztelt ebben a programban”. Tehát alapvetően az alternatív bejelentkezési azonosító használata bármelyik harmadik féltől származó IDP-vel eltérő lehet.