Naming chaos… name things by their names.
One of the most common issues I find when chatting to my customers and colleagues, is understanding things the same way. We all been in a situation where we know something by one name, but our colleague from another region (or country) call it differently. Well, on IT this happens all the time. Manufacturers do name their stuff according to its best, but then it comes the “understanding” of each person who deals with this stuff. However things complicate when there is no clear word for that, or like in my case, when a “model” is defined, then calling thing the same way helps the comprehension of the topic. We must understand the difference between Privileged and Semi-Privileged Users.
In Active Directory world, you have 2 default definitions for users: Privileged and Non-Privileged users. Privileged users can do all what they want; on Windows called Administrator. On Unix/Linux they called root… and then you have all the rest of users. In simple words, one has all the power on the server, and the other one has very limited rights.
On an earlier post, I explained my vision of “Segregation of Duties”, and yes, this idea is to segregate users, but think a bit on the idea, is ALL or NOTHING concept. Modern democracy builds into segregation of power: the group of persons who write laws must be different from the ones who apply and enforce these laws. We don’t want to have too much power on a particular group or person, like the case of the Administrator or root.
Neuron fight result… an idea
As we don’t have to worry (too much) for the Non-Privileged users, we will focus on the Privileged ones. As I mentioned, the Administrator has full power to do whatever he wants into our environment. To me, this is not a clever idea. For sure you need an emergency, very powerful account to fix things when something goes wrong. Nevertheless regularly using these kinds of accounts? I don’ think this is smart or desirable.
Here is where the Semi-Privileged account comes into play. These accounts will have a higher degree of privileges than a normal or Non-Privileged account, but will not be as the privileged ones. By having this “sub-set” category, we can granular control what it can perform on our environment, without giving too much.
We can have as many Semi-Privileged account that our environment operation needs, but without having all the eggs on the same basket. By following the idea of segregating duties, we must segregate individual tasks into several semi-privileged users. This is like having a “mini-Admin”, where she is able to complete its assigned tasks.
As a clear example we can have a person (or a team) in the Access Management role; having the task to grant and revoke access by changing group membership. This team should not use its non-privileged account to complete this task, but is not wise to use a more powerful set of privileges, as it could be the Account Operators group. Why? Because the Account Operators group, among changing group membership, it can create and manage users, something that might not be part of the earlier mentioned Access Management Group. Here is where the inventive solution of Architect comes to play; we need a semi-privileged user that can complete the task without going into full-privilege mode.
What would I do if I’m working for you
Find and track all privileged users, because we don’t want to run our environment with these. Once identified, start the provisioning process of the Semi-Privileged users. This last step will fit perfectly into the Delegation Model, specifically when assigning the different roles the model provides.
Bear in mind that the total amount of Semi-Privileged users should not exceed the 2% of the overall objects. Going beyond this percentage might indicate that we have to review our model and semi-privileged account numbers.
What we can Achieve by using privileged and Semi-Privileged Users
Although we are having more users, these users are controlled and segregated according to our operational model. All Semi-Privileged users are easily controlled and audited, and we have the opportunity to implement the “least privileged access” to them.
Remember that this article is only talking about one single brick in the wall, helping to build it solid and secure!