Populating a field on the Web UI using a script.

One way this could be accomplished is the use of the onPostGet event handler. Review this in the Active Roles SDK as well as the following support article. As this KB article indicates, if not coded properly, this event handler should be used with the knowledge that it can be very taxing on the Administration Service and could cause slowness/unresponsiveness as objects are viewed.

How To Populate a Virtual Attribute that is NOT Stored in the Database (4256736) (oneidentity.com)

Maybe I can give you more context on what i am trying to do.  I am working on a script to try and get the Windows LAPS password from AD.  Since the attribute is encrypted, I have to run powershell to get the value I am looking for.  This is my first script for ARS so no idea if I am even close to being correct.

$machineName = $this

function LAPSPassword($Request)
{
$customValue = Get-LapsADPassword -Identity "$machineName" -AsPlainText | Select-Object Password
$machineName.VirtualAttributes["edsvaLAPS"] = $customValue
}

Thank you.  I was able to get past that error but get a new one after I click on the lightning bolt:  Cannot generate unique edsvaLAPS (edsvaLAPS) using configured rules. Enter this value manually.  How do I troubleshoot next steps?

function onGetEffectivePolicy($Request){

if($Request.Class -eq "computer"){

$machineName = $Request.Get("cn")

$customValue = Get-LapsADPassword -Identity "$machineName" -AsPlainText | Select-Object Password

$strAttrname = "edsvaLAPS"

$Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_GENERATED_VALUE, $customValue)
$Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_AUTO_GENERATED, $true)
$Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_SERVER_SIDE_GENERATED, $customValue)

}#end request class

}#end on get effective policy

I take the line that is populating $customValue works outside of Active Roles and returns a value? You will need to account for Computer objects that may not have a LAPS password in AD, or an error occurs with the running of the Get-LapsADPassword cmdlet and $customValue is getting set to $null. Wrap the Get-LapsADPassword in a Try/Catch and after that add something like below, so that $customValue will always get set to a non-null value.

      if ($customValue -eq $null)
      {
         # An error occurred
         $customValue = "An error occurred, verify that this computer is registered with LAPS"
      }

Also, to continue looking into this a little further, within the properties of the Script Module itself, you can enable logging under the Debugging tab. Enable the bottom, most verbose selection in the list, reproduce the issue and then come back to the Debugging tab. Search the resulting log file for "SET $customValue". A few lines above the SET line, you will see Active Roles running the PowerShell cmdlet and what it is setting this variable to. This could further help determine if data is getting returned from the running of Get-LapsADPassword.

Thank you for the information.  Did some more testing.

1) Doesn't look like the lightning bolt icon is triggering the script.  Click and the debug log is empty.

2) I created a workflow to run the scrip just for testing and the output is below

WARNING: The names of some imported commands from the module 'ActiveRolesManagementShell' include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.
<-------------------------------------------------------------->
<----  New Debug Session  6/9/2023 10:19:38 AM ---->
<-------------------------------------------------------------->
<------------------- $Request  XML ------------------------>
 <RunScheduledWorkflowRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" dn="CN=Workflow,CN=Policies,CN=Configuration" isStartedBySchedule="false" xmlns="urn:schemas-quest-com:ActiveRolesServer" /> 
 <------------------- $Request  XML ------------------------>
Call:  Set-PSDebug -trace 2
DEBUG:    1+  >>>> s8a4c23af-b8e7-42b6-adeb-fc2cd3ef4a40 'onGetEffectivePolicy' $Request
DEBUG:     ! CALL function '<ScriptBlock>'
DEBUG:   29+   >>>> &$args[0] $args[1]

DEBUG:     ! CALL function '<ScriptBlock>'
DEBUG:    1+ function onGetEffectivePolicy($Request) >>>> {

DEBUG:     ! CALL function 'onGetEffectivePolicy'
DEBUG:    3+     if( >>>> $Request.Class -eq "computer"){

DEBUG:   23+  >>>> } #end on get effective policy

<------------------- $Request  XML ------------------------>
 <RunScheduledWorkflowRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" dn="CN=Workflow,CN=Policies,CN=Configuration" isStartedBySchedule="false" xmlns="urn:schemas-quest-com:ActiveRolesServer" /> 
 <------------------- $Request  XML ------------------------>

Updated script:

function onGetEffectivePolicy($Request){

    if($Request.Class -eq "computer"){
    
        $machineName = $Request.Get("cn")

        try {
            $customValue = Get-LapsADPassword -Identity "$machineName" -AsPlainText | Select-Object Password
        }
        catch {
            # An error occurred
            $customValue = "An error occurred, verify that this computer is registered with LAPS"
        }

        $strAttrname = "edsvaLAPS"
    
        $Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_GENERATED_VALUE, $customValue)
        $Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_AUTO_GENERATED, $true)
        $Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_SERVER_SIDE_GENERATED, $customValue)
    
    } #end request class
    
} #end on get effective policy

The debugging information should start to be logged to the Script Module simply by opening the properties of the Computer object. As I have been guilty of previously, I would verify within the properties of the Provisioning Policy that it is referencing the correct script and that the Policy is linked to the OU of the Computer you are testing with.

Thanks Richard.  Wanted to confirm a few things:

1) The virtual attribute edsvaLAPS is linked to the Policy Objects (Windows LAPS Password) under the Administration tab

2) The provisioning policy (Windows LAPS Password) is linked to the script with the code below.  It is also linked to the OU that has the server and Virtual Attributes within the Policy Scope.  Parameters tab is blank.

3) On the Web UI, I have added the Virtual Attribute (edsvaLAPS) to the Operating system tab of the Computers Properties.  It is set as an Entry Type Auto, Read Only and Syntax DirectoryString.

I have rechecked everything and it seems to be correct from what I can tell.  When I check the field, it is still not showing any value.  I have also changed it to not require the lightning bolt.  I am sure I am missing something silly.

function onPostGet($Request){

    if($Request.Class -ne "computer") {return}
        if ($Request.IsAttributeRequested("edsvaLAPS") -eq $false) {return}
        
        $machineName = $Request.Get("cn")

        try {
            $customValue = Get-LapsADPassword -Identity "$machineName" -AsPlainText | Select-Object Password
        }
        catch {
            # An error occurred
            $customValue = "An error occurred, verify that this computer is registered with LAPS"
        }

        $strAttrname = "edsvaLAPS"
    
        $Request.Put($strAttrname, $customValue)
        
    } #end request class

Do I need to set up an Access Templates/Rules for this?

I think you still need these two lines:

$Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_GENERATED_VALUE, $customValue)
$Request.SetEffectivePolicyInfo($strAttrName, $Constants.EDS_EPI_UI_AUTO_GENERATED, $true)

Did you abandon your onGetEffectivePolicy handler?

My previous comment assumed you were still using that.

I am trying different things seeing if any of it works. :)  The updated script should show the value in the web ui field without clicking on an icon.  Just failing to get any value at all to be displayed.

I would start by placing a static line of text in the Request.Put line, just to see if things are linked and referenced properly and to see something displayed in the web interface.

$Request.Put($strAttrname, "From onPostGet Handler")

If this is successful, then there is something up with the PowerShell cmdlet populating $customValue. It is not erroring out, but it does not seem to be returning a value. You can also use native Active Roles cmdlets to get to the same information. Example:

# Retrieve LAPS password from AD
$objComp = Get-QADComputer -Proxy -Identity $machineName -IncludedProperties "ms-Mcs-AdmPwd"
[string]$customValue = $objComp." ms-Mcs-AdmPwd"

I would start by placing a static line of text in the Request.Put line, just to see if things are linked and referenced properly and to see something displayed in the web interface.

$Request.Put($strAttrname, "From onPostGet Handler")

If this is successful, then there is something up with the PowerShell cmdlet populating $customValue. It is not erroring out, but it does not seem to be returning a value. You can also use native Active Roles cmdlets to get to the same information. Example:

# Retrieve LAPS password from AD
$objComp = Get-QADComputer -Proxy -Identity $machineName -IncludedProperties "ms-Mcs-AdmPwd"
[string]$customValue = $objComp." ms-Mcs-AdmPwd"

Thanks for the suggestion.  The updated $Request.Put did display on the web ui as you suggested above so that is working.  The issue is more likely the Powershell.  I would love to use native cmdlets but this is the new Windows LAPS that was released in the April patches.  This update uses new attributes in AD but the password is encrypted at rest.  This means I can't just display the attribute value. :)  I need to run the PowerShell command within the script to have it get the password and display it as plain text.  I have validated the ARS servers can do this command find via the PS prompt.

Use Windows LAPS PowerShell cmdlets | Microsoft Learn

I finally figured it out.  The powershell command was not just outputting the value of the password which was causing it to be confused.

Updated: $customValue = Get-LapsADPassword -Identity "$machineName" -AsPlainText | ForEach-Object { $_.Password }

That's great to hear. And thanks for the encryption info on the LAPS pw now.