CA Identity Suite/Identity Manager PX unable to call external command

[William Cheang]

Hi Team,
Am using CA Identity Suite 14.3 vapp with Identity Portal & Identity Manager.
I have configured with external code in PX to trigger a etautil command

But after submit the task, IM throw an error "Permission denied" .

Q. Does in CA IM 14.3 vapp, we still able to call external command ? or call a java program ?

Q. My purpose of call etautil command is to add a group to an account. After the account is successfully created by the admin task.
Any alternative way ?

regards,
William

[Kevin Kruse]

Hi,

Two things.

1. Verify that the service account running the IDM application actually has permissions to run the script - and in particular execute rights to the path of the etautil application.
2. You could achive the same in a couple of different ways. Here is how I know it could be done:

1:
Do it as a TEWS action by exposing the the Admin task: Modify Group Members and then do a SOAP action in your PX policy.

2:
If you have not encrypted the Global User store, then do it as an LDAP action.

[Iyes Dendeni]

If you can be more specific about the account type you're creating and the group you're trying to assign, it will be helpful to better frame the discussion.

If this is an endpoint account, how about using the PX action 'Modify Account Attribute by Account Identifier' and manipulate the attribute rhat holds the group association (i.e. memberOf attribute)?

[William Cheang]

Dear Kevin & Lyes,

Firstly, I would like to find out can we still execute external command via PX in CA Suite Virtual Appliance ?
As i have found out there is permission issue, kindly refer screen shot.






Secondly, this is my usecase.
1. IDM will process new joiner, which a CSV(new joiner info) will be extracted from HR system.
2. IDM will create the new user in IDM & AD domain. (which we will use AD Account template to create AD account)
3. IDM will assign newly create AD account with AD group. But this group have condition as following
if user from Company1 then assign AD Group1.
If user from Company2 then assign AD Group2 & etc(there are about 10-20 company).

How can we handle the AD group assignment based on Company value (After create AD account) ?

[Kevin Kruse]

Based on your usecase you either setup identity policies and automatically assigns additional provisioning roles (and with that additional AD group memberships) or if you would like to do that in a PX policy you will have to do a SOAP base query as action, where you call the corresponding TEWS method for either assigning endpoint entitlements directly to the user or assigning provisioning roles to the user.

Få Outlook til Android

[William Cheang]

Thanks for the info. 
Q. How can i find out what capabilities is available in TEWS ? 

[Kevin Kruse]

I recommend that if you can solve this with identity policies, you should that. If TEWS is still the way you choose you needs to do some pre-tasks:

I recommend that you do not expose the default admin tasks on the webservice so go ahead and create a copy of the ones you are gonna expose.

Next up: create an admin role specifically for the use case and give it only the newly created copy tasks.

Modify the created tasks: profile tab: enable webservice.

In your browser: <url of your IDM>/iam/im/TEWS6/<your environment>?WSDL

If you have it right, then you will see an XML document. Then right-click and view source, copy everything to a file on your computer (eg tews.xml).

Now use SOAPUI (free tool)  or any other WSDL consuming test tool with the xml file and look at your options.

Test, tweak and test again until you have somerthing working and then copy that working to a PX policy SOAP base query.

But never the less: SOUPUI is your friend in regards of exploring the TEWS interface.

Shortly put though:
Any Admin task in IDM can be exposed on the TEWS webservice meaning that executing tasks (Create User, Create Provisioning Role, Reset User Password, Define member/admin/owner policies on virtually any existing role etc.) can be done with external code - if you choose to expose it. So that is the capeabilities of TEWS.

Identity Portal actually interacts with TEWS btw. This is how it is capeable of being the main frontend for end users.

Få Outlook til Android

[Kevin Kruse]

Be warned though that using TEWS also has some vulnerabilities:

For example: If you enable creation of Provisioning Roles or Admin Roles through TEWS (think for example if you have automated server spawn/creation which in the creation process needs to create AD groups for administrative access to the servers, and therefor also needs to create corresponding Provisioning Roles, Account templates and bind it all together, then TEWS is a fantastic way of doing this), you can now create these from an exernal application. However all roles NEEDS to have a defined Owner policy which you defines in the SOAP request along with all the basic information of the role. However as long as the syntax and format is correct IDM accepts everything - even though the user you are using for the TEWS request has only scoped access to see very specific users or admin roles - meaning that if you can execute the task you can define a Provisioning role which has the OWner policy set to any user you like or <All/>. An owner can modify the role so the owner can modify which account template it provides, for example Domain Admin.

[Iyes Dendeni]

Identity Manager is flexible in that it gives you different options to do things. For this use case, you could use any of the following options:

1. Since the number of companies is small and manageable, you could use account templates and provisioning roles:
a. First you need a user attribute to hold the company name.
b. For each company, create and account template and a corresponding provisioning role.
c. Use either PX or Identity Policy sets to assign the appropriate role to the use based on the company attribute value.

2. A second option is to create a single PX policy that would modify the memberOf attribute (ADD operation) based on the account value and company attribute value:
a. PX data elements: get Accounts for user (endpoint type AD) - get companyName
b. PX entry rule: AD Accounts is not empty
c. PX action rules: Modify Account Attribute Value by Account Identifier. The Account Identifier is the AD account name gathered in the data element, and the attribute is the memberOf attribute, the Operation is ADD, and the value is the groupName based on the value of the company attribute (you need between 10 and 20 conditional actions based on the number of companies you have).

[William Cheang]

Hi Lyes, for Option 2. i actually tried it but i hit a problem.

Assuming i have this feed CSV file.
action,userid,firstname,lastname
create, s1001, Test, User1

my bulk loader task able to create this in CA IM and AD account using the "Create User Task"
Then my PX is configured to run after Task Completed on "Create User Task".
In my PX, i have data element to retrieve AD account info, but what i found out is that we can not retrieve the AD account info(it always return blank).

Then i tried another approach, where in my feed now i have 2 lines
create,s1001,Test, User1
modify,s1001

Then my PX is modified to run after completed of "Modify user Task", with this approach I can retrieve AD account info.

[Kevin Kruse]

As I can see below you where able to use one of the approaches suggest by Lyes. Waaay better than using TEWS.

As the modify is executed only when the Create event is truly completed - inclusive the verification from provisioning that the assigned provisioning roles/account templates has ben successfully provisioned (that the execution agianst the downstream system was also a success) - the AD account information is available because they are now present and verified in the Provisioning Directory.

You COULD skip the modify line by changing your PX policy to trigger after provisioning of provisioning role instead.

[daniel wilkinson]

Suggestion: You can execute etautil like this - "su - imps -c "etautil". So you might be able call a shell script to execute etautil. When you launch an external command from PX hosted on vApp, always use fully qualified paths to all files or executables. It seems to have the relative path when using "su - imps -c "etautil", but I have run into many instances where the relative path is not retained when the external script is called from a PX, causing the external command to fail. This is also true if your external command launches another script. Use fully qualified paths to avoid failures that leave you scratching your head.

[William Cheang]

Hi Daniel, i have tried ur method, it did not work. 
I have build a shell script that called etautil, it works if i ran it using "config" id in SSH terminal session.

But when i trigger this command via PX->External command, i got this error.

using actual path also failed