AnsweredAssumed Answered

Move Account Provisioining Command Node in Fulfillment Workflow

Question asked by Viktor Daskalov on Feb 28, 2020
Latest reply on Mar 26, 2020 by Ahmed Nofal
Branched from an earlier discussion

Like • Show 0 Likes0
Comment • 9

Hi,

I've seen the same topic that, I am interested in is already raised so, I would like to bring out the following scenario which is still not working for me. I am trying to move an account from 1 OU to another in AD (further I will need the same for OpenLDAP as well) whenever its being requested account deletion. This is the WF that I am using currently. The WF I use originally was the AFX default fulfillment, but I have reworked it as it has to perform some specific scenario.

For moving the account in another OU, I redirected the start to a derision node Is Account Deletion (true/false) in order not to pass trough the AFX Fullfilment Handler because the account will be deleted (I need it only moved in other OU). Right?
Then I have the following query:

select 
'CN=' || '${jobUserData_Z3ID}' || 
',OU=Tenant A,OU=Users,OU=Test,OU=Test1,DC=access,DC=example,DC=com' as OLD_DN,
'OU=Tenant B,OU=Users,OU=Test,OU=Test1,DC=access,DC=example,DC=com' as NEW_DN
from dual

I have already predefined the variable '${jobUserData_Z3ID}' in the other sql select node. Actually the variable is the user ID itself.

Provisioning node accordingly has the variables of the sql select node:

If I execute a change request the variable values are being presented in the WF:

The request complete successfully but, if I check in AD the Account is not being moved, its still in the same OU e.g. OU=Tenant A

AFX connector, Move an Account capability mapping, I left empty because values are being taken from the provisioning node right ? Also here should not be used AFXCUSTOM_ (as I am using it successfully for specific account attribute values population in case of an account creation only).

Does anyone have a clue what might be missed ?

Thanks.

Ahmed Nofal

Mar 13, 2020 8:08 AM

Correct Answer

Hi Viktor,

The provisioning command works as an ad-hoc command to fire a single capability (AFX request) where it is not reliant on the AFX fulfillment handler. The AFX capability parameter attribute values are not counted in any provisioning command where it requires values from the workflow, dis-regarding any attribute configured in any capability parameter at the connector's side.

Turning the connector to test, the provisioning command still is getting it's parameter values from the workflow. The only reason the CR didn't bring up any errors/messages was that the provisioning commands works the same whether the connector's state is 'Test' or 'Active'. So you are basically doing the same thing with the connector being in 'Test' state.

To test the capability, I've recorded a 1 minute video of how to do so which can define more where the problem is at, by checking the processing error if the ad-hoc capability action failed.

https://Dell.zoom.us/rec/share/-uFKL5up3zlJU6uWxl_PBZBiM6Dheaa82icar6FZz0z5hxMy6vf7hNdgihXFBXfv

In conjunction with this, have the AFX connector log file tailed, possibly as well with DEBUG if the error coming from the test doesn't make much sense or if there is no error.

See the reply in context

No one else had this question

Outcomes

Jesvin Joseph Mar 13, 2020 5:46 AM

Hi Viktor,

Have you checked the AFX Test connector capability and tried moving the AD account to the new OU.?

If that is successful, I would try checking the provisioning node status - Handling Provisioning Node Failures and see what error does the AFX throws during the execution.

Adding to the above, if you are looking to get the current DN, you could query from the PV_ACCOUNT table [Select DN from PV_ACCOUNT where ID = {}].

Actions

Ahmed Nofal

Mar 13, 2020 5:46 AM

Can you try checking the AFX connector log file found in AFX_USER_HOME/AFX/esb/logs/esb.AFX-CONN-<CONNECTOR_NAME>.log for any errors related to such an action?

Did testing the capability succeed when putting the values of the OLD_DN, NEW_DN in the test fields?

1 person found this helpful

Actions

Viktor Daskalov @ Ahmed Nofal on Mar 26, 2020 9:58 PM

Hi Ahmed,

The variable values of OLD_DN, NEW_DN are being presented in the wf runtime data.

I have been testing the connector in test mode as I put the values as following

it does not work.

Should the wf (I've shown above) branch needs to pass trough the afx fulfillment handler ?

The AFX connector log itself shows:

2020-03-13 07:40:27.902 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Create Account without password is done
2020-03-13 07:40:27.903 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Send ResetPassword command explicitly
2020-03-13 07:40:28.049 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - User Account Control values exist. No need to enable account explicitly
2020-03-13 07:40:28.050 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Force Password Reset not needed
2020-03-13 07:40:28.050 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Exchange CreateAccount not required
2020-03-13 07:40:28.051 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - No output parameters defined... skipping CreateAccount output parameter LDAP search
2020-03-13 07:40:28.052 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - AFX_OUT redirect flow invoked...
2020-03-13 07:40:57.532 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Adding group DN to user entry not required
2020-03-13 07:40:57.533 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - AFX_OUT redirect flow invoked...

Actions

Mostafa Helmy

@ Viktor Daskalov on Mar 13, 2020 5:53 AM

Probably try enabling DEBUG logging on your AFX connector following 000030219 - How to turn on debug logging for RSA Identity Governance & Lifecycle AFX connectors in 7.0.1 and higher

You can also change the LDAP loggers to DEBUG so it also logs the LDAP-related processing steps.

1 person found this helpful

Actions

Ahmed Nofal

@ Viktor Daskalov on Mar 13, 2020 8:08 AM

Hi Viktor,

To test the capability, I've recorded a 1 minute video of how to do so which can define more where the problem is at, by checking the processing error if the ad-hoc capability action failed.

https://Dell.zoom.us/rec/share/-uFKL5up3zlJU6uWxl_PBZBiM6Dheaa82icar6FZz0z5hxMy6vf7hNdgihXFBXfv

In conjunction with this, have the AFX connector log file tailed, possibly as well with DEBUG if the error coming from the test doesn't make much sense or if there is no error.

1 person found this helpful

Actions

Viktor Daskalov @ Ahmed Nofal on Mar 26, 2020 4:16 AM

Thanks a lot Ahmed,

Now I am able to move objects in LDAP fron one to another container via provisioning node.

Actions

Viktor Daskalov Mar 13, 2020 9:33 AM

Hi Ahmed,

Thank you for your response and the shared video.

I have just tested the AFX connector TEST capabilities as I've put static values which I got from the last submitted change request wf runtime data. it worked.

Then, I have put the same static values directly in provisioning command node in the wf and it worked as well. The account was moved on the target system (AD).

When, I used variables OLD_DN, NEW_DN (even they are presented in the runtime data) in the provisioning node it does not work.

I was able to handle the provisioning status variables below and they had the following output:

${jobUserData_acm.provisioningCommandStatusCode}

${jobUserData_acm.provisioningCommandStatusMessage}

ERRORCODE1
ERRORMSGLDAPException: Cannot connect to server. Please check the host and port settings

Actions

Viktor Daskalov Mar 26, 2020 4:21 AM

Hi Ahmed, everyone,

Thanks for the assistance.

Now I am able to move user account objects fro one container to another in LDAP via provisioning node.

My configuration was correct, I only was not setup the correct Business Source in the provisioning node. Stupid miss but it happens.

1 person found this helpful

Actions

Ahmed Nofal

@ Viktor Daskalov on Mar 26, 2020 7:06 PM

no worries, It happens to all of us. Speak to you soon

1 person found this helpful

Actions

9 Replies

Jesvin Joseph Mar 13, 2020 5:46 AM
Mark Correct
Correct Answer
Hi Viktor,

Have you checked the AFX Test connector capability and tried moving the AD account to the new OU.?

If that is successful, I would try checking the provisioning node status - Handling Provisioning Node Failures and see what error does the AFX throws during the execution.

Adding to the above, if you are looking to get the current DN, you could query from the PV_ACCOUNT table [Select DN from PV_ACCOUNT where ID = {}].
Like • Show 1 Like1
Actions
Ahmed Nofal Mar 13, 2020 5:46 AM
Mark Correct
Correct Answer
Can you try checking the AFX connector log file found in AFX_USER_HOME/AFX/esb/logs/esb.AFX-CONN-<CONNECTOR_NAME>.log for any errors related to such an action?

Did testing the capability succeed when putting the values of the OLD_DN, NEW_DN in the test fields?
1 person found this helpful
Like • Show 1 Like1
Actions
- Viktor Daskalov @ Ahmed Nofal on Mar 26, 2020 9:58 PM
  Mark Correct
  Correct Answer
  Hi Ahmed,
  
  The variable values of OLD_DN, NEW_DN are being presented in the wf runtime data.
  
  I have been testing the connector in test mode as I put the values as following
  
  it does not work.
  Should the wf (I've shown above) branch needs to pass trough the afx fulfillment handler ?
  
  The AFX connector log itself shows:
  2020-03-13 07:40:27.902 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Create Account without password is done 2020-03-13 07:40:27.903 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Send ResetPassword command explicitly 2020-03-13 07:40:28.049 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - User Account Control values exist. No need to enable account explicitly 2020-03-13 07:40:28.050 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Force Password Reset not needed 2020-03-13 07:40:28.050 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Exchange CreateAccount not required 2020-03-13 07:40:28.051 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - No output parameters defined... skipping CreateAccount output parameter LDAP search 2020-03-13 07:40:28.052 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - AFX_OUT redirect flow invoked... 2020-03-13 07:40:57.532 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - Adding group DN to user entry not required 2020-03-13 07:40:57.533 [INFO] org.mule.api.processor.LoggerMessageProcessor:193 - AFX_OUT redirect flow invoked...
  Like • Show 0 Likes0
  Actions
  - Mostafa Helmy @ Viktor Daskalov on Mar 13, 2020 5:53 AM
    Mark Correct
    Correct Answer
    Probably try enabling DEBUG logging on your AFX connector following 000030219 - How to turn on debug logging for RSA Identity Governance & Lifecycle AFX connectors in 7.0.1 and higher
    
    You can also change the LDAP loggers to DEBUG so it also logs the LDAP-related processing steps.
    1 person found this helpful
    Like • Show 1 Like1
    Actions
  - Ahmed Nofal @ Viktor Daskalov on Mar 13, 2020 8:08 AM
    Unmark Correct
    Correct Answer
    Hi Viktor,
    
    The provisioning command works as an ad-hoc command to fire a single capability (AFX request) where it is not reliant on the AFX fulfillment handler. The AFX capability parameter attribute values are not counted in any provisioning command where it requires values from the workflow, dis-regarding any attribute configured in any capability parameter at the connector's side.
    
    Turning the connector to test, the provisioning command still is getting it's parameter values from the workflow. The only reason the CR didn't bring up any errors/messages was that the provisioning commands works the same whether the connector's state is 'Test' or 'Active'. So you are basically doing the same thing with the connector being in 'Test' state.
    
    To test the capability, I've recorded a 1 minute video of how to do so which can define more where the problem is at, by checking the processing error if the ad-hoc capability action failed.
    https://Dell.zoom.us/rec/share/-uFKL5up3zlJU6uWxl_PBZBiM6Dheaa82icar6FZz0z5hxMy6vf7hNdgihXFBXfv
    
    In conjunction with this, have the AFX connector log file tailed, possibly as well with DEBUG if the error coming from the test doesn't make much sense or if there is no error.
    1 person found this helpful
    Like • Show 2 Likes2
    Actions
    - Viktor Daskalov @ Ahmed Nofal on Mar 26, 2020 4:16 AM
      Mark Correct
      Correct Answer
      Thanks a lot Ahmed,
      
      Now I am able to move objects in LDAP fron one to another container via provisioning node.
      Like • Show 0 Likes0
      Actions
Viktor Daskalov Mar 13, 2020 9:33 AM
Mark Correct
Correct Answer
Hi Ahmed,

Thank you for your response and the shared video.
- I have just tested the AFX connector TEST capabilities as I've put static values which I got from the last submitted change request wf runtime data. it worked.
- Then, I have put the same static values directly in provisioning command node in the wf and it worked as well. The account was moved on the target system (AD).
- When, I used variables OLD_DN, NEW_DN (even they are presented in the runtime data) in the provisioning node it does not work.
I was able to handle the provisioning status variables below and they had the following output:
${jobUserData_acm.provisioningCommandStatusCode}
${jobUserData_acm.provisioningCommandStatusMessage}

ERRORCODE1
ERRORMSGLDAPException: Cannot connect to server. Please check the host and port settings
Like • Show 0 Likes0
Actions
Viktor Daskalov Mar 26, 2020 4:21 AM
Mark Correct
Correct Answer
Hi Ahmed, everyone,

Thanks for the assistance.

Now I am able to move user account objects fro one container to another in LDAP via provisioning node.
My configuration was correct, I only was not setup the correct Business Source in the provisioning node. Stupid miss but it happens.
1 person found this helpful
Like • Show 1 Like1
Actions
- Ahmed Nofal @ Viktor Daskalov on Mar 26, 2020 7:06 PM
  Mark Correct
  Correct Answer
  no worries, It happens to all of us. Speak to you soon
  1 person found this helpful
  Like • Show 1 Like1
  Actions

Move Account Provisioining Command Node in Fulfillment Workflow

Outcomes

Related Content

Recommended Content