Timed Rollback - Action to Create Scheduled Job

Question

Is it possible to create a scripted action to create a new scheduled job, and for the job to delete itself when complete?

Scenario is an over-night callout that requires a support user to request and be granted elevated access rights by being added to an 'Emergency Support' group that grants admin access to a server/OU. When this action is approved it dynamically creates a scheduled job that is timed to execute 24 hours later that rolls back/removes the user from the group.

Another similar feature would be a script that mimics 'time based' rules that would return a true/false statement so that an Action would only be permitted between certain hours e.g. Will not run between 9am - 5pm, but will between 5pm - 9am.

Rgds

Comments

So...
An admin uses Adaxes to give emergency admin access to another person that you want removed 24 hours later?
Instead of creating a scheduled task just for that user, why don't you set up a business rule to add a date stamp to an available attribute that is +24 hours from the time access is given and then just continuously run a script that checks the group members and removes those in which the date stamp has expired?

---

Good idea!

In general I think have time based elements available for actions would be useful, but that certainly sounds like an elegant workaround.

Answer 1

Hello,

Actually, I wanted to suggest a solution that is almost exactly what jiambor suggested to you. jiambor, thank you for your active participation on our forum. We really appreciate it!

Here's what you can do to accomplish your task: you can add the user to your 'Emergency Support' group with the help of a Custom Command. In this Custom Command, you can send the action for approval, and then, when approved, you can set a certain property of the user whom you add to the group to the date and time when the user should be removed from the group. For this purpose you may use one of the Adaxes virtual properties that can be used to store date and time values, for example, CustomAttributeDate1. Adaxes virtual properties are not stored in Active Directory, but you may use them as any other property of directory objects.

Then, you can create a Scheduled Task that will run, say, every hour and check the value of that virtual property of every user account and compare it to the current date and time. If it is already the time to remove the user from the group, the Scheduled Task will do this.

To create such a Custom Command:

1. Create a new Custom Command.
2. On the 2nd step of the Create Custom Command wizard, select User.
3. On the 3rd step, add the Send this operation for approval action.
4. Click the Add Action button.
   
5. Add the Update the User action and press Add...
   
6. In the dialog that appears, open the drop-down list of the Property to modify field and select Show all properties.
7. Select the property that you chose to store the date/time when the user should be removed from the group (for example, CustomAttributeDate1).
8. Click the calendar button that is embedded in the New value field.
   
9. In the dialog box that appears, activate the Generate date tab and select Current Date/Time in the Set the date to field.
10. Tick the checkbox opposite day and select plus 1 day.
    
11. Click OK 3 times.
12. Click the Add Action button.
13. Select the Add the User to a group action and click Select Group.
    
14. In the dialog box that appears, select the group that you would like to add the user to ('Emergency Support').
15. Click OK two times and finish creation of the Custom Command.

To create the Scheduled Task:

1. Create a new Scheduled Task.
2. On the 3rd step of the Create Scheduled Task wizard, select User.
3. On the 4th step, add the remove the User from a group and click Select Group.
   
4. In the dialog box that appears, select the group that the Scheduled Task should remove the user from ('Emergency Support').
5. Click OK two times.
6. Click the Add Action button.
7. Select the Update the User action and press Add...
   
8. In the dialog that appears, open the drop-down list of the Property to modify field and select Show all properties.
9. Select the property that you chose to store the date/time when the user should be removed from the group and that you chose on step 7 of creating the Custom Command (for example, CustomAttributeDate1).
10. Switch the radio button to Remove property. This will remove the property as we no longer need it after the Scheduled Task completes its job.
    
11. Click OK two times.
12. Click the Add Condition button.
    
13. In the dialog box that appears, select the If <property> <relation> <value> condition and open the <property> drop-down list.
14. Select Show all properties.
15. Select the property that you chose to store the date/time when the user should be removed from the group and that you chose on step 7 of creating the Custom Command (for example, CustomAttributeDate1).
    
16. Select If CustomAttributeDate1 less or equal and press the calendar button.
    
17. In the dialog box that appears, activate the Generate date tab and select Current Date/Time in the Set the date to field.
    
18. Click OK two times and finish creation of the Scheduled Task.

Comments

Another similar feature would be a script that mimics 'time based' rules that would return a true/false statement so that an Action would only be permitted between certain hours e.g. Will not run between 9am - 5pm, but will between 5pm - 9am.

This is a very easy thing to do with a PowerShell script that you may use with the If PowerShell script returns true condition in your Business Rule.

In the PowerShell script, you need to get the current date and time and compare it with the hours when the action is allowed to run. If a condition is met, your script must set the ConditionIsMet property of the $Context variable to $True. Here's an example of such a script as per the hours that you specified:

$currentDateTime = [System.DateTime]::Now
if (($currentDateTime.Hour -ge 17) -or ($currentDateTime.Hour -le 9))
{
    $Context.ConditionIsMet = $True
}
else
{
    $Context.ConditionIsMet = $False
}

---

Support - that's perfect, thanks - I have setup a POC for our business scenario to prove the workflow works.

Another quick question (and I'm wring this from home where I can't check so I may be asking a stupid question...!) - is it possible to prompt a user for freeform text input when running a custom command? Scenario is as listed above, but when the user requests access it opens a text box where they have to input a reason (ala the Approval deny box) so this can be sent with the approval request (email/sms etc)?

Many Thanks

---

Hello,

is it possible to prompt a user for freeform text input when running a custom command? Scenario is as listed above, but when the user requests access it opens a text box where they have to input a reason (ala the Approval deny box) so this can be sent with the approval request (email/sms etc)?

This feature is in our TODO list. The implementation of this feature is scheduled for 2013.2.

---

Thanks - good to know!

As a bit of feedback - we'd make a good deal of use of this via the web portal, and we're looking at supporting tablets/smartphones (especially for approvals as the required personnel may be offsite). As the use of web pop-ups can be 'problematic' for some mobile device browsers, if the entry fields are displayed on-demand I'd recommend that you don't enable it via a pop-up web page (if that makes sense).

Finally, one more question :)

When sending an action for approval is there any way of stopping an action being automtically approved if the initiatior is a member of the approved user list? Usually this behaviour is what is wanted, but in some scenarios we'd want another member of the approved user list to be the approver so that we can enforce "4 eyes" approvals for high risk actions.

---

As a bit of feedback - we'd make a good deal of use of this via the web portal, and we're looking at supporting tablets/smartphones (especially for approvals as the required personnel may be offsite). As the use of web pop-ups can be 'problematic' for some mobile device browsers, if the entry fields are displayed on-demand I'd recommend that you don't enable it via a pop-up web page (if that makes sense).

Sure, thanks for the suggestion!

When sending an action for approval is there any way of stopping an action being automtically approved if the initiatior is a member of the approved user list? Usually this behaviour is what is wanted, but in some scenarios we'd want another member of the approved user list to be the approver so that we can enforce "4 eyes" approvals for high risk actions.

For security-sensitive operations you can add two Send this operation for approval actions to your Business Rule, and specify different sets of approvers for each one. Adaxes will not execute the operation until it is approved by at least one approver from each set.

---

Yep - we have tested in that way to give us an approximation - but the limitation is that we have to create a arbitrary split of the approving users e.g. AppoveGroup-1 and ApproveGroup-2 when the precise business logic is "any two of ApproveGroup".

The ideal would be to have a tickbox option on the approval action along the lines of:-

[Yes/No] Allow initiator to self-approve if in approval list

Rgds

---

Sorry - one more totally unconnected question!

I seem to remember somewhere you had the option of not allowing actions to be performed on multi-selected objects e.g. you could select and delete one object, but if you multi-selected objects it wasn't allowed. Is that correct, or have I totally confused myself?!

Rgds

---

Hello,

This option is available for Home Page Actions in the Web Interface:

For more details, see Configure Home Page Actions.

So, you can disable the Delete operation in the Web Interface and allow it to be executed via the Home Page only.

Also, have a look at Protect/Unprotect Objects from Accidental Deletion. Note that with the help of Business Rules, Custom Command and Scheduled Tasks you can automatically protect AD objects from accidental deletion.