This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD Account Provisioning Error. Corporate policy violation

Hello Everyone, 

I have just run in to an error whilst trying to provision an AD Account using an Account definition. 

Just to give some background information, I am using the ARS connector to connect to their AD environment. I am able to pull in information with a sync and was even able to provision AD accounts perfectly up until recently.

It turned out that the customer didn't transfer the policies from their production environment in to Dev / UAT and all of a sudden, i am now not able to provision after the move. 

I have been working with the AD admin and have met all of the requirements for the policies however it doesn't seem to be making any difference. 

For example the error in the screenshot below shows that the Firstname / Givenname property does not conform to their policy. I don't understand how this is occurring as the policy just states that the field should be mandatory and before the policies were applied, it was creating AD accounts using this property.

I have seen the page for a similar issue in ARS and have referred it to the Admin. 

https://support.oneidentity.com/active-roles/kb/215373 

 

Also I am using v7.1

Any help or guidance would be greatly appreciated

 

Thanks 

Yahya

  • That error is coming for Active Roles and it is basically saying that the parameters provided for First Name does not comply to the current policy applied to the OU in Active Roles. I would check within Active Roles to see which policy is currently applied to that specific OU.

     

    I would then attempt to create a test user within Active Roles in that same OU and use a similar first name as the user trying to be created via identity manager

     

    I would imagine that you get the exact same error message

  • When working on issues such as this, what I usually do is block inheritance on the policies then attempt to create a test user. I would suggest blocking the policies that relate to users one by one then test. That will tell you which policy is breaking it. 

     

  • Firstly, thank you for the reply. Secondly, we tried creating the accounts in the front end of Active Roles and it worked so i'm a little confused. We filled out the details of the account the exact same way 1IM was trying to provision the accounts.
  • As you can see I easily reproduced the issue. All I did was create a new provisioning policy in Active Roles that validates the first name user property. It says that the first name must end with a 1. I then set that new policy on my detestation OU. Went in and assigned my account definition that creates users in this specific OU and voila we get the exact same error.

     

     

  • If you still have the frozen job present in the job queue you could enable the process step option under the view menu and then expand the basisobjectkey for this object and confirm what the given name value is that is trying to be passed to Active Roles. Just scroll down until you see given name

     

     

    You can do the same if the job is now in process history

     

  • In the end the issue was that the the service account used to connect to the Active Roles instance did not have the necessary permissions that was specified in the ARS Documentation.

    Thanks
    Yahya