Advice on Windows auth and Active Directory

I am looking to create a dashboard which reads the current logged in user from Windows Server Active Directory (not Azure) and gets the properties for that user. So the logged in user to UD’s details from Active Directory.

I currently have v3 of Universal Dashboard running on IIS using Windows Auth.

My question is - is it possible to get the AD properties for the logged if they are logged in to UD using Windows Auth. Or do i need to use another form of auth? If so which one?

Perhaps I just need the command for the current logged in Windows Auth User? $user? and then search AD with that?

I am also using the free version - do I need to buy a version to access more auth functionality?

The last 2 sections on this page will perhaps help me achieve getting current logged in AD user?:
Example: Forms Authentication with Active Directory
Example: Policy based on Active Directory Group Membership

thank you for any help in advance

Hey there PlyrialBerg,
I believe that authentication methods are only supported in the premium version of UD, at least this was the case for 2.9.0 and below, not sure about how it’s handling it in universal / UDv3, but i’d imagine its the same.

Basically, while you can use the free version with IIS configured for windows auth, and you can put your permissions into IIS to allow or deny from the entire dashboard, you wont have access to the $user variable in order to obtain the username of the visiting user, also you wont be able to use roles which would allow for more granular permissions on pages and elements etc.

If you do decide to go for premium, I wrote a function that i’d be happy to share with you, but basically it’s a wrapper for get-aduser, which uses the visiting ($user). It pulls basic details, name, displayname, email and thumbnailphoto (which it converts to base64 so it can be used as an embeded image), it then stores it to a $session variable, it will only do this, if that session variable has not already been populated, so as to minimise the calls to AD each time a user visits the dashboard.

But yes, if you have premium you can access the full claims object for the user, which should include all AD group membership. It’s easy enough to configure policies based on that within your dashboards.

1 Like

Great thank you for the quick reply.

Yes I would be interested in your AD wrapper code if you could send it on here or I can send my email address?

Will go for Premium as need to access logged in user.

function get-uduser {
        [parameter(Position=0)][string]$user = $user

    # - workaround:
    if($ErrorActionPreference -eq 'Ignore'){ 
        $ErrorActionPreference = 'Ignore'

    if($user -like "*`\*"){
        $domain = ($user -split "\\")[0]
        $username = ($user -split "\\")[1]

    $aduser = get-aduser $username -server "$" -Properties mail,thumbnailphoto,displayname -erroraction Ignore

        return [pscustomobject]@{
        return [pscustomobject]@{

We’re a large multi domain forest here, so I’m passing the domain into the full domain name as we have users from different domains coming to use the dashboard.
But you’ll need to change the -server param on get-aduser to your domain name.
(Really I should be using a local DC with the global catalog service instead to get the global users - this is something intend to change but it’s not currently causing much of a slow down).

I’m not personally bothered about errors if theres any issues with the user lookup so on my dash, these are bypassed with ignore (dont want them going into the $error var either).
I just simply populate the user object with what I’ve got from $user only.

I have the above function in a ps1 file which i’m dot sourcing in before loading my dashboard.
in my page i have the following:

if($null -eq $session:UDuser){
    $session:UDuser = get-uduser -erroraction ignore

I also often write pages with ‘impersonate’ mechanism, so that i can see what data is loaded from another user, thats why i left the -user param there too, so you can pass through an alternative user, doesnt have to be pulled directly from $user.

Also, the $session.UDuser.avatar object, can be passed directly into the new UD avatar function.
If the avatar is a blank string, it will come back as a grey placeholder avatar instead :+1:


thank you for the advice and PS :+1: