[MUSIC PLAYING] Two degrees of automation to create the perfect identity lifecycle with Active Roles. My name is Eric Hibar. My partner in crime today is AJ Lindner. Let's go ahead and get into it.
So today we'll be talking about how to use Active Roles to create user accounts in an automated fashion. We'll be using it to partially automate the process, i.e. create user accounts using manual input from HR staff to essentially put guardrails around the process. We'll show you some extra automation around that process as well, putting users into certain OUs, adding them to certain groups, and putting approvals around that process. And then AJ will show you how to fully automate that process using the Sync service.
So what I'm going to do is I'm going to run through a demo, and I'm logged in here as Adam Strong. Adam is going to create a user account as if he is a HR user. And so he creates a new user in the enterprise users container. Now autofill the person's first name and last name. I type in their employee ID manually, and then I can go ahead and manually select their manager. Now, this can be automatically selected if you'd like, but I just go ahead and manually select it for demo purposes here.
Now if I select the lightning-bolt icon, that automatically enters in the person's username, and then the dropdown menus allow me to select their department, job title, and office location built on policies that we've put into the product. I can then generate their password, select their Exchange mailbox to be created, and now the user account is created.
So now if we go to the Information Technology OU, can see that David Miles has been created there in that particular OU. Even though we created him in the previous OU, he's been moved here to this OU.
Now if we look at his organization information, all of his information there is filled out. Additionally, if we take his group membership and look at that, all of that has been filled out as well. So if you look here, he's been added to the Information Technology group, AllUsers.Chicago, and then the Employees group as well.
So how did we accomplish all of this? The first thing that we did is we applied access templates to the users which are creating the user accounts. Access templates delegate least-privilege access to end users over the objects which they need to create or manage. For example, it might provide your HR staff limited CRUD permissions for enterprise users. It might provide IT support group membership permissions. It might provide group owners access to manage their own groups, for example.
Managed units allow you to organize Active Directory and Entra ID objects basically however you want. We refer to them as sort of virtual containers or virtual OUs. They utilize dynamic real-time queries to add and remove user objects, computer objects, really whatever you want into their structure and allow you to visualize the directory in an entirely new and different way than you would be able to achieve natively by using just your standard OU structure in Active Directory. So we can group your enterprise users or groups, computer objects, essentially whatever else is in Active Directory into these dynamic containers here. The other cool thing is that you can assign access templates to these managed units for least-privilege access.
Provisioning policies allow you to set up guardrails around the creation and updating of Active Directory and Entra ID objects. It allows you to validate attributes around rules, essentially stating that you can or cannot have certain values within a certain attribute, for example. It allows you to generate attributes behind the scenes. It can create and assign some entitlements like mailboxes or home folder shares. It can also utilize scripting for some more advanced features.
Dynamic groups and group families-- dynamic groups work just like managed units but for group memberships. It essentially allows you to add and remove members from a group in real time based on highly configurable queries. You can add or remove people based on whether or not an attribute equals a certain value, for example. You can even write things like LDAP queries to allow people to be added and removed from this group in real time.
Group families work in a slightly different way. It allows you to create groups and assign memberships based on certain attributes that exist within a scope. It runs on a schedule. It's a bit of a slower process, but that means it's great for bulk tasks and bulk changes or frequent changes. So as an example, a distribution group for every manager. But as I mentioned, it is based on a set of attributes, but you can filter based on, again, LDAP queries.
A change workflow or an OU assignment, as we saw earlier when I created the user, I created the account within a parent OU, but then it shuffled the user into its appropriate OU based on the department value that I set. So a change workflow in this context detected and responded to this change, or in the context of Active Roles, could be any change occurring in Active Roles that can process the actions before or after the change. For example, it can set the user's creation container before they're created in AD.
Now in this particular example, I'm again logged in as Adam Strong, and we will take David Miles's account. We're going to look at his group memberships. Here, we can see that he is, again, added to AllReports.Aliyah.Duncan, AllUsers.Information.Technology, the Employees group, so on and so forth.
And now if I look at his Active Directory properties, we can again see that he is in the Information Technology OU. Everything looks to be in order there. But if I take his department and I change that to Engineering, we'll see several things occur. Now, if I look at, again, his group membership after I make that change to his account, we can see he was automatically taken out of the Information Technology group and added to the Engineering group. And additionally, if I look at his properties again, we can see that he was removed from the IT OU and then added to the Engineering OU.
So now a change workflow can be kicked off during any change within Active Rules. It doesn't necessarily have to occur because I attempt to add a user to a group or a specific group or anything like that. It could occur because I check a box in a user's properties or I change someone's department from accounts payable to accounts receivable, so on and so forth. So in the context of this demo, we can require approval from the group owner before membership is updated. We can move a user to a new OU after their department is updated, so on and so forth. But now we will move to a different demo.
And so, again, we will take David Miles, and this time we will take his account, and we will deprovision his account. And so this is going to prompt us for change approval. We will put in our reasoning, and then that will be sent off to the approver.
Now, the approver in this case is his manager. And so we are logged in here as Aliyah Duncan, as we can see there. We go to the approval tasks that are in our user profile here, and we can examine this task. We can see who requested the operation and what the reasoning is, the date and time of the request, the approval progress, the details of the request, and all of that. And then we can approve or reject and then enter in our reasoning as well, which is optional. Sure, why not?
So that will then deprovision that person's account, and now we are back as Adam Strong. So now if we go out and find David's account again, we'll see that several things have occurred, and several changes actually have occurred to David's account. So if we look at the deprovisioning results, if we expand all of the report or the entire report here, we can see the completion reason. We can see that the account was deprovisioned. It was disabled. Certain properties were changed, like the description was changed to deprovisioned on such and such date. He was removed from any and all security groups. It was relocated to a new OU. For example, it was moved to the disabled users OU. And so it will also be marked as permanently deleted after a certain amount of time.
But we can also undo the deprovisioning of any object within Active Roles. So we can even leave the password unchanged after we scrambled it, and so that will undo everything that we've done now to David.
So now if we go back to his general properties, we can see that he was moved back into, in this case, the Engineering OU, where he came from initially. And his manager is back. His job title is back, all of that. It's basically like nothing ever happened. If we go back to his group memberships, all of his groups are now back as well.
All right, so how did we accomplish all that? So the deprovisioning policy is essentially a one-click automation to remove the user or group object appropriately. So we do have deprovisioning policies for both user objects and group objects as well.
In the case of this demo, the user account could potentially be disabled. We can change certain attributes to other values. We can remove the group memberships from the user, with certain optional exceptions. We can reassign access to the home share and exchange resources-- for example, assign the new owner to their manager. We can schedule the account for permanent deletion after a certain time period. We can send notifications to downstream parties, such as their manager or other administrators. And then, of course, as with anything, you can extend this with custom scripting.
So all these concepts and features that we just saw in Eric's manually driven process still apply when we're ingesting that same data programmatically from a source like your HR system, as we're about to see with the Active Role Synchronization Service. So this is our Sync Service workflow for synchronizing users from our HR system into Active Directory. This is something that you may typically run on a schedule, but in our case, I'm just going to manually kick this off now so we can see the results as we go through it. We're going to do a full run here without automatically committing the changes, which, as we'll see in a moment, will give us the chance to review everything that is about to be done before actually letting it commit into Active Directory.
Right now, it's running its initial synchronization steps for creating, updating, and deprovisioning user accounts. And as part of that, it's creating mappings. So it's determining, based on the rules we've configured, whether an object needs to be created, whether it already exists and might have changes that need to be updated, or whether that user needs to be deprovisioned, in our case, based on matching employee number to the employee ID attribute.
Now, like I said, before those changes go through, we can actually look through and see all of the attributes that are going to be stamped when this user is created. In our update step, we can see all the values of every attribute that is going to be updated. In fact, it will also show us the original value as well. So we can see this user is moving from the sales department to accounting and finance. They've got job-title changes as well as location changes.
And, of course, we can also view the users that are about to be deprovisioned. In my case, this will happen if their status in the HR system has changed or their Active attribute has changed from true to false or if they've otherwise dropped from the file.
Once I've confirmed this, I'll click Commit and let it actually push those changes into Active Directory. And once that's finished, we can go back and confirm everything that we expected to happen actually happened, that there weren't any sort of errors or policy violations that stopped this from completing the way that we expected it to.
Now, of course, if you were running this on a schedule, this whole check and commit step wouldn't typically be occurring. It would just commit the changes automatically with certain thresholds, certain alerts, or certain reporting if it encounters some sort of error, depending on what you've chosen to configure.
So here is what that HR Sync Service workflow looks like. It's just a set of steps that I've configured in order to create Active Directory user accounts, make changes to those user accounts, and eventually deprovision those user accounts based off of the data in our HR database.
And here, for example, is what that creation step looks like. We're using our HR database, which is just a SQL database, as our source system. And we've got a filter on the creation criteria to make sure we're only going to create user accounts if the Active field in that HR database is set to true.
Then our target is Active Roles. We're going to be creating a user object in the staging container of the oneid.lab domain. And as part of that creation, we're going to use the employee_number field from the HR database as our unique name attribute in Active Directory.
And then, finally, we have a set of creation rules that determine what values we're going to write to various Active Directory attributes. Some of these are simple direct mappings, like the employee number from the HR database is getting written directly to the employeeID attribute. Some of these might use a rule to manipulate those attributes appropriately, such as for the language attribute where we're replacing an in the language string from the HR system with a hyphen. And some of these might need a little more advanced manipulation, and we can utilize PowerShell scripts to make whatever changes we want. In the case of the manager attribute, the HR system has the manager's employee number, but in order to stamp that on the Active Directory account, we need the manager's distinguished name from their Active Directory account. So we have a simple PowerShell script to locate the managers Active Directory account by searching using their employee number and returning the distinguished name so we can put it in the manager attribute.
And, finally, we'll finish up with some best practices if you are going to implement lifecycle management using Active Roles in your environment. First, as we saw, especially with the Synchronization Service, it's good practice to use a staging OU specifically for the initial creation of user accounts. This allows for you to have separate administration policies that have different requirements for an account being created versus when an account is later being modified. For example, you might want to require that password must be changed at next logon anytime a new account is created, but you certainly don't want to require that every single time a change of any sort is made to that account in the future, and this is a great way to ensure that you can separate those policies.
And remember, it doesn't matter what OU the user account is initially created in because, like we saw earlier in Eric's example, we have a change workflow in place that will appropriately relocate that account to the OU that it actually belongs in.
Another benefit is this also helps abstract the directory structure from your delegated users, which you can also supplement with the use of managed units. Your HR team shouldn't necessarily need to care or know where to go in the actual directory structure to create or find user accounts. Well, we can use managed units inside of Active Roles to provide them views into that data without them having to know the ins and outs of Active Directory, and they can more easily meet their requirements.
Also, just to note on the Synchronization Service one of the things that has to be provided from the source system or otherwise generated is going to be that unique identifier used to stamp the name or CN attribute. So best practice here would be to utilize what we know already as a unique identifier from our source system, or if there's a chance that might not already be unique, use a combination of options that it can try in order. You can always use something like a change workflow in order to make changes to that name after the fact once that account has been created initially.
And finally, most importantly, we want to make sure we are very carefully and appropriately delegating access so that people like our HR staff who might be going in and creating user objects or making changes to user objects are limited only to the scope that they actually need to do their job, and combining this level of appropriate access with all the other features can create an incredibly streamlined process that's not only more secure, but significantly easier for those delegated users.
With that, thank you for joining and checking out this webinar session. As always, if you have any questions about this or any other One Identity content, please feel free to reach out to One Identity.
[AUDIO LOGO]