Office 365 – Begränsningarna av alternativa inloggnings-ID

Intune
Jag har inte mycket bakgrund på detta en annan än att det har varit där sedan den ursprungliga funktionen release. I anteckningarna har det alltid stått: ”Om du är en Intune-kund som använder SCCM Connector kan det krävas ytterligare konfiguration”. Det säger mig att det finns något problem, men kanske någon som är mer involverad i Intune kan hjälpa till att fylla i detaljerna.
Exchange Hybrid Autodiscover: Det primära problemet här är missmatchningen mellan autentiseringsuppgifter som är giltiga på plats och autentiseringsuppgifter som är giltiga i molnet. I en Exchange Hybrid-miljö pekar Autodiscover-posterna fortfarande på den lokala Exchange där en användare autentiserar sig och sedan utför en Autodiscover-sökning. Om användaren har en brevlåda i molnet omdirigeras användaren till Office 365 där ytterligare en Autodiscover-sökning görs, med autentisering, och sedan returneras Autodiscover-svaret. Problemet som uppstår är att det krävs olika autentiseringsuppgifter för lokalväxeln (som inte vet något om alternativt inloggnings-ID) och molnet (som förväntar sig alternativt inloggnings-ID).
För domänanslutna maskiner räcker de inloggade autentiseringsuppgifterna för att autentisera till lokalväxeln och sedan får användaren den vanliga enda uppmaningen för att autentisera till Exchange Online. Den enda skillnaden du märker här är att prompten för Office 365 har fel autentiseringsuppgifter fyllda i inloggningsrutan och du måste ange ditt alternativa inloggnings-ID.
Exchange Hybrid Autodiscover: För icke-domänanslutna maskiner som inte är domänanslutna visas användaren uppmaningar för både lokala datorer och molnet utan att veta vilken plattform uppmaningen gäller. Resultatet är att även om det är tekniskt möjligt att navigera i inloggningsfrågorna är det osannolikt att användarna vet vilka autentiseringsuppgifter de ska ange vid vilken fråga.
Där det verkligen blir svårt att veta vilket konto som ska användas är när du har offentliga mappar på plats som du har gjort tillgängliga för brevlådeanvändare i molnet. Proxybrevlådan för de lokala offentliga mapparna returneras som en del av svaret för molnets automatiska identifiering och någon gång när du öppnar Outlook förväntas du ange autentiseringsuppgifterna för de lokala mapparna. Jag skulle säga att den här konfigurationen är nästan oanvändbar.
Exchange Hybrid Autodiscover: Mac
När du använder den nya ”Outlook för Mac”, kommer felmatchningen av alternativt inloggnings-ID att leda till att Outlook misslyckas under den automatiska kontoinställningen. Användaren måste manuellt konfigurera Outlook för att använda målet ”https://outlook.office365.com/EWS/Exchange.asmx”.
Office ProPlus
Beteendet här är något märkligt. När en användare använder alternativt inloggnings-ID kommer Office ProPlus att installeras och visas aktiverat under användarens konto i molnet, men i de lokala programmen kommer det att visa att du är inloggad under ditt lokala UPN.
Resultatet är att du inte kommer att se länkarna till ditt OneDrive for Business i Office-programmen och OneDrive for Business Sync Client kommer inte att konfigureras. Även om du kan logga ut från den lokala UPN:n och logga in med ditt alternativa inloggnings-ID, ifrågasätter jag om Office ProPlus skulle gå in i ”läge med reducerad funktionalitet” efter en viss tid om du förblir inloggad med det lokala kontot.
Remote Connectivity Analyzer
Inte att detta är ett kritiskt problem, men Remote Connectivity Analyzer Autodiscover-testet vet inte hur man hanterar Alternate Login ID med Exchange Hybrid på grund av den dubbla autentiseringsprompten.
Azure Application Proxy
Som kommentatorn nedan noterade har den nya Azure Application Proxy en fotnot som säger: ”UPN:erna i Azure Active Directory måste vara identiska med UPN:erna i ditt lokala Active Directory för att förautentisering ska fungera. Kontrollera att Azure Active Directory är synkroniserad med din lokala Active Directory.” Detta innebär att Alternate Login ID inte är kompatibelt i den här situationen.
Tredje parts identitetsleverantörer (IDP:
Microsoft har ett program för testade tredje parts IDP:er som heter ”Works with Office 365 – Identity”. En del av detta program är en lista över testade leverantörer tillsammans med eventuella undantag som kan vara kända med dessa produkter. I anteckningarna till det här programmet står det att ”Användning av inloggning med alternativt ID till UPN testas inte heller i det här programmet”. Så i princip kan det variera när du använder alternativt inloggnings-ID med någon av dessa IDP:er från tredje part.