Share all details about your problem, including any error messages you may have received.
Hi,
I have one use case for the LDAP connector to implement.
I am creating an account with the help of a provisioning policy form by providing a list of required attributes for our requirements. Among those attributes, there are two we have. One is uidNumber and second is ipaNTSecurityIdentifier. We can pass -1 to the uidNumber so that the application will generate the unique number dynamically after an account has been created in the LDAP application. Once we aggregate, then we will get those attributes’s data. Now, the second one is that we can’t simply pass -1. We have to pass a certain value that contains the uidNumber as well. So, basically, if you want to pass the ipaNTSecurityIdentifier value, you have to rely on the uidNumber value. Now, my question is: how can we get the value of uidNumber and pass it to create an account with this value?
The uidNumber value we will get only after aggregation is done. So, how can we achieve this scenario of creating an account by passing those values?
I have tried to pass the values in after provisioining rule. But by this time, the uidNumber value would not be there on the link because the aggregation was not done yet. And it is not allowing single account aggregation as well.
I have a couple of ways to implement it in mind. But those are not more standard. I am looking for a better solution.*
using afterProv rule is a good idea. Usually in the return plan, that you can see in after rule, you can have the response of the target, because the connetore does a getObject after creation(more or less).
Try to print the plan in you after and see if you have the id and later build and execute another plan.
Also, if the id is mapped on an identity attribute you can use a lifecicle event with type attribute change and build and execute a new plan there.
Other, you can use a customization/aggrergation rule during aggrergation for evaluate this attribute.
PS I am talking about plan, but you can do everything
I think need to understand more about the application , what are these 2 attributes and what is dependency of these 2 attributes also how frequently accounts are getting created in this application.
few options but not in particular order , order will be depend on understanding application better.
Custom Rule Task to populate value
After provisioning rule.
Modifying the workflow for particular application .
4 Let application owner populate that field based on logic on ldap itself
Initially, I thought of using the plan object in the after provisioning rule. But we don’t have the value by the time. We have to aggregate the account in order to get the uidNumber. I have tried to print the plan and checked for getting the uidNumber, so that we can use the Provisioner class to execute whatever I need. But here, it is not helpful because it doesn’t have value.
We don’t use the identity attribute to map. Because it is a one-time activity at the time of account creation only. Not required later. So, we are thinking of making use of the identity attribute for this one, and that too, these accounts provisioning is not frequent at the moment. And this application is used by only a couple of users, not everyone.
I will check the aggregation rules once. But I am still thinking that if we use the customization rule, every time the account aggregation task runs, this rule will be executed, (which is not required. (Ideally, the value should be added only at the time of creating the account.) And it takes a long time to complete the task. I think creation rule may work, but not sure. I have to check.
If I want to create an account in the application, I have to pass those two values (uidNumber and ipaNTSecurityIdentifier). We can pass -1 to the uidNumber so that the application will generate the unique number dynamically after an account has been created in the LDAP application. We cannot pass -1 to ipaNTSecurityIdentifier because this value is something different that contains the uidNumber as well. So for that, we have to get the uidNumber before passing this value to Plan.
And the provisioning of these accounts is not frequent at the moment. And this application is used by only a couple of users, not everyone.
After provisioning rule is not working out in this case because the value would not be there by then. We can only get the value after aggregation.
I will check the workflow part.
No, the LDAP application team won’t provide or populate the value. That is something we have to take care of at SailPoint. The reason is that we are completely automating the provisioning activities for the application. Again, asking, involving them, or calculating and populating the value is tedious work. If SailPoint can’t handle it or if it is not feasible, they have to do it, btw​. There is no way. I’m just looking from our SailPoint side at the moment.
Follow this approach, Create a workflow which will actually take Account name, application name as input and in the workflow try to do a account aggregation in first steps and next step send a modify plan to update the attribute ipaNTSecurityIdentifier , in the first step as your aggregation is completed you will have uid and use that in next step
Now in your after provisioning rule call this workflow using native identity which is basically your account name and schedule the workflow after 5 min , also have this under condition of provisioning result as committed and operation as create ( so that the workflow will trigger only for accounts that are created anyhow its up to you )
This approach should resolved your issue, let me know if you still see any issues with this approach.
Note - I checked the usage of this attribute on LDAP side, technically it is not mandatory during ldap account creation and can be set later once the account is created as well
Yeah, this is also one of the things we can do. But there might be an issue with this. Like in the workflow, the first step is aggregation. So, for my application to complete aggregation, it is taking 10 to 15 minutes of time. Imagine if the user count is more than 50, 100, or more. Then it will take 500 minutes to complete for just 50 users (it may increase in future), and it leads to the provisioning being still pending and might get stuck or have performance impacts we may encounter. And this application is not allowing single account aggregation as well.
And we will be having aggregation schedules 3 or 4 times a day, which is good enough to pull all the users on a daily basis.
Yes, technically, the attribute is not mandatory during LDAP account creation. But we have a requirement that we set the value for the attribute at least once the first aggregation is done after account creation is completed in LDAP.
@bhanuprakashkuruva
I mean in the workflow just do the OnDemand aggregation of account that is created using API , I am not asking to run the aggregation task, are you saying this LDAP application doesn’t support onDemand aggregation using API for the single user?
As it is ldap , I think you should be able to do this, did you try this already?
I think best would be this need to handle at application side itself , or if you need to do from sailpoint only better option is write a custom rule and trigger once a day/ week based on the criticality.
We can do it however we want to achieve it. But what I did and worked for me is:
As usual, I am passing a -1 value to the ipaNTSecurityIdentifier attribute in the Create Provisioning Policy form in the first step because it requires for one of objectClasses.
I have created a role that contains a match list. The ipaNTSecurityIdentifier should be -1 (You can add more if you want). Besides this, this role contains a role provisioning policy. I have added the attribute (ipaNTSecurityIdentifier) to pass the value (I have to write a logic to return the value based on our requirement).
So, in the next refresh after aggregation is run, the role will be assigned and the value will also be updated. Later, the schedule aggregation runs, and the ipaNTSecurityIdentifier value will be updated with the actual value, and the role will be unassigned in the next scheduled refresh task. Here is one small workaround we have: once the role is unassinged, whatever the attributes we have in the role provisioning policy form, those values will be removed from the account, which should not happen. So for that, we have to write a snippet code to check if the ipaNTSecurityIdentifier’s remove request, then don’t do that in the before provisioning rule.
. There is no way. I’m just looking from our SailPoint side at the moment.
