Отчет по практике в АГЦТТ

Опять жмем Next >, в следующем окне жмем Install для запуска установки роли. Установили. Нажимаем Close.

Шаг 2. Жмем Пуск и в поле поиска пишем dcpromo и жмем Enter. Запустится мастер Active Directory Domain Services Installation Wizard.

Расширенный режим (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 высшего уровня, основанные на географии корпорации. Организационные единицы высшего уровня, основанные на географии, могут использоваться для делегирования административных задач. 

 

 

 

Рис. 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. Внедрите систему резервного копирования данных пользователей.**