Office 365 – Die Grenzen der alternativen Anmelde-ID

BY admin
|

Intune
Ich habe nicht viel Hintergrundwissen zu diesem Thema, außer dass es schon seit der ursprünglichen Version der Funktion vorhanden ist. In den Hinweisen hieß es immer: „Wenn Sie ein Intune-Kunde sind und den SCCM Connector verwenden, ist möglicherweise eine zusätzliche Konfiguration erforderlich“. Das sagt mir, dass es irgendeine Art von Problem gibt, aber vielleicht kann jemand, der mehr mit Intune zu tun hat, die Details aufklären.
Exchange Hybrid Autodiscover: Domain Joined
Das Hauptproblem hier ist die Nichtübereinstimmung zwischen Anmeldeinformationen, die vor Ort gültig sind, und Anmeldeinformationen, die in der Cloud gültig sind. In einer Exchange-Hybridumgebung verweisen die Autodiscover-Datensätze immer noch auf den lokalen Exchange, wo sich ein Benutzer authentifiziert und dann eine Autodiscover-Suche durchführt. Wenn der Benutzer über ein Cloud-Postfach verfügt, wird er dann an Office 365 weitergeleitet, wo eine weitere Autodiscover-Abfrage mit Authentifizierung durchgeführt und die Autodiscover-Antwort zurückgegeben wird. Das Problem, das dabei auftritt, ist, dass unterschiedliche Anmeldeinformationen für On-Premises (die nichts über die alternative Anmelde-ID wissen) und die Cloud (die die alternative Anmelde-ID erwartet) erforderlich sind.
Für domänenverbundene Rechner reichen die angemeldeten Anmeldeinformationen aus, um sich beim On-Premises-Exchange zu authentifizieren, und dann erhält der Benutzer die übliche einzelne Aufforderung zur Authentifizierung bei Exchange Online. Der einzige Unterschied besteht darin, dass bei der Eingabeaufforderung für Office 365 die falschen Anmeldeinformationen in das Anmeldefeld eingegeben werden und Sie Ihre alternative Anmelde-ID eingeben müssen.
Exchange Hybrid Autodiscover: Non-Domain Joined
Bei nicht domänenverbundenen Rechnern werden dem Benutzer Aufforderungen sowohl für On-Premises als auch für die Cloud angezeigt, ohne dass er weiß, für welche Plattform die Aufforderung gilt. Das Ergebnis ist, dass es zwar technisch möglich ist, durch die Anmeldeaufforderungen zu navigieren, es aber unwahrscheinlich ist, dass Ihre Benutzer wissen, welche Anmeldeinformationen sie bei welcher Aufforderung angeben müssen.
Wo es wirklich schwierig wird, zu wissen, welches Konto zu verwenden ist, ist, wenn Sie öffentliche Ordner vor Ort haben, die Sie für Benutzer von Cloud-Postfächern zugänglich gemacht haben. Das Proxy-Postfach für die lokalen öffentlichen Ordner wird als Teil der Cloud-Autodiscover-Antwort zurückgegeben, und irgendwann beim Öffnen von Outlook wird erwartet, dass Sie die lokalen Anmeldeinformationen eingeben. Ich würde sagen, dass diese Konfiguration fast unbrauchbar ist.
Exchange Hybrid Autodiscover: Mac
Bei Verwendung des neuen „Outlook für Mac“ führt die Nichtübereinstimmung der alternativen Anmelde-ID dazu, dass Outlook bei der automatischen Kontoeinrichtung fehlschlägt. Der Benutzer muss Outlook manuell konfigurieren, um das Ziel „https://outlook.office365.com/EWS/Exchange.asmx“ zu verwenden.
Office ProPlus
Das Verhalten ist hier etwas seltsam. Wenn ein Benutzer eine alternative Anmelde-ID verwendet, wird Office ProPlus installiert und unter dem Konto dieses Benutzers in der Cloud aktiviert angezeigt. In den lokalen Anwendungen wird jedoch angezeigt, dass Sie unter Ihrem lokalen UPN angemeldet sind.
Das Ergebnis ist, dass Sie die Links zu Ihrem OneDrive for Business innerhalb der Office-Anwendungen nicht sehen und der OneDrive for Business Sync Client nicht eingerichtet wird. Sie können sich zwar vom lokalen UPN abmelden und sich mit Ihrer alternativen Anmelde-ID anmelden, aber ich frage mich, ob Office ProPlus nach einer gewissen Zeit in den „Modus mit eingeschränkter Funktionalität“ wechseln würde, wenn Sie mit dem lokalen Konto angemeldet bleiben.
Remote Connectivity Analyzer
Nicht, dass dies ein kritisches Problem wäre, aber der Autodiscover-Test des Remote Connectivity Analyzer weiß nicht, wie er mit der Alternate Login ID mit Exchange Hybrid aufgrund der doppelten Authentifizierungsaufforderung umgehen soll.
Azure Application Proxy
Wie vom Kommentator unten angemerkt, hat der neue Azure Application Proxy eine Fußnote, die besagt: „Die UPNs in Azure Active Directory müssen mit den UPNs in Ihrem lokalen Active Directory identisch sein, damit die Vorauthentifizierung funktioniert. Stellen Sie sicher, dass Ihr Azure Active Directory mit Ihrem lokalen Active Directory synchronisiert ist.“ Das bedeutet, dass Alternate Login ID in dieser Situation nicht kompatibel ist.
Drittanbieter-Identitätsanbieter (IDPs)
Microsoft hat ein Programm für getestete Drittanbieter-IDPs namens „Works with Office 365 – Identity“. Teil dieses Programms ist eine Liste von getesteten Anbietern zusammen mit allen Ausnahmen, die mit diesen Produkten bekannt sein könnten. In den Hinweisen zu diesem Programm heißt es: „Die Verwendung der Anmeldung über eine alternative ID an UPN wird in diesem Programm ebenfalls nicht getestet“. Die Verwendung einer alternativen Anmelde-ID mit einem dieser IDPs von Drittanbietern kann also von Fall zu Fall unterschiedlich sein.