Automatic logon / authentication using AD without getting a logon prompt - what am I missing

Okay so just watched that video (thanks) and tried the second method e.g. directly setting the Claim Type and Claim Value under Security > Roles > edit properties for the specific role.

The user who I am logging on with is in a group AD group called PUTEST and if I check View Claim Information when logged on as that user I can see the SID associated to that AD group.

But when I next logon I still have full access as that user to everything in PU and it doesn’t seem to have restricted my access to just the “Operator” role as it should.

i used the script, not those 2 boxes

I tried that way afterwards and didn’t work either for some reason, I just don’t understand why

Did you put an OU in the script that is in the admin role?

  Policies should return $true or $false to determine whether the user has the particular 
  claim that require them for that role.
    $UserName = ($User.Identity.Name)
    $UserName = $UserName.Substring($UserName.IndexOf('\') + 1, ($UserName.Length - ($UserName.IndexOf('\') + 1)))

    if ($UserName -eq "Default Admin") {
        Write-Host "Default admin logged in, setting admin to true."
        return $true

    $IsMember = $false;

    # Perform LDAP Group Member Lookup
    $Searcher = New-Object DirectoryServices.DirectorySearcher
    $Searcher.SearchRoot = 'LDAP://OU=something,DC=domain,DC=com'
    $Searcher.Filter = "(&(objectCategory=person)(memberOf=CN=something,OU=something,OU=UsersGroups,OU=Standard,OU=Departments,OU=something,DC=domain,DC=com))" 

    $Users = $Searcher.FindAll()
    $found = $users | Where-Object { $_.Properties.samaccountname -eq $UserName }
    If ($found.Properties.samaccountname -eq $UserName) {
        Write-Host "$UserName is a member of admin group!" 
        $IsMember = $true
    else {
        Write-Host "$UserName is NOT member of admin group!" 


I haven’t done anything for the admin role, just the operator role as per previous post

same idea :wink: you can use the same script for operator, just change the OU to the operator AD OU group

Just a head up, you can try to add the psu url into the trusted locations.
if you want to use gpo you can find the setting.
User Config/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/Site to Zone Assignment List
Add your url there.
https://***** 1

Going round in circles here.

I have tried it with both script and setting it directly in GUI as per post 21

I am NOT trying to do anything for admin - that logs in fine and has the correct role by default anyway.

I am just trying to set roles for a particular user so when they logon they only get operator role as explained.

Think it is going to be easier just to use form authentication, at least I can easily set which users can login and which roles they get. With AD it seems confusing to get the roles working (hence my question), and I don’t yet see how you can stop other users being able to login, as it lets any user login at the moment.

Thanks, as per reply above I have the logging on / passing of credentials working fine now - it is just getting role assignment working I am struggling with

Your claims mapping is correct for Operators. Users can have multiple roles so that’s why you end up with Administrator access even after you have setup the Operators role. By default, users receive all the roles when logging in.

If you want to prevent users from logging in, you will need to update the other roles to prevent them from receiving that role.

In your roles.ps1, you can also disable roles until you have them configured. For example, the only user that would receive the administrator role would be MyAdmin. The operator role is set to use claim mapping. The other roles are disabled.

New-PSURole -Name "Administrator" -Description "Administrators can manage settings, create and edit any entity and view all the entities with PowerShell Universal." -Policy {

$User.Identity.Name -eq 'MyAdmin'


New-PSURole -Name "Operator" -Description "Operators have access to manage and execute scripts, create other entities within PowerShell Universal but cannot manage PowerShell Universal itself." -ClaimType 'xyz' -ClaimValue 'xyz'

New-PSURole -Name "Reader" -Description "Readers have read-only access to PowerShell Universal. They cannot make changes to any entity within the system." -Policy { } -Disabled 
New-PSURole -Name "Execute" -Description "Execute scripts within PowerShell Universal." -Policy { } -Disabled
New-PSURole -Name "User" -Description "Does not have access to the admin console but can be assigned resources like APIs, scripts, dashboards and pages." -Policy { } -Disabled

Thank you so much Adam, that solution is exactly what I needed and made so much more sense to me than all the other examples I was trying from Security - PowerShell Universal - I think that example script should go on that page too for others who may find it useful, as despite reading that page and several forum topics multiple times it has taken me several days to get my head around both AD authentication (with credential passthru) and role assignment - both of which are now working thanks to your response for roles and my step by step here for the AD authentication.

Thanks. That’s good feedback and we can update the docs.


@adam - one final question related to this

I tried amending the roles.ps1 so I could assign Administrator role based on AD group membership rather than name - same as I was doing for Operator but found it doesn’t seem to work for some AD groups e.g. I thought perhaps rather than creating a specific group for the PU admin users I would utilize an existing group that all admins are in anyway e.g. admins (S-1-5-32-544) or domain admins (S-1-5-21-xxxxxxx-xxxxxxx-xxxxxxx-512) but neither of those worked and gave me access denied message? any reason for that? in the end I used another group which was relevant to all IT admins which worked fine, just curious as to why those two wouldn’t work.

Thanks again

Hi all,

I put together a KB article for this at Would appreciate any feedback. If @adam approves of this content then it will likely be added to the documentation.

The intention here is to help new users who followed the documentation but are still getting the authentication prompt.


@BuggeX - Good find about the zone mapping. Adam and I spent time on this yesterday and at the end of what we started, zone mapping was a factor. However, zone 1 is intranet not trusted*. It does make a difference as trusted does not work.