External Applications with ActiveRoles Scripts

Aug. 18th 2014

External Applications with ActiveRoles Scripts

TPAM Example

ActiveRoles Server is one of my favorite Active Directory management and automation applications.  Not only does it provide management isolation and roles based security, but combined with Workflows, scripting, and Administration Policies, ActiveRoles server capabilities cover a very wide range of scenarios.

In one of my previous articles Bulk Import with ActiveRoles, we learned that an ActiveRoles script module could access a CSV located on an ARS server.  Did you know that ARS can also interact with other external systems and applications as well?  As long as the application has a CLI or the system is accessible through the command line, more than likely, functions will be able to be integrated into a ARS Workflow or Administration Policies.

Writing scripts to access or utilize these systems is a simple matter to utilize the PowerShell Invoke-Expression cmdlet to allow PowerShell to execute a non-PowerShell executable.  For example:

$Command = “netsh interface show interface”

$Results = Invoke-Expression $Command

With the example above, the command to be executed is assigned to a variable named $Command, and then the Invoke-Expression cmdlet is run using the command variable.  The output of this command is saved into another variable named $Results.  The reason for performing the command this way is so the output may be evaluated for error codes, completion status, or even to use the output for further commands, processing, or population into attributes within Active Directory.

I have been asked on more than one occasion if Dell TPAM can be integrated with ARS.  While there is no direct or ‘official’ integration between these two products, TPAM does have a CLI interface that may be accessed to perform functions within the system.  This interface is only accessible by using SSH, and as we all know that Windows does not come with a SSH client.  The most prevalent go to SSH client is Putty, but the TPAM CLI requires the use of an authentication key and putty is a bit cumbersome when it comes to using keys and command line.  For using ARS with TPAM, I have configured and used SSH in CYGWIN on ARS.

For this example, I will assume that you, the reader, has some experience with TPAM and ARS.

First, download and install CYGWIN from the official website and install it.  During the install on the packages selection page, search for SSH.  Once the filter applies, expand Net and select openssh and libssh2_1 to install CYGWIN base and openssh.

Now, a TPAM CLI user needs to be configured and the key needs to be saved and placed on the ARS server for use with the CYGWIN openssh.

On the ARS server, if an attempt were made to use openssh to connect to TPAM using this key, openssh would complain that the key is not private.  The error message would be similar to the one below, possibly with the exception of the path of the key.

 

 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Permissions 0660 for ‘~/.ssh/id_rsa’ are too open.

It is required that your private key files are NOT accessible by others.

This private key will be ignored.

bad permissions: ignore key: ~/.ssh/id_rsa

In order to correct this error, the following commands will need to be ran from within the CYGWIN shell interface.  Just navigate to where the key is saved and replace id_rsa with the name of the key that needs to be changed.

chgrp Users id_rsa

chmod 600 id_rsa

Now that the permissions have been corrected, connect to TPAM with the CLI user id and key manually one time to save the TPAM system in the authorized hosts on the ARS system.  This will prevent any pauses or failures of the ARS script due to a needed response for the SSH client.

A command that can be used to initiate SSH and save the authorized hosts is:

ssh -i .\id_rsa cli_user@tpam.domain.com list user

This TPAM system has now been saved as an authorized host on the ARS system and the ARS script may be created for whatever purpose that is deemed necessary, for example resetting a password on an account in TPAM.

A suggested setting in the script is to define a Cygwin environment variable to prevent openssh from throwing a dos warning since PowerShell will be executing SSH outside of the Cygwin shell.  The format of the command is as follows and it should be placed before executing SSH.

$env:CYGWIN = “nodosfilewarning”

The following script is a password reset example that will need to be placed in an onPreModify script module that is executed by an Administration Policy or a workflow.

$UserID = $DirObj.get(“sAMAccountName”)

$Password = $Request.Get(“edsaPassword”)

$command1 = “UpdateAccount –AccountName $UserID –SystemName HostName –Password $Password”

$command2 = “ssh -i c:\keys\id_rsa cli_user@tpam.domain.com $command1 2>&1”

$results = Invoke-Expression $command2

An explanation of the above script is that first, we grab the sAMAccountName of the account having the password reset and store this into a variable.

Second, within ARS, when a password is changed, the password is temporarily stored in a virtual attribute and this attribute is cleared after the password has been committed.  Since we are executing this onPreModify, we can intercept the data in this field and store it for use in the rest of the script.  For this example, the password data is stored in a variable called $Password.

Next the command for connecting to TPAM.  For readability, the command has been broken into two pieces.  $command1 is the actual TPAM command, which tells TPAM to update the account we stored in $UserID on the system HostID with the password stored in $Password.  Just for clarification, this changes the password on the system/account object within TPAM.  $command2 is the actual ssh command that ARS will use to contact TPAM, which also includes a reference to $command1 to build the full command string.

The last operation is to execute the command with Invoke-Expression and store the results in a variable called $results.

Moving forward, this script could be expanded to write information in the event viewer, just replace the $variable with the item you want to appear in the event log.

$EventLog.ReportEvent($Constants.EDS_EVENTLOG_WARNING_TYPE, [string] $variable)

Another option is to place some event handling logic in the script that will read through the $results and evaluate the data for a success or failure notification.

This was just an example of what can be accomplished using the flexibility within ActiveRoles Server, a short primer if you will.  Hopefully you can use some of the concepts and ideas here to come up with your own use cases and solutions when it comes to using external systems and command line applications with ActiveRoles Server.

Author: Russ Burden, Technical Architect, LeadThem Consulting

Posted by LeadThem Consulting | in ARS | Comments Off on External Applications with ActiveRoles Scripts

ARS Bound List Boxes

Aug. 18th 2014

ARS Bound List Boxes

                Bound list boxes in the ARS web interface have always been a challenge.  There are ARS Add-Ons available to facilitate bound list boxes within the ARS Web Interface up and including ARS 6.8.  Did you know that bound list box functionality is now included with ARS 6.9?  This has always been a sought after feature within ARS, and now that it is built into the product, we will go over how to utilize bound list boxes, but first, what are bound list boxes?

Bound list boxes are essentially multiple drop down list boxes on a web interface that are dependent.  What this means is, list box one contains a list of items, list box two is bound to list box one.  Whenever a selection is made from list box one has been selected, the available choices in list box two changes based upon the selection in list box one.

Now for the example.  A global organization has sites in multiple cities, but not all departments are in all cities. We have a web interface form that we want to allow the admin to select a city, and the selection of the city changes the available departments.

There are multiple parts to this solution to make the bound list box perform what we want it to do.

We need to have the list of cities and the departments that fall into each city.  For this example, we will use the following:

New York

Human Resources

Finance

Help Desk

London

Human Resources

Help Desk

Network Support

Tokyo

Human Resources

Research & Development

Instructional Development

Beijing

Human Resources

Manufacturing

Software Development

 

All of these items have to be stored somewhere, so the cities will be stored in a property and validation rule within an administration template.  That brings us to the second item needed, an Administration Template.  This template will be linked to all OUs that require use of the bound list box.  The template will contain the aforementioned property and validation rule and a script module that contains the code that allows the list box to function.

The script module required will be utilizing the function onGetEffectivePolicy.  This function allows us to inject code at page load time and affect how the page reacts to selections and we can even inject custom error messages/responses.

Building the solution:

First, let’s create the administration policy.

  1. Connect to the ARS MMC with a user that has permissions to create Administration Policies and Script Modules
  2. Expand Configuration->Policies->Administration
  3. Right click on the container you want to create your new policy within, move down to New, and click Provisioning Policy
  4. Enter a name for the Policy and click Next, in this example I named my policy Bound List Box.
  5. Select Property Generation and Validation, click Next
  6. Click Select and locate City (l) and click ok to select this attribute. Click Next
  7. Check City must be specified and City must be <value> (generates Default Value)
  8. In the bottom pane, click on <click to add value>
  9. Enter the first city name and click OK
  10. Click <click to add value> and add each of the other city names
  11. Click Next
  12. Click Next to accept the policy name
  13. Click Add and enter an OU to attach this policy to.
  14. Click Next
  15. Click Finish

Let test this policy to ensure we will see these cities.

  1. Connect to the ARS Admin Web Interface.
  2. Navigate to the OU in which you attached the Admin Policy
  3. Click on one of the users located in that OU to view its properties
  4. Click on the Address Tab
  5. The City field should be a drop down with the city names we just entered into the Admin Policy

1

Now that we have the drop down for the City created and working, let’s work on the Script Module that will connect the data in the Department field to what is selected in the City field.

First let’s create a script module

  1. in the ARS MMC, expand Configuration->Script Modules
  2. Right click on a container where the module will be created, move to new, and click Script Module
  3. Name the Script Module, I named this BLB – CityDepartment for the example
  4. Leave the language PowerShell
  5. Click Next
  6. Select Policy Script and Click Next
  7. Check onGetEffectivePolicy and click Next
  8. Click Finish

Now that the module has been created, let’s break down the code needed for this module:

$listNYC = @(‘Human Resources’,’Finance’,’Help Desk’)$listLON = @(‘Human Resources’,’Help Desk’,’Network Support’)

$listTOK = @(‘Human Resources’,’Research & Development’,’Instructional Development’)

$listBEJ = @(‘Human Resources’,’Manufacturing’,’Software Development’)

$listDefault = @(‘Select a City’,’to change this dropdown’)

 

This first section builds each list that the Department drop down will display when the city has been selected.  Each variable is named for the city and contains an array of the departments assigned to that city.

NOTE:  The $listDefault is required, if a default set of values are not defined for the drop down, the web form field will not appear as a drop down and will not cycle when the city is selected.

function onGetEffectivePolicy($Request){

if($Request.Class -eq “user”)

{

 

The next code snipped creates the function for onGetEffectivePolicy and then verifies that the class of object that exists in the request is user.  Any other classes will not execute any code in the script other than verifying the class.

         $Request.SetEffectivePolicyInfo(‘department’, $Constants.EDS_EPI_UI_RELOAD_EPI_BY_RULE, ‘l’)

 

This next line tells the page to reload the ‘department’ field when the City field (‘l’ attribute) is changed.

       $UserCity = GetCurrentValue -Request $Request -AttributeName ‘l’

 

Now, we must get the current value of the City drop down.  This line calls the function GetCurrentValue.

function GetCurrentValue($Request, [string]$AttributeName){

trap {continue}

$value = $Request.Get($AttributeName)

if($value -eq $null)

{

$DirObj.GetInfoEx(@($AttributeName),0) | Out-Null

$value = $DirObj.Get($AttributeName)

}

$value

}

 

The function get current value is used to acquire the current value of the department attribute from the request.  If the request does not contain a value for the department attribute, it attempts to get the value from the actual directory object.

       switch($UserCity){

‘New York’          {$possibleValues = $listNYC}

‘London’                        {$possibleValues = $listLON}

‘Tokyo’              {$possibleValues = $listTOK}

‘Bejing’              {$possibleValues = $listBEJ}

default              {$possibleValues = $listDefault}

}

 

 

This section uses the value attained from the request to switch the values for the $possibleValues attribute.  This variable becomes populated with the city specific department data depending on the city found during the GetCurrentValue function execution.

         $Request.SetEffectivePolicyInfo(‘department’, $Constants.EDS_EPI_UI_POSSIBLE_VALUES, [string[]]$possibleValues)}

}

Lastly, this line places the $possibleValues variable into the department field in the Web Interface form.  Since this is a multi-valued array, the department field on the form is represented as a drop down list in the Web Interface.

Putting it all together, the entire script module appears as follows:

$listNYC = @(‘Human Resources’,’Finance’,’Help Desk’)$listLON = @(‘Human Resources’,’Help Desk’,’Network Support’)

$listTOK = @(‘Human Resources’,’Research & Development’,’Instructional Development’)

$listBEJ = @(‘Human Resources’,’Manufacturing’,’Software Development’)

$listDefault = @(‘Select a City’,’to change this dropdown’)

 

function onGetEffectivePolicy($Request)

{

if($Request.Class -eq “user”)

{

$Request.SetEffectivePolicyInfo(‘department’, $Constants.EDS_EPI_UI_RELOAD_EPI_BY_RULE, ‘l’)

$UserCity = GetCurrentValue -Request $Request -AttributeName ‘l’

switch($UserCity)

{

‘New York’   {$possibleValues = $listNYC}

‘London’     {$possibleValues = $listLON}

‘Tokyo’       {$possibleValues = $listTOK}

‘Bejing’     {$possibleValues = $listBEJ}

default       {$possibleValues = $listDefault}

}

$Request.SetEffectivePolicyInfo(‘department’, $Constants.EDS_EPI_UI_POSSIBLE_VALUES, [string[]]$possibleValues)

}

}

 

function GetCurrentValue($Request, [string]$AttributeName)

{

trap {continue}

$value = $Request.Get($AttributeName)

if($value -eq $null)

{

$DirObj.GetInfoEx(@($AttributeName),0) | Out-Null

$value = $DirObj.Get($AttributeName)

}

$value

}

 

Now, we need to add the script module to the Admin Policy so that this script takes effect when the form has been loaded.

  1. In the MMC, expand Configuration->Policies->Administrative
  2. Double click or Right click and select properties on the Admin Policy that was created earlier in this example.
  3. Click on the policies tab, and click Add
  4. Click next
  5. Select Script Execution and click Next
  6. Select the script module created in the previous steps and click Next
  7. Click Next
  8. Click Finish
  9. Click Ok to exit the Admin Policy dialog

Lastly, we either need to create a web form or modify an existing form.  For this example, we will modify the existing user create form.

  1. Login to the Admin portal as an ARS Admin user, http://<server>/ARServerAdmin
  2. Click on Directory Management
  3. Click on the domain the managed OU exists within
  4. Navigate and click on the OU the Admin Policy was applied to
  5. Select New User from the drop down menu at the top of the page
  6. Click on Customize this form and the bottom right of the page
  7. Hover over Add Entry, and click on Select
  8. Check City and Department and click save
  9. Click save
  10. Click Reload
  11. Click Exit

Now, all we have to do is test the web form.

After clicking exit from the previous steps, the Web Interface should return to the New User form and as you can see, New York is selected as the default for City and if the drop down for department is clicked, Human Resources, Finance, and Help Desk are present.

2

Selecting Tokyo from the list, Human Resources, Research & Development, and Instructional Development appear in the Department list.

3

When Beijing is selected, the departments Human Resources, Manufacturing, and Software Development are viable departments for that city.

4

Lastly, Selecting London from the list shows Human Resources, Help Desk, and Network Support as selectable options.

5

Now, we can see that the drop down works as expected, the creation of a new account is needed to see that the values are set.  I used the new user form to create a new user completely and once created, I opened up the properties of that user to verify the values that were set.

Selecting the Address Tab shows Tokyo for the City.

6

And clicking on the Organization Tab shows Research & Development assigned as the users Department

7

There are many other uses for Bound List Boxes, just use the fundamentals from this article to apply this functionality to your scenarios.

 

Author: Russ Burden, Technical Architect, LeadThem Consulting

Posted by LeadThem Consulting | in ARS | Comments Off on ARS Bound List Boxes

Active Roles Server – Bulk Import with Delegation using a Workflow

Feb. 22nd 2014

Active Roles Server – Bulk Import with Delegation using a Workflow

                I recently had a customer that required bulk importing with some sort of security or delegation.  The first thought was using a CSV connector with Quick Connect, but Quick Connect does not have any facilities for delegation, therefore anyone with permissions on the server would be able to execute bulk imports.  The next thought is to create a bulk import script within ARS and attach it to a Workflow.  ARS would allow for user delegation within the ARS management console.

The first step in the process was to develop a PowerShell bulk import script that would read an import file and utilize the QAS PowerShell cmdlets to provision the objects within the directory.

The script example below can be used to import user accounts:

function CreateUserAccounts {$Accounts = Import-Csv -Path “C:\CSV\UserImport.csv”$WorkflowInfo = Get-QARSWorkflowInstance -Workflow “CN=Import User Accounts,CN=Custom,CN=Workflow,CN=Policies,CN=Configuration” -TaskStatus Pending

$WorkflowID = $WorkflowInfo.ID

 

$i = 1

 

foreach ($Account in $Accounts) {

    $UserID = $Account.logonname

    $Domain = $Account.FQDomain

    $UPN = $UserID + “@” + $Domain

    $OU = $Account.ou

    $Password = $Account.pw

    if ($Account.accountExpires -eq “”) {

        $AccountExpires = $Null

        }

    else {  

        $accountExpires = $Account.accountExpires

    }

    $Description = $Account.description

    $FirstName = $Account.givenName

    $LastName = $Account.sn

    $displayName = $Lastname + “, ” + $FirstName

    $i ++

    try {

        New-QADUser -name $UserID -SamAccountName $UserID -ParentContainer $OU -UserPrincipalName $UPN -UserPassword $Password -Description $Description -FirstName $FirstName -LastName $LastName -displayName $displayName -ErrorAction Stop

        Set-qaduser -identity $upn -usermustchangepassword $true -accountExpires $accountExpires

        }

    catch {

        $str += “Error occurred while processing Line ” + $i + ” where logonname = ” + $UserID

        $str += [System.Environment]::NewLine

        $str += $_

        $str += [System.Environment]::NewLine

        $str += “———————————————————-“

        $str += [System.Environment]::NewLine

        }

    }

[System.IO.File]::AppendAllText(“C:\ImportLogs\UserImport_$WorkflowID.log”, $str)

}

 

 

This script utilizes a CSV file with specific headers.  The headers the script above uses are below:

LogonName, FQDomain, OU, PW,AccountExpires, description, givenName, sn

These headers are fairly self-explanatory, LogonName is the user’s logon (sAMAccountName), FQDomain is the fully qualified domain name or more specifically, the UPN suffix.  OU is the DN of the organizational unit where the user account needs to be created.  PW is the user’s initial password, description is the user’s description, givenName is the user’s last name, and sn is the user’s first name.

The basic outline of the script operation is:

  • Import the CSV
  • Acquire the Workflow ID
  • Loop through the user array
    • Assign a variable to the logonname
    • Assign a variable to the FQDomain
    • Construct the UPN from the logonname and FQDomain
    • Assign a variable to the OU
    • Assign a variable to the pw
    • Verify if the accountexpires  is populated
      • Assign null if it is empty
      • Assign a variable to accountexpires if populated
    • Assign a variable to the description
    • Assign a variable to the givenName
    • Assign a variable to the sn
    • Build the CN from givenName and sn
    • Use New-QADUser cmdlet to create an account using the variables from above
    • Use Set-QADUser cmdlet to set usermustchangepassword and accountexpiration
    • Catch errors and write them to a log file named UserImport_<WorkflowID>

The next step is to create a script module:

  • Launch the ARS MMC
  • Expand the Configuration node
  • Expand Script Modules
  • Right click on the container you wish to use, navigate to New->Script Module
  • Enter the script name and leave PowerShell as the script language
  • Click Next

  • Select Policy Script as the type and click Next

  • Do not select any handler and click Next
  • Click Finish
  • Click on the newly created script module, you should see an empty windows to the right.
  • Copy the script from above and paste it into the script module window.
    • Click yes to edit the script
    • Right Click on the script in the tree and click Save script on Server

Now that the script is saved, a workflow needs to be created.

  • Within the ARS MMC, expand the Configuration node
  • Expand the Policy node
  • Expand the Workflow node
  • Right click on the container you want to create a Workflow in
  • Click Next on the Welcome screen
  • Enter the Workflow name and click next
  • Select On user demand or on a schedule and click next
  • Click Finish on the next page

Now we will configure the Workflow.

  • Click on the new Workflow in the tree to see the Workflow screen
  • Click on Workflow Options and Click Configure
  • Leave the workflow on demand and select Do not start a new instance and click ok
  • Drag the script activity over to the workflow
  • Right click on the run script activity and click properties
  • Click on browse                and select the script that was created earlier
  • Click on the Function and select the CreateUserAccounts function
  • Click OK
  • Click on Save Changes

After the CSV is created and placed in the appropriate location all that is left is to delegate permissions to the workflow.  Configuring an import in this fashion, it allows the administrators of ARS the ability to place the files in the import location so the delegated user is only able to execute the bulk import.

Currently the below template is the only way I can make the delegation work, as far as allowing a non-Administrator the ability to Run a workflow.  I will revisit this to discover the least amount of permission needed to accomplish the delegation.

  • Open the ARS MMC
  • Expand the Configuration node
  • Expand the Access Template node
  • Right click on the container you wish to you, select New->Access Template
  • Enter the name of the Access Template and click Next
  • In the permissions entry page, we will need several entries
    • All Classes – Read All Properties
    • All Classes – Read Control
    • Workflow Container – List Object
    • Workflow Container – List Contents
    • Workflow Definition – List Object
  • After add these to the list, click Next
  • Click Finish

Now that the Access Template has been created, we need to assign or delegate control to the workflow container that holds the workflow you wish to delegate.  Note:  If the workflow is in a nested hierarchy of workflow containers, you will need to create another template that only has the List Object and List Contents permissions to be able to navigate the Workflow Tree.

  • Open the ARS MMC
  • Expand the Configuration Node
  • Expand the Policies Node
  • Expand the Workflow Node
  • Right Click on the container you wish to delegate and click Delegate Control
  • In the Security box click the Add button
  • Click Next on the Welcome page
  • Click Add and select the user or group you want to delegate control to (The user or group you want to be able to run the Import Workflow), Click Next
  • Select the Run Workflow Access Template from the list and click Next
  • Leave the Inheritance options default and click Next
  • Click Finish on the confirmation page
  • Click OK to close the Security box

With these steps completed, you should now be able to log in as the delegated user and have the ability to run the Workflow.  With these permissions in place, the delegated user will be able to open the workflow and review the configuration options of the workflow, but will be unable to modify the workflow.

 

 

Author: Russ Burden, Technical Architect, LeadThem Consulting

 

________________________________________________________________________________________________________________

 

 

Posted by LeadThem Consulting | in ARS | Comments Off on Active Roles Server – Bulk Import with Delegation using a Workflow

Reusing Functions in ARS Scripting

Nov. 20th 2013

Sometimes in scripting, I tend to reuse the same bit of code over and over again and it can cause the script being written to become overly large, or larger than it really has to be.  This is where powershell functions come into play.

 

A function is nothing more than a reusable bit of code that is referenced by a name and possibly some variables that are passed into the function.

 

An example of this is:

 

function HelloWorld {

 

write-host “Hello to the World!”

 

}

 

And in the script, it would be called by simply referencing the name

 

HelloWorld

 

The function may be included in the body of a script and called directly and all works as expected, but what can we do if the function is utilized across multiple scripts without re-inventing the wheel each time?  Well, we can place the function(s) in a PowerShell script and just include that script or reference the function script within the new script.  In PowerShell this is called dot sourcing and is formatted like so:

 

. c:\scripts\include.ps1

 

Note:  The format is a period, space, and then the path to the script to include.  When dot-sourcing a script, all variables and functions are available to the console after the script ends.

 

So, now we have the basics of that out of the way, the same idea can be used in Quest Active Roles Server (ARS).  Script modules within ARS can be created for a multitude of operations:

 

  • onPreCreate
  • onPostCreate
  • onPreDelete
  • onPostDelete
  • onPreModify
  • onPostModify
  • onPreMove
  • onPostMove
  • onPreRename
  • onPostRename
  • onPreGet
  • onPostGet
  • onPreDeprovision
  • onPostDeprovision
  • onPreUnDeprovision
  • onPostUnDeprovision

 

Let’s just say, for all of the operations above, you had a need to write the date and time to the description field if the object was a type of User.  This could be a requirement for and easy to tell when the user object was last touched by the automation of ARS.

 

The scenario above would be good use of a function and including this function with all ARS Policy scripts, then it could be called from all scripts.

 

To accomplish this, first, we need to create a Library script within ARS.  A Library script is the only type of script in ARS that may be referenced from a policy script.  In the ARS console, expand Configuration, then Script Modules.  From here the Library script can be created, or a new Script Container can be made to house and organize the custom modules.

ARS1

 

I have a custom scripts container where I place all of my created scripts (Library and Policy).  Right click where you want to create a script, and select New->Script Module.  This will open the Wizard to create a new Script Module object.

ARS2

 

Enter a name for the new library, select your language of choice (this has been written around using PowerShell), enter a Description if so desired, and click Next.

ARS3

 

This page is where we select Library script.  As you can see by the explanation, this is exactly what we are looking for.  Click Next.

ARS4

 

The last page is just a confirmation, click Finish to create the new Library.

In order to add functions to the new Library, locate it within the tree, click on it (you will see the right pane is blank), and either click the icon b1or press F4 to edit the script.

Now, we create our function.  I will just show the finished code below:

Function SetUserDescription {

If ($Request.Class –eq “User”) {

$dn = $DirObj.Get(“distinguishedName”)

$Date = Get-Date -Format “yyyyMMdd-HHmmss”

$Description = “User Modified by ARS on “ + $Date

Set-QADUser $dn –Description $Description

}

}

The code above checks the class, grabs the users DN, grabs the Date, builds the description text, and then sets the users description.

Save the Library script by clicking the icon b2 or by pressing Alt-S

We have a script Library with our function saved in it, now to use it within a policy script.

A new Policy script can be created using the previous steps for the Library script, just select Policy Script in the second step.

Follow the Library procedures for editing the script.

Now we are in editing mode, let’s include our Library.  Click the icon b3 or press Alt-L.

ARS5

 

This dialog appears, and all that is required is to expand the container that the Library exists in and check the box next to the Library and click OK.  Note:  Multiple Libraries may be included at the same time with this dialog.

After the OK button is clicked, code will appear at the top of your edit window that looks like the following:

function onInit($Context)

{

$Context.UseLibraryScript(“Script Modules/Custom Scripts/TestLibrary”)

}

With this included now, you may reference any function that exists within that Library.  In our example, you would just reference SetUserDescription in order to call that function.

function OnPreMove($Request)

{

***Do some stuff ***

SetUserDescription

}

The above will execute the SetUserDescription function from the included Library script before a User is moved but after ‘stuff’ script commands execute.

Once your Library is built up and assigned to Policy Scripts, you are ready to assign these Policy scripts to Provisioning Policies, Deprovisioning Policies, or Workflows within ARS.

 

Author: Russ Burden, Technical Architect, LeadThem Consulting

 

________________________________________________________________________________________________________________

 

 

Posted by LeadThem Consulting | in ARS | Comments Off on Reusing Functions in ARS Scripting