{"id":524,"date":"2024-01-28T16:43:45","date_gmt":"2024-01-28T15:43:45","guid":{"rendered":"https:\/\/sparrow365.de\/?p=524"},"modified":"2024-11-04T20:21:31","modified_gmt":"2024-11-04T19:21:31","slug":"connect-mggraph-with-username-and-password","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/en\/2024\/01\/28\/connect-mggraph-with-username-and-password\/","title":{"rendered":"Connect-MgGraph with Username and Password"},"content":{"rendered":"

In my work on the practical implementation<\/a> of Password Rotation without Privileged Authentication Administrator<\/a>, I stumbled upon a somewhat extensive<\/strong> challenge.<\/p>\n

When trying to use PowerShell to sign in to the Graph API using username + password<\/strong>, I couldn’t find a combination in the PowerShell SDK<\/a>.
\nThe only method would be ClientID + Secret – but that would mean using App Permissions again, which I specifically want to avoid in this case.<\/p>\n

We also know that it is possible<\/em>, because in the Azure command line<\/strong> such a connection is available<\/a> – but to demand the Az module or the Azure CLI just for this<\/strong> contradicts my perfectionism. Especially since it’s also not trivial to authenticate against a specific App Registration this way.<\/p>\n

\n

Accordingly, the lazy solution already exists<\/a> – the token can then be further used with Connect-MgGraph -AccessToken $(ConvertTo-SecureString "<AccessToken>")<\/code><\/code><\/em><\/p>\n<\/blockquote>\n

Since such a specific sub-problem soon took up half the article, I prefer to summarize separately how I arrived at my solution<\/strong><\/a>.<\/p>\n


<\/p>\n

Initial Investigation<\/h2>\n

Starting with the knowledge that there is a working implementation, I decided to get more details<\/a>. This led me to the Resource Owner Password Credentials (ROPC) grant<\/strong>. In the associated documentation<\/a>, we find very detailed information on how to use it<\/strong>.<\/p>\n

Ideally, not at all:<\/strong><\/u><\/p>\n

\"ROPC<\/p>\n

Modern authentication protocols are designed, so that user login is separated from the application<\/strong> as far as possible – in all other OIDC flows, we simply get confirmation that the user is authenticated. Here, we temporarily hold his credentials<\/strong> – where we mostly wouldn’t need to.<\/p>\n

However, the key phrase is: "in most scenarios"<\/em><\/u>. If I want to log in without interaction<\/strong> as a normal user<\/em><\/u>, to my knowledge, there is no alternative<\/strong> – but I am open to correction. The upside in my scenario is worth it, because paradoxically, in my very specific use case, user permissions are miles more granular<\/strong> than application rights – and I already have the user passwords in the PAM vault anyways.<\/p>\n

However, we will also very likely not find any SDKs<\/strong> that work the way I would like: I agree with Microsoft, I do not want this app to be accessed by users. Otherwise, they could authenticate without MFA<\/strong> and make requests against the API. The best way would be to register a confidential client app<\/strong><\/a>, where requests always have to include a certificate to prove that the system is allowed<\/strong> to use the app registration. But:<\/p>\n

\"ROPC<\/p>\n

Understandable, assuming that at login<\/strong> passwords would be passed on to the server. Not applicable in our case, however, because we already have the passwords<\/strong>.<\/p>\n

If the SDKs don’t support it, we will have to replicate the Web Requests. <\/p>\n


<\/p>\n

Building the Code<\/h2>\n

I may often put in more effort than necessary (Like right now? \ud83e\udd14) – but I don’t want to be ridiculous. There are more than enough implementations<\/strong> of Graph API Auth via Invoke-WebRequest<\/code><\/code> – so I will take the best possible version and adapt<\/strong> it for ROPC.<\/p>\n

The best version<\/strong> to me seemed to be the one by Adam The Automator<\/a> – especially since it also already implements certificate-based authentication<\/strong>, which I probably would have struggled with for a while.<\/p>\n

But in my first tests of the code, I stumble over a problem:<\/p>\n

\"Error<\/p>\n

After a bit of troubleshooting, I identify the following 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
Probably because my private keys are non-exportable, $PrivateKey<\/code><\/code> remained empty.
\nHowever, private keys that cannot be exported are still usable on the system where they are installed – otherwise, Connect-MgGraph -CertificateThumbprint -ClientId<\/code><\/code> would also fail.<\/p>\n
If we construct a .Net object directly from the certificate that can provide us with a signature, we can make progress:<\/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
After that, adjustments take a while but are less interesting to present: I<\/em><\/p>\n
    \n
  1. transfer the HTTP examples from the documentation<\/a> into corresponding PowerShell syntax<\/em><\/li>\n
  2. use the Access Token to connect with Connect-MgGraph<\/em><\/li>\n
  3. parameterize everything so that it becomes a reusable function<\/em><\/li>\n
  4. incorporate authentication against Public Clients and with Client Secret, for the sake of completion<\/em><\/li>\n
  5. ensure that the sensitive variables are cleared<\/em><\/li>\n<\/ol>\n

    <\/p>\n
    Usage<\/h2>\n
    Requirements:<\/strong>  <\/p>\n