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.

  • 1. Create a Change Workflow that responds to a Deprovision event (you may ultimately want to set some "filters" on this later but this is a start)

    2. Within the change workflow, add a Search Activity that searches AD for objects where your LMSManager and LMSApprover properties contain the "target object".  You might need to do two searches.

    3.  In the workspace of each Search (the gray area under the search activity in the workflow), add an Update Activity that clears the respective VA

    Here's the documentation topic on workflows:

  • Hi again! I have been working on this and have run into an issue. I have the search set up to look for any user that has the edsvalmsmanager set to "CN=bethany round9,OU=Users,OU=00010,OU=Franchise,DC=servprotest,DC=servpro,DC=int" I have hardcoded this this DN for edsvalmsmanager as I  know there is a user with this set. However, my search (I am getting a notificaiton) is running but not finding the user, so nothing is getting cleared. I am at a loss of what else to try. Is there any debugging available? I have included screenshot of my workflow below for reference. Any help is appreciated.

  • Searching for distinguishednames is a dubious proposition.  Could you store some other name property of the manager like their samaccountname or even their "Name"?

  • The edsvalmsmanager attribute is set for the DN in our production environment. Would it be possible to change it to store samaccountname or name now? I know we already have this field populated for many users with the DN, but we could potentially change it if it doesn't break anything. Is that possible?

  • I can't answer that question as I don't know what process sets the value in the first place (something in your environment as this is not an out-of-the-box virtual property) nor what other processes may depend on the contents of the property.

  • 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

    $ManagerObj = [ADSI]"LDAP://$CurrManagerDN"
    $ManagerSAM = [string]$ManagerObj.samaccountname
    Write-Host "Couldn't find the Manager object for $CurrUserDN"

    # Bind to the Approver object and grab the samaccountname

    $ApproverObj = [ADSI]"LDAP://$CurrApproverDN"
    $ApproverSAM = [string]$ApproverObj.samaccountname
    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

    $CurrUserObj = [ADSI]"EDMS://$CurrUserDN"
    $CurrUserObj.LMSManagerSam = $ManagerSAM
    $CurrUserObj.LMSApproverSam = $ApproverSAM
    Write-Host "Problem updating VAs on for $CurrUserDN"

    } # End of processing user items