Основы работы в сети: Часть 5 — Контроллеры домена

• Основы работы в сети. Часть 7. Введение в роли FSMO
• Основы работы в сети. Часть 8. Роли FSMO (продолжение)
• Основы работы в сети, часть 11: консоль пользователей и компьютеров Active Directory
• Основы работы в сети. Часть 12. Управление учетными записями пользователей
• Основы работы в сети. Часть 13. Создание групп
• Основы работы в сети. Часть 14. Группы безопасности
• Основы работы в сети. Часть 15. Универсальные группы и вложение групп
• Основы работы в сети: Часть 16. Роль операционной системы Windows в сети
• Основы работы в сети. Часть 17. Модель OSI

В предыдущей статье этой серии я говорил о роли различных компьютеров в сети. Как вы, возможно, помните, одной из ролей, о которых я немного говорил, была роль контроллера домена. В этой статье я расскажу больше о том, что такое контроллеры домена и как они вписываются в вашу сетевую инфраструктуру.

Одним из наиболее важных понятий в сети Windows является понятие домена. Домен — это, по сути, набор учетных записей пользователей и учетных записей компьютеров, которые сгруппированы вместе, чтобы ими можно было управлять централизованно. Задача контроллера домена — упростить централизованное управление ресурсами домена.

Чтобы понять, почему это важно, учтите, что любая рабочая станция с Windows XP содержит несколько встроенных учетных записей пользователей. Windows XP даже позволяет создавать дополнительные учетные записи пользователей на рабочей станции. Если рабочая станция не работает как автономная система или не является частью одноранговой сети, эти учетные записи пользователей уровня рабочей станции (называемые локальными учетными записями пользователей) не используются для управления доступом к сетевым ресурсам. Вместо этого локальные учетные записи пользователей используются для регулирования доступа к локальному компьютеру. Они действуют главным образом как механизм, гарантирующий, что администраторы могут выполнять обслуживание рабочих станций, а конечные пользователи не имеют возможности вмешиваться в настройки рабочих станций.

Причина, по которой локальные учетные записи пользователей не используются для управления доступом к ресурсам за пределами рабочей станции, на которой они находятся, заключается в том, что это создало бы чрезмерную нагрузку на управление. Подумайте об этом на минуту. Учетные записи локальных пользователей находятся на каждой отдельной рабочей станции. Это означает, что если бы локальные учетные записи пользователей были основным механизмом безопасности сети, то администратору пришлось бы физически перемещаться к компьютеру, содержащему учетную запись, каждый раз, когда необходимо внести изменения в разрешения учетной записи. Это может не иметь большого значения в небольших сетях, но внесение изменений в систему безопасности будет чрезвычайно обременительным в больших сетях или в ситуациях, когда изменение необходимо применить глобально ко всем учетным записям.

Другая причина, по которой локальные учетные записи пользователей не используются для управления доступом к сетевым ресурсам, заключается в том, что они не перемещаются вместе с пользователем с одного компьютера на другой. Например, если компьютер пользователя вышел из строя, пользователь не мог просто войти на другой компьютер и работать, пока его компьютер ремонтировали, потому что учетная запись пользователя привязана к компьютеру, на котором произошел сбой. Чтобы пользователь мог выполнять какую-либо работу, необходимо создать новую учетную запись на компьютере, с которым он сейчас работает.

Это лишь некоторые из причин, по которым использование локальных учетных записей пользователей для защиты доступа к сетевым ресурсам нецелесообразно. Даже если вы захотите реализовать этот тип безопасности, Windows этого не позволит. Учетные записи локальных пользователей можно использовать только для защиты локальных ресурсов.

Домен решает эти и другие проблемы за счет централизации учетных записей пользователей (и других объектов, связанных с конфигурацией и безопасностью, о которых я расскажу позже). Это упрощает администрирование и позволяет пользователям входить в сеть с любого ПК в сети (если вы не ограничиваете, с каких компьютеров пользователь может входить в систему).

С информацией, которую я дал вам до сих пор относительно доменов, может показаться, что философия доменов заключается в том, что, поскольку ресурсы, к которым пользователям нужен доступ, находятся на сервере, вы должны использовать учетные записи пользователей на уровне сервера для управления доступом к этим ресурсам.. В некотором смысле эта идея верна, но в ней есть нечто большее.

Еще в начале 1990-х я работал в крупной страховой компании, которая управляла сетью с серверами под управлением Novell NetWare. Сеть Windows еще не была изобретена, и в то время в качестве серверной операционной системы была выбрана Novell NetWare. Когда меня наняли, в компании был только один сетевой сервер, на котором хранились все учетные записи пользователей и все ресурсы, к которым пользователям требовался доступ. Несколько месяцев спустя кто-то решил, что пользователям компании нужно запустить совершенно новое приложение. Из-за размера приложения и объема данных, создаваемых приложением, приложение было размещено на выделенном сервере.

Версия Novell NetWare, которую компания использовала в то время, использовала идею, которую я представил ранее, в которой ресурсы, находящиеся на сервере, были защищены учетными записями пользователей, которые также находились на этом сервере. Проблема с этой архитектурой заключалась в том, что у каждого сервера был свой собственный, полностью независимый набор учетных записей пользователей. Когда новый сервер был добавлен в сеть, пользователи вошли в систему обычным способом, но им пришлось вводить другое имя пользователя и пароль для доступа к ресурсам на новом сервере.

Сначала все шло гладко, но примерно через месяц после установки нового сервера дела пошли плохо. Пришло время пользователям сменить пароль. Пользователи не осознавали, что теперь им нужно менять пароль в двух разных местах. Это означало, что пароли не синхронизировались, а служба поддержки была завалена звонками, связанными со сбросом паролей. Поскольку компания продолжала расти и добавляла новые серверы, проблема еще больше усугублялась.

В конце концов, Novell выпустила версию 4.0 NetWare. NetWare версии 4 представила технологию под названием Служба каталогов. Идея заключалась в том, что у пользователей не должно быть отдельной учетной записи для каждого сервера. Вместо этого для аутентификации пользователей можно было использовать одну учетную запись пользователя независимо от того, сколько серверов было в сети.

В этом небольшом уроке истории интересно то, что, хотя домены уникальны для сетей Microsoft (сети Novell не используют домены), домены работают по тому же основному принципу. На самом деле, когда была выпущена Windows 2000, Microsoft включила функцию, которая используется до сих пор, под названием Active Directory. Active Directory очень похожа на службу каталогов, которую используют сети Novell.

Какое отношение все это имеет к доменам? Итак, на серверах Windows, работающих под управлением Windows 2000 Server, Windows Server 2003 или готовящегося к выпуску Longhorn Server, задача контроллера домена — запустить службу Active Directory. Active Directory действует как репозиторий для объектов каталога. Среди этих объектов есть учетные записи пользователей. Таким образом, одной из основных задач контроллера домена является предоставление услуг проверки подлинности.

Следует помнить одну очень важную концепцию: контроллеры домена обеспечивают аутентификацию, а не авторизацию. Это означает, что когда пользователь входит в сеть, контроллер домена проверяет имя пользователя и пароль пользователя и фактически подтверждает, что пользователь является тем, за кого себя выдает. Однако контроллер домена не сообщает пользователю, на какие ресурсы у него есть права.

Ресурсы в сетях Windows защищены списками управления доступом (ACL). ACL — это, по сути, просто список, в котором указано, кто на что имеет права. Когда пользователь пытается получить доступ к ресурсу, он представляет свою личность серверу, содержащему этот ресурс. Этот сервер удостоверяется, что личность пользователя была аутентифицирована, а затем сверяет личность пользователя со списком ACL, чтобы узнать, на что у пользователя есть права.

Вывод

Как видите, контроллер домена играет очень важную роль в сети Windows. В следующей части этой серии статей я больше расскажу о контроллерах домена и об Active Directory.

• Основы работы в сети. Часть 7. Введение в роли FSMO
• Основы работы в сети. Часть 8. Роли FSMO (продолжение)
• Основы работы в сети, часть 11: консоль пользователей и компьютеров Active Directory
• Основы работы в сети. Часть 12. Управление учетными записями пользователей
• Основы работы в сети. Часть 13. Создание групп
• Основы работы в сети. Часть 14. Группы безопасности
• Основы работы в сети. Часть 15. Универсальные группы и вложение групп
• Основы работы в сети: Часть 16. Роль операционной системы Windows в сети
• Основы работы в сети. Часть 17. Модель OSI