{"id":518,"date":"2024-01-28T15:11:04","date_gmt":"2024-01-28T14:11:04","guid":{"rendered":"https:\/\/sparrow365.de\/?p=518"},"modified":"2024-11-04T20:21:32","modified_gmt":"2024-11-04T19:21:32","slug":"connect-mggraph-mit-benutzername-und-passwort","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/2024\/01\/28\/connect-mggraph-mit-benutzername-und-passwort\/","title":{"rendered":"Connect-MgGraph mit Benutzername und Passwort"},"content":{"rendered":"

In meiner Arbeit an der praktischen Umsetzung<\/a> von Kennwortrotation ohne Privileged Authentication Administrator<\/a>, bin ich \u00fcber eine etwas umfangreiche Herausforderung<\/strong> gestolpert.<\/p>\n

Wenn man sich \u00fcber PowerShell mit Benutzername + Passwort<\/strong> an der Graph API anmelden will, findet man keine Kombination in der PowerShell SDK<\/a>.
\nDie einzige Methode w\u00e4re ClientID + Secret – damit w\u00e4ren wir aber wieder bei der Nutzung von App Permissions, was ich in diesem Fall konkret vermeiden will.<\/p>\n

Wir wissen auch, dass es geht<\/em>, weil in der Azure command line<\/strong> ein solcher connect m\u00f6glich<\/a> ist – nur daf\u00fcr<\/strong> aber das Az Modul oder die Azure CLI zu fordern widerspricht meinem Perfektionismus<\/strong>. Vor allem weil es dort auch nicht trivial ist, sich gegen eine spezifische App Registration zu authentifizieren.<\/p>\n

\n

Die faule L\u00f6sung gibt es entsprechend schon<\/a> – den Token kann man dann mit Connect-MgGraph -AccessToken $(ConvertTo-SecureString "<AccessToken>")<\/code><\/code> weiter verwenden<\/em><\/p>\n<\/blockquote>\n

Da ein so spezifisches Teilproblem bald den halben Artikel einnahm, fasse ich lieber hier separat zusammen, wie ich zu meiner L\u00f6sung<\/strong><\/a> gekommen bin.<\/p>\n


<\/p>\n

Erste Untersuchung<\/h2>\n

Beginnend mit dem Wissen, dass es eine funktionierende Implementierung gibt, habe ich mir mal mehr Details geben lassen<\/a>. So komme ich also zu dem Resource Owner Password Credentials (ROPC) grant<\/strong>. In der zugeh\u00f6rigen Dokumentation<\/a> finden wir auch schon sehr detaillierte Informationen, wie er zu benutzen ist. <\/p>\n

N\u00e4mlich idealerweise gar nicht:<\/strong><\/u><\/p>\n

\"ROPC<\/p>\n

Moderne Authentifizierungsprotokolle sind so gebaut, dass Benutzeranmeldung so weit von der Applikation getrennt sein soll wie m\u00f6glich<\/strong> – bei allen anderen OIDC Flows bekommen wir einfach die Best\u00e4tigung, dass der Benutzer authentifiziert ist. Hier halten wir tempor\u00e4r seine Credentials<\/strong> – wo wir es meistens gar nicht m\u00fcssten.<\/p>\n

Allerdings ist da die relevante Phrase: "in most scenarios"<\/em><\/u>. Wenn ich mich ohne Interaktion<\/strong> als normaler Benutzer<\/em><\/u> anmelden will, gibt es meines Wissens keine Alternative<\/strong> – ich bin aber f\u00fcr eine Korrektur offen. Der Upside ist es in meinem Szenario Wert, weil paradoxerweise in meinem ganz spezifischen Usecase Benutzerberechtigungen um Meilen granularer<\/strong> sind als Applikationsrechte – und ich eh die Passw\u00f6rter der Benutzer im PAM Vault habe.<\/p>\n

Wir werden aber auch sehr wahrscheinlich keine SDKs<\/strong> finden, die so funktionieren wie ich es gerne h\u00e4tte: Ich stimme Microsoft zu, ich will nicht, dass auf diese App von Benutzern zugegriffen wird. Sonst w\u00fcrden sie sich ohne MFA<\/strong> Authentifizieren k\u00f6nnen und requests gegen die API stellen. Der beste Weg dazu w\u00e4re, dass ich eine confidential client App<\/strong><\/a> registriere, wo bei Requests immer ein Zertifikat mitgegeben werden muss um nachzuweisen, dass das System die App Registration nutzen darf<\/strong>. Aber: <\/p>\n

\"ROPC<\/p>\n

Nachvollziehbar, wenn man davon ausgeht, dass beim Login<\/strong> Passw\u00f6rter an den Server weiter gegeben werden w\u00fcrden. In unserem Fall aber nicht zutreffend, weil wir die Kennw\u00f6rter ja schon haben<\/strong>.<\/p>\n

Wenn die SDKs es nicht unterst\u00fctzen, werden wir wohl die Web Requests nachbauen m\u00fcssen.<\/p>\n


<\/p>\n

Bau des Code<\/h2>\n

Ich mache mir zwar oft viel mehr Arbeit als notwendig w\u00e4re (So wie jetzt gerade? \ud83e\udd14) – ich will aber nicht ganz \u00fcbertreiben. Es gibt mehr als genug Implementierungen<\/strong> der Graph API Auth \u00fcber Invoke-WebRequest<\/code><\/code> – ich werde mir also eine m\u00f6glichst gute Version nehmen und f\u00fcr ROPC anpassen<\/strong>.<\/p>\n

Am besten<\/strong> sah f\u00fcr mich die Version von Adam The Automator<\/a> aus – vor allem weil dort auch direkt die zertifikatsbasierte Authentifizierung<\/strong> implementiert ist, an der ich wahrscheinlich eine ganze Weile geknabbert h\u00e4tte.<\/p>\n

Bei ersten Tests des Codes stolpere ich aber \u00fcber in Problem:<\/p>\n

\"Error<\/p>\n

Nach ein wenig Troubleshooting identifiziere ich die folgende Passage:<\/p>\n

#...\n$Certificate = Get-Item Cert:\\CurrentUser\\My\\$thumbprint\n#...\n\n# Get the private key object of your certificate\n$PrivateKey = $Certificate.PrivateKey\n\n# Define RSA signature and hashing algorithm\n$RSAPadding = [Security.Cryptography.RSASignaturePadding]::Pkcs1\n$HashAlgorithm = [Security.Cryptography.HashAlgorithmName]::SHA256\n\n# Create a signature of the JWT\n$Signature = [Convert]::ToBase64String(\n    $PrivateKey.SignData([System.Text.Encoding]::UTF8.GetBytes($JWT),$HashAlgorithm,$RSAPadding)\n) -replace '\\+','-' -replace '\/','_' -replace '='\n#...<\/code><\/pre>\n
Wahrscheinlich weil meine Private Keys nicht exportierbar sind blieb $PrivateKey<\/code><\/code> leer.
\nAuch private Keys, die nicht exportiert werden k\u00f6nnen sind aber auf dem System nutzbar, auf dem sie installiert sind – sonst w\u00fcrde Connect-MgGraph -CertificateThumbprint -ClientId<\/code><\/code> auch fehlschlagen.<\/p>\n
Baut man ein .Net Objekt direkt aus dem Zertifikat, dass einem eine Signatur liefern kann, kommen wir weiter:<\/p>\n
$rsaCert = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($Certificate)\n$Signature = [Convert]::ToBase64String(\n    $rsaCert.SignData([System.Text.Encoding]::UTF8.GetBytes($JWT), $HashAlgorithm, $RSAPadding)\n) -replace '\\+', '-' -replace '\/', '_' -replace '='<\/code><\/pre>\n
\"SuccessfulSignature\"<\/p>\n

<\/p>\n
Danach folgen nur noch Anpassungen, die zwar eine Weile dauern, aber weniger interressant darzustellen sind: Ich<\/em><\/p>\n
    \n
  1. \u00fcbertrage die HTTP Beispiele aus der Doku<\/a> in entsprechende PowerShell Syntax<\/em><\/li>\n
  2. benutze den Access Token, um mich mit Connect-MgGraph zu verbinden<\/em><\/li>\n
  3. parametrisiere alles, so dass es eine wiederaufrufbare Funktion wird<\/em><\/li>\n
  4. \u00fcbernehme auch die Authentifizierung gegen Public Clients und mit Client Secret, der Vollst\u00e4ndigkeit halber<\/em><\/li>\n
  5. stelle sicher, dass die sensiblen Variablen geleert werden<\/em><\/li>\n<\/ol>\n

    <\/p>\n
    Nutzung<\/h2>\n
    Voraussetzungen:<\/strong>  <\/p>\n