Remove Attribute from Accounts if Deprovisioned

Hi! I am trying to figure out the best way to handle this situation. When we create accounts, we set 2 virtual attributes (edsvaLMSManager and edsvaLMSApprover). Both of these virtual attributes use the DN of the users that are set for their LMSManager and LMSApprover. When the LMSManager and LMSApprover accounts are deprovisioned, we have found that they are not being removed from the accounts and are just displaying as deprovisioned on the accounts they are set for. What is the best way to clear these virtual attribute fields for any account that they are set on when these users are deprovisioned?

In my mind, I feel like when an account is deprovisioned, we would need to search through all SSO accounts, get a list of the users that have the edsvaLMSManager and edsvaLMSApprover set as the deprovisioned user, then clear those attributes. However, I am not sure how to achieve this.

Any suggestions or advice is appreciated.

Parents Reply Children
  • This value is set by the user. I am wondering if I could update the VA from being a DN to the samAccountName/Name, then manually update the others that are set with DN to samAccountName/name via script. If I could change the VA to samAccountName/Name, would it make the workflow search easier to accomplish?

  • IF you can make all that fall into place, then a search based on the samaccountname would be your best bet as unfortunately, names can be ambiguous.

  • If the VA is currently a DN, I don't believe you can change the syntax.  So you would need to save off all the existing contents and then perform a delete / create.

    Or, maybe it would be easier just to create new VAs - e.g. LMSManagerSam and LMSApproverSam and then use a script to populate those based on the DNs in the existing VAs.  You could then base your update process on these new VAs.

  • Any suggestions on how best to script that or any examples?

  • Try this - I wrote it quickly so it may require some de-bugging.  Slight smile

    # NOTE: Run script on host with Quest cmdlets and Quest ADSI provider installed

    # Enumerate users - need to use proxy switch as we need to pull virtual attribute contents
    # Modify domain name to suit
    # -sl 0 makes sure you get them all


    $UserInfo = Get-QADUser -sl 0 -Proxy -SearchRoot "DC=MyDomain,DC=Com" -IncludedProperties LMSManager,LMSApprover | select DN,LMSManager,LMSApprover

    Foreach ($UserInfoItem in $UserInfo)
    {

    $CurrManagerDN = [string]$UserInfoItem.LMSManager
    $CurrApproverDN = [string]$UserInfoItem.LMSApprover
    $CurrUserDN = [string]$UserInfoItem.DN

    # NOTE: Script uses ADSI style coding technique below for better performance on a large dataset

    # Bind to the Manager object and grab the samaccountname

    Try
    {
    $ManagerObj = [ADSI]"LDAP://$CurrManagerDN"
    $ManagerObj.RefreshCache(@("samaccountname"))
    $ManagerSAM = [string]$ManagerObj.samaccountname
    $ManagerObj.Close()
    }
    Catch
    {
    Write-Host "Couldn't find the Manager object for $CurrUserDN"
    }

    # Bind to the Approver object and grab the samaccountname


    Try
    {
    $ApproverObj = [ADSI]"LDAP://$CurrApproverDN"
    $ApproverObj.RefreshCache(@("samaccountname"))
    $ApproverSAM = [string]$ApproverObj.samaccountname
    $ApproverObj.Close()
    }
    Catch
    {
    Write-Host "Couldn't find the Approver object for $CurrUserDN"
    }

    # Bind to the current user object and update the new virtual attributes with the samaccountnames
    # We use EDMS for the bind as we need to perform it "through" the AR server so we can access the virtual attributes

    Try
    {
    $CurrUserObj = [ADSI]"EDMS://$CurrUserDN"
    $CurrUserObj.LMSManagerSam = $ManagerSAM
    $CurrUserObj.LMSApproverSam = $ApproverSAM
    $CurrUserObj.CommitChanges()
    }
    Catch
    {
    Write-Host "Problem updating VAs on for $CurrUserDN"
    }


    } # End of processing user items