Office 365 PowerShell mit MFA
Microsoft propagiert seit viel Jahren, dass eine bessere Absicherung von administrativen Konten anzuraten ist, damit ein bekannt gewordenes Kennwort nicht ausgenutzt werden kann. Das betrifft erst recht auch die verschiedenen Zugänge per PowerShell. Solange ein Administrator "interaktiv" sich per PowerShell verbindet, ist MFA ja noch einfach. Was mache ich aber mit automatisierten Dienstkonten, die entsprechende Aktionen auslösen?
Momentaufnahme Nov 2018
Ich habe also einfach mal ein Admin-Konto mit MFA aktiviert und versucht per PowerShell-Script die Verbindung aufzubauen.
Module | Meldung | Status |
---|---|---|
Connect-AzureAD |
Connect-AzureAD : AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication |
Das Modul erkennt die MFA-Erfordernis und bricht ab.- |
Connect-MSOLOnline |
Kein Fehler aber interaktiver Dialog |
Trotz Angabe von entsprechenden Credentials kommt bei mir ein interaktiver Dialog zur Eingabe von Anmeldedaten. Damit geht dann zwar MFA aber das bringt mir bei einem Skript ohne Benutzersteuerung nichts. Inwieweit man später mit den Parametern "AdGraphAccessToken" oder "MsGraphAccessToken" etwas bewirken kann, habe ich noch nicht ermittelt. |
SfB Online |
Get-CsAccessToken : AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<39624784-6cbe-4a60-afbe-9f46d10fdb27'. |
Das Modul erkennt die MFA-Erfordernis und bricht ab. Interessant finde ich, dass es einen Befehl "Get-CsAccessToken" gibt, der hier im Fehler als Quelle erscheint. |
Exchange Online |
New-PSSession : [outlook.office365.com] Beim Verbinden mit dem Remoteserver "outlook.office365.com" ist folgender Fehler aufgetreten: Zugriff verweigert |
Ich bekomme eine Fehlermeldung, dass die Anmeldung fehlgeschlagen ist aber keinen Hinweis auf MFA als Ursache |
Compliance PowerShell |
New-PSSession : [ps.compliance. protection.outlook.com] Beim Verbinden mit dem Remoteserver "ps.compliance.protection.outlook.com" ist folgender Fehler aufgetreten: Zugriff verweigert. |
Gleiches Verhalten wie Exchange |
Sobald also MFA aktiviert ist, kann sich keine Powershell mehr automatisch allein mit Benutzername und Kennwort anmelden. Allerdings poppt auch kein zusätzliches Fenster auf, um einen zweiten Faktor anzufügen, d.h. keine Einmalcode-Eingabe, kein Telefonanruf o.ä.
- Verbinden mit allen Office 365-Diensten
in einem einzigen Windows PowerShell-Fenster
https://docs.microsoft.com/de-de/office365/enterprise/powershell/connect-to-all-office-365-services-in-a-single-windows-powershell-window
Host als zweiter Faktor
Anders als Anwender und Administratoren laufen automatisierte Skripte in der Regel auf einem oder wenigen festgelegten Systemen. Es gibt oft den einen Server, auf dem alle Skripte per Taskplaner o.ä. gestartet werden. Da wäre es eine Überlegung werden, die Ausführung dieser Skripte unter Nutzung des zugeordneten Dienstkontos auf dieses System zu beschränken. Dazu fallen mir folgende Optionen ein:
- IP-Adresse des Hosts
Eine IP-Adresse zu fälschen ist möglich aber im Internet nicht ganz trivial. Office 365 sieht die Anfrage über eine öffentliche IP-Adresse, die Sie als Administrator beeinflussen können. Allerdings werden die meisten Internetzugänge mehrere Clients hinter der gleichen Adresse verstecken. Es wäre schon eine Einschränkung, wenn hier eine 1:1 Zuordnung konfiguriert werden müsste. Aber dann könnten Sie als Office 365 Admin dort unter MFA eine entsprechende Regel einrichten, dass für dieses Dienstkonto diese IP-Adresse als zweiter Faktor gewertet wird.
Solche Regeln sind auch für Anwender üblich, um z.B. den Zugang zu Office 365 für "bekannte vertrauenswürdige" Netzwerke ohne weiteren Faktor zu erlauben. - Zertifikate
Eine andere Option wäre die Nutzung von Benutzerzertifikaten, mit denen sich der Anwender gegen Office 365 ausweist. So ein Zertifikat könnte einmal auf den UPN des Anwender ausgestellt werden und auf dem Computer als "nicht exportierbar" hinterlegt werden. In dem Fall gibt es quasi kein weiteres Kennwort und bei entsprechender Konfiguration könnte der Zugriff auf den privaten Schüssel auf das lokale Dienstkonto beschränkt werden, unter dem das Skript lokal gestartet wird. - App-Password
Auf App Password habe ich beschrieben, wie automatische Prozesse über ein einmaliges und sehr langes "App-Password" sich gegen Office 365 anmelden können. Dieser Weg ist natürlich kein MFA mehr aber beschränkt den Zugang auf "nicht interaktive" Dienste. Mit einem App-Kennwort kann ich mich z.B. nicht per Browser anmelden. Für einen Angreifer ist aber die PowerShell eh lohnender.
Eine Lösung per Zertifikate wäre aus meiner Sicht hier sehr charmant aber aktuell noch nicht nutzbar, so dass eine Beschränkung des Dienstkontos in der Cloud über
Andere Kriterien?
Office 365 MFA erlaubt natürlich noch weitere Methoden sich mit einem zusätzlichen Faktor anzumelden. Allerdings ist keine davon für eine automatische Nutzung geeignet. Ich denke nicht, dass sie als Administrator bei jeder Anmeldung des Skripts an Office 365 auf einem Smartphone einen Anruf annehmen oder eine Abfrage bestätigen wollen.
Es könnte aber interessant sein, dies einmalig beim Start des Prozesses durchzuführen, so dass sich der Prozess ein OATH-Token über eine klassische MFA-Anmeldung besorgen kann. Solange der Dienst dann "läuft" und das Ticket auch immer wieder erneuern kann, ist der Zugang sichergestellt. Wenn der Host oder der Dienst aber neu gestartet wird oder von einem Angreifer ein "Clone" gezogen und anderweitig gestartet wurde, dann wäre eine erneute Bestätigung des zweiten Faktors erforderlich.
Der Schutz wäre damit verbessert aber natürlich wäre auch die eigene legitime Einsatz ist schon etwas erschwert. So müsste nach einem automatischen Neustart wieder jemand dem Dienst unter die Arme greifen. Auf der anderen Seite würde so natürlich sofort auffallen, wenn auf dem legitimen Service etwas passiert. Sicherheit hat nu mal ihren Preis.
Allerdings sind all diese Dinge rein hypothetische Überlegungen, denn meines Wissens gibt es hier noch keine entsprechende Lösungen.
Zwischenstand
MFA für Administratoren, die interaktiv sich an Office 365 per PowerShell oder Webbrowser anmelden, ist nicht nur eine gute Idee sondern wirklich dringend anzuraten. Der Einsatz für automatisierte Dienstkonten ist möglich, wenn Sie z.B. die IP-Adresse als Faktor nutzen. Dann müssen Sie auch nichts an ihren bestehenden PowerShell-Skripten anpassen. Wer mag, kann natürlich auch App Passworte nutzen.
Bei einigen PowerShell-Modulen ist erkennbar, dass Sie sehr wohl erkennen, dass MFA die Anmeldung verbietet aber es gibt keine Möglichkeit hier per Skripte dies zu umgehen. Auf der folgenden Seite ist aufgeführt, wie sie per PowerShell sich mit MFA anmelden können
- Verbinden mit allen Office 365-Diensten in einem einzigen
Windows PowerShell-Fenster
https://docs.microsoft.com/de-de/office365/enterprise/powershell/connect-to-all-office-365-services-in-a-single-windows-powershell-window
Wenn Sie aber genau hinschauen, dann werden die Commandlets zur Verbindung einfach ohne Credentials aufgerufen, so dass Sie die Anmeldedaten interaktiv eingeben können. Das bringt und hier also nicht weiter, wenn Automatismen diesen Zugang nutzen sollen.