Monday, December 11th, 2017

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

Published on Февраль 18, 2009 by   ·   Комментариев нет

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

В предыдущей статье из этой серии я рассказал о роли различных компьютеров в сети. Как вы можете вспомнить, одна из ролей, которую я упоминал, была роль контроллера домена (domain controller). В этой статье мы расскажем о том, что такое контроллеры домена и об их функциях в вашей сетевой инфраструктуре. Одна из самых важных концепций в работе в сетях Windows связана с доменом. Обычно, домен – это набор учетных записей пользователей и учетных записей компьютеров, которые объединены вместе таким образом, что ими можно централизованно управлять. Задача контроллера домена заключается в обеспечении этого централизованного управления над ресурсами домена.

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

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

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

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

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

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

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

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

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

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

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

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

Безопасность ресурсов в сетях Windows обеспечивается с помощью списков контроля доступа (access control lists или ACL). ACL – это просто список, который говорит у кого на что есть права. Если пользователь пытается получить доступ к ресурсу, он предоставляет свою подлинность серверу, на котором содержится ресурс. Этот сервер проверяет, что подлинность пользователя прошла аутентификацию, а затем с помощью ссылок проверяет по списку ACL, на какие ресурсы у него есть права.

Заключение

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

www.windowsnetworking.com


Смотрите также:

Tags: , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]