Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2007-09-11) Determining The Effective PSO For A User

Posted by Jorge on 2007-09-11

In "Windows Server 2008 – Fine-Grained Password Policies" I explain the new password and account lockout feature/concept in Windows Server 2008. When using ADUC it is interesting to know what PSO is effective from some user, and better yet, what the settings are from that effective PSO. Of course you could use the new "Attribute Editor", and look at the value of the "msDS-ResultantPSO" attribute. After knowing that you to go into to "Password Settings Container". As explained in the previous post about FGPP you need to have at least ALLOW:read permissions on a PSO to be able to retrieve its settings. By default only "Enterprise Admins" and "Domain Admins" have that permission. Also as explained in the post, you can configure a certain group to be able to read PSO settings.

Assuming the permissions are in place, you could also write your own tool/script to retrieve the effective PSO and its settings. Stop! Don’t do that. Somebody else already created a kick a$$ tool to manage/read/create/delete PSOs. Well have a look at PSOMGR from

What I did was to adjust the admin contextmenu for user objects and add a new option. That option performs retrieves the effective PSO and reads the that PSO’s settings. When choosing that action a script is executed which runs the tool and shows you the info. Have a look at the picture below.


To create the new context option for user objects, execute the following:

  • ADMOD -replacedn XXX-CONFIG-XXX:_config -b "CN=user-Display,CN=409,CN=DisplaySpecifiers,XXX-CONFIG-XXX" "adminContextMenu:+:99,Effective PSO Settings,D:\TOOLS\CONFIG\COMMON\Effective-PSO-On-User-Object.vbs"
    • Change "409" into the locale of the OS you are using. 409 is US English
    • Change "Effective PSO Settings" into whatever name the contextmenu option should have
    • Change "D:\TOOLS\CONFIG\COMMON\Effective-PSO-On-User-Object.vbs" into a central network location where you can find the script "Effective-PSO-On-User-Object.vbs" (that location must be available from whatever computer doing this)



The contents of "Effective-PSO-On-User-Object.vbs" is:

Option Explicit Dim WshShell Dim wshArguments, objRootDSE Dim strDomainControllerFLnum, strDomainFLnum Dim strUser, Return On Error Resume Next Const cPSOMGR = "D:\TOOLS\MISC\PSOMgr.exe" ' CHANGE THIS TO A CENTRAL LOCATION WHERE YOU CAN FIND PSOMGR Set WshShell = Wscript.CreateObject("Wscript.Shell") Set objFSO = CreateObject("Scripting.FileSystemObject") Set wshArguments = WScript.Arguments Set objRootDSE = GetObject("LDAP://RootDSE") strDomainControllerFLnum=objRootDSE.Get("domainControllerFunctionality") strDomainFLnum=objRootDSE.Get("domainFunctionality") If Int(strDomainControllerFLnum) < "3" Then Wscript.Echo("This feature can only be used on W2K8 DCs! The script will now stop.") Call srClearDimVars() Wscript.Quit(1) End If If Int(strDomainFLnum) < "3" Then Wscript.Echo("This feature can only be used on W2K8 DCs when the domain functional level is at least 'Windows Server 2008'! The script will now stop.") Call srClearDimVars() Wscript.Quit(1) End If If objFSO.FileExists(cPSOMGR) Then Else Wscript.Echo("The file location '" & cPSOMGR & "' does not exist! The script will now stop.") Call srClearDimVars() Wscript.Quit(1) End If strUser = Right(wshArguments(0), Len(wshArguments(0))-Instr(wshArguments(0),"CN=")+1) Return = WshShell.Run("CMD /C" & cPSOMGR & " /EFFECTIVE " & Chr(34) & strUser & Chr(34) & " " & Chr(38) & " PAUSE", 1, true) Sub srClearDimVars() On Error Resume Next Set WshShell = Nothing Set wshArguments = Nothing Set objRootDSE = Nothing Set strDomainControllerFLnum = Nothing Set strDomainFLnum = Nothing Set strUser = Nothing Set Return = Nothing End Sub


Interesting to know is that you can also use DSGET to retrieve the effective PSO on a user object

  • dsget user <User-DN> -effectivepso

Also see: Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration





* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!



############### Jorge’s Quest For Knowledge #############

######### ########


8 Responses to “(2007-09-11) Determining The Effective PSO For A User”

  1. […] Determining The Effective PSO For A User […]


  2. […] That should do it! Be aware though that Windows Server 2008 AD supports MULTIPLE password and account lockout policies! However, that is NOT done through GPOs, but rather through Password Settings Objects (PSOs). You can read more about this here and here. […]


  3. […] Determining the Effective PSO for a User […]


  4. […] If you want to do this by using a custom made script (e.g. VBScript, PowerShell), then the complexity of logic in the script depends on whether or not you are using Password Settings Objects (PSO). For more information about PSOs, click here and here. […]


  5. […] PSO. In this case you could either use the Attribute Editor or ADSIEDIT as your GUI. In the post “(2007-09-11) Determining The Effective PSO For A User” I explain how you could add a function to Active Directory Users And Computers (ADUC) to […]


  6. I have not quite finished the script, but the snippet of it that does what you are doing with a third party exe is pretty easy to do once you figure out the syntax…
    On Error Resume Next
    Dim objSysInfo, objUser
    Set objSysInfo = CreateObject(“ADSystemInfo”)
    Set objUser = GetObject(“LDAP://” & objSysInfo.UserName)
    objUser.GetInfoEx Array(“msDS-ResultantPSO”),0
    WScript.Echo “PSO: ” & objUser.get(“msDS-ResultantPSO”)

    I am trying to write a custom defined password change prompt, but they need to search through PSO settings… Similar to your page ( but only with VBScript. So far i have the PSO for the user, now i have to search that PSO for MaxPWAge and apply it to an existing script i found on the net. Happy to share it when its complete.



  7. […] settings only apply Azure AD native authN, not for on-premises authN as AD policies (GPO or PSO and PSO) govern that part. The settings that govern Azure AD Password Protection are in the section […]


  8. […] (2007-09-11) Determining The Effective PSO For A User […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: