PowerShell Web Access "An authorization failure occurred"

Getting “An authorization failure occurred” when attempting to log in to PowerShell Web Access when using an AD group for the Add-PswaAuthorizationRule UserGroupName parameter (e.g. Add-PswaAuthorizationRule -computer ‘dom\server1’ -UserGroupName ‘dom\ADGroup1’ -ConfigurationName ‘Test1’) BUT it works perfectly when either an explicit username or an asterisk is used as the value for the UserGroupName parameter (e.g. Add-PswaAuthorizationRule -computer ‘dom\server1’ -UserGroupName ‘dom\user1’ -ConfigurationName ‘Test1’).

“User1” is a member of “ADGroup1” and “User1” is a member of the local Administrators and Remote Management Groups.

Any ideas what the problem might be?

I’d have to go log-digging to see if I could find anything useful from a diagnostics perspective. Like, on the PWA server. See also https://technet.microsoft.com/en-us/library/dn282395(v=ws.11).aspx.

Unfortunately nothing in the “Troubleshooting Access Problems in Windows PowerShell Web Access” link seems directly applicable. And all I’m getting out of the PowerShellWebAccess logs is eventID 261 “The Windows PowerShell session cannot be started”

The confounding parts are:
a) Everything works perfectly when users are explictly defined in the auth rule, but fails for those same users when a group (of which the users are members) is used.
b) Test-PswaAuthorizationRule succeeds for the users in question with either rule (user or group)

I suppose I can just provide a (lengthy) list of explicit user names rather than using a group … but this is obviously a less than ideal solution.

I have two PowerShell Web Access servers – TEST and PRD. In my TEST environment, I have this same exact problem where it doesn’t work for a group, but it does for the group’s users, when each is added individually. I haven’t, but I always wanted to rebuild this server and see if that’s fixes the problem. Have you done that – fully rebuilt the server from the ground up?

My PRD server works perfectly, although I should mention that each of the server are joined to a different domain, as you might expect. If you’re going to have to live with it like this, you might consider writing a small, scheduled script to create an authorization rule for each user, by first collecting the users in your group. This “fix” would help ensure your authorization rules were always close to matching the group’s membership. So yeah, rebuild that PSWA server and let me know if I should too ;).

I had a similar situation on my PSWA 5.0 server using the usergroupname parameter. Make sure the security group is also in the Remote Management Users group instead of just the users. After a reboot of the server, everything is working correctly for me with the security group.