[MUSIC PLAYING] (SINGING) Doo, doo, doo, doo, doo, doo
Doo, doo, doo, doo, doo, doo
Good afternoon. So my colleague--
Raul D'Opazo.
[LAUGHTER]
Reto Bachmann, we will have the presentation around Red Forest, how we can help customers by introducing another concept of Red Forest or helping to migrate from existing Red Forest environments. So the agenda shortly is, first of all, a short introduction of how we can help with Active Roles to migrate or to, let's say, replace the existing ESEA concept of Microsoft.
And then my colleague Raul will present a customer example, how he did on a real customer example, a concept for PAM together with Active Roles. And, after, I will also present how we implemented on a huge finance company this Tier0 concept with Active Roles without the Microsoft concept in the end.
So, first of all, who knows about the ESEA concept? Just one? [LAUGHS] So this is the concept or, let's say, the official way of Microsoft to have a tiered concept in Active Directory. The former concept, which you can see, it has retired, by Microsoft, was very complex. So, in the end, you had to have different forests in place for the Tier0, Tier2, servers as well users.
And one of the requirements was also to have a MIM in place to synchronize the so-called Shadow-Principals between the forests. And, also, MIM, the support, will end by '26 with extended support. So, for normal customers, the support in the end has ended.
And the other one is for LAPS, which also has not any development since 2020, which is also part of this concept. There is no announcement or no information from Microsoft how they will go further with this different technology they are using.
There is a new concept from Microsoft, how to implement a tier concept. There the problem is, it still covers AD. And for Azure Active Directory, or now Entra ID, you need this PIM concept. So there are two different concepts in the end. It's not something common. And it's also time-cost intensive.
And, also, you need a lot of things to do, and it's not really easy. So, in the end, for a customer which is using the old one, which was not easy to implement, has now to go to another one, which also not so easy to implement. And that's the reason why we have customers, they went to us, and we help them now to either migrate or to show them how we can do this better.
How or why Active Roles can help here? So, first of all, Microsoft-- or, Microsoft-- Active Roles is doing this concept since ever, since Active Roles is on the market. And Active Roles is on the market since Active Directory is there. So it was the first product in this space on the market.
And what Active Roles can do or handle in the end is, first of all, we can manage this Shadow-Principals in one single product in the end. So you don't need any other things to do. It's in Active Roles. You can manage it from there as well.
And the other thing is, Active Roles has a sync engine, and the sync engine is much powerful than MIM. And by site, it's still supported. It has much more connectors. So you have the possibility not just to synchronize in the end, the Shadow-Principals, you can also synchronize other things, exchange. You can synchronize to cloud with our Starling platform.
And one thing a lot of customers are using also since a long time is they are using the sync engine of Active Roles to keep the productive and the test Active Directory in sync. So they sync constantly the productive and the test Active Directory with this sync engine, which is part of Active Roles. Customers have it, so they don't need to buy any additional product in the end. So this, in the end, helps to replace it.
And if you are not too tired after this session and you join the next session, we will show you how we can, together with Safeguard, provide a possibility to replace also the LAPS concept, but much better, much easier, and much more secure. So this is, in the end, also the integration or the benefit of having more than just one product of One Identity.
So for those who were not in touch with this ESEA concept is that, when you do this old concept, you have to install or extend your schema, which, in the end, in the configuration container, adds this Shadow-Principals, which is, in the end, a hidden attribute. You will not see it in the normal Active Directory.
And, in this, in the end, Shadow-Principal, you store the accounts which are allowed to work in the different tier models. And this can be managed by Active Roles without any additional things. So you don't need to install or configure anything. So this is the first step to help existing customers to get rid of MIM and all this other stuff in the end.
And how this looks like in the end in Active Roles. So in Active Roles, by site Active Directory, the domains, you will also see the whole configuration partitions of the different domains. And there you see this Shadow-Principal extension.
And this can be managed directly in Active Roles. So you don't need to open up the ADSI Edit or any other tool. You can go directly there and you can manage the existing accounts. You can add accounts, you can remove accounts directly in the console without going to any other product, without any sync, whatever. So it can be done directly in here.
So now you have the account in this Shadow-Principal. And, as you can see here, the domains, these are non-joint domains. So Active Roles can handle multi domains, multi forests without trusts between. So this is also a function which is there since ever, which is used by customers also since ever.
So we have customers with over 60 Active Directories managed in one console. So this is very, very powerful, and it's very easy. And, as you can see here, you can manage much more than just the normal Active Directory. And this is the first step of helping existing customers to migrate away.
And the other option, as I said, is you can use the Active Role Sync Engine to also synchronize then all this information and can get rid the MIM in the end for all the synchronization stuff. And customers having other requirements, they can use then the Sync Engine also to do many other things.
So I'm not allowed to say this, but Active Roles, in the end, is a lightweight, not identity management tool, but it goes in this direction because you have a lot of possibilities in Active Roles. It has provisioning function in it. It has security function in it. So these are the two main, let's say, functions of Active Roles doing this delegation.
And the other one is doing this provisioning stuff in all Active Directory, Azure Active Directory, as well, AD LDS, a lot of customers using AD LDS, for example, for externals for customers, which they don't want to have in Active Directory, but they want to have an LDAP where they can store the external accounts.
And, also, in Active Roles you have the possibility also to graphically manage the AD LDS instances. And this is also another benefit of Active Roles. So there are a lot of benefits in the product itself, which are there since ever, which can help customers keeping their Active Directory as well, Azure Active Directory secure.
So now I pass over to my colleague Raul, which will explain his project he did.
Yes. Yeah, I'm going to speak a little bit about a customer request that I had a couple of time ago. And, again, it was all about security. We all know Active Roles. We all know that the delegation model is really easy to implement and it provides a proxy and firewall to manage a Active Directory objects and Azure AD.
But, in this case, the customer wanted to go ahead at the end. We have been speaking many times about zero trust model, less privileged access model, just-in-time privilege that we can also cover with Sidecar integration.
But, in this case, they didn't have Sidecar. They were managing a huge AD environment with many departments, many IT staff, and they just wanted to go to a more secure zero trust model in the delegation.
So the idea was, OK, why not? I mean, having in mind that, OK, Active Roles is a management tool. Of course, we need to implement an MFA, and it's possible to add an MFA into the web interface. So we can be sure that the people that are logging into the web interface that are who should be.
And the thing is that, OK, why to provide to you a permissions to create accounts 24 hours every day, every week, all the year? So the idea was to be really, really be more careful when the people from IT or from help desk needed to do something in AD. It can be create user, it can be change the department attribute, can be manager group, it can be anything. It can be a [INAUDIBLE], it can be a management unit.
The idea was to be at least a more-- have a control and granular way with approval workflows. So if I am an admin guy, I need to do something, just request the [INAUDIBLE] revision in real time. Of course, you see in different objects, different out-of-the-box feature that we have with dynamic groups, with workflows, add the user into the group and, automatically, the user will be able to do the task that it should be done.
And, of course, everything in temporal way because, again, we can use the temporary membership info that we have. So we can also remove these permissions over-- after the time that you will-- that's it. Five minutes, 10 minutes, one hour, one day, no matter who wants. So this was more or less the idea.
And, well, we did it really easily at the end. We were speaking yesterday in different Active Role sessions that with imagination and with really good knowledge of the product, you can do many things that maybe are not out of the box, but it can be really easily done, again, using virtual attributes, workflows, scripts, web interface customization.
And, again, what I'm going to show you is one example is more or less how I did this in this customer. It can be done in definitely, in other ways. So there is not always a simple or single way to make this kind of things. But let me show you all the preparation stuff that we did.
So, well, basically, again, I'm going to show you the requirements. We had to create, in my case, one single virtual attributes Boolean attributes in order to just have a request in the web interface. So the idea of this attribute is just to have a custom web command into the web interface.
Of course, I have managed a template-- sorry, an access templates to provide permissions over these virtual attributes because I only want to show this elevation rights to maybe only different people, not to all the company.
Of course, you can create here, you can have your managed unit structure. So you can see that there is a read-only and there is the proper access template with full control over users. So allowing all the people to read all these management units, and then the possibility to request access rights to this management unit through the virtual attributes.
After having the structure, you can have a simple workflow. You can do it with maybe also dynamic groups. In this case, I used a workflow with different scripts. Why? Because I wanted to go through the web interface, request something, so I had to get the initiator of the request.
So the workflow, of course, starts when this attribute Boolean will be OK. And then I should get the [INAUDIBLE] of the initiator because I have an approval workflow in the middle and this makes me forward to get this info before the approval workflow. Because, if not, the requester will be the service account of Active Roles.
So once we have the approval, we do the operation, we escalate, and then, well, in this case, this is an script to get the initiator again. So I will show you later the scripts. And then, of course, at the end, I run another script because the idea is to be able that, depending on the OU that I have request these rights, there are different groups in AD that are going to allow me to access the OU with enough rights.
So I have a simple script in this case. This one is to get the initiator that is running in the workflow at the beginning. That's a really simple script. I saved the initiator in a global parameter. And then you can see that the just-in-time elevation is really easily. It's just a switch. Depending of the OU, I select the group that I am going to add the initiator.
And the last part, of course, is how I can control the temporally-- to remove, in this case, after 50 minutes, I think, the user from the group. So really simple. It can be more professional, of course, if it can be done in different ways, but it's an easy way to show you how easily it can be to do these kind of things.
And from the web interface perspective, again, it's really easily. I only create one new command based on the virtual attribute that I created before, and I add this command into the OU object. So I go to OU and I create a new command. You can see that it's already created. But, again, maybe you remember, it's to create a new command, select the attribute. The command is based on an attribute change, that's all.
And I am not going to save this value because I only want to know that someone else is requesting something in real time. I don't really need this attribute to be stored in our database. And this is more or less all the preparation that it should be done.
And let me go and-- so this is more or less everything that I was explaining before. Of course, you have to have the security groups, management units, et cetera. And then, how it's look-- feel at the end is, the user, you can see Henar Garcia is a normal IT guy. It's only a member of the IT read all.
So this lady can read all the management unit that I have delegated through an access template. It goes to the web interface. She can see all the management units that are allowed to see.
And then, go to, by example, Users Spain, and then you will see that there is only one option, is get just-in-time access. This is the command that I create with the build var attribute. It's start the workflow.
If you remember, we get the initiator. This is an approval workflow in the middle. You can say here whatever you want to do. This is to have a really granular control about this rights permissions delegation. So the manager has to approve this delegation.
Now I'm going to log in with the administrator or the manager who has to approve. So we'll easily go to Approvals. And you will see here that all the information about the workflow is there with the regions. I can go through the approval workflow, I can go to the details of the approval workflow to see the specific OU that has been requested. You can see at the end the object. User is Spain.
And then, you know that Active Roles, the security model of Active Roles is really easily, and it's on real time. This means that as soon as you get-- or you are a member of other group, all the delegation model when you go through the web interface is check on real time.
So the next time, Henar Garcia, that in this case, through the script, it has been added, and you can see the temporal clock into this membership. So it's going to be removed from this group in 50 minutes, I don't remember, or 60, I don't remember it, but at the time that I wish we had decided.
And, again, because of the web interface model Henar Garcia directly, if she synchronize and refresh the view, automatically, she will be able, in this case, to fully control over this OU, in this case, a user objects. She will be able to create, delete, remove, et cetera.
Of course, you can see-- or the user can see or receive emails when this approval has been approved or rejected, and then go to the directory management and automatically synchronize and refresh. It's a question of time. Sometimes you have to synchronize, you have to refresh the view because sometimes, if not, you will not see the difference. But, as soon as you do, you go to User Spain, maybe refresh again. [LAUGHS]
And now you can see that-- and I can create new user and new special accounts. That is a custom command that we have for another type of accounts with other workflows, et cetera. So a really easy example that we can help in a tiering model because, at the end, if you think, in a tiering model is the concept of Active Roles is going to help you any way, I mean, the delegation model.
But going a little bit more, let's say, security and freight, in this case, for them, was-- for this customer was really important to control also that the admin guys will not be able every day, every week to do everything without any authorization. So now we can control with a really granular way how and when we delegate these permissions over Active Role, over AD or Azure AD. Well, that's all. I pass again my-- the pass to my colleague, Reto.
So my example, as I said, was a request from an existing customer, which is in the finance industry. So his, let's say, issue was to find an easy way that administrator can request a Tier0 account. The customer was in the middle of a PAM project but had not yet really a PAM product. And the AD guys were forced by auditors to do something. So they had to do, or to introduce, by their own a concept to really manage this Tier0 accounts.
And the idea was to do this over the self-service interface. What you have seen, what Raul was showing is the admin interface. So Active Roles has different interfaces. One is the admin interface, what Raul was showing, and there is a self-service interface which, in the end, is for a normal user where he can manage his own attributes, but he will not see the structure in Active Directory.
And the idea was also that the administrator, they don't see the structure, they just request a Tier0 account via this interface. And, similar to Raul's case, that we create-- or the user, which will be created in the end, will be member for a particular time into the group he can choose, like the schema admin, like the domain admin, so he can then automatically be removed after this time.
And, of course, the other one was that an approval is required. So someone has to approve it. So it's not a task someone can do by itself and no one knows it. It was really a requirement that the security group has to approve this request as well.
So what I will show you is similar to what Raul in the end was presenting, how to configure it. The difference is we created-- because I, in the end, developed this in my environment. And one of the key benefits of Active Roles is also for the people knowing Identity Manager, there is also a kind of a Deployment Manager, so you can export the whole configuration and you can import it into your productive Active Roles environment.
And this is also a very nice feature. So you can create all this-- everything you did in the end, you can create- it's an XML file in the end, and then you can import it into any other Active Roles environment.
So the first step is to import this deployment into the existing Active Roles environment. And for this, we have this configuration deployment tool which allows you to import any kind of extension done by anyone. So you need to add the packages there. Again, it's an XML file which contains everything.
And then you have to configure all the information. And this is an important thing, you have to replace the domain name because Active Directory is a bit picky about to import things from another domain. So here you can add the domain where you developed it or from the development environment, and then you can add it into the production environment.
So this will create, in the end, all the objects, like the virtual attributes, like the access templates. So everything you configured in Active Roles will be then deployed into the other Active Roles environment.
So this takes some times normally. So you can see the scripts, the managed units, everything will be imported into Active Roles. By the way, who knows Active Roles? OK. [LAUGHS] In the meanwhile, managed units-- managed units is a kind of, you can say, virtual OUs in Active Directory.
You have seen before, in the console, managed units are on top. You can put users, groups, whatever from different active directories in managed units. And managed units can contain all the objects by query, for example. So you can say, give me all the users, OUs from all my active directories and put in this managed unit.
And then, over this managed unit you can assign permissions what people can do in this managed units. And then you can assign user or groups to this managed units. So independent where a user is in your Active Directory structure, they will then have access to all the users groups.
But, in Raul's case, he was working with managed units. And if you have looked closely on the Active Directory top, he was not able to see the Active Directory structure. He has only seen the managed units. So this is also a way how you can reduce the view for normal administrators like first level help desk to the Active Directory structure in the end.
So now it's imported into Active Roles. And loading schema, by the way, means that Active Roles, as Raul also mentioned, is this is a proxy solution against Active Directory. So this is a real view on Active Directory. And, as you can see, all the configuration is on top. So all the managed units, the access templates, I did the same. I created an access template with giving exactly the permission I want to give to this user.
I also have managed units. One is for the administrators doing the approvals, the other for the request, and I also created a workflow. And this workflow, in the end, is handling the request of the user. And, also, I created some scripts, for example, also one which is generating the password for the user, which will be created after.
Then I have some attributes, a bit more than Raul, because I need a bit more for the request handling in the end. One is this Tier0 access request. This, in the end, is also a Boolean, which just goes if it's true or false. And this will handle, in the end, the view in the web console.
So if a user has not this access request template set, he is not allowed to see the request in the web console. So this is also something based on such attributes. You can make the view in the web UI dynamic, what the user can see and what not.
And, by the way, this virtual attribute, as it says, is not stored in Active Directory. You see this only with the Active Roles together in the end. But there are specific PowerShells where you can call against Active Roles, and then you see Active Directory and the virtual attributes.
So the next step is to configure the tab. So this is the configuration in the web UI. This is what, in the end, the end user will see so they can request this admin groups.
So, for this, we start the web front end. And, as I said, there are three web front ends which are deployed in the standard. You can create as many as you like. And this is the end user, or, let's say, the self-service UI in the end. And the nice thing is, you can configure this directly, customize this directly in the web UI. You don't need to write any code, so you can add an additional tab. We call them Reto admin request.
Then the next step is the visibility, so who can see this. And, for this, we need this Tier0 access request attribute. So this one allowed. And, if this is true, then the user is able to see this in the end when he opens the web UI. Otherwise, the user will not see this tab in the web UI. So refresh.
And in the next step, we have to add the attributes we want to give the user to request in the end. So I added some of the attributes. And you can add any kind of attribute. And you can build your own tabs for any other reason. So it's a really nice functionality.
You can add the text to it, description, tooltip. You have also the possibility to set directly attributes to read-only. So you have different options here how to handle the attributes in the end. Then another attribute is also the, in the end, what they should request. So it's the group. There, the user, in the end, gets a list of group he is allowed to request.
And also this, in the end, you will see after, you can this-- make a pre-populated list of groups. You can make this a dynamic, static list. This is also a standard function in Active Roles to provide all this informations so that you can, in the end, clean up your Active Directory. So you can give user possibility what they are able to enter into the fields and what not, so phone numbers, any kind of information you can control in the end.
Then, also, the start and end time, similar to Raul case, you can say when he needs this and the end date when it should end, which, in the end, is a normal date field. I think there are just two left, and then it should be finished, the end time, yeah. So also text to it.
And the whole thing, by the way, you can also make this multi-language-aware, that's also possible. So it's not just English. So that should be it. Just do reload. And, no? Should be finished, I think, yeah.
And now you can see, it's not visible because this user has not this permission. So he's not able to see this in the end. And, if we go back to the policies, so there is a Tier0 policy which, in the end, contains two validations. One is the access request group. So this will populate which groups he is allowed to request, like domain admin, enterprise admin.
And this list, you can make also dynamic or read it directly from via PowerShell from Active Directory, or you can have it from a SQL database. So this is all you can do directly with the Active Roles in the end.
So I open it with another user. That's the Tier0 or the test account, which is requesting a Tier0 account. And you can see, he has this tab. So he is saying, I want to request this account. For which group, in the end? For the domain admins, start date, as well the end date.
And now, when he saves it, the approval starts. So he has to enter the command why he is requiring it. Of course, normally a meaning-- much more meaningful than just this.
And now the approval is sent to the approval group. So the approver is now going and logging on. And, by the way, this approval you can also send to an email, to an Outlook or whatever. So this is also possible so the administrator or the person which needs to approve has not to log on all the time directly to the portal.
And this is now similar to Raul's case. You have this request. They can change the request, they can reject the request, or approve the request. So same here, I can-- same, I can check who is requesting, the time. I have, again, the possibility to change this if I like. So he approves it. Also that text, you can make this mandatory or optional.
And now Active Role starts and creates a Tier0 account. And this Tier0 account, in the end, will also be mapped then to the user which requested this Tier0 account. So there is this new Tier0 account, which has the adm in front and the logon name of the user who requested it after. And you can see, he is also member for a certain period for the domain admins.
And what happens after the request is over, it's the same. It will be removed from this group automatically, so no one has to take care on it. And the other thing is, this test account or this adm test account will be deleted as well. And you see also, there are two emails, and one is with the initial password. So the requester gets an email with this initial password. He has to log on, he has to change the password, and then he can do the work in the end.
So that's the case we did on this company, how we introduced a very, let's say, lightweight fast. So it was, I think, a day of work to do this, to create this environment that the user, in the end, is able to request an admin account and can work with it. And it has a reported audited way of users having access, in the end, to the Active Directory, do their work.
And, in the end, everything gets be cleaned up. So they have not to mess up with auditors, finding users which are still there, or having too many accounts with too many groups. So this was the other example how we are using Active Roles for this tier concept in the end, which allows existing customers or customers which are, let's say, in the concept of introducing the new Microsoft concept, how they can build something easier, something better.
And, again, this works not just for Active Directory, this works also for Azure Active Directory because Active Roles is able to manage both Active Directory as well Azure Active Directory. So it's one single console, it's one single product. You have not to go to do different consoles. So one, the portal of Azure, the other one you have to go for the other in Active Directory. So this is also a very nice benefit, in the end of, of Active Roles.
Thank you.
[LAUGHTER]
Thank you for coming here.
[APPLAUSE]
[MUSIC PLAYING]
(SINGING) Doo, doo, doo, doo, doo, doo
Doo, doo, doo, doo, doo, doo