2

We do the 30 days kerberos decryption key rollover process automated by using an "encrypted" password stored within a text file to create the neccessary PSCredential object for the Powershell command new-azureADSSOAuthenticationContext.

This works - but I want to improve the general security and want therefore to eliminate the PSCredential object for the Global Administrator of our Tenant on Azure.

I have seen that the new-azureADSSOAuthenticationContext command also can be feed with an access token (via parameter -token). An access token I can retrieve by using a certificate stored within the much more secure machine cert store by using "Get-MsalToken"

So far I have created an Azure app, have assigned its SecurityPrincipal the Global Administrator role (under Enterprise Apps) and have created a self-signed certificate (stored within the machine personal store) and uploaded this cert to the Azure App.

I am getting the token with: $Token = Get-MsalToken -ClientId $ClientId -TenantId $TenantId -ClientCertificate $Certificate -RedirectUri "http://bla.com"

This works and I also can use the token within the new-azureADSSOAuthenticationContext.

But when I then call Update-AzureADSSOForest -OnPremCredentials $OnpremCred, I get the following error:

  • When run under the "new" Powershell 7: Line | 133 | Update-AzureADSSOForest -OnPremCredentials $OnpremCred | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not load type 'System.ServiceModel.Web.WebChannelFactory`1' from assembly 'System.ServiceModel.Web, Version=4.0.0.0, Culture=neutral, | PublicKeyToken=31bf3856ad364e35'.

  • When run under the "old" Powershell 5.1: Update-AzureADSSOForest : Uploading computer account information failed. Error message: DesktopSsoNumOfDomains request was made with invalid authenticatedToken. Value:'' At C:\Scripts\DEV-MIHA\KerberosKeyRollover\M365_Kerberos_Key_Rollover.ps1:133 char:1

  • Update-AzureADSSOForest -OnPremCredentials $OnpremCred
  •  + CategoryInfo : NotSpecified: (:) [Update-AzureADSSOForest], Exception + FullyQualifiedErrorId : System.Exception,Microsoft.KerberosAuth.Powershell.PowershellCommands.UpdateAzureADSSOForestCommand

Hint: I have read quite some hours regarding the general issue - and so far have not found any solution for this problem. Except that some claim that this is currently not possible.

But maybe somebody out there has managed already what I want to achieve

Suggestions are welcome. :-)

Improve this question
2
  • Did you ever get anywhere with this? Also interested! Commented Oct 2, 2023 at 16:52
  • Until now, unfortunately not. Commented Oct 4, 2023 at 14:25

1 Answer 1

Reset to default
2

This isn't the answer - but maybe making progress towards it. Here's what I've found so far:

Firstly, New-AzureADSSOAuthenticationContext doesn't check the token you provide via the -Token parameter until you actually run a command that relies on it (like Get-AzureADSSOStatus or Update-AzureADSSOForest) - e.g. the following will complete without an error:

New-AzureADSSOAuthenticationContext -Token "12345" -Tenantid <YourTenantId>

Secondly, based on some investigation into how New-AzureADSSOAuthenticationContext works using Fiddler, I have managed to get it to work with a Get-MsalToken generated token using interactive login as follows:

$TenantId = '<Your Tenant ID>' Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1' $Token = Get-MsalToken -ClientId '55747057-9b5d-4bd4-b387-abf52a8bd489' -TenantId $TenantId -Interactive -Scopes 'https://proxy.cloudwebappproxy.net/registerapp/.default' New-AzureADSSOAuthenticationContext -Token $Token.AccessToken -TenantId $TenantId Get-AzureADSSOStatus | ConvertFrom-Json

The above will allow Get-AzureADSSOStatus to return correctly, which has to be a good start. The next part of the problem is probably to get the Azure AD Connect proxy application to accept an application's client credentials grant token instead of a user's authorization code grant token.

Improve this answer
6
  • Good observation. Commented Nov 3, 2023 at 18:40
  • I've looked at this again today but can't see how to get a client credentials grant token. The ClientID above is found here learn.microsoft.com/en-us/entra/identity/app-proxy/… but no details on how it can work with client credentials. Maybe Microsoft may need to allow whatever API is necessary to work with applications - either with an Access Control List or Application permissions learn.microsoft.com/en-us/entra/identity-platform/… but I'm not sure we can do that ourselves. Commented Nov 6, 2023 at 13:41
  • 1
    Yep - I don't think this'll work until Microsoft set things up for client credentials grant - either an access control list, or application permissions like this github.com/MicrosoftDocs/azure-docs/issues/50935 :( Commented Nov 6, 2023 at 14:07
  • 2
    They (M$) are very inconsistent with their security. On one side, they require everything locked down with certificates and 2FA - on the other hand they require us to use the Global Admin credentials in near cleartext within our scripts and we have to manually change the password for that every other month or so. A really poor way of doing it. It's a shame... Commented Nov 10, 2023 at 7:38
  • 1
    It's not just that - if you try to pass an MFA account to New-AzureADSSOAuthenticationContext -CloudCredentials, the request fails. Which is pretty inconsistent - given that Microsoft want all Administrator accounts to be enabled for MFA. Commented Nov 17, 2023 at 12:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.