Hi. Welcome to the session on Active Roles requests. I'd like to take this opportunity to thank you for joining me as we take a peek under the hood of Active Roles. In this session, you will learn how Active Roles users request to execute operations. You will also learn about how Active Roles processes the requests and how they can be manipulated to improve efficiency and performance. Having an understanding of how requests work will allow you to get more out of Active Roles. We've broken this session down into multiple sections to walk you through this.
What we'll start with this an introduction. We'll go through some request basics, then look at some basic requests, followed by request processing, modifying the contents of a request, modifying the behavior of a request. And then we'll have a look at some nonoperational requests. These are special types of requests.
Firstly, I would like to take this opportunity to introduce myself. My name is Chris Rudd. I'm one of the customer advocacy representatives for One Identity in EMEA. I've been working in the IT sector for over 35 years, with 20 of these being in a consulting capacity. I've worked for One Identity and Quest for the last 14 years, the first three in a consulting capacity, and the remaining as a practice manager running a consulting team, finally, before switching to a customer advocacy role.
So today, I'm going to walk you through the requests, which are fundamental to the way Active Roles works. So just for those that don't know, we'll just cover the Active Roles architecture. It's a request-based solution. So you may not know this, and it may not be visible. But clients send requests to an administration service. And the administration service processes the requests.
Basically, the app in service does all the work. So clients leverage the service by sending the request. The admin service executes the requests on the network datasource and returns the results. Active Roles is a three-tier model solution-- presentation, application, and data. And we refer to the data layer as the network datasources.
The key point to understand about Active Roles is that clients send the request and the admin services does all the work. Just to highlight this, here's an overview of the architecture. So clients use Microsoft's ADSI provider, LDAP, to access Active Directory directly. Active Roles has its own ADSI provider, EDMS, which allows clients to access Active Roles the same way that the LDAP provider allows clients to access Active Directory directly.
The Active Roles ADSI provider is basically based on the Microsoft LDAP provider. We just add some extensions. The core of the Microsoft ADSI provider is AIDS.H for those that are interested. And you can look that up on Technet or other Microsoft sources. For more information on the Active Roles, the ADSI provider can be found in the SDK that was shipped with the product.
Let's have a look at some request basics. When requests are sent to Active Directory, you have no control over a request. It's sent, and you get a response. It's kind of like going to a web page. You click on the link. It takes you to the page. What's really happening under the covers is you're sending a request, and you're getting a response back.
When a request is sent to an Active Roles, you can control the request. The requests in Active Roles support the same basic properties as Microsoft requests and the same basic methods as the Microsoft ADSI provider. But the Active Roles ADSI provider gives you a lot more. So here's a quick overview.
I'm not going to go into every property or method because there's just too many. But what we're going to do is look at some key ones throughout this presentation. It's just to give you an insight into the value add that you get from Active Roles about the native functionality offered by active directory.
So when considering request types, most people think of the [INAUDIBLE] operations. In addition, Active Roles supports a number of other operation types. So in total, we actually support 11 types of requests. And we divide these into two categories.
Now, this is just a logical categorization. There's no strict coding or anything like that. But we talk about it in terms of operational requests and nonoperational requests. Operational requests perform an operation on a network datasource. They have an operation ID. And examples of these are Create, Delete, Set, Move, et cetera.
Nonoperational requests don't perform an operation on a network datasource. They don't get an operation ID. Some examples of such is Get, GetEffectivePolicy, and CheckPropertyValues. As I say, we're going to dig into these in a bit.
So when Active Roles receives a request, there are a number of key stages in request processing. Active Roles always performs a security check first regardless of the request time. For operational requests, the processing is always pre-processing, operation execution, and post-processing. And if an error occurs at any of these stages, then the ADSI provider sends a response back straightaway.
For a nonoperational request, the processing may just simply execute a function such as GetEffectivePolicy. Or others might do pre- and post-processing such as [INAUDIBLE] search. So not all stages are required for all the nonoperational requests. We can use policies and workflow to modify the contents of the request. And we could use controls to modify the behavior of the request.
So here's a quick overview of how request processing really works. So first, that user permissions are checked. Work flows are executed in the pre stage. Policies are processed. The operation is executed. Policies are processed in the post stage. And then workflows are executed in the post stage.
Having a better understanding of how this actually works will help you when you're implementing Active Roles and maintaining it. So for instance, you can't rely on values set in policies in the pre stage during a workflow because the workflows execute before the policies. When creating or modifying objects, it is best practice to minimize the number of changes to the object. For example, when creating a user, it's best to set as many attributes as possible at the time of create rather than doing a create request followed by multiple sets.
In Active Roles, whenever you do anything, there's never a single request. If you look under the hood, you will see that there's always lots of requests going on. Just the getting to the point of making a request involves lots of different requests under the hood. So what you'll find is the interfaces are doing searches, gets, checking effective policy, checking compliance, getting more data, creating an object, and then continuing on. So the admin service executes each of these requests independently as separate, isolated requests. But they're all formed in a chain to provide an operation
Active Roles has a concept of subrequest. Effectively, subrequests are just new requests. We refer to subrequests as a request made during the execution of an operation. So a good example of this would be a script policy that updates an associated admin account when a standard account is updated. So with subrequests, it's important to understand that the admin service-- it starts processing the initial request to update the standard account, in this example.
The script policy would then kick in and initiate the request to update the admin account. The admin service would fully execute the admin account request. And then it would complete the request to update the standard account. So the subrequest is fully updated before it finishes the standard account updated. And you can have multiple requests during an operational request.
So before we go into the demos and show you some of this functionality, I just want to give you a quick overview of the configuration. So we've got one OU first for each specific demo, containing a basic user account. We've got some basic policy objects linked to the OUs and some basic workflows scoped at OU level. And we're using simple PowerShell scripts, using the Active Roles' commandlets to execute most of the requests.
So we're going to start off with some basic requests. So for the virtual Unite, we're going to just show you one example, the multiple requests example. In this example, what we're going to do is show you a short demo of making two changes to the same object in separate requests. Again, we're going to use a PowerShell script. Only out-of-the-box policies are applied. And the whole purpose of this is just to show you that two requests are processed separately.
In this demonstration, we will make two requests to change the same user object. The change will, again, be made using the Active Roles management shell and a PowerShell script. If we switch to the MMC and open the properties of the user object, we will see that the description and the office location are not set. Let's switch to the script that we have prepared.
The script simply gets the user object and then pipes it to set QAD user, first to update the description, and then again in a second time to update the office. Lets execute the script. What you'll see is the script has been executed and two changes have been made to the user object.
If we switch back to the MMC, we can refresh the properties and then open them again. And then we can see that both the description and office location have been set. If we look at the change history for the user, we'll see two different operations, both for change user. And if we expand them, one is for the office location. And the other one is for the description.
So now we're going to have a look at a demonstration of request processing. So for this demonstration, we're going to show you the pre- and post-processing order in action. So what we're going to do is submit a request to change an object with both a policy and a workflow link. The change will be made using PowerShell script. What we're going to do is we're going to use the admin policy to set the office attribute. And the workflow policy will write entries to a log file. The reason we're using a log file in this example is just to show you the processing order a little bit better.
In this demonstration, you will see how Active Roles processes policies and workflows. We will use Active Roles' management shell to make a change to a user object, although the change itself is not important. We have a policy and a workflow linked to the OU where the user object resides. Both the policy and the workflow execute scripts during the pre- and post-processing stages. This is purely to show each state in the change history.
Let's switch to the script and execute it, a simple script just to make an update. And we're going to execute it. That change has now been made. If we switch back to the MMC, we refresh the user object and then view the change history.
If we expand the details, we now need to look at workflow activities and policy actions. What we'll see is the workflow scripts run first followed by the policy script in the pre stage. And in the post stage, it's the policy script that runs first, followed by the workflow. Here, you can clearly see the policy processing order.
So in the next demonstration, we're going to look at modifying request contents. In this demonstration, you'll see policy- and workflow-based modifications. So we're going to send a request to change an object with both an administrative policy and a workflow applied. The change is going to be made by the script. The administration policy will update the office attribute. And the workflow will update the address details based on the office location. And this is just to show how administration policies and workflows can be combined to simplify administration.
In this demonstration, we will see both workflow- and policy-based modification. If we take a look at the MMC, we have a user and an OU. We have a policy linked to this. And if we take a look at the policy, you'll see there's a couple of simple rules, the most important one being the property generation and validation rule, which is setting the office location to be the same as the description.
We also have a workflow associated with this OU. If we expand it, the workflow contains some logic, first to check the description has a value then update the office attribute accordingly. And then it checks which location has been set. And then it updates the address details accordingly.
If we switch back to the OU, now if we go to our script that we prepared earlier, we can send a modification. That's been completed. We come back to the MMC, refresh the user, look at the properties. And we see both the office and the description have been set. And if we check the address, we see the address details have also been set. If we look at the change history for the user and then expand the properties during this operation, we'll see all the attributes that have been set during this request.
So next, we're going to take a look at how to modify request behavior. So in this particular example, we're going to change the behavior to use a specific domain controller. So we're going to send a request to change an object. What we're going to do is execute the operation on a specific domain controller. This is useful when changes should be made closer to the user and you don't want to wait for replication. Now, I must admit, I've kind of cheated in this demo because I've used an alias for the domain controller.
In this demonstration, we will make a change to a user object. We will modify the request processing to get Active Roles to execute the request on a specific domain controller. We have a demo user here, and it doesn't have a description. We'll update the description. And during the request processing, we will use a workflow with a custom activity, which is going to set the domain controller to be a specific domain controller.
Let's go back to our OU. Switch to the script. Make the change. Change has been completed. We go back to the user. We refresh. Now, unfortunately, if we look at Change History, it does show details of the operation. However, it doesn't show which domain controller that the request was executed on.
But we created a custom log. And if we were to take a look at the log, we can see the original domain controller is WINEMEADC01. And then after we execute the custom activity, it's been changed to dem08dc.
So now we're going to take a quick look at nonoperational requests. So in this particular example, we're going to use GetEffectivePolicy. So GetEffectivePolicy allows clients to query the administration server for compliance data. So when you create a policy rule, such as a property generation and validation rule, Active Roles uses this information to generate compliance data for each object. Active Roles clients can access and update this information using a couple of functions called GetEffectivePolicy and SetEffectivePolicy.
In this demonstration, you will see how Active Roles clients can request effective policy information from the Active Roles administration service. If we switch to the MMC and go to our demo OU, you'll see there's no users. Now, in addition to the built-in policies, we have one specific policy applied. And this contains a number of property generation and validation rules. Specifically, we're going to look closely at display name, logon name, and account name, in this example.
Now, in order to show this clearly, I've created a custom utility that's going to walk us through the process. So what this utility does is bind to the OU and create a user in the property cache. It then adds the first name to the property cache and calls GetEffectivePolicy information. It then adds the surname into the property cache and repeats the call to GetEffectivePolicyInfo
Lastly, it adds the UPM prefix to the property cache and calls it one final time. You will notice the admin service returns a number of values, specifically for display name and UPM prefix in the first two examples. This is because the first name and surname are used to generate these values. Therefore, it can generate a value for both the display name and the UPM prefix.
The Sam account name is empty in the first two because the UPM prefix is not in the property cache. In the last example, we've added the UPM prefix to the property cache and recalled it. And now we see a value generated by Active Roles.
This concludes this demonstration.
Thank you for attending this session.
18:21