Role-based security
You can't get around the fact that certain users need permissions in your directory to do their job. It doesn't matter whether it is helpdesk staff or other power users – the only thing that matters is granting those permissions efficiently and securely. And this is what Adaxes can help you accomplish.
Role-based access model
In a nutshell, Adaxes lets you delegate permissions by assigning security roles to your users. A security role is simply a set of permissions that corresponds to a job function.
For instance, a Helpdesk role will typically include the permissions to reset passwords and do something else along the line.
Assigning a role to the users is as simple as selecting who should have the permissions, and where they should apply. You don't need to rummage through AD to modify the access control list of that OU buried in its depths. The information about all rights of a particular group is just a couple of clicks away.
Moreover, all domains managed by Adaxes become a part of the same ecosystem, so all limitations on assigning permissions are lifted. For example, you can grant permissions to a group from one domain over an OU from another domain, even if these domains don't have trust relationships.
Maintenance of permissions is just as simple. Need to grant the permission to reset MFA to your helpdesk staff? Add it to the Helpdesk role. Revoke some other permission? Remove it from the Helpdesk role. Extend the influence of the helpdesk over another OU? You get the idea.
You can even strip your users of all native directory permissions for additional security. Adaxes relies on its own security model and doesn't care about native rights anyway. It follows the principle that everything permissions-related should be managed from the same place and should take no longer than several minutes of your time.
Dynamic permissions
What about spending zero time on managing permissions, is it even possible? With Adaxes, it is. Users can automatically obtain the exact permissions they need to perform their job, and have them taken away when necessary.
Here's a familiar example. Imagine a security role that grants the Helpdesk group certain permissions over sales staff. It looks completely normal, right?
However, everything about the role is, in fact, automated. The Helpdesk group is rule-based – it is a special group that is configured to contain only the users whose employee type has the word helpdesk and whose account is enabled. Sales Staff is not an OU, it's a business unit – a virtual collection of users whose department is sales, regardless of their actual location in the directory.
What does this mean? It means you can automatically grant permissions to those users who are worthy (judging by their attribute values, not personal character, of course). And, these permissions can be granted only over objects that meet your specific criteria.
Employees will come and go, change offices and departments, while Adaxes will keep doing its job of granting and revoking rights with zero input from the administrators. For a change, you can truly embrace the set-and-forget approach to managing permissions and be confident they are applied correctly and in time.
Delegating tasks
Granting permissions is only a means to an end. Users need a tool to take advantage of their rights. Adaxes Web interface is the place where they will be able to do everything you've allowed them.
A lot can be said about the Web interface, and you are encouraged to learn more, but here is the crucial bit. The Web interface can shape itself and adapt to the permissions of the signed-in user.
Control elements (e.g. Modify user or Create group buttons) and even entire sections of the UI will become hidden if the user is not allowed to do what these elements suggest. This way, users don't need to steer around the features that don't work because of insufficient permissions.
If they attempt to view or do anything outside of their prescribed role, they will get stonewalled. Here is an example of what an HR user will see.
Yes, the role-based access model isn't perfect, but it's a much better approach than arbitrarily deciding who should get access to which resources. And, with all other features and tricks in Adaxes, it becomes even better.
If you thought about delegating tasks to your users but ditched that idea because the permission management would have been a nightmare, give Adaxes a shot. You'll be surprised how little you need to do to construct a secure environment.
