Connect-ExchangeOnline Zugriff verweigert

Exchange Online verweigert ie Verbindung, obwohl die Berechtigungen richtig gesetzt sind. Wieso dies passieren kann und wie man das Problem löst ist in diesem Artikel beschrieben.

Der Fehler

Das Exchange Online PowerShell Modul ist super m Exchange Online ohne GUI zu administrieren, besonders wenn man ein PowerShell Fan wie ich ist. Also verbindet man sich mit dem Modul ExchangeOnlineManagement:

Warum auch immer hat die Verbindung plötzlich nicht mehr geklappt. Also habe ich geforscht und sehr viel über folgenden Fehler gelernt:

New-ExoPSSession : Connecting to remote server outlook.office365.com failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At C:\Users\Andreas\Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement\2.0
.5\netFramework\ExchangeOnlineManagement.psm1:475 char:30
… PSSession = New-ExoPSSession -ExchangeEnvironmentName $ExchangeEnviro 
…             ~~~~~~~~~~~~~
CategoryInfo : ResourceUnavailable: (:) [New-ExoPSSession], PSRemotingTransportException
FullyQualifiedErrorId : System.Management.Automation.Remoting.PSRemotingDataStructureException,Microsoft.Exchang
e.Management.ExoPowershellSnapin.NewExoPSSession

Die Nachforschungen können ziemlich viel Zeit in Anspruch nehmen. Ich zeige in dem Artikel alles, was ich versucht habe und wie ich das Problem in den Griff bekommen habe.

Lösungsvorschlag von Microsoft

Eines der ersten Suchergebnisse im Web ist diese Website von Microsoft: Access is denied when you connect to Exchange Online with Windows PowerShell – Exchange | Microsoft Docs. Das Konto war Global Admin (zugewiesen über Priviledged Identity Management vor mehr als 1 Stunde und immer noch aktiv). Zusätzlich habe ich auch versucht, das Konto explizit zu den Organization Admins und der AAD RBAC Rolle Exchange Admins hinzuzufügen. Nichts führte zum Erfolg.

Das Konto ist natürlich aktiv, das Passwort nicht abgelaufen. Security Defaults sind im Tenant nicht aktiv, da Conditional Access verwendet wird.

Die Lösungsansätze von Microsoft haben also nicht geholfen. Versuchen wir einen anderen.

Registry Hack

Im Internet kann man auf einigen Seiten lesen, dass es einen Registry Key gibt, der auf einem Windows Rechner gesetzt werden muss. Ich habe nicht daran geglaubt, dass es hilft (weil schon der Name gefährlich klingt), aber ich habe es ausprobiert. Der Eintrag lautet wie folgt:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client
DWORD32 "AllowBasic" Value: 1

Das hat auch nach PowerShell- und PC-Neustart nicht geholfen. Da dieser Eintrag auf meinem Windows 11 Computer anfangs nicht vorhanden war, habe ich ihn wieder gelöscht.

Ist der Fehler reproduzierbar?

Um sicherzugehen, dass der Fehler nicht mit einem bestimmten Client zusammenhängt, habe ich versucht, mich mit demselben Konto von einem anderen Computer aus anzumelden, der mit diesem Azure Active Directory verbunden ist und verwaltet wird (und damit compliant ist). Das Ergebnis war derselbe Fehler -> er muss irgendwo in der Cloud verursacht werden. Normalerweise sollte dies am Anfang der Fehlersuche überprüft werden 😉

PowerShell 7 macht den Unterschied

Jetzt kommt PowerShell 7 ins Spiel. In der Hilfe zu Connect-ExchangeOnline habe ich gelesen, dass die Modulversion 2.0.4 einen neuen Parameter namens „-Device“ eingeführt hat, der nur mit PowerShell 7 funktioniert. Das klingt gut, um endlich mögliche Probleme mit dem Konto zu beseitigen. Hier sieht man was passiert, wenn man sich mit diesem neuen Parameter anmeldet:

Wenn man zu dieser Website wechselt, wird man nach dem Code gefragt, der im PowerShell Fenster angezeigt wird. Ich habe dies in einem Edge-Browser getan, in dem ich derzeit mit dem Administratorkonto angemeldet bin, das ich bei der Authentifizierung in der Shell zu verwenden versuche:

Nachdem ich den Code eingegeben habe, fragt mich Microsoft, mit welchem Konto ich mich bei ExoV2 anmelden möchte. Hier wähle ich mein Admin-Konto:

Was dann geschah, ist wirklich interessant – dieser Fehler ist nicht nur „Access Denied“ wie im PowerShell-Fehler (Ihr erinnert Euch an die Fehlermeldung vom Anfang dieses Beitrags?), es ist tatsächlich Conditional Access!

Das ist wirklich seltsam, denn die ersten Gedanken waren:

• mein Gerät ist compliant
• Ich habe MFA durchgeführt (erfolgreich)
• Ich habe alle Regeln erfüllt, die den Zugang blockieren können

Die Odyssee geht also weiter. Danke, PowerShell 7, ohne diesen Hinweis hätte es viele Stunden gedauert, das zu ergründen!

Untersuchung der Conditional Access Regeln

Innerhalb von Conditional Access sind die Anmelde-Logs der beste Ansatzpunkt. Diese lassen sich leicht in einem Browser mit dem Administrator öffnen, der sich nicht über die Shell anmelden kann. Es dauert nicht lange, bis man die Fehlerereignisse und die Gründe für die Blockierung des bedingten Zugangs findet:

Was ich dann sah, hat mich vom Hocker gehauen. Natürlich war es Conditional Access. Aber die schuldige Regel war seltsam:

Ich schwöre, ich komme von einem Windows-11-Computer, ich habe kein Linux in meiner Umgebung (und brauche es derzeit auch nicht), deshalb gibt es diese Regel. Die Regel ist einfach. Sie blockiert den Zugang für alle Benutzer für alle Cloud-Apps auf Windows Phone und Linux. Die Vermutung: Da PowerShell 7 sich als „Core“ präsentiert, wird es nicht als Windows, Android oder iOS erkannt und (technisch korrekt) in meinem Fall blockiert.

Hierfür gibt es mehrere Lösungsansätze:

• Die eigene oder Büro-IP von der Regel ausschließen
• Den Tenant Admin von der Regel ausschließen
• Die App „Office 365 Exchange Online“ von der Regel ausschließen (und dann auch alle anderen Produkte wie Teams, denn die werden sicher auch nicht verbinden können?)

Komischerweise sah das Anmeldefenster nach dem Hinzufügen des Ausschlusses oder dem Löschen dieser Regel in meinem Fall etwas anders aus:

Danach folgt eine Bestätigungsaufforderung, das Fenster nach erfolgreicher Authentifizierung zu schließen. Ich dachte, das war’s, aber —- war der Fehler immer noch da. Also hat es an Conditional Access auch nicht gelegen. Die Änderungen an der Regel waren also nicht nötig. Also habe ich auch die wieder rückgängig gemacht.

Das Ende der Odyssee – ExoV2 V2.0.6

Um ehrlich zu sein: Ich habe die Recherche nicht bis zum letzten Bit & Byte abgeschlossen. Nach mehrstündiger Forschungsarbeit sah ich irgendwo im PowerShell-Fenster eine Meldung, die besagte, dass einige Befehle bald veraltet sein könnten und ich eine Vorschauversion installieren sollte. Nun, zum Zeitpunkt des Verfassens dieses Artikels ist die aktuelle GA-Version 2.0.5. 2.0.6 ist nur als Vorschau verfügbar. Aber einen Versuch ist es wert. Also habe ich das „alte“ Modul 2.0.5 gelöscht und die neuere Version installiert:

Install-Module ExchangeOnlineManagement -AllowPrerelease

Glaubt es oder nicht – das hat das Problem für mich gelöst. Ich habe meine gesamte Testkonfiguration entfernt, alles auf die Standardeinstellungen zurückgesetzt und das Ergebnis war eine erfolgreiche Verbindung:

Das Leben kann so einfach sein… Und das Fazit lautet: Haltet eure PowerShell Module immer auf dem neuesten Stand!