авы. Введение Исследовательская часть
 Скачать 280.34 Kb.
|
|
Расширенный режим (Use advanced mode installation) нам не нужен, жмем Next >. Далее предупреждение о совместимости Жмем далее, в следующем окне установите переключатель на Create a new domain in a newforest, т.к. предполагается, что мы создаем новый домен в новом лесу. В следующем окне нужно ввести имя домена, у меня это будет home.local Чтобы получить все новые возможности управления доменом от Windows Server 2008, то в следующем окне выставляем режим функциональности — Windows Server 2008 R2. В следующем окне согласимся с добавлением DNS server Далее нам необходимо утвердительно ответить на запрос на продолжение, выбрав Yes Оставляем папки для Database, Log Files и SYSVOL по умолчанию В следующем окне необходимо придумать пароль для учетной записи Administrator. Далее будет выведена суммарная информация о сделанных настройках в ходе работы мастера. Начнется установка DC, можете отметить опцию Reboot on completion, т.к. после завершения установки обязательно нужно перезагрузить систему. После перезагрузки Вы заметите, что вход всистему будет уже не локальный, а вход в домен. Далее нам необходимо установить и настроить еще одну роль на этот контролер домена – DHCPServer. Шаг 3. Добавим нашему серверу роль DHCP Server, который будет отвечать за выдачу IP-адресов. Запускаем Server Manager и добавим роль. Все время жмите Next > пока не дойдете до следующего окна: В поле Preferred DNS server Ipv4 address введем IP-адрес нашего DNS-сервера, у меня это будет 10.10.10.10. В следующем окне мастер спрашивает о WINS-сервере. Укажем ему IP нашего контролера домена. Позже возможно нам понадобится эта функция. Вот и дошли до главной настройки DHCP, собственно он для этого и создается. Это создание диапазона выдачи IP-адресов для клиентов DHCP. В окне Add or Edit DHCP Scopes нажмем Add… В открывшемся окне задаем: Scope name: — имя диапазона, может быть любым; Starting IP address: — начальный IP адрес диапазона; Ending IP address: — конечный IP адрес диапазона; Subnet mask: — маска подсети; Default gateway (optional): — шлюз по умолчанию. Заметьте, что диапазонов может быть несколько, чтобы задать еще один – жмем Add… На следующей странице нас спрашивают об использовании IPv6. Я пока ip протокол версии 6 использовать не буду, поэтому поставлю Disable. Потом если понадобится Ipv6 можно его подключить. В следующем окне оставляем по умолчанию. В следующем окне еще раз проверьте сводную информация о сделанных настройках и нажмитеInstall. В конце процесса установки вы должны увидеть Installation succeeded в зеленом цвете. Итак, подведем итоги. Теперь наш сервер полностью готов выполнять роли Domain Controller,DNS Server и DHCP Server. 3. Задание № 3 Постановка задачи: Создайте в соответствии с разработанными Вами политиками: 1. Организационные единицы** 2. Учетные записи пользователей (для примера в каждой организационной единице)** 3. Учетные записи компьютеров (по одному: ноутбук/рабочая станция, в каждой организационнойединице)** 4. Структуру каталогов для хранения данных: пользователей, данных отделов, данных филиала** Выполнение: Организационные единицы характеризуются следующим: - Проектирование OU не оказывает влияния на проектирование пространства имен DNS. OU получают имена каталога в пределах пространства имен DNS. Например, организационная единица может иметь отличительное имя OU=ManagersOU, OU=AdministrationOU, DC=Contoso, DC=Com. В этом случае Contoso.com является DNS-име-нем, а LDAP-имена внутри пространства имен DNS являются именами OU; - Организационные единицы могут быть созданы внутри других единиц. По умолчанию административные права и параметры настройки Group Policy(Групповая политика), установленные на верхнем уровне единиц OU, наследуются дочерними OU. Это поведение может быть изменено; - Организационные единицы ОU прозрачны для конечных пользователей. Когда пользователь ищет объект в Active Directory, приложение пользователя делает запрос об этой информации к GC-каталогу. Пользователю не требуется знать структуру OU, чтобы сделать вход в систему или найти объекты в Active Directory; - По сравнению с другими компонентами Active Directory, такими как домены и леса, структуру OU легко изменить после развертывания. Перемещение объектов между OU сводится к щелчку правой кнопкой мыши на объекте и выбору Move (Переместить) из контекстного меню. Одна из причин создания структуры OU заключается в возможности делегирования административных задач. Все это становится возможными путем создания структуры OU в Active Directory и последующим делегированием административного доступа. Возможно представление любого уровня административного доступа на уровне OU. Если вы создаете OU для отдаленного офиса, вы можете представить его администратору полное управление объектами этого офиса. Администратор может выполнять любую административную задачу в этой OU, включая создание дочерних OU и делегирование разрешений другим администраторам. Если вы создаете OU для каждого отдела, вы можетепредоставить очень специфические права, типа права сбрасывания паролей, нескольким пользователям в отделе. Можно предоставить административные права, основанные на типах объектов в OU, например, администраторы отдела могут изменять учетные записи пользователя, но не объекты групп или компьютеров. В главе 9 содержится подробная информация о делегировании администрирования. Следует прочесть эту главу перед созданием проекта OU. Для большинства компаний организационные единицы высшего уровня будут разрабатываться на основе требований, связанных с делегированием администрирования. Скорее всего, эти единицы OU будут основаны на географическом месте расположения офисов компании или на деловых подразделениях. Эти границы OU будут также и административными границами. Проект 0U, основанный на проекте групповых политик Вторая причина для создания OU заключается в управлении назначением групповых политик. Групповые политики используется для изменения и управления конфигурацией рабочих столов. С помощью групповых политик можно обеспечить пользователям стандартную конфигурацию рабочего стола, включая автоматическую инсталляцию набора приложений. Групповая политика может управлять изменениями, которые пользователи выполняют на своих компьютерах, и конфигурировать параметры настройки защиты. Почти все групповые политики в Active Directory назначаются на уровне OU, так что развертывание групповых политик будет играть важную роль в проекте OU. При планировании структуры OU вы группируете вместе объекты, которые требуют одинаковых параметров настройки групповой политики. Например, если всем пользователям одного отдела требуется одинаковый набор приложений, их можно установить, используя групповую политику. Пользователи могут нуждаться в стандартном наборе отображаемых дисков (mapped drives). Сценарии входа в систему для пользователей можно назначить, также используя групповую политику. Возможно, что вы захотите применить шаблон защиты ко всем файловым серверам вашей организации. Чтобы сделать это,сгруппируйте все файловые серверы в OU и назначьте шаблон защиты, используя групповую политику. В большинстве компаний низкие требования к уровню проекта OU будут определяться, прежде всего, потребностью применения групповой политики. По умолчанию все групповые политики наследуются от родительских OU. Это означает, что вы можете применить групповую политику на высоком уровне в структуре OU, а затем применить специфичную групповую политику на более низком уровне. Если нужно изменить заданное по умолчанию наследование групповой политики, это можно сделать, создав OU и заблокировав любое наследование групповой политики на уровне OU. Такая зависимость проекта OU от групповых политик означает, что вы должны понять функциональные возможности групповых политик и требования вашей организации. В главах 11, 12, 13 подробно обсуждается, что можно делать с помощью групповых политик. Создание проекта OU Начните разрабатывать проект OU с организационных единиц высшего уровня. Их труднее модифицировать после развертывания из-за OU, расположенных ниже. OU высшего уровня должны основываться на чем-то неизменном: на географических регионах или деловых подразделениях. Проект OU, основанный на географии компании, вероятно, будет наиболее устойчив к изменениям. Некоторые компании часто реорганизуются, но редко изменяют географическую конфигурацию. Структура OU, основанная на географии компании, хорошо работает, если компания использует децентрализованную административную модель, основанную также на географии. Если каждое географическое место (один офис или центральный офис с несколькими филиалами) имеет свой собственный набор сетевых администраторов, то географические OU могут использоваться для делегирования административных задач этим администраторам. Основной недостаток структуры OU, основанной на географии, проявляется тогда, когда возникает несколько деловых подразделений в каждом географическом месте. Например, если каждый отдел представлен в каждом офисе компании, более эффективно на высшем уровнеиспользовать структуру OU, основанную на деловых подразделениях. Вторая структура OU высшего уровня основывается на деловых подразделениях. В этой модели OU высшего уровня создается для каждого делового подразделения в пределах корпорации. Этот тип конфигурации является наиболее подходящим, если компания находится в одном месте или если многие административные задачи делегируются на уровень делового подразделения. Проблема, которая может возникнуть, заключается в том, что OU высшего уровня изменятся в случае реорганизации компании. Большинство крупных корпораций фактически будут использовать комбинацию единиц, основанных на географии и на деловых подразделениях. Обычная конфигурация - это OU высшего уровня, основанные на географических регионах, со следующим уровнем OU в пределах каждого региона, основанных на деловых подразделениях. Некоторые компании могут выбрать OU высшего уровня, основанные на деловых подразделениях, а затем создавать под высшим уровнем структуру OU, основанную на географии. На рисунке 8 показан проект OU для крупной компании. OU высшего уровня включает Domain Controllers OU (OU контроллеров домена) (все контроллеры домена расположены в этой OU) и OU администраторов уровня домена. OU высшего уровня могут включать OU службы учетных записей для всех служебных учетных записей (Service Account), используемых в домене. Создание на высшем уровне OU для специальных учетных записей пользователей, таких как служебные учетные записи, упрощает их администрирование. OU высшего уровня могут включать OU серверов, если все серверы управляются централизованно. В дополнение к этим административным OU могут быть также OU высшего уровня, основанные на географии корпорации. Организационные единицы высшего уровня, основанные на географии, могут использоваться для делегирования административных задач. [pic] Рис. 8. Типовая структура OU OU второго уровня в каждом географическом регионе основаны на деловых подразделениях региона. OUбизнес-подразделений могли бы использоваться для делегирования администрирования, а также для назначения групповых политик. Под деловыми OU располагаются OU, основанные на отделах. На этом уровне OU будет использоваться для назначения групповых политик или определенных административных задач, типа права сброса паролей. OU отделов могут содержать другие OU. - OU учетных записей - содержит учетные записи пользователей и групп отдела. В некоторых случаях OU учетных записей разбиваются на OU, содержащие группы, учетные записи пользователей или удаленных пользователей. - OU компьютеров - содержит все пользовательские компьютеры и включает отдельные OU компьютеров с системой Windows NT, Windows 2000, Microsoft Windows XP Professional и OU портативных компьютеров. - OU ресурсов - содержит ресурсы, связанные с данной OU. Включает домены локальных групп, серверы, принтеры и совместно используемые папки. - OU приложений или проектов. Если группа людей и ресурсов работают над определенным проектом (приложением), который требует уникального управления, можно создать структуру OU для этих пользователей, а затем сгруппировать пользователей, ресурсы и компьютеры, необходимые для данного проекта, в OU. Теоретически, не существует ограничения на количество уровней, которое может иметь ваша структура OU. Обычно практический опыт подсказывает, что не нужно иметь более десяти уровней. Для большинства компаний структура OU, состоящая из четырех или пяти уровней, — это все, что может когда-либо потребоваться. Работая над созданием проекта OU, нужно его тщательно задокументировать. Проект будет включать диаграмму структуры OU, список всех организационных единиц OU и цели каждого OU. Если вы используете OU для делегирования административных задач, задокументируйте права, делегированные каждому уровню OU. Развертывая групповую политику, связанную с каждым OU, задокументируйте конфигурацию групповых политик. 4. Задание № 4 Постановка задачи: 1. Внедрите политику безопасности, согласно которой,пользовательский пароль должен быть ни менее 8 знаков и быть комплексным. Пароль должен меняться по истечении 25 дней. Учетная запись пользователя должна блокироваться в случае 7 неудачных попыток входа.** 2. Внедрите систему резервного копирования данных пользователей.** 3. Внедрите систему аудита доступа к документам, принадлежащим административному отделу** 5. Разработайте документ «План восстановления работы Домена после сбоя». * Выполнение: «Политики учетных записей». Применение этих политик распространено в предприятиях с доменной средой. Для обеспечения безопасности ваших компьютеров, применение политик этой группы на компьютерах, не входящих в доменную среду (например, использование политик на вашем домашнем компьютере) поможет вам существенно повысить безопасности компьютера. Для того чтобы найти политики, предназначенные для управления учётными записями, в редакторе управления групповыми политиками откройте узел Конфигурация компьютера\Параметры безопасности\Политики учетных записей. Рассмотрим подробно каждую политику безопасности, которая применяется для управления паролями и блокировкой учетных записей пользователей. Политика паролей. При помощи этого узла вы можете изменять настройки паролей учетных записей пользователей, которые состоят как в домене, так и в рабочих группах. В организациях вы можете применять одинаковые политики паролей для всех пользователей, входящих в домен или только для отдельных групп при помощи оснастки «Консоль управления групповыми политиками». В узле «Политика паролей» вы можете использовать до шести политик безопасности, при помощи которых можно указать наиболее важные параметры безопасности, применяемые для управления паролями учетных записей. Доступны следующие политики безопасности: Вести журнал паролей. Насколько не был бы ваш пароль безопасным, злоумышленник рано или поздно сможет его подобрать. Поэтому необходимо периодически изменять пароли учетных записей. При помощи этой политики вы можете указатьколичество новых паролей, которые назначаются для учетных записей до повторного использования старого пароля. После того как эта политика будет настроена, контроллер домена будет проверять кэш предыдущих хэш-кодов пользователей, чтобы в Рис. 9 Узел «Политика паролей» качестве нового пароля пользователи не могли использовать старый. Число паролей может варьироваться от 0 до 24. Максимальные срок действия пароля. Эта политика указывает период времени, в течение которого пользователь может использовать свой пароль до последующего изменения. По окончанию установленного срока пользователь обязан изменить свой пароль, так как без изменения пароля войти в систему ему не удастся. Доступные значения могут быть установлены в промежутке от 0 до 999 дней. Если установлено значения равное 0, срок действия пароля неограничен. Минимальная длина пароля. При помощи этой политики вы можете указать минимальное количество знаков, которое должно содержаться в пароле. Если активировать этот параметр, то при вводе нового пароля количество знаков будет сравниваться с тем, которое установлено в этой политике. Если количество знаков будет меньше указанного, то придется изменить пароль в соответствии с политикой безопасности. Минимальные срок действия пароля. Многие пользователи не захотят утруждать себя запоминанием нового сложного пароля и могут попробовать сразу при вводе изменить такое количество новых паролей, чтобы использовать свой хорошо известный первоначальный пароль. Для предотвращения подобных действий была разработана текущая политика безопасности. Вы можете указать минимальное количество дней, в течение которого пользователь должен использовать свой новый пароль. Доступные значения этой политики устанавливаются в промежутке от 0 до 998 дней. Установив значение равное 0 дней, пользователь сможет изменить пароль сразу после создания нового. Пароль должен отвечать требованиям сложности. Это одна из самых важных политик паролей, которая отвечает за то, должен ли пароль соответствовать требованиямсложности при создании или изменении пароля. В связи с этими требованиями, пароли должны: • содержать буквы верхнего и нижнего регистра одновременно; • содержать цифры от 0 до 9; • содержать символы, которые отличаются от букв и цифр (например, !, @, #, $, *); • Не содержать имени учетной записи пользователя или частей полного имени пользователя длиной более двух рядом стоящих знаков. Хранить пароли, используя обратимое шифрование. Для того чтобы пароли невозможно было перехватить при помощи приложений, Active Directory хранит только хэш-код. Но если перед вами встанет необходимость поддержки приложений, использующих протоколы, требующие знание пароля пользователя для проверки подлинности, вы можете использовать текущую политику. Обратимое шифрование по умолчанию отключено, так как, используя эту политику, уровень безопасности паролей и всего домена в частности значительно понижается. Использование этой функции аналогично хранению пароля в открытом виде. |