Office 365 – De beperkingen van Alternate Login ID
Intune
Ik heb niet veel achtergrond over deze, anders dan dat het er al is sinds de oorspronkelijke feature release. De notities hebben altijd gezegd: “Als u een Intune klant bent die de SCCM Connector gebruikt, kan er extra configuratie nodig zijn”. Dat zegt me dat er een of ander probleem is, maar misschien kan iemand die meer met Intune te maken heeft helpen de details op te helderen.
Exchange Hybrid Autodiscover: Domain Joined
Het primaire probleem hier is de mismatch tussen credentials die geldig zijn on-premises en credentials die geldig zijn in de cloud. In een Exchange Hybrid omgeving verwijzen de Autodiscover records nog steeds naar de on-premises Exchange waar een gebruiker zich authentiseert en vervolgens een Autodiscover lookup uitvoert. Als de gebruiker een cloud mailbox heeft, wordt de gebruiker doorgestuurd naar Office 365 waar een andere Autodiscover lookup wordt gedaan, met authenticatie, en vervolgens de Autodiscover response wordt teruggestuurd. Het probleem dat zich voordoet is dat er verschillende credentials nodig zijn voor on-premises (die niets weet over Alternate Login ID) en de cloud (die de Alternate Login ID verwacht).
Voor domain joined machines zijn de ingelogde credentials voldoende om te authenticeren bij de on-premises Exchange en vervolgens krijgt de gebruiker de gebruikelijke enkele prompt om te authenticeren bij Exchange Online. Het enige verschil is dat de prompt voor Office 365 de verkeerde inloggegevens bevat en je dus je Alternate Login ID moet invoeren.
Exchange Hybrid Autodiscover: Non-Domain Joined
Voor niet-domain joined machines krijgt de gebruiker prompts te zien voor zowel on-premises als de cloud zonder te weten voor welk platform de prompt is. Het resultaat is dat, hoewel het technisch mogelijk is om door de aanmeldingsprompts te navigeren, het onwaarschijnlijk is dat uw gebruikers weten welke referenties ze bij welke prompt moeten opgeven.
Waar dit echt moeilijk wordt om te weten welke account moet worden gebruikt, is wanneer u on-premises Public Folders hebt die u toegankelijk hebt gemaakt voor cloud-mailboxgebruikers. De proxy mailbox voor de on-premises Public Folders wordt geretourneerd als onderdeel van de cloud Autodiscover respons en op een gegeven moment bij het openen van Outlook, wordt van je verwacht dat je de on-premises credentials invoert. Ik zou zeggen dat deze configuratie bijna onbruikbaar is.
Exchange Hybrid Autodiscover: Mac
Bij gebruik van de nieuwe “Outlook for Mac”, zal de credential mismatch van Alternate Login ID ervoor zorgen dat Outlook faalt tijdens de automatische account setup. De gebruiker zal Outlook handmatig moeten configureren om het doel van “https://outlook.office365.com/EWS/Exchange.asmx” te gebruiken.
Office ProPlus
Het gedrag hier is enigszins vreemd. Wanneer een gebruiker een alternatieve aanmeldings-ID gebruikt, wordt Office ProPlus geïnstalleerd en geactiveerd weergegeven onder de account van die gebruiker in de cloud, maar in de lokale toepassingen wordt weergegeven dat u bent aangemeld onder uw on-premises UPN.
Het resultaat is dat u de koppelingen naar uw OneDrive for Business binnen de Office-toepassingen niet ziet en dat de OneDrive for Business Sync Client niet wordt ingesteld. Hoewel u zich kunt afmelden van de on-premises UPN en aanmelden met uw Alternatieve Login ID, vraag ik me af of Office ProPlus zou gaan in “verminderde functionaliteit modus” na een periode van tijd als bleef aangemeld met de on-premises account.
Remote Connectivity Analyzer
Niet dat dit een kritiek issue is maar de Remote Connectivity Analyzer Autodiscover test weet niet hoe om te gaan met Alternate Login ID met Exchange Hybrid vanwege de dubbele authenticatie prompt.
Azure Application Proxy
Zoals opgemerkt door de commenter hieronder, de nieuwe Azure Application Proxy heeft een voetnoot waarin staat: “De UPN’s in Azure Active Directory moeten identiek zijn aan de UPN’s in uw on-premises Active Directory om preauthenticatie te laten werken. Zorg ervoor dat uw Azure Active Directory is gesynchroniseerd met uw on-premises Active Directory.” Dit betekent dat Alternate Login ID in deze situatie niet compatibel is.
Third-Party Identity Providers (IDP’s)
Microsoft heeft een programma voor geteste IDP’s van derden genaamd “Works with Office 365 – Identity”. Onderdeel van dit programma is een lijst met geteste providers samen met eventuele uitzonderingen die bekend zijn met deze producten. In de opmerkingen bij dit programma staat dat “Gebruik van Aanmelden via Alternatieve ID naar UPN is ook niet getest in dit programma”. Dus in principe kan uw ervaring variëren bij het gebruik van Alternatieve Login ID met een van deze IDP’s van derden.