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.






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 Security

Posted by bc-admin | in ARS | Comments Off on External Applications with ActiveRoles Scripts