IdStory Identity Manager

1
Maybe the best solution can be to embedded WinRM connector into AD connector. Then you can configure all properties together in one place and choose for example if you want to execute create via LDAP protocol or powershell or both and choose order of these operations - for example create user via LDAP protocol and then create homedir for him via WinRM. There should be a configuration property for delay between executing the second method - use case is o365 where we need to wait 30 minutes for synchronizing AD user to cloud

User will have one account to the end system and logic will be implemented in connector. The possibility to use "only" LDAP protocol will be untouched.

2
Solution with some kind of dependency in IdM will be probably almost unreal to implement, because provisioning operations are asynchronous. I will consult this possibility to be sure.

3
Other option can be to configure WinRM as other system and then make some projspec implementation when create to AD will be executed I will assign role "powershell" to that user so provisioning via WinRM will be executed after AD. Thx to Ondra for this advice.
For create operation this solution will be OK, but for update and delete I can't guarantee which provisioning will be first.

Unluckily, some kind of dependency of systems is needed for other systems as well - some examples here: https://redmine.czechidm.com/issues/1260. There are more systems that are dependent on AD (Kerio, Alvao, Plone, ...). It would be really nice to solve it in the product, not by project specific implementation.

Which options do we have to support delay between execution update with multiple connectors:

1-Use two connectors in one with blocking wait for the second execution - big disadvantage is that no other operation can be performed from IdM. If we need to wait for example 20 minutes then IdM can perform like 1 operation per 20 min

2-Use two connectors in one with non blocking wait. - Previous disadvantage is eliminated, but IdM will have no way how to know about the result of the second execution. E.g. If the second execution which will be run after 20 minutes will fail. We won't be able to see this error in IdM, only in server log

3-Same as solution num. 2, but we will have our connector dependent on IdM so we can alter provisioning operations after the error. - Don't know for 100% if this solution will be usable, and the connector will be usable only with IdM

4-Use two connectors in one without delay and if the second execution will fail, we will trust that IdM retry provisioning will fix it later. E.g. I will assign role to ad via LDAP protocol and I need to wait for synchronization between AD and o365 and then execute powershell, in first try it will failed(only the powershell part). IdM will try it again and again, ..
We need to test what will happen if I try to assign role to user in AD which he already has, because in the next attempts it will run both execution (ldap + powershell) When retry provisioning is performed it will call search again so when there is another attempt and user has the role from previous execution it will not try to provision it again
This solution seems like the best one for now

5-Use two separate connectors and trust in retry provisioning - Not sure if this will work correctly.

6-Implement this feature on IdM level together with system dependency and have it as two systems.