[MUSIC PLAYING] Hello, AND welcome to this Active Roles Deep Dive presentation. My name is Rich Lambert, and I'm a Presales Product Architect with One Identity. Also providing content for this presentation was another presales architect on the Active Roles team, Eric Hibar Jr.
During this Active Roles Deep Dive, we will be taking a fairly in-depth look into Active Roles Workflows. Workflows are a very powerful feature of Active Roles that can help automate and orchestrate, well, a lot-- items such as simple, repetitive tasks to extremely intricate, complex use cases. We will review the different Workflow types, Workflow activities, which can also be referred to as steps, Workflow parameters, and running scripts within Workflows. We will also review a script-based component of Active Roles called Policy Types that can be used to add custom entries to Workflows and policies. Here's a brief overview of the agenda for this deep dive.
I'd like to start off by asking the question, why use Active Roles Workflows? Workflows are based on Microsoft's Windows Workflows Foundation. Windows Workflow Foundation is used to create items in .NET applications that execute an ordered business process. As you can see on this slide, Workflows are built in a graphical user interface, which makes them very easy to visually see the design of the Workflow and what actions are taking place. Being able to visually see the structure of a Workflow makes them much easier to spot check and troubleshoot than, say, compared to a lengthy PowerShell script.
In Active Roles versions of yesteryear, it used to be necessary to develop a lot of scripts within Active Roles to perform actions and operations. But is the power of Workflows have evolved through the releases of Active Roles, Workflows can now perform a lot of these actions. That's not to say that there still isn't an instance when a well-placed script is called for.
Before we start our journey into Workflows, I thought it would be fun to take a very quick look at where Workflows came from in previous versions of Active Roles. Going back to Active Roles 6.7, there was only one type of Workflow, Change Workflows. And that Change Workflow only had five steps available.
Compared to today's releases of Active Roles where there are now two types of Workflows, there's still the Change Workflows which now have 18 available steps and an Automation Workflow type, which have 17 available steps. So let's now begin our analysis of Workflows by looking at the various types and components within the Workflows themselves.
There are two types of Workflows, Change and Automation. Change Workflows react to changes made to the directory data. These changes can be referred to as requests.
These requests can be anything from, say, a new user creation to the modification of an organizational unit. Change Workflows allow access to the data of the submitted request in both a pre- and post-execution phase of the request. We will touch more on this later.
The other type of Workflow is automation Workflows. These types of Workflows can be scheduled or run on demand. A prime example of an automation Workflow would be to search Active Directory on a regular basis to look for empty groups or stale user or computer objects. If found, these Workflows can then be configured to automatically perform actions, like deleting them or maybe disabling them and moving them to a disabled object's organizational unit.
Before going any further, I thought it might be beneficial to take just a minute and go through a very brief overview of how Active Roles performs operations. When a request is sent to Active Roles, an access check is always performed to make sure the user or system that issued the request has the rights to perform and make the request to change. Once the access check is complete, control is turned over to the pre-execution activity as a Workflows in Policies. The default processing order is that Workflows run first and then policies. However, this behavior can be altered if necessary on a policy-by-policy basis
This pre-execution phase allows inspection as well as the ability to modify the data contained in the requested operation. An example of a pre-execution phase modification of data from a policy would be, say, the policy rule to generate a user's CM account name during the creation of a new user. Another example of an action that can take place during the pre-execution phase would be a change Workflow temporarily halting a submitted request to seek approval.
These types of approval requests are typical on modifications of group memberships. When the pre-execution processing is complete or approval is granted, Active Roles then executes the operation. After the execution operation is complete, the post-execution processing takes place, and it is in reverse order with Policies and then Workflows. I'm not currently aware of any means by which to alter this processing order in the post-processing phase. These post-execution activities could be the creation of a user's home folder, the provisioning of an Azure user, or the sending of an email.
Continuing on now with the Workflows-- as mentioned in the previous slide, the default processing behavior of Workflows first and then Policies during the pre execution phase can be adjusted. There's an attribute on the policy that can be set to true to allow the configured policy to run before any Workflows. This is outlined in One Identity Support KV Article 4338998.
Also, another Workflow processing adjustment that might be useful-- if multiple change Workflows are configured to react to the same type of operation is the order in which the change Workflows are started. There is a Workflow priority attribute that can have a number assigned to it. The change Workflows will be then executed in order of lowest number to the highest number last. If multiple change Workflows happen to have the same number assigned, they will then be executed in alphabetical order.
All Workflows can have values assigned to Workflow parameters at the start of the Workflow. The values for parameters can be populated statically via a script or, in the case of an interactive automation Workflow, presented to the user to provide a value. These parameter values then become static and available to subsequent steps in the Workflow.
There is an item worth mentioning if using a script to populate a parameter. Any time a Workflow is saved, Active Roles will run the scripts assigned to populate parameters. This is to verify that the script will be returning an appropriate value. In this example with the error message, the script assigned to populate a parameter is trying to return multiple values to a parameter that has been defined as a single value. This is mentioned because it may be necessary to make adjustments to scripts just a little bit to take into account scenarios like this.
Along with parameters that are instantiated at the start of a Workflow, initialization scripts can also be configured. These initialization scripts are useful if there are PowerShell modules that need to be loaded or global variables defined. These global variables can then be accessed and also updated by subsequent scripts within the Workflow. Unlike parameters that are read-only, defining global variables in an initialization script could be a mechanism by which to share data or results between Workflow steps that run scripts.
There are several other options that can be configured within Workflows. One of these options is to define the Run as option. By default, Workflows will run under the context of the Active Roles service account. If this is not the desired functionality of the Workflow, the Workflow can be configured to run under the context of the person who initiated the Workflow or who submitted the request to change.
Another important option specifically for change Workflows is the Enforce Approval setting. This is useful to make sure that no matter who submitted a request to Active Roles, especially those users assigned to the special Active Roles admin group, that the request will be subject to approval. Otherwise, an Active Roles admin user can carry out changes that under other circumstances would require an approval.
And one final option to mention specifically for automation Workflows is the ability to set a timeout value. This would be to help account for the instance that the Workflow runs too long or enters into a type of infinite loop of some kind. As we continue to review Workflows, let's take a specific look at a few more commonly used Workflow steps, AKA Workflow activities.
Notification steps can be added to Workflows and are used to send out emails. With that said, most Workflow steps do contain a notification tab within them to also send out emails. The email messages can be customized within the Notification settings. The Script Activity is used to have a Workflow run a script. This will be looked at a little bit further later in this presentation.
The If-Else step can be used to make logical decisions, which can then control the subsequent steps to execute. If-Else steps can also be configured with more than just two paths. Also depicted on this slide specifically for Change Workflows during the pre-execution phase is the modify request to change a step. This step can be used to modify or insert data into the requested change. This would be as the request is in-flight before the request is sent to Active Roles for processing.
The Workflow step labeled Add Report Section is useful to log additional information to the Workflows run history. This Report Section step can also be useful in troubleshooting the logic of search activities. The Search activity is probably one of the most commonly used steps. This step is used to search the directory for objects to process or report on.
Examples can be searching for empty groups, inactive users, or searching for a group or groups to add a user to. Steps added within the context of a search activity have access to the objects that are found by the search. The objects are not presented all at once to the associated steps, but one at a time. This can be thought of as more like a For-Each loop. Also worth noting-- the resulting LDAP query from the configured search is always visible in the Workflows run history.
Up to this point, there has been a lot of talk about Workflows, their types, activities, parameters, and options. So now let's take a look at how to create an automation Workflow and how to add a few steps to it. You'll see that the Workflow Designer is a very convenient drag-and-drop interface, which means Workflows can be created and edited very quickly and easily.
Once the automation Workflow created, we'll drag over a search activity, then go into the properties of that search activity. You can change the name of the search activity, which might make sense for trying to read the run history and also for referencing the search if it's a complex Workflow. We'll set the specifics of the search activity here to find specifically users. And then we'll narrow the search down to be specific as possible and concise so that the search runs as quickly as possible.
We'll add a condition here to the search. We're going to specifically look for users that have the name that starts with the letter V, first name specifically. You can save that. So if we run the Workflow, we take a look at the change history of the Workflow here-- or sorry-- the run history, we would expect to maybe see the Workflow find some objects. But that information actually is not initially available unless the Workflow actually does something.
So if we're in doubt that the Workflow-- the configured search is actually configured properly, there's the LDAP query. We can copy that and paste that into the MMC console of Active Roles to just test it out. This is useful, too, to see if the logic of the search has been configured properly.
If the LDAP query finds objects here, then we can be rest assured that the LDAP query is properly configured. So we see here that three users are found. So the search is configured properly.
So why this Add Report Section Workflow step is useful is it can be used to also help output the activity of the search results. Then, we can see what the actual Workflow is finding because unless a Workflow step is taking action on the objects of a found activity, they don't appear by default in the run history of the Workflow. So we'll just quickly create a very basic report section here to just output some information for us on the found objects. And if there were multiple search objects in the Workflow, you could see there that the name of the search activity was there, which could be helpful for determining which search activity you want to add the report section for.
So you defined a subject here or a title of the header of the report, and then here's the information that would be contained in the report line of the Workflow history. These do require just a little bit to set up. But the outputted information is very beneficial and useful, especially if you're trying to troubleshoot very complex Workflows.
We're going to output the first name of the found object. That should be it for that. We hit Save. Now we can run the Workflow again.
We will see that the information is now going to appear in the run history. See, now there's our three users. So we know for a fact that these same three users are found and then that any Workflow steps added within that search context would be able to access those three objects.
Let's continue reviewing just a few more Workflow steps. The update step is used to modify attribute values on existing objects in Active Directory. This step can also be used to modify control values, which can be important to carry out specific actions. This will be looked into a little later in the presentation.
The Save Object Property step is useful if an attribute value is possibly going to be altered or changed later in the Workflow, but the Workflow might still want or need its current value before the attribute is modified. This can be thought of as taking a snapshot of the selected attribute for either later comparison or possible inclusion in email notification messages. A helpful tip here-- as we saw in the demo, when changing the values of the search activity, it's also important to change the name of the Saved Object Property steps, and the names need to be unique. You'll see that this makes later referencing these steps in scripts a lot easier.
The Modify Requested Changes step has already been reviewed in a previous slide in this presentation, but it's really used to add or remove property changes directly within the request. And a Workflow step specifically for automation Workflows is a step called Office 365 Script Execution Configuration. Adding this step to an automation Workflow allows any subsequent script steps added to the Workflow to leverage the connection to Azure that is already configured within Active Roles.
A little history here-- prior to this step being introduced, if a script that was added to an automation Workflow was needing to do something in Azure or Office 365, that script needed to make its own connection. This Office 365 Script Execution Configuration step eliminates that need because Active Roles already has a perfectly viable connection to Azure. Why not be able to utilize it? And finally, here's a list again of all the steps available in both Workflow types.
As the functionality of Workflows has continued to evolve, there are still use cases where scripts are needed to help further expand and complement Workflows. Here, we're going to take a little deeper look into how scripts can leverage and act upon the data within the Workflows context.
You need to first mention that when performing any scripting development work for Active Roles, the SDK help file and sample scripts are always a great place to start. There are a lot of scripting examples contained within the SDK file.
One of the most common items that scripts added to Change Workflows are going to want to access is the Workflow Target Object. This is the object whose change started the Workflow. For existing objects, scripts can access data from the Workflow target object by using the built-in $DirObj reference. This is a reference to the in-process directory object. This $DirObj reference allows direct access to all of the attributes on the target object.
Well, now you might be asking the question, well, what if the change Workflow is running in response to the creation of an object? Can $DirObj still be used? The answer to that would be no and yes. If you remember, Change Workflows allows steps to be added to both the pre- and post-execution phases. In the pre phase of an object creation, the object doesn't yet exist, so the $DirObj reference is not yet available. However, in the post phase, the object has been created, and so has now the $DirObj reference.
Mentions of $DirObj here wouldn't be complete without also mentioning the request object reference, which is not depicted on the slide. The request object contains all information related to the change itself. Looking specifically at an object creation request, for example, this would be all the attributes Active Roles has received as part of the Create request. Again, all of this information is contained in the Active Roles SDK.
Let's move on to the next item, Parameters. Scripts can access the value of parameters by using the Workflow reference. As you can see in this example, this is accomplished by using $Workflow.Parameter and then specifying the parameter name. If the parameter is multi-valued, then use the $Workflow.ParameterEx method.
Information from Saved Object Properties is another common item that scripts will be needing access to. Workflow.SavedObjectProperties, then specify the name given to the Workflow step, then dot, then the name of the attribute. As mentioned earlier, this is where giving the Workflow steps unique, meaningful names will come in handy.
And to wrap up the scripting review, scripts can access information found in Search activities. Just add the script step within the context of the Search step. Again, please keep in mind that Search activities within Workflows act as a For-Each loop, so the script will only see a single object each time the script is executed.
Use Workflow.FoundObject, specify the name of the search activity, then Get, and then distinguished name. Search steps just return the distinguished name of the found object. So with the distinguished name, the scripts can retrieve additional information from the found object by using the Active Roles Get-QAD management cmdlets.
Custom policy types are somewhat of an overlooked component of Active Roles. Maybe that's because it isn't obvious that they are there or what they actually do. One of the uses of custom policy types is to create custom script-based Workflow steps. The pieces that need to be in place for the creation of a custom policy type is that a script must first be developed to do something.
Once the script is in place, then the creation of the custom policy type within Active Roles configuration can be done. The custom policy tie points to the script and tells Active Roles what types of Workflows the step will be visible in. There will be a demo on this in just a little bit.
Custom policy types can also be used to create custom entries in both provisioning and deprovisioning policies. The scripts for these types of custom policy entries will need to be written to utilize the event handlers, like onPostCreate, for example.
This demo will show a custom policy type that creates a new custom Workflow step. This step will be used to have a change Workflow manually start a synchronization process in the Active Roles sync service. So here's the script that's been developed with two functions oninit and a function execute sync service Workflow. The oninit function is used to populate some parameters. The execute sync service Workflow is the function that's actually going to reach out to the sync service to execute a Workflow step within the sync service.
We're creating a new policy type container. It's worth noting that the name given to this new container-- which, in here, is sync service-- is the heading under which this new Workflow step will appear. So be mindful of the name that's given to the custom container because it will be appearing in Workflows.
Let's create a new policy type, reference to script that was already developed, Workflow activity-- this is the function that will actually run the Workflow in the sync service. This can be used in change or automation Workflows. We'll select both. And then the function to declare parameter values is the oninit function.
I'm now going to go under Policies, Workflows. This is where the new change Workflow is going to be created. This Workflow is going to then be kicking off the HR sync Workflow within the sync service upon user creation. The reason why this is being shown here is because once the policy type is created, you'll notice that it does not appear by default within the Active Roles MMC but that the MMC needs to be closed and reopened to pick up the new policy type. And what we see in the background here is the sync service Workflow with the three Workflow steps.
If we go back into the Workflow that was just created, we will see here the new custom Workflow step is created under the sync service heading. We can drag and drop the new Workflow step into the Workflow Designer in the post-execution phase. There's a parameter, so this will be populated by a script. It's actually reaching out to the sync service and pulling back the configured Workflows so that we can select it from a dropdown list. We specifically run to run the HR sync Workflow within the sync service upon a user creation.
We're going to further refine the Workflow start conditions. By default, it is any user within the entire Active Directory, which is all managed domains within Active Roles. We're going to narrow that down a little bit because we don't necessarily want it to kick off for any new user that gets created. So we'll still say any user, but if a new user is created specifically with the enterprise user's OU.
We're going to add a little bit of additional filtering here, change the value of the Workflow context. This is part of the requested changes. And again, part of these start conditions, we only want this Workflow to kick off if an employee ID has been specified during the new user creation. This is useful because the sync service cues off of employee ID field. So if the employee ID is not populated for the new user, we also don't want this Workflow kicking off because the sync service will not be able to map it between the source system and the new Active Directory object.
So we're refreshing the Active Roles web interface. I'm actually going to quickly step through the creation of a new user-- new user's given an employee ID, along with first name, last name. You'll see how some of the fields are already pre-populating.
Here's a policy that's being kicked off on the pre-execution phase that generated the same account name. And other policies help formulate a dropdown list for the Department field. We'll have Active Roles generate a new complex random password for u. We're not going to create a mailbox, so we're going to have the new user get created. Here's Carol Williams, got created.
Now it's an existing Active Directory object, but there's some data missing. And this data that's missing comes from this source feed. That won't happen until the sync service kicks off, which by creating the new user, the Workflow step picked up the new user creation.
And we can see here some statistics that are being run. It automatically kicked off the sync service Workflow. And here in just a second, we're going to see actually the objects to be updated is going to be set to 1, which is the new user that we just created.
It does sometimes take just a minute for this to execute. There's are one user. We can click on it here within the sync service to see that, again, Carol Williams got picked up because of the employee ID, and it matched an existing user in the source system. And if we go back to Carol's object, we'll see now there's a phone number. Some of the addresses have been populated, as well as additional organizational fields, including the employee's manager.
Let's next review and compare change Workflows versus Policies. A general common thing you might be continuing to ask yourself in configuring Active Roles-- there's almost always seems to be more than one way to do something. And you'd be right if you're saying this. And on top of that, there's also really isn't a right way or a wrong way to accomplish a given scenario or use case.
When trying to determine when to use a policy or Workflow, this could depend on what the intended outcome or user experience should be. There can be a few requirements to help steer picking one over the other. Items to consider when thinking about using change Workflows are that they can be started or triggered upon a very specific set of conditions with extensive filtering. Change Workflows also allow access to the requested operation in both the pre- and post-execution phases. Logic in the form of If-Else branches can also be added to the Workflow to make even more logical decisions.
Items to consider for Policies are that the policy is applied to all objects of the selected object type where the policy has been linked, such as an organizational unit. However, if not wanting to apply a policy to all objects contained within the selected organization unit, then a managed unit might be able to help filter or narrow down the objects affected by a policy. Policies also have the ability to affect the GUI or user experience by creating such as dropdown lists for locations or departments or in generating values in real time for the user as a requested operation is in progress, like the manual creation of a user object. Also, policies apply to anyone and everyone who submits the request, even those designated as Active Roles admins. They cannot bypass rules being enforced by a policy.
The next portion of this deep dive will show demonstrations that highlight various use cases for Active Roles Workflows. This demo will show an Automation Workflow that can be configured to search for computer objects and delete them. Normally if a computer object has leaf objects associated to it, the Delete operation will fail. This demonstration, will show two different deletion attempts. One will be without the DELTREE control set, and the second one will be with the DELTREE control set.
If we take a look at the computer objects, there's two computer objects here within the United States organizational unit. One is called DeleteMe, one is called has leaf objects. Here's a prebuilt automation Workflow that's searching for computers in the United States OU.
And within that Search step is a delete found computers. It's just a straight up delete operation. We'll go ahead and manually kick it off.
We'll see here on the run history of the Workflow that the Delete Me computer was deleted, but the actual Workflow had an issue deleting the has leaf objects computer. That's because there are child objects of the computer object that a normal delete operation isn't allowed to do. We could simulate this here too by also running it against the same computer object with a PowerShell command, Remove QAD Object. We can easily add this DELTREE control to a PowerShell script by adding the -delete tree. But we want to figure out how to add that to a Workflow.
We're going to very quickly recreate the DeleteMe computer so that we can see that the adjusted automation Workflow will again delete both computer objects this next time it's run. You also see that Workflow steps can be enabled and disabled at will. So we'll disable the previous one and enable the other one, which actually has the DELTREE control set.
We'll see specifically where to do that. It's the same type of delete. But then with an additional settings, we see the control name is the number 10, and you can set its value to literally anything.
There's also another way to add additional information to the change. It's called Operation Reason. You can type in free-form text there, which will also be part of the Workflow run history. Referring to the Active Roles SDK, we'll see the Control Delete Tree.
Control ID is the number 10, so that's what's added to the Workflow step. And that basically says that you can set this value to anything you'd like in order for it to be set to True. So as you saw earlier, I literally set the value to anything, which will enable the control 10 to now take effect.
If we run this Workflow again, we'll let it run and inspect the run history, we see now that there's no longer an error, that the DeleteMe computer has been gone and now has leaf objects should also be deleted. Now we've swung over to the Active Roles web interface. We'll just refresh the page, and then we see that both objects are now gone.
We can take a look now at the run history again of the Workflow to see that both computer objects again were deleted. And then if we look into the actual operation ID, this is where we'll see that text Workflow, DELTREE, has delete leaf objects. That's the free-form text that was typed into the additional properties of the Workflow.
This demonstration, we'll show how an Automation Workflow can be configured to ask the user who started it to populate some information into a parameter. The choices for the parameter will be generated by a script, and the user is able to select one of the items. The Workflow will then create a standard set of OUs, groups, and users in the domain that was selected by the user who ran it, who executed it.
Here's a pretty involved automation Workflow that's going to create a standard set of OUs, users, and groups, and actually conduct a little bit of group nesting. We'll take a look at the parameters. There's a domain name parameter.
That's going to be presented to the user who kicks off the Workflow. And there was also a password value that was not shown because it's a secured value. That's the password that's going to be automatically assigned to new users that this Workflow creates.
Here's a Workflow function that's going to populate the parameter that's presented to the end user. You can see it's really only two lines of code. It's just searching Active Roles for all managed domains and returning that value to the parameter. We'll take a look into a few of these.
With the error checking that this Workflow does, since it's creating a standard set of objects within the new domain, you want to make sure it's creating a set of migration OUs. So you want to see if an OU with the name migration OU already exists at the root of the domain. And so if it does, we will want to save that OU's object ID value.
Then an If-Else branch-- if the value from that saved object property is null, there it is empty, then we want to go ahead and create that migration OU. If an OU with the same name already existed, then we can continue to search if any of the additional OUs within that OU already exist. If not, create them.
This could be if this Workflow maybe had been previously run but then encountered an error and maybe didn't complete all the way through successfully. That's why all the checks are you want to make sure the OU exists. If it does, move on, see if the next OU exists. If it doesn't, create it. And then we'll get to the point where it's going to create groups, create users, and then perform add users to groups.
This is to create activity. It's going to create an organizational unit. Again, this is if the root migration OU didn't exist. We can then go ahead and create all of the additional child OUs within that OU. We're not going to step through all of these.
We're just going to take a look at a few of them here at the beginning of the Workflow. You get an idea here what the Workflow is trying to accomplish.
Again, this is a lot easier than maybe looking at a very lengthy script that's going to be accomplishing the same thing. Everything's nice and visually available here. You can double-click on things, look at the properties, see what they're doing.
Here's a Search activity. It's searching for groups with the name of migration DA. This needs to be a domain-wide search.
If the object exists, save its object GUID. If the object already exists, don't do anything. On the other side, if the object GUID does not exist, that means the object needs to be created. We specify the OU where the group is to be created.
We're going to repeat this step for user objects for migration service account. And we specify the OU with the domain name parameter. There's the username and then what are the initial set of attributes that we're going to populate on the user once it gets created. Again, there's that password parameter value.
We're going to then take a look and find the migration DA group again. And this is going to add another group to that migration DA group, do a little group nesting. It's also going to add the newly created migration service account. We're going to want to do is search for that service account specifically, which will return the distinguished name of that user. And then there's an Add to Group Workflow step that's going to use the found object from that search activity and add it to this group.
We can kick off the Workflow. Since it's an Automation Workflow, we can kick the Workflow off by right-clicking on it. This Workflow is going to be run against the oneid.lab domain. As you can see off the route of the domain, there is no migration OU. So we're going to right-click on this and say Run.
Here's the parameter. It's going to prompt us to select which domain would you like to run this Workflow in. I'm going to select the ONEID domain and click OK.
And then we can look at the run history. It's completed. All those steps actually ran that fast.
Here's all the Workflow steps that executed, all the results of the Workflows. We just quickly spot check for any errors. Looks like the Workflow ran great.
Nothing's highlighted in red here. We can go back to the domain and refresh it. We'll see that we now have a new migration OU off the root of the domain.
Within that, there's a couple of other OUs, one for our migration DA group that got created. There's our service account. If we look at the Member of tab of this service account, we'll see that it was added to the migration DA group. And then that group that created is now a member of the Domain Admins group. All that was handled by that Automation Workflow.
this demonstration will show how a Change Workflow is able to intercept a user Create request and adjust the value for the user's homeDirectory location based on a part of the user's last name. Once complete, control is returned to Active Roles to process the user creation. A post-create step is then executed against the newly created homeDirectory to create a standard set of subfolders.
Here's the change Workflow that's going to initiate on the creation of a user within a specific OU-- so all users that get created it in that OU. Here's an If-Else branch that has four branches to it. I stand corrected. This is going to be based off of the user's first name, not last name as said previously.
So based on the user's first name, we'll take a look at the first letter, and we'll see if it's A through an F, uppercase/lowercase doesn't matter. Here's G through L. We want to run that branch-- M through R, and then S through Z.
Since this is executing in the pre-execution phase, we are able to insert home folder information into the request so that once this step completes, this home folder attribute is populated and then sent to Active Roles for processing. We can see here that the folders for users is different based on their first name. We're going to go take a look at the user's home folder directory. Here's the four folders that house the user's home folders.
And there's the post-execution phase script that's going to run to create some additional standard set of home folders. Here's the script itself, create home subfolders. It's a pretty simple script. It's going to create a document and files folder underneath the main user's home folder.
So let's step through the process here of quickly creating a user. We'll specify an employee ID, first name, and last name. Click the Policy Generate button there.
The provisioning policy generates the same account name for us. Another policy is generating the dropdown list for the Department field. Have actor roles generate a complex password for us.
We're not going to create a mailbox for the user. We click Next here as the user gets created. If we take a look at the properties of Bob, we're going to take a look at his Profile tab.
And then we can see that the U drive is now mapped to the A through F folder because his first name begins with the letter B. There's the Home folder. There's the two standard set of subfolders.
Just for completeness, we'll run this again with a user with the first name in a different location. It begins with the letter M, so we'll see this folder-- or I'm sorry-- this home drive getting created under the other set of folders based on the first letter of the first name. We'll finish out this user creation request. We'll see that Mary got created. We'll find her account here.
Just quickly look in the properties. Go to the Profile tab. We'll see now that it's under the MR folder for the home folders. If we go back to home folders here, MR, now there's Mary's folder with the standard set of subfolders.
This is just a quick review of the provisioning policy that helped link that script to the OU. This policy does provide some information to Active Roles, but what this change Workflow running that If-Else branch in the pre-execution phase does is helps complete that home folder path in order to determine where to create the home folder.
This demonstration, we'll show how a Change Workflow is able to follow up a user's deprovisioning in the post-deprovisioning phase by searching other domains for a matching user and also deprovisioning those found users. The same can also happen on undo deprovision action. Say the user returns to the organization. All of their associated user objects can also be un-deprovisioned.
We take a look at the change Workflow here. The start conditions are on deprovision of a user. We'll see here that this Search activity step is in the post-execution phase. So what would happen first is the user that is to be deprovisioned will get deprovisioned under the execution area. Once that is complete, Active Roles then runs a search, searching for some very specific criteria.
And then it will issue the deprovisioning of the user that was found. And here's another Workflow step for the undo deprovisioning. It's essentially the same type of Workflow with a Search activity that's now looking for the deprovisioned status set to 1, which is an internal Active Roles control to indicate that the object was deprovisioned. Active Roles does keep track of which objects were and weren't deprovisioned, so it won't let you perform an undo deprovision action on an item that actually wasn't truly deprovisioned by Active Roles.
We have a user here that we're going to take a quick look at. We'll just take a look at some properties. So that was the matching account for Barbara. The main object ID-- or I'm sorry-- the main object or the home object for Barbara is actually in the ONEID domain. We'll see they have matching employee IDs.
If we deprovision the ONEID user for Barbara, see that Active Roles is going to deprovision the object. And then what also happened is it searched the other domain for a matching employee ID for Barbara. So we can see the ONEID object got deprovisioned. Here's the terminated users OU. If we refresh, we'll see that automatically her associated user object in another domain was also deprovisioned.
We can also initiate the undo deprovision on either one of the objects. if we un-deprovision that one, we can see that now that it's been moved back, basically plays back the deprovisioning actions. If we go down to the ONEID domain, we'll see the Barbara object is no longer under Disabled Users but has been re-enabled and placed back under the normal United States users OU.
This demonstration will show how an automation Workflow is able to search for users whose password is getting ready to expire and send them an email reminding them of the upcoming password expiration. Here is an automation Workflow with one large search activity in it. We are searching for users specifically in the enterprise users OU. No other conditions-- we just want to find all users.
Every day, this is going to search all users. Here's an If-Else branch. We are looking at the built-in attributes, MSDS user password expiry, time computed. And we're setting that against a script. A script is calculating some date/time values for us that are relevant to when the Workflow is actually initiated.
The password is set to expire in less than one day. Here's the If-Else branch for that. We see we also have some nested If-Else branches within the If-Else branch.
Here's a notification step. The notification message-- we'll see how the email itself can be customized. Save Object Properties is the value of the first name.
This is to help personalize the email. Then the message is, your password is either expired or getting ready to expire in the next 24 hours. That's the message the user will see if their password is within 24 hours.
This is how the Save Object Property can be used to help find attributes to be used in notification emails. Here's the various scripts that run that return very specific date and time references. That's add one day, so that would be two days. Here's seven days. This can be useful for helping return multiple date/time values to compare against.
This is being run interactively, but this would normally run on a schedule basis. We can see that this one Workflow step did find somebody. What we're going to do is take a look at that user's inbox. Here's the email that they just received. That was done from the Automation Workflow for password expirations.
I want to thank you for your time during this Active Roles deep dive presentation. I hope you learned a lot. I enjoyed putting this presentation together.
[MUSIC PLAYING]