A little about how not to protect accounts in Active Directory
Write this text I was prompted by the periodic appearance on Windows of articles by Windows administrators, whose authors, in my opinion, do not understand very well what they are doing. The last of these posts is about protecting service accounts .
First of all, I would like to say the following: dear colleagues, the protection of accounts is a typical, but by no means a simple task, especially for the average system administrator who is not an information security specialist. If you are lucky and you are in an organization where all the regulations and processes have been developed before you, of course, it will be quite easy for you to take advantage of the labor of others. But if everything that you have in your hands is freshly raised (or, even worse, lifted, do not understand by whom and how) the AD and Google domain, you should not approach the task in the style of “read Best practices, I will do as they write, and that's all will be a bunch.
As an example of why any general recommendations should be applied with extreme caution, consider the classic option of blocking accounts by the number of failed login attempts mentioned in the article above. Many people unreasonably believe that the best practice here is to include a lock. This can actually be a useful measure, if for some reason you are sure that an attacker will be able to find out the names of only a small number of accounts.
Unfortunately, this method has one drawback - if the attacker has access to the list of accounts, he will be able to block them all. Here, in particular, one thing should be remembered - 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 finds out the login password of at least one user, he will be able to get a list of ALL (yes, absolutely all) accounts in the domain using a simple LDAP query. And, if you have the lockout policy enabled, it will be able to block them all. Imagine the consequences and try to think of what you will do if you suffer a similar 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 actually used to brute-force passwords with automated tools, 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 a blocking of records at all, and whether it would be better to track unsuccessful attempts to log in on your own, since you can even hang up on events that occurred in the Event Log and handle these events as you need even with regular Windows tools. (and not just by "three unsuccessful attempts - a shot"). At the same time, however, it is worth remembering that accounting can authenticate on any domain controller in the network, and each CD should be monitored separately. It may be recalled that in more or less modern versions of Windows, there may be several security policies. Consequently, it is possible to more accurately approach the question, which uchetka block, and which - no. Thirdly, you can even tackle the question that the usual Windows administrator never deals with, namely restricting data to a user with default rights in AD (I note that this may make sense outside the context of protecting exactly the account).
Thus, even one of the most frequent and typical tasks for a successful solution (and not the visibility of a solution) requires a sufficiently careful approach and may require deepening into questions that the vast majority of Windows administrators simply do not think about.
Further, when we turn to the protection of service (and not user) accounts, the author believes that these records are "not protected from brute force and over the years the password has not been changed." Let's leave aside the issue with Managed Service accounts - in my personal experience there are far fewer places where they can be used than places where it is impossible. However, two things need to be remembered - firstly, passwords for service accounts do not have to meet the requirement of convenience for a person, and, therefore, can be much stronger, and secondly, surprisingly, there are automation tools in Windows that allow passwords to be changed - a simple example . It is clear that automation is not always possible here (and in general, changing the password in some cases may represent a quest that you absolutely do not want to go through without emergency), but, nevertheless, you need to remember this.
The author also mentions the restrictions on local input for service uchetok common domain policy. In some cases, this may be useful, but it should be understood that a ban on local logging may not mean anything 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 for which accounting can even enter is a stronger thing, but it should be applied with extreme caution.
And, of course, these are far from all the questions that can be discussed both in relation to the article being criticized, and to the topic in general.
Summing up some results:
1. You should not even treat the basic moments of information security as a “simple” question. Think and think well, especially if you are a beginner.
2. The illusion of security that adherence to not-so-well-thought-out advice can create 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, carefully study the topic on which you are writing. Incompetence in the world is more than enough, you should not multiply it, at the same time risking to create big problems for those whom you, in theory, want to help.
First of all, I would like to say the following: dear colleagues, the protection of accounts is a typical, but by no means a simple task, especially for the average system administrator who is not an information security specialist. If you are lucky and you are in an organization where all the regulations and processes have been developed before you, of course, it will be quite easy for you to take advantage of the labor of others. But if everything that you have in your hands is freshly raised (or, even worse, lifted, do not understand by whom and how) the AD and Google domain, you should not approach the task in the style of “read Best practices, I will do as they write, and that's all will be a bunch.
As an example of why any general recommendations should be applied with extreme caution, consider the classic option of blocking accounts by the number of failed login attempts mentioned in the article above. Many people unreasonably believe that the best practice here is to include a lock. This can actually be a useful measure, if for some reason you are sure that an attacker will be able to find out the names of only a small number of accounts.
Unfortunately, this method has one drawback - if the attacker has access to the list of accounts, he will be able to block them all. Here, in particular, one thing should be remembered - 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 finds out the login password of at least one user, he will be able to get a list of ALL (yes, absolutely all) accounts in the domain using a simple LDAP query. And, if you have the lockout policy enabled, it will be able to block them all. Imagine the consequences and try to think of what you will do if you suffer a similar 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 actually used to brute-force passwords with automated tools, 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 a blocking of records at all, and whether it would be better to track unsuccessful attempts to log in on your own, since you can even hang up on events that occurred in the Event Log and handle these events as you need even with regular Windows tools. (and not just by "three unsuccessful attempts - a shot"). At the same time, however, it is worth remembering that accounting can authenticate on any domain controller in the network, and each CD should be monitored separately. It may be recalled that in more or less modern versions of Windows, there may be several security policies. Consequently, it is possible to more accurately approach the question, which uchetka block, and which - no. Thirdly, you can even tackle the question that the usual Windows administrator never deals with, namely restricting data to a user with default rights in AD (I note that this may make sense outside the context of protecting exactly the account).
Thus, even one of the most frequent and typical tasks for a successful solution (and not the visibility of a solution) requires a sufficiently careful approach and may require deepening into questions that the vast majority of Windows administrators simply do not think about.
Further, when we turn to the protection of service (and not user) accounts, the author believes that these records are "not protected from brute force and over the years the password has not been changed." Let's leave aside the issue with Managed Service accounts - in my personal experience there are far fewer places where they can be used than places where it is impossible. However, two things need to be remembered - firstly, passwords for service accounts do not have to meet the requirement of convenience for a person, and, therefore, can be much stronger, and secondly, surprisingly, there are automation tools in Windows that allow passwords to be changed - a simple example . It is clear that automation is not always possible here (and in general, changing the password in some cases may represent a quest that you absolutely do not want to go through without emergency), but, nevertheless, you need to remember this.
The author also mentions the restrictions on local input for service uchetok common domain policy. In some cases, this may be useful, but it should be understood that a ban on local logging may not mean anything 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 for which accounting can even enter is a stronger thing, but it should be applied with extreme caution.
And, of course, these are far from all the questions that can be discussed both in relation to the article being criticized, and to the topic in general.
Summing up some results:
1. You should not even treat the basic moments of information security as a “simple” question. Think and think well, especially if you are a beginner.
2. The illusion of security that adherence to not-so-well-thought-out advice can create 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, carefully study the topic on which you are writing. Incompetence in the world is more than enough, you should not multiply it, at the same time risking to create big problems for those whom you, in theory, want to help.
Source: https://habr.com/ru/post/246447/
All Articles