How can you make remote access more secure using a token? What is Active Directory - how to install and configure Active Directory Management

Being well acquainted with small business from the inside, I have always been interested in the following questions. Explain why an employee should use the browser that the system administrator likes on his work computer? Or take any other software, for example, the same archiver, email client, instant messaging client... I am gently hinting at standardization, and not based on the personal sympathy of the system administrator, but on the basis of the sufficiency of functionality, cost of maintenance and support of these software products. Let's start considering IT as an exact science, and not as a craft, when everyone does as they please. Again, there are also a lot of problems with this in small businesses. Imagine that a company in a difficult time of crisis changes several of these administrators, what should poor users do in such a situation? Constantly retrain?

Let's look from the other side. Any manager should understand what is currently happening in his company (including in IT). This is necessary to monitor the current situation and to promptly respond to the emergence of various types of problems. But this understanding is more important for strategic planning. After all, having a strong and reliable foundation, we can build a house with 3 or 5 floors, make a roof of different shapes, make balconies or a winter garden. Similarly, in IT, we have a reliable foundation - we can further use more complex products and technologies to solve business problems.

The first article will talk about such a foundation - Active Directory services. They are designed to become a strong foundation for the IT infrastructure of a company of any size and any area of ​​activity. What it is? So let's talk about this...

Let's start the conversation with simple concepts - domain and Active Directory services.

Domain is the basic administrative unit in an enterprise's network infrastructure, which includes all network objects such as users, computers, printers, shares, and more. The collection of such domains is called a forest.

Active Directory Services (Active Directory Services) are a distributed database that contains all domain objects. The Active Directory domain environment provides a single point of authentication and authorization for users and applications across the enterprise. It is with the organization of a domain and the deployment of Active Directory services that the construction of an enterprise IT infrastructure begins.

The Active Directory database is stored on dedicated servers – domain controllers. Active Directory Services is a role of Microsoft Windows Server server operating systems. Active Directory Services is highly scalable. More than 2 billion objects can be created in an Active Directory forest, allowing the directory service to be implemented in companies with hundreds of thousands of computers and users. The hierarchical structure of domains allows you to flexibly scale the IT infrastructure to all branches and regional divisions of companies. For each branch or division of a company, a separate domain can be created, with its own policies, its own users and groups. For each child domain, administrative authority can be delegated to local system administrators. At the same time, child domains are still subordinate to their parents.

Additionally, Active Directory Services allows you to configure trust relationships between domain forests. Each company has its own forest of domains, each with its own resources. But sometimes you need to provide access to your corporate resources to employees of another company - working with common documents and applications as part of a joint project. To do this, trust relationships can be set up between organizational forests, which will allow employees of one organization to log in to the domain of another.

To ensure fault tolerance for Active Directory services, you must deploy two or more domain controllers in each domain. All changes are automatically replicated between domain controllers. If one of the domain controllers fails, the functionality of the network is not affected, because the remaining ones continue to work. An additional level of resiliency is provided by placing DNS servers on domain controllers in Active Directory, which allows each domain to have multiple DNS servers serving the domain's primary zone. And if one of the DNS servers fails, the others will continue to work. We will talk about the role and importance of DNS servers in the IT infrastructure in one of the articles in the series.

But these are all technical aspects of implementing and maintaining Active Directory services. Let's talk about the benefits a company gets by moving away from peer-to-peer networking and using workgroups.

1. Single point of authentication

In a workgroup, on each computer or server, you will have to manually add a complete list of users who require network access. If suddenly one of the employees wants to change his password, then it will need to be changed on all computers and servers. It's good if the network consists of 10 computers, but what if there are more? When using an Active Directory domain, all user accounts are stored in one database, and all computers look to it for authorization. All domain users are included in the appropriate groups, for example, “Accounting”, “Finance Department”. It is enough to set permissions for certain groups once, and all users will have appropriate access to documents and applications. If a new employee joins the company, an account is created for him, which is included in the appropriate group - the employee gets access to all network resources to which he should be allowed access. If an employee quits, then just block him and he will immediately lose access to all resources (computers, documents, applications).

2. Single point of policy management

In a workgroup, all computers have equal rights. None of the computers can control the other; it is impossible to monitor compliance with uniform policies and security rules. When using a single Active Directory, all users and computers are hierarchically distributed across organizational units, each of which is subject to the same group policies. Policies allow you to set uniform settings and security settings for a group of computers and users. When a new computer or user is added to a domain, it automatically receives settings that comply with accepted corporate standards. Using policies, you can centrally assign network printers to users, install the necessary applications, set browser security settings, and configure Microsoft Office applications.

3. Increased level of information security

Using Active Directory services significantly increases the level of network security. Firstly, it is a single and secure account storage. In a domain environment, all domain user passwords are stored on dedicated domain controller servers, which are usually protected from external access. Secondly, when using a domain environment, the Kerberos protocol is used for authentication, which is much more secure than NTLM, which is used in workgroups.

4. Integration with corporate applications and equipment

A big advantage of Active Directory services is its compliance with the LDAP standard, which is supported by other systems, for example, mail servers (Exchange Server), proxy servers (ISA Server, TMG). And these are not necessarily only Microsoft products. The advantage of such integration is that the user does not need to remember a large number of logins and passwords to access a particular application; in all applications the user has the same credentials - his authentication occurs in a single Active Directory. Windows Server provides the RADIUS protocol for integration with Active Directory, which is supported by a large number of network equipment. Thus, it is possible, for example, to ensure the authentication of domain users when connecting via VPN from outside, or the use of Wi-Fi access points in the company.

5. Unified application configuration storage

Some applications store their configuration in Active Directory, such as Exchange Server. Deployment of the Active Directory directory service is a prerequisite for these applications to work. Storing application configuration in a directory service offers flexibility and reliability benefits. For example, in the event of a complete failure of the Exchange server, its entire configuration will remain intact. To restore the functionality of corporate mail, it will be enough to reinstall Exchange Server in recovery mode.

To summarize, I would like to once again emphasize that Active Directory services are the heart of an enterprise’s IT infrastructure. In case of failure, the entire network, all servers, and the work of all users will be paralyzed. No one will be able to log into the computer or access their documents and applications. Therefore, the directory service must be carefully designed and deployed, taking into account all possible nuances, for example, the bandwidth of channels between branches or offices of the company (the speed of user login to the system, as well as data exchange between domain controllers, directly depends on this).

How it will help Active Directory specialists?

Here is a small list of “goodies” that you can get by deploying Active Directory:

• a single user registration database, which is stored centrally on one or more servers; thus, when a new employee appears in the office, you will only need to create an account for him on the server and indicate which workstations he can access;
• since all domain resources are indexed, this makes it possible for users to search easily and quickly; for example, if you need to find a color printer in a department;
• the combination of applying NTFS permissions, group policies and delegation of control will allow you to fine-tune and distribute rights between domain members;
• roaming user profiles make it possible to store important information and configuration settings on the server; in fact, if a user with a roaming profile in a domain sits down to work at another computer and enters his username and password, he will see his desktop with the settings he is familiar with;
• using group policies, you can change the settings of user operating systems, from allowing the user to set wallpaper on the desktop to security settings, and also distribute software over the network, for example, Volume Shadow Copy client, etc.;
• Many programs (proxy servers, database servers, etc.) not only produced by Microsoft today have learned to use domain authentication, so you do not have to create another user database, but can use an existing one;
• Using Remote Installation Services makes it easier to install systems on workstations, but, in turn, only works if the directory service is implemented.

And This is not a complete list of possibilities, but more on that later. Now I will try to tell you the logic of construction Active Directory, but again it’s worth finding out what our boys are made of Active Directory- these are Domains, Trees, Forests, Organizational Units, User and Computer Groups.

Domains - This is the basic logical unit of construction. Compared to workgroups AD domains are security groups that have a single registration base, while workgroups are just a logical association of machines. AD uses DNS (Domain Name Server) for naming and search services, rather than WINS (Windows Internet Name Service), as was the case in earlier versions of NT. Thus, the names of computers in the domain look like, for example, buh.work.com, where buh is the name of the computer in the work.com domain (although this is not always the case).

Workgroups use NetBIOS names. To host a domain structure AD It is possible to use a non-Microsoft DNS server. But it must be compatible with BIND 8.1.2 or higher and support SRV() records as well as the Dynamic Registration Protocol (RFC 2136). Every domain has at least one domain controller that hosts the central database.

Trees - These are multi-domain structures. The root of this structure is the main domain for which you create child domains. In fact, Active Directory uses a hierarchical structure similar to the domain structure in DNS.

If we have a domain work.com (first-level domain) and create two child domains for it first.work.com and second.work.com (here first and second are second-level domains, and not a computer in the domain, as in the case , described above), we end up with a domain tree.

Trees as a logical structure are used when you need to divide the branches of a company, for example, by geography, or for some other organizational reasons.

AD helps to automatically create trust relationships between each domain and its child domains.

Thus, the creation of the first.work.com domain leads to the automatic establishment of a two-way trust relationship between the parent work.com and the child first.work.com (similarly for second.work.com). Therefore, permissions can be applied from the parent domain to the child, and vice versa. It is not difficult to assume that trust relationships will exist for child domains as well.

Another property of trust relationships is transitivity. We get that a trust relationship is created for the net.first.work.com domain with the work.com domain.

Forest - Just like trees, they are multi-domain structures. But forest is a union of trees that have different root domains.

Suppose you decide to have multiple domains named work.com and home.net and create child domains for them, but because the tld (top level domain) is not under your control, in this case you can organize a forest by selecting one of the first-level root domains. The beauty of creating a forest in this case is the two-way trust relationship between these two domains and their child domains.

However, when working with forests and trees, you must remember the following:

• you cannot add an existing domain to the tree
• You cannot include an existing tree in the forest
• Once domains are placed in a forest, they cannot be moved to another forest
• you cannot delete a domain that has child domains

Organizational units - In principle, they can be called subdomains. allow you to group user accounts, user groups, computers, shared resources, printers and other OUs (Organizational Units) in a domain. The practical benefit of their use is the possibility of delegating rights to administer these units.

Simply put, you can appoint an administrator in a domain who can manage the OU, but does not have rights to administer the entire domain.

An important feature of OUs, unlike groups, is the ability to apply group policies to them. “Why can’t you split the original domain into multiple domains instead of using an OU?” - you ask.

Many experts advise having one domain if possible. The reason for this is the decentralization of administration when creating an additional domain, since the administrators of each such domain receive unlimited control (let me remind you that when delegating rights to OU administrators, you can limit their functionality).

In addition to this, to create a new domain (even a child one) you will need another controller. If you have two separate departments connected by a slow communication channel, problems with replication may arise. In this case, it would be more appropriate to have two domains.

There is also one more nuance of using group policies: policies that define password settings and account lockouts can only be applied to domains. For OUs, these policy settings are ignored.

Websites - This is a way to physically separate a directory service. By definition, a site is a group of computers connected by fast data transfer channels.

If you have several branches in different parts of the country, connected by low-speed communication lines, then for each branch you can create your own website. This is done to increase the reliability of directory replication.

This division of AD does not affect the principles of logical construction, therefore, just as a site can contain several domains, and vice versa, a domain can contain several sites. But there is a catch to this directory service topology. As a rule, the Internet is used to communicate with branches - a very insecure environment. Many companies use security measures such as firewalls. The directory service uses about one and a half dozen ports and services in its work, the opening of which to allow AD traffic to pass through the firewall will actually expose it “outside”. The solution to the problem is to use tunneling technology, as well as the presence of a domain controller in each site to speed up the processing of AD client requests.

The logic of nesting of directory service components is presented. It can be seen that the forest contains two domain trees, in which the root domain of the tree, in turn, can contain OUs and groups of objects, and also have child domains (in this case, one for each). Child domains can also contain object groups and OUs and have child domains (not shown in the figure). And so on. Let me remind you that OUs can contain OUs, objects and groups of objects, and groups can contain other groups.

User and computer groups - are used for administrative purposes and have the same meaning as when used on local machines on the network. Unlike OUs, group policies cannot be applied to groups, but management can be delegated for them. Within the Active Directory scheme, there are two types of groups: security groups (used to differentiate access rights to network objects) and distribution groups (used mainly for distributing email messages, for example, in Microsoft Exchange Server).

They are divided by scope:

• universal groups may include users within the forest as well as other universal groups or global groups of any domain in the forest
• global domain groups may include domain users and other global groups of the same domain
• domain local groups used to differentiate access rights, can include domain users, as well as universal groups and global groups of any domain in the forest
• local computer groups– groups that contain SAM (security account manager) of the local machine. Their scope is limited only to a given machine, but they can include local groups of the domain in which the computer is located, as well as universal and global groups of their own domain or another that they trust. For example, you can include a user from the domain local Users group in the Administrators group of the local machine, thereby giving him administrator rights, but only for this computer

In 2002, while walking along the corridor of the computer science department of my favorite university, I saw a fresh poster on the door of the “NT Systems” office. The poster depicted user account icons grouped into groups, from which arrows in turn led to other icons. All this was schematically combined into a certain structure, something was written about a single sign-on system, authorization and the like. As far as I understand now, that poster depicted the architecture of Windows NT 4.0 Domains and Windows 2000 Active Directory systems. From that moment my first acquaintance with Active Directory began and immediately ended, as then there was a hard session, a fun vacation, after which a friend shared FreeBSD 4 and Red Hat Linux disks, and for the next few years I plunged into the world of Unix-like systems , but I never forgot the contents of the poster.
I had to return to systems based on the Windows Server platform and become more familiar with them when I moved to work for a company where the management of the entire IT infrastructure was based on Active Directory. I remember that the chief administrator of that company kept repeating something about some Active Directory Best Practices at every meeting. Now, after 8 years of periodic communication with Active Directory, I understand quite well how this system works and what Active Directory Best Practices are.
As you probably already guessed, we will talk about Active Directory.
Anyone who is interested in this topic is welcome to cat.

These recommendations are valid for client systems starting from Windows 7 and higher, for domains and forests at the Windows Server 2008/R2 level and higher.

Standardization
Planning for Active Directory should begin by developing your standards for naming objects and their location in the directory. It is necessary to create a document that defines all the necessary standards. Of course, this is a fairly common recommendation for IT professionals. The principle “first we write documentation, and then we build a system using this documentation” is very good, but it is rarely implemented in practice for many reasons. Among these reasons is simple human laziness or lack of appropriate competence; the remaining reasons are derived from the first two.
I recommend that you first write the documentation, think it over, and only then proceed with installing the first domain controller.
As an example, I will give a section of the document on standards for naming Active Directory objects.
Naming objects.

• The name of user groups must begin with the prefix GRUS_ (GR - Group, US - Users)
• The name of computer groups must begin with the prefix GRCP_ (GR - Group, CP - Computers)
• The name of delegation of authority groups must begin with the prefix GRDL_ (GR - Group, DL - Delegation)
• The name of resource access groups must begin with the prefix GRRS_ (GR - Group, RS - resources)
• The name of groups for policies must begin with the prefixes GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
• The name of client computers must consist of two or three letters from the name of the organization, followed by a number separated by a hyphen, for example, nnt-01.
• The name of the servers must begin with only two letters, followed by a hyphen and followed by the role of the server and its number, for example, nn-dc01.

I recommend naming Active Directory objects so that you don't have to fill out the Description field. For example, from the name of the group GPCP_Restricted_Groups it is clear that this is a policy group that is applied to computers and performs the work of the Restricted Groups mechanism.
Your approach to writing documentation should be very thorough, this will save a lot of time in the future.

Simplify everything as much as possible, try to achieve balance
When building Active Directory, it is necessary to follow the principle of achieving balance, opting for simple and understandable mechanisms.
The principle of balance is to achieve the required functionality and safety with maximum simplicity of the solution.
It is necessary to try to build the system so that its structure is understandable to the most inexperienced administrator or even user. For example, at one time there was a recommendation to create a forest structure of several domains. Moreover, it was recommended to deploy not only multi-domain structures, but also structures from several forests. Perhaps this recommendation existed because of the “divide and conquer” principle, or because Microsoft told everyone that the domain is the security boundary and by dividing the organization into domains, we will get separate structures that are easier to control individually. But as practice has shown, it is easier to maintain and control single-domain systems, where the security boundaries are organizational units (OUs) rather than domains. Therefore, avoid creating complex multi-domain structures; it is better to group objects by OU.
Of course, you should act without fanaticism - if it is impossible to do without several domains, then you need to create several domains, also with forests. The main thing is that you understand what you are doing and what it can lead to.
It is important to understand that a simple Active Directory infrastructure is easier to administer and monitor. I would even say that the simpler, the safer.
Apply the principle of simplification. Try to achieve balance.

Follow the principle - “object - group”
Start creating Active Directory objects by creating a group for this object, and assign the necessary rights to the group. Let's look at an example. You need to create a main administrator account. First create the Head Admins group and only then create the account itself and add it to this group. Assign head administrator rights to the Head Admins group, for example, by adding it to the Domain Admins group. It almost always turns out that after some time another employee comes to work who needs similar rights, and instead of delegating rights to different Active Directory sections, it will be possible to simply add him to the necessary group for which the system has already defined role and the necessary powers are delegated.
One more example. You need to delegate rights to the OU with users to the system administrators group. Do not delegate rights directly to the administrators group, but create a special group like GRDL_OUName_Operator_Accounts to which you assign rights. Then simply add the responsible administrators group to the GRDL_OUName_Operator_Accounts group. It will definitely happen that in the near future you will need to delegate rights to this OU to another group of administrators. And in this case, you will simply add the administrators data group to the GRDL_OUName_Operator_Accounts delegation group.
I propose the following group structure.

• User groups (GRUS_)
• Admin Groups (GRAD_)
• Delegation groups (GRDL_)
• Policy groups (GRGP_)

Computer groups

• Server groups (GRSR_)
• Groups of client computers (GRCP_)

Resource Access Groups

• Shared Resource Access Groups (GRRS_)
• Printer Access Groups (GRPR_)

In a system built according to these recommendations, almost all administration will consist of adding groups to groups.
Maintain balance by limiting the number of roles for groups and remember that the group name should ideally fully describe its role.

OU architecture.
The architecture of an OU should first of all be thought through from the point of view of security and delegation of rights to this OU to system administrators. I do not recommend planning the architecture of OUs from the point of view of linking group policies to them (although this is most often done). For some, my recommendation may seem a little strange, but I do not recommend tying group policies to OUs at all. Read more in the Group Policies section.
OU Admins
I recommend creating a separate OU for administrative accounts and groups, where you can place the accounts and groups of all administrators and technical support engineers. Access to this OU should be limited to ordinary users, and management of objects from this OU should be delegated only to main administrators.
OU Computers
Computer OUs are best planned in terms of the geographic location of the computers and the types of computers. Distribute computers from different geographical locations into different OUs, and in turn divide them into client computers and servers. Servers can also be divided into Exchange, SQL and others.

Users, rights in Active Directory
Active Directory user accounts should be given special attention. As was said in the section about OU, user accounts should be grouped based on the principle of delegation of authority to these accounts. It is also important to observe the principle of least privilege - the fewer rights a user has in the system, the better. I recommend that you immediately include the user’s privilege level in the name of his account. An account for everyday work should consist of the user's last name and initials in Latin (For example, IvanovIV or IVIvanov). Required fields are: First Name, Initials, Last Name, Display Name (in Russian), email, mobile, Job Title, Manager.
Administrator accounts must be of the following types:

• With administrator rights to user computers, but not servers. Must consist of the owner's initials and the local prefix (For example, iivlocal)
• With rights to administer servers and Active Directory. Must consist of initials only (For example, iiv).

The Surname field of both types of administrative accounts should begin with the letter I (For example, iPetrov P Vasily)
Let me explain why you should separate administrative accounts into server administrators and client computer administrators. This must be done for safety reasons. Administrators of client computers will have the right to install software on client computers. It is never possible to say for sure what software will be installed and why. Therefore, it is unsafe to run the installation of a program with domain administrator rights; the entire domain can be compromised. You must administer client computers only with local administrator rights for that computer. This will make it impossible for a number of attacks on domain administrator accounts, such as “Pass The Hash”. Additionally, administrators of client computers need to close connections through Terminal Services and network connections to the computer. Technical support and administrative computers should be placed in a separate VLAN to limit access to them from the network of client computers.
Assigning administrator rights to users
If you need to give administrator rights to a user, never place their account for day-to-day use in the computer's local administrators group. An account for daily work should always have limited rights. Create a separate administrative account for him like namelocal and add this account to the local administrators group using a policy, limiting its application only on the user’s computer using item-level targeting. The user will be able to use this account using the Run AS mechanism.
Password Policies
Create separate password policies for users and administrators using fine-grained password policy. It is advisable that the user password consist of at least 8 characters and is changed at least once a quarter. It is advisable for administrators to change the password every two months, and it should be at least 10-15 characters and meet the complexity requirements.

Composition of domain and local groups. Restricted Groups mechanism
The composition of domain and local groups on domain computers should be controlled only automatically, using the Restricted Groups mechanism. I will explain why it needs to be done only this way using the following example. Typically, after the Active Directory domain is broken, administrators add themselves to domain groups like Domain admins, Enterprise admins, add technical support engineers to the necessary groups, and also distribute the rest of the users into groups. In the process of administering this domain, the process of issuing rights is repeated many times and it will be extremely difficult to remember that yesterday you temporarily added accountant Nina Petrovna to the 1C administrators group and that today you need to remove her from this group. The situation will get worse if the company has several administrators and each of them from time to time grants rights to users in a similar style. In just a year, it will be almost impossible to figure out what rights are assigned to whom. Therefore, the composition of groups should be controlled only by group policies, which will put everything in order with each application.
Composition of built-in groups
It is worth saying that built-in groups like Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators should be empty, both in the domain and on client computers. These groups are primarily needed to ensure backward compatibility with older systems, and users of these groups are given too much rights in the system, and privilege escalation attacks become possible.

Local Administrator Accounts
Using the Restricted Groups mechanism, you must block local administrator accounts on local computers, block guest accounts, and clear the local administrators group on local computers. Never use group policies to set passwords for local administrator accounts. This mechanism is not secure; the password can be extracted directly from the policy. But, if you decide not to block local administrator accounts, then use the LAPS mechanism to correctly set passwords and rotate them. Unfortunately, setting up LAPS is not fully automated, and therefore you will need to manually add attributes to the Active Directory schema, assign rights to them, assign groups, and so on. Therefore, it is easier to block local administrator accounts.
Service accounts.
To run services, use service accounts and the gMSA mechanism (available on Windows 2012 and higher systems)

Group Policies
Document policies before creating/modifying them.
When creating a policy, use the Policy - Group principle. That is, before creating a policy, first create a group for this policy, remove the Authenticated users group from the scope of the policy and add the created group. Link the policy not to the OU, but to the domain root, and regulate the scope of its application by adding objects to the policy group. I consider this mechanism more flexible and understandable than linking a policy to an OU. (This is exactly what I wrote about in the section about OU Architecture).
Always adjust the scope of the policy. If you created a policy only for users, then disable the computer structure and vice versa, disable the user structure if you created a policy only for computers. Thanks to these settings, policies will be applied more quickly.
Set up daily policy backups using Power Shell so that if configuration errors occur, you can always return the settings to their original settings.
Central Store
Starting with Windows 2008, it became possible to store ADMX Group Policy templates in a central storage location, SYSVOL. Previously, by default, all policy templates were stored locally on clients. To place ADMX templates in the central storage, you need to copy the contents of the %SystemDrive%\Windows\PolicyDefinitions folder along with subfolders from client systems (Windows 7/8/8.1) to the domain controller directory %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions with content merged, but without replacement. Next, you should make the same copy from the server systems, starting with the oldest. Lastly, when copying folders and files from the latest version of the server, do a MERGE AND REPLACE copy.

Copying ADMX templates

Additionally, ADMX templates for any software products, for example, Microsoft Office, Adobe products, Google products and others, can be placed in the central storage. Go to the software vendor's website, download the ADMX Group Policy template and unpack it to the %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions folder on any domain controller. Now you can manage the software product you need through group policies.
WMI filters
WMI filters are not very fast, so it is preferable to use the item-level targeting mechanism. But if item-level targeting cannot be used, and you decide to use WMI, then I recommend immediately creating several of the most common filters for yourself: the “Client operating systems only” filter, “Server operating systems only”, “Windows 7” filters, “Windows” filters 8", "Windows 8.1", "Windows 10". If you have ready-made sets of WMI filters, then it will be easier to apply the desired filter to the desired policy.

Auditing Active Directory Events
Be sure to enable event auditing on domain controllers and other servers. I recommend enabling auditing of the following objects:

• Audit Computer Account Management - Success, Failure
• Audit Other Account Management Events - Success, Failure
• Audit Security Group Management - Success, Failure
• Audit User Account Management - Success, Failure

• Audit Kerberos Authentication Service - Failure
• Audit Other Account Logon Events - Failure
• Audit Audit Policy Change - Success, Failure

Auditing must be configured in the section Advanced Audit Policy Configuration and be sure to enable the setting in the section Local Policy/Security Options - Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings, which will override the top-level settings and apply the advanced ones.

Advanced audit settings

I will not dwell in detail on audit settings, since there are a sufficient number of articles on the Internet devoted to this topic. I will only add that in addition to enabling auditing, you should set up e-mail alerts about critical security events. It is also worth considering that in systems with a large number of events, it is worth dedicating separate servers for collecting and analyzing log files.

Administration and cleaning scripts
All similar and frequently repeated actions must be performed using administration scripts. These actions include: creating user accounts, creating administrator accounts, creating groups, creating OUs, and so on. Creating objects using scripts allows you to respect your Active Directory object naming logic by building syntax checks right into the scripts.
It is also worth writing cleaning scripts that will automatically monitor the composition of groups, identify users and computers that have not connected to the domain for a long time, identify violations of other standards, and so on.
I have not seen it as an explicit official recommendation to use admin scripts to monitor compliance and perform background operations. But I myself prefer checks and procedures in automatic mode using scripts, since this saves a lot of time and eliminates a large number of errors and, of course, this is where my slightly Unix approach to administration comes into play, when it’s easier to type a couple of commands than click on windows .

Manual administration
You and your colleagues will need to do some administrative operations manually. For these purposes, I recommend using the mmc console with snap-ins added to it.
As will be said later, your domain controllers should operate in Server Core mode, that is, you should administer the entire AD environment only from your computer using consoles. To administer Active Directory, you need to install Remote Server Administration Tools on your computer. Consoles should be run on your computer as a user with Active Directory administrator rights and delegated control.
The art of managing Active Directory using consoles requires a separate article, and maybe even a separate training video, so here I’m only talking about the principle itself.

Domain controllers
In any domain, there must be at least two controllers. Domain controllers should have as few services as possible. You should not turn a domain controller into a file server or, God forbid, upgrade it to the role of a terminal server. Use operating systems on domain controllers in Server Core mode, completely removing WoW64 support; this will significantly reduce the number of required updates and increase their security.
Microsoft has previously discouraged virtualizing domain controllers due to the potential for intractable replication conflicts when restoring from snapshots. There may have been other reasons, I can’t say for sure. Now hypervisors have learned to tell controllers to restore them from snapshots, and this problem has disappeared. I have been virtualizing controllers all the time, without taking any snapshots, because I don’t understand why there might be a need to take such snapshots on domain controllers. In my opinion, it is easier to make a backup copy of the domain controller using standard means. Therefore, I recommend virtualizing all domain controllers that are possible. This configuration will be more flexible. When virtualizing domain controllers, place them on different physical hosts.
If you need to place a domain controller in an unsecured physical environment or in a branch office of your organization, then use RODC for this purpose.

FSMO roles, primary and secondary controllers
FSMO domain controller roles continue to create fear in the minds of new administrators. Often, newbies learn Active Directory from outdated documentation or listen to stories from other administrators who read something somewhere once.
For all five + 1 roles, the following should be briefly said. Starting with Windows Server 2008, there are no longer primary and secondary domain controllers. All five domain controller roles are portable, but cannot reside on more than one controller at a time. If we take one of the controllers, which, for example, was the owner of 4 roles and delete it, then we can easily transfer all these roles to other controllers, and nothing bad will happen in the domain, nothing will break. This is possible because the owner stores all information on work related to a particular role directly in Active Directory. And if we transfer the role to another controller, then it first of all turns to the stored information in Active Directory and begins to perform the service. A domain can exist for quite a long time without role owners. The only “role” that should always be in Active Directory, and without which everything will be very bad, is the global catalog (GC) role, which can be borne by all controllers in the domain. I recommend assigning the GC role to each controller in the domain, the more there are, the better. Of course, you can find cases where it is not worth installing the GC role on a domain controller. Well, if you don’t need it, then don’t. Follow the recommendations without fanaticism.

DNS service
The DNS service is critical to the operation of Active Directory and must function without interruption. It is best to install the DNS service on each domain controller and store the DNS zones in Active Directory itself. If you will use Active Directory to store DNS zones, then you should configure the TCP/IP connection properties on domain controllers so that each controller has any other DNS server as the primary DNS server, and you can set the secondary one to address 127.0.0.1. This setting must be done because for the Active Directory service to start normally, a working DNS is required, and for the DNS to start, the Active Directory service must be running, since the DNS zone itself lies in it.
Be sure to set up reverse lookup zones for all of your networks and enable automatic secure update of PTR records.
I recommend additionally enabling automatic zone cleaning of outdated DNS records (dns scavenging).
I recommend specifying protected Yandex servers as DNS-Forwarders if there are no other faster ones in your geographic location.

Sites and replication
Many administrators are accustomed to thinking that websites are a geographical grouping of computers. For example, the Moscow site, the St. Petersburg site. This idea arose due to the fact that the original division of Active Directory into sites was done for the purpose of balancing and separating replication network traffic. Domain controllers in Moscow do not need to know that ten computer accounts have now been created in St. Petersburg. And therefore, such information about changes can be transmitted once an hour according to a schedule. Or even replicate changes once a day and only at night, to save bandwidth.
I would say this about websites: websites are logical groups of computers. Computers that are connected to each other by a good network connection. And the sites themselves are connected to each other by a low-bandwidth connection, which is a rarity these days. Therefore, I divide Active Directory into sites not to balance replication traffic, but to balance the network load in general and for faster processing of client requests from site computers. Let me explain with an example. There is a 100-megabit local network of an organization, which is served by two domain controllers, and there is a cloud where the application servers of this organization are located with two other cloud controllers. I will divide such a network into two sites so that controllers on the local network process requests from clients from the local network, and controllers in the cloud process requests from application servers. Additionally, this will allow you to separate requests to DFS and Exchange services. And since now I rarely see an Internet channel less than 10 megabits per second, I will enable Notify Based Replication, this is when data replication occurs immediately as soon as any changes occur in Active Directory.

Conclusion
This morning I was thinking about why human selfishness is not welcomed in society and somewhere at a deep level of perception causes extremely negative emotions. And the only answer that came to my mind was that the human race would not have survived on this planet if it had not learned to share physical and intellectual resources. That is why I am sharing this article with you and I hope that my recommendations will help you improve your systems and you will spend significantly less time troubleshooting. All this will lead to freeing up more time and energy for creativity. It is much more pleasant to live in a world of creative and free people.
It would be good if, if possible, you share your knowledge and practices of building Active Directory in the comments.
Peace and goodness to everyone!

You can help and transfer some funds for the development of the site

Any novice user, faced with the abbreviation AD, wonders what Active Directory is? Active Directory is a directory service developed by Microsoft for Windows domain networks. Included in most Windows Server operating systems as a set of processes and services. Initially, the service dealt only with domains. However, starting with Windows Server 2008, AD became the name for a wide range of directory-based identity services. This makes Active Directory for beginners a better learning experience.

Basic definition

The server that runs Active Directory Domain Directory Services is called a domain controller. It authenticates and authorizes all users and computers in a Windows network domain, assigning and enforcing security policies for all PCs, and installing or updating software. For example, when a user logs on to a computer that is joined to a Windows domain, Active Directory checks the provided password and determines whether the subject is a system administrator or a standard user. It also enables information management and storage, provides authentication and authorization mechanisms, and establishes a framework for deploying other related services: certificate services, federated and lightweight directory services, and rights management.

Active Directory uses LDAP versions 2 and 3, Microsoft's version of Kerberos, and DNS.

Active Directory - what is it? In simple words about the complex

Monitoring network data is a time-consuming task. Even on small networks, users typically have difficulty finding network files and printers. Without some kind of directory, medium to large networks cannot be managed and often face difficulties in finding resources.

Previous versions of Microsoft Windows included services to help users and administrators find information. Network Neighborhood is useful in many environments, but the obvious disadvantage is the clunky interface and its unpredictability. WINS Manager and Server Manager can be used to view a list of systems, but they were not available to end users. Administrators used User Manager to add and remove data from an entirely different type of network object. These applications were found to be ineffective for large networks and begged the question, why do companies need Active Directory?

A directory, in the most general sense, is a complete list of objects. A phone book is a type of directory that stores information about people, businesses, and government organizations, andThey usually record names, addresses and telephone numbers. Wondering Active Directory - what is it, in simple words we can say that this technology is similar to a directory, but is much more flexible. AD stores information about organizations, sites, systems, users, shares, and any other network entity.

Introduction to Active Directory Concepts

Why does an organization need Active Directory? As mentioned in the introduction to Active Directory, the service stores information about network components. The Active Directory for Beginners guide explains that this Allows clients to find objects in their namespace. This t The term (also called the console tree) refers to the area in which a network component can be located. For example, a book's table of contents creates a namespace in which chapters can be assigned to page numbers.

DNS is a console tree that resolves hostnames to IP addresses, such asPhone books provide a namespace for resolving names for phone numbers. How does this happen in Active Directory? AD provides a console tree for resolving network object names to the objects themselves andcan resolve a wide range of entities, including users, systems, and services on a network.

Objects and Attributes

Anything that Active Directory tracks is considered an object. We can say in simple words that this is in Active Directory is any user, system, resource or service. A common term object is used because AD is capable of tracking many elements, and many objects can share common attributes. What does it mean?

Attributes describe objects in Active Directory, for example, all user objects share attributes to store the username. This also applies to their descriptions. Systems are also objects, but they have a separate set of attributes that include hostname, IP address, and location.

The set of attributes available for any particular type of object is called a schema. It makes object classes distinct from each other. The schema information is actually stored in Active Directory. That this security protocol behavior is very important is demonstrated by the fact that the design allows administrators to add attributes to object classes and distribute them across the network to all corners of the domain without restarting any domain controllers.

LDAP container and name

A container is a special type of object that is used to organize the operation of a service. It does not represent a physical entity like a user or a system. Instead, it is used to group other elements. Container objects can be nested within other containers.

Every element in AD has a name. These are not the ones you are used to, for example, Ivan or Olga. These are LDAP distinguished names. LDAP distinguished names are complex, but they allow you to uniquely identify any object within a directory, regardless of its type.

Tree of terms and website

A term tree is used to describe a set of objects in Active Directory. What is this? In simple words, this can be explained using a tree association. When containers and objects are combined hierarchically, they tend to form branches - hence the name. A related term is continuous subtree, which refers to the unbroken main trunk of a tree.

Continuing the metaphor, the term "forest" describes a collection that is not part of the same namespace, but shares a common schema, configuration, and global directory. Objects in these structures are available to all users if security allows. Organizations divided into multiple domains should group trees into a single forest.

A site is a geographic location defined in Active Directory. Sites correspond to logical IP subnets and, as such, can be used by applications to find the nearest server on the network. Using site information from Active Directory can significantly reduce traffic on WANs.

Active Directory Management

Active Directory Users snap-in component. This is the most convenient tool for administering Active Directory. It is directly accessible from the Administrative Tools program group in the Start menu. It replaces and improves upon the Server Manager and User Manager from Windows NT 4.0.

Safety

Active Directory plays an important role in the future of Windows networks. Administrators must be able to protect their directory from attackers and users while delegating tasks to other administrators. All of this is possible using the Active Directory security model, which associates an access control list (ACL) with every container and object attribute in the directory.

A high level of control allows the administrator to grant individual users and groups different levels of permissions on objects and their properties. They can even add attributes to objects and hide those attributes from certain user groups. For example, you can set an ACL so that only managers can view other users' home phones.

Delegated administration

A concept new to Windows 2000 Server is delegated administration. This allows you to assign tasks to other users without granting additional access rights. Delegated administration can be assigned through specific objects or contiguous directory subtrees. This is a much more efficient method of granting authority across networks.

IN the place where someone is assigned all global domain administrator rights, the user can only be given permissions within a specific subtree. Active Directory supports inheritance, so any new objects inherit the ACL of their container.

The term "fiduciary relationship"

The term "fiduciary relationship" is still used, but has different functionality. There is no distinction between one-way and two-way trusts. After all, all Active Directory trust relationships are bidirectional. Moreover, they are all transitive. So, if domain A trusts domain B, and B trusts C, then there is an automatic implicit trust relationship between domain A and domain C.

Auditing in Active Directory - what is it in simple words? This is a security feature that allows you to determine who is trying to access objects and how successful the attempt is.

Using DNS (Domain Name System)

The system, otherwise known as DNS, is necessary for any organization connected to the Internet. DNS provides name resolution between common names, such as mspress.microsoft.com, and raw IP addresses, which network layer components use for communication.

Active Directory makes extensive use of DNS technology to look up objects. This is a significant change from previous Windows operating systems, which require NetBIOS names to be resolved by IP addresses and rely on WINS or other NetBIOS name resolution techniques.

Active Directory works best when used with DNS servers running Windows 2000. Microsoft has made it easier for administrators to migrate to Windows 2000-based DNS servers by providing migration wizards that guide the administrator through the process.

Other DNS servers may be used. However, this will require administrators to spend more time managing DNS databases. What are the nuances? If you choose not to use DNS servers running Windows 2000, you must ensure that your DNS servers comply with the new DNS dynamic update protocol. Servers rely on dynamically updating their records to find domain controllers. It is not comfortable. After all, eIf dynamic updating is not supported, you must update the databases manually.

Windows domains and Internet domains are now fully compatible. For example, a name such as mspress.microsoft.com will identify the Active Directory domain controllers responsible for the domain, so any client with DNS access can find the domain controller.Customers can use DNS resolution to look up any number of services because Active Directory servers publish a list of addresses to DNS using new dynamic update features. This data is defined as a domain and published through service resource records. SRV RR follow the format service.protocol.domain.

Active Directory servers provide the LDAP service for object hosting, and LDAP uses TCP as the underlying transport layer protocol. Therefore, a client looking for an Active Directory server in the mspress.microsoft.com domain will look for the DNS entry for ldap.tcp.mspress.microsoft.com.

Global catalog

Active Directory provides a global catalog (GC) andprovides a single source for searching for any object on an organization's network.

The Global Catalog is a service in Windows 2000 Server that allows users to find any objects that have been shared. This functionality is far superior to the Find Computer application included in previous versions of Windows. After all, users can search for any object in Active Directory: servers, printers, users and applications.

Active Directory is a Microsoft directory service for the Windows NT family of operating systems.

This service allows administrators to use group policies to ensure uniformity of user work environment settings, software installations, updates, etc.

What is the essence of Active Directory and what problems does it solve? Read on.

Principles of organizing peer-to-peer and multi-peer networks

But another problem arises, what if user2 on PC2 decides to change his password? Then if user1 changes the account password, user2 on PC1 will not be able to access the resource.

Another example: we have 20 workstations with 20 accounts to which we want to provide access to a certain . To do this, we must create 20 accounts on the file server and provide access to the required resource.

What if there are not 20 but 200 of them?

As you understand, network administration with this approach turns into absolute hell.

Therefore, the workgroup approach is suitable for small office networks with no more than 10 PCs.

If there are more than 10 workstations in the network, the approach in which one network node is delegated the rights to perform authentication and authorization becomes rationally justified.

This node is the domain controller - Active Directory.

Domain Controller

The controller stores a database of accounts, i.e. it stores accounts for both PC1 and PC2.

Now all accounts are registered once on the controller, and the need for local accounts becomes meaningless.

Now, when a user logs into a PC, entering his username and password, this data is transmitted in private form to the domain controller, which performs authentication and authorization procedures.

Afterwards, the controller issues the user who has logged in something like a passport, with which he subsequently works on the network and which he presents at the request of other network computers, servers to whose resources he wants to connect.

Important! A domain controller is a computer running Active Directory that controls user access to network resources. It stores resources (eg printers, shared folders), services (eg email), people (user and user group accounts), computers (computer accounts).

The number of such stored resources can reach millions of objects.

The following versions of MS Windows can act as a domain controller: Windows Server 2000/2003/2008/2012 except Web-Edition.

The domain controller, in addition to being the authentication center for the network, is also the control center for all computers.

Immediately after turning on, the computer begins to contact the domain controller, long before the authentication window appears.

Thus, not only the user entering the login and password is authenticated, but also the client computer is authenticated.

Installing Active Directory

Let's look at an example of installing Active Directory on Windows Server 2008 R2. So, to install the Active Directory role, go to “Server Manager”:

Add the role “Add Roles”:

Select the Active Directory Domain Services role:

And let's start the installation:

After which we receive a notification window about the installed role:

After installing the domain controller role, let's proceed to installing the controller itself.

Click “Start” in the program search field, enter the name of the DCPromo wizard, launch it and check the box for advanced installation settings:

Click “Next” and choose to create a new domain and forest from the options offered.

Enter the domain name, for example, example.net.

We write NetBIOS domain name, without zone:

Select the functional level of our domain:

Due to the peculiarities of the functioning of the domain controller, we also install a DNS server.

The locations of the database, log file, and system volume are left unchanged:

Enter the domain administrator password:

We check the correctness of filling and if everything is in order, click “Next”.

After this, the installation process will begin, at the end of which a window will appear informing you that the installation was successful:

Introduction to Active Directory

The report discusses two types of computer networks that can be created using Microsoft operating systems: workgroup and Active Directory domain.