A little bit about how to protect accounts in Active Directory
I was prompted to write this text by the periodic appearance on Windows of articles of Windows administrators, whose authors, in my opinion, do not very well understand what they are doing. The last of these posts is on the protection of business accounts .
First of all, I would like to say the following - dear colleagues, account protection - although typical, but by no means an easy task, especially for the average system administrator who is not an information security specialist. If you are lucky and you find yourself in an organization where all the regulations and processes are developed before you - of course, it will be quite simple for you to take advantage of the labor of others. But if all that you have on hand is a freshly raised (or, even worse, raised by someone and how) domain AD and Google, you should not approach the task in the style of "I read Best practices, I will do as they write, and that's it will be a bunch. "
As an example of why any general recommendations should be applied with extreme caution, consider the classic version of blocking accounts by the number of failed login attempts mentioned in the article above. Many people unreasonably believe that Best practice here is to enable locking. This can really be a useful measure if for some reason you are sure that the attacker can only find out the names of a small number of accounts.
Unfortunately, this method has one drawback - if an attacker gained access to the list of accounts, he will be able to block all of them. Here, in particular, one thing to keep in mind is that any account in the AD domain can send requests to the directory service and by default has the right to read almost all of its sections. In practice, this means that if an attacker learns the login password of at least one user, he can use a simple LDAP request to get a list of ALL (yes, absolutely all) accounts in the domain. And, if you have an account lockout policy enabled, it will be able to block all of them. Imagine the consequences and try to figure out what you will do if you suffer such a fate.
By the way, the solution proposed by the author with the automatic unlocking of the account and sending a message to the administrator is not really a solution - if the record is really attacked by password guessing by automated means, it is very likely to be immediately blocked again.
How can you not shoot yourself in the foot? For example, to think about the question of whether you need to lock records at all, and whether it would be better to track unsuccessful login attempts on their own, since even using regular Windows tools, you can put alerts on events that fell into Event Log and process these events as you need (and not just by “three unsuccessful attempts - a shot”). In this case, however, it is worth remembering that the account can log in to any domain controller in the network, and each CD must be monitored separately. You may recall that in more or less modern versions of Windows, there may be several security policies. Therefore, it is possible to more accurately approach the question of which accounts to block and which not. Thirdly, you can even tackle the issue that the regular Windows administrator never deals with, namely, restricting user data by default to rights in AD (I note that this may make sense outside the protection context of the accounts too).
Thus, even one of the most common and typical tasks for a successful solution (and not the appearance of a solution) requires a rather careful approach and may require deepening in issues that the vast majority of Windows administrators simply do not think about.
Further, when we move on to the protection of service (rather than user) accounts, the author believes that these entries are “not protected from enumeration and do not change password over the years”. We will leave aside the issue with Managed Service accounts - in my personal experience there are much fewer places where they can be applied than places where you can’t. However, there are two things to keep in mind: firstly, service account passwords do not have to meet the convenience requirement for a person, and therefore can be much stronger, and secondly, Windows, surprisingly, has automation tools that allow you to change passwords - a simple example. It is clear that automation is not always possible here (and in general, changing a password in some cases may represent a quest that you absolutely do not want to go through unless absolutely necessary), but, nevertheless, you need to remember this.
The author also mentions restrictions on the local login for service accounts by the general domain policy. In some cases, this may be useful, but it must be understood that the prohibition on local login may mean nothing at all, especially in the very common case when the service account has extended rights in the domain or on individual computers. Limiting the list of machines that the account can access at all is a stronger thing, but it must be used with extreme caution.
And, of course, these are by no means all the issues that can be discussed both in relation to the article being criticized, and to the topic in general.
Summing up some results:
1. One should not even regard the basic points of information security as a “simple” question. Think and think well, especially if you are a beginner.
2. The illusion of security that can be created by following not too well-thought-out advice is worse than understanding that you have a problem and not enough knowledge to solve.
3. If you want to write an article on a topic, and not just share your personal experience in the style of “I did what you think about it?” - please study the topic on which you are writing. There is more than enough incompetence in the world, and you should not increase it, at the same time risking creating big problems for those whom you, in theory, want to help.
First of all, I would like to say the following - dear colleagues, account protection - although typical, but by no means an easy task, especially for the average system administrator who is not an information security specialist. If you are lucky and you find yourself in an organization where all the regulations and processes are developed before you - of course, it will be quite simple for you to take advantage of the labor of others. But if all that you have on hand is a freshly raised (or, even worse, raised by someone and how) domain AD and Google, you should not approach the task in the style of "I read Best practices, I will do as they write, and that's it will be a bunch. "
As an example of why any general recommendations should be applied with extreme caution, consider the classic version of blocking accounts by the number of failed login attempts mentioned in the article above. Many people unreasonably believe that Best practice here is to enable locking. This can really be a useful measure if for some reason you are sure that the attacker can only find out the names of a small number of accounts.
Unfortunately, this method has one drawback - if an attacker gained access to the list of accounts, he will be able to block all of them. Here, in particular, one thing to keep in mind is that any account in the AD domain can send requests to the directory service and by default has the right to read almost all of its sections. In practice, this means that if an attacker learns the login password of at least one user, he can use a simple LDAP request to get a list of ALL (yes, absolutely all) accounts in the domain. And, if you have an account lockout policy enabled, it will be able to block all of them. Imagine the consequences and try to figure out what you will do if you suffer such a fate.
By the way, the solution proposed by the author with the automatic unlocking of the account and sending a message to the administrator is not really a solution - if the record is really attacked by password guessing by automated means, it is very likely to be immediately blocked again.
How can you not shoot yourself in the foot? For example, to think about the question of whether you need to lock records at all, and whether it would be better to track unsuccessful login attempts on their own, since even using regular Windows tools, you can put alerts on events that fell into Event Log and process these events as you need (and not just by “three unsuccessful attempts - a shot”). In this case, however, it is worth remembering that the account can log in to any domain controller in the network, and each CD must be monitored separately. You may recall that in more or less modern versions of Windows, there may be several security policies. Therefore, it is possible to more accurately approach the question of which accounts to block and which not. Thirdly, you can even tackle the issue that the regular Windows administrator never deals with, namely, restricting user data by default to rights in AD (I note that this may make sense outside the protection context of the accounts too).
Thus, even one of the most common and typical tasks for a successful solution (and not the appearance of a solution) requires a rather careful approach and may require deepening in issues that the vast majority of Windows administrators simply do not think about.
Further, when we move on to the protection of service (rather than user) accounts, the author believes that these entries are “not protected from enumeration and do not change password over the years”. We will leave aside the issue with Managed Service accounts - in my personal experience there are much fewer places where they can be applied than places where you can’t. However, there are two things to keep in mind: firstly, service account passwords do not have to meet the convenience requirement for a person, and therefore can be much stronger, and secondly, Windows, surprisingly, has automation tools that allow you to change passwords - a simple example. It is clear that automation is not always possible here (and in general, changing a password in some cases may represent a quest that you absolutely do not want to go through unless absolutely necessary), but, nevertheless, you need to remember this.
The author also mentions restrictions on the local login for service accounts by the general domain policy. In some cases, this may be useful, but it must be understood that the prohibition on local login may mean nothing at all, especially in the very common case when the service account has extended rights in the domain or on individual computers. Limiting the list of machines that the account can access at all is a stronger thing, but it must be used with extreme caution.
And, of course, these are by no means all the issues that can be discussed both in relation to the article being criticized, and to the topic in general.
Summing up some results:
1. One should not even regard the basic points of information security as a “simple” question. Think and think well, especially if you are a beginner.
2. The illusion of security that can be created by following not too well-thought-out advice is worse than understanding that you have a problem and not enough knowledge to solve.
3. If you want to write an article on a topic, and not just share your personal experience in the style of “I did what you think about it?” - please study the topic on which you are writing. There is more than enough incompetence in the world, and you should not increase it, at the same time risking creating big problems for those whom you, in theory, want to help.