OIDC Login Issues Post 2.8.1 Upgrade

PowerShell Universal
1

Hosting PSU in IIS with Azure AD (via OIDC) authentication. Post upgrade to 2.8.1 users (other than myself) are unable to login. They are seeing this error:

Snag_2076e3a5

Looking in PSU logs I see what looks like a corresponding error:

2022-02-15 15:20:40.748 -08:00 [INF] Returning user information
2022-02-15 15:20:43.408 -08:00 [ERR] Message contains error: 'invalid_client', error_description: 'AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.
Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Timestamp: 2022-02-15 23:20:43Z', error_uri: 'https://login.microsoftonline.com/error?code=7000218', status code '401'.
2022-02-15 15:20:43.413 -08:00 [ERR] Exception occurred while processing message.
Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolException: Message contains error: 'invalid_client', error_description: 'AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.
Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Timestamp: 2022-02-15 23:20:43Z', error_uri: 'https://login.microsoftonline.com/error?code=7000218'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.RedeemAuthorizationCodeAsync(OpenIdConnectMessage tokenEndpointRequest)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleRemoteAuthenticateAsync()
2022-02-15 15:20:43.419 -08:00 [ERR] Connection id "0HMFGR73ATM81", Request id "0HMFGR73ATM81:00000003": An unhandled exception was thrown by the application.
System.Exception: An error was encountered while handling the remote login.
 ---> Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolException: Message contains error: 'invalid_client', error_description: 'AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.
Trace ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Timestamp: 2022-02-15 23:20:43Z', error_uri: 'https://login.microsoftonline.com/error?code=7000218'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.RedeemAuthorizationCodeAsync(OpenIdConnectMessage tokenEndpointRequest)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleRemoteAuthenticateAsync()
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
2022-02-15 15:20:46.834 -08:00 [INF] Starting job using Process.
2022-02-15 15:20:53.995 -08:00 [INF] Starting job using Process.

Tried recycling AppPool and restarting server, but no difference. Also tried creating a new client secret/value and updating the appsettings.json file, but no dice.

Product: PowerShell Universal
Version: 2.8.1
2

Do you have anything configured in authentication.ps1? %ProgramData%\UniversalAutomation\Repository.universal

3

Yes, this was in there (though I don’t recall ever setting this up prior to 2.8.1, only using appsettings.json).

Set-PSUAuthenticationMethod -Type "OpenIDConnect" -CallbackPath "/auth/signin-oidc" -ClientId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx" -Authority "https://login.microsoftonline.com/xx-x-xx-x-x" -ResponseType "code" -UseTokenLifetime $true -GetClaimsFromUserInfoEndpoint $true -Scopes "openid profile groups"
4

Try removing that line from authentication.ps1 and restart the app pool, I saw the same issue. Since there is no client secret in authentication.ps1, it’s throwing the 401 error.

5

I’ll look into it. However, it looks like this may be related to a new URL/geographic/IP block policy our Security team implemented today. They’re all gone for the day, so have to wait until tomorrow to rule it out, but the behavior lines up and the upgrade just happened at the same time. I need to rule their change out before I keep going with PSU.

1 Like
6

So we did have some network traffic being blocked, however it looks like the ultimate culprit in the slow login was using Policy Defined RBAC and the time it was taking to process the roles. We only have ~12 roles, and nothing fancy, just “If($User.HasClaim(“Groups”,”"))" for each role. However, Adam pointed me to this new feature and converting our roles to this format has resulted in much quicker logins again.