ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 28.04.2024
Просмотров: 45
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Для создания новой группы выделим контейнер, в котором будем создавать группу и в меню «Действия» в пункте «Создать» выбираем «Группа» Открывается окно создания группы. Указываем следующие параметры:
-
Имя группы: Служащий -
Область действия группы: Локальная в домене -
Тип группы: Группа безопасности
-
Имя группы: Руководитель -
Область действия группы: Глобальная -
Тип группы: Группа безопасности
-
Имя группы: Специалист по безопасности -
Область действия группы: Глобальная -
Тип группы: Группа безопасности
Добавим нашу группу безопасности «Служащий» в локальную группу «Пользователи»
Чтобы включить глобальную группу в локальную, заходим в свойства группы во вкладку "Член групп" и нажимаем кнопку "Добавить". Добавляем глобальные группы в соответствие с нашим условием
Создадим новых пользователей:
| № | Пользователь | Пароль | Группа |
| 1 | Виктор | 123456ю. | Руководитель |
| 2 | Олег | 123456ю. | Специалист по безопасности |
| 4 | Мария | 123456ю. | Сотрудник |
Чтобы создать нового пользователя, выбираем контейнер (Users) и в меню «Действия» в пункте «Создать» выбираем «Пользователь»
Далее присвоим учётным записям членство в группах. Для этого заходим в свойства учётной записи пользователя и заходим во вкладку «Член групп» и добавляем нужную группу.
Руководитель
Специалист по безопасности
Сотрудник
Теперь для организации ограничений пользователям на программы создадим новую локальную группу в домене.
Занесем в эту группу учётные записи пользователей «Мария» и «Виктор»
Рассмотрим, как можно ограничить запуск программ.
Для этого существует оснастка «Локальная политика безопасности».
По умолчанию политика не определена, ее необходимо создать, для чего кликнув правой кнопкой мыши по ней выбираем в меню «Действие» пункт «Создать политики ограниченного использования программ».
В результате мы видим две появившиеся вкладки: «Уровень безопасности» и «Дополнительные правила».
В уровне безопасности создались два правила: «Не разрешено» и «Неограниченный», причем по умолчанию установлен уровень «Неограниченный», эти два уровня определяют, что делать с программой в правиле – разрешать или запрещать ее выполнение, данную вкладку мы оставим без изменения.
А вот запрещать запуск программ, не относящихся к служебной деятельности сотрудников будем во вкладке «Дополнительные правила». Первый и самый простой способ запретить запуск ПО – это запрет накладываемый на запуск по пути исполняемого файла. Делаем правый клик мыши и выбираем пункт «Создать правило для пути», в открывшемся окне по кнопке «Обзор» выбираем программу, задаем уровень безопасности «Не разрешено» и составляем описание для правила.
Но что делать, если пользователь продвинутый просто изменил имя файла? Тут на помощь приходит возможность создавать правила для файлов не по их именам и пути, а по их хешу. Хэш – это своего рода цифровой отпечаток файла, то есть мы можем изменить имя файла или его расширение, но его хеш останется не изменен.
Зайдем от учетной записи Korelin_2 и проверим ограничение.
Следует отметить, что если даже пользователь принесет на носителе данное приложение, то он ее все равно не сможет запустить.
Итоговая таблица
Учетные записи
| Имя учетной записи | Член глобальной группы | Член локальной группы |
| Виктор | Руководитель | Ограничение запуска |
| Олег | Специалист по безопасности | |
| Мария | Сотрудник | Ограничение запуска |
Глобальные группы
| Имя глобальной группы | Член глобальной группы | Член локальной группы |
| Руководитель | Администратор предприятия | Пользователи |
| Специалист по безопасности | Администраторы | Пользователи |
| Сотрудник | – | Пользователи |
Локальные группы
| Имя учетной записи | Член глобальной группы | Член локальной группы |
| Ограничение запуска | – | – |
Вывод:
Мы спланировали модель доменной сети небольшой организации. Сформулировали требования и специфические условия работы заданных пользователей. Создали учетные записи пользователей. Представими в виде схемы.
7. Изучить процесс аутентификации пользователя с помощью доменной учетной записи и роль протокола Kerberos. С помощью команды klist найти билеты Kerberos в локальном кэше, определить их назначение и свойства. Очистить кэш и показать динамику получения билетов Kerberos определенными службами. Показать важность свойств меток времени Kerberos и необходимость синхронизации системного времени на компьютерах домена.
Выполнение
Kerberos — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический разделяемый секрет, при условии, что пакеты, проходящие по незащищенной сети, могут быть перехвачены, модифицированы и использованы злоумышленником. Kerberos построен на криптографии симметричных ключей и требует наличия центра распределения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определенных этапах аутентификации.
Kerberos применяется всякий раз, когда
-
пользователь регистрируется на компьютере, присоединенном к AD -
при доступе к сетевым ресурсам, таким как общие папки и приложения.
Вместо того чтобы передавать через сеть конкретный пароль, Kerberos работает с последовательностью билетов. На высоком уровне это выглядит так: при регистрации пользователя на компьютере формируется серия обменов данными с контроллером домена (DC), и в случае успеха пользователю назначается билет на право получения билетов (TGT). Впоследствии при каждом обращении к службе, такой как общая папка или приложение, TGT используется, чтобы получить билет для доступа к службе или приложению.
Схема работы Kerberos :
Пользователь вводит имя и пароль на клиентской машине.
Клиентская машина выполняет над паролем одностороннюю функцию (обычно хеш), и результат становится секретным ключом клиента/пользователя.
Аутентификация клиента:
Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения мандатов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:
-
Идентификатор клиента, его метка времени и идентификатор сервера.
Если политика KDC требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но уже c данными для установления подлинности.
СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP), включающее:
-
Сессионный ключ клиента или TGS, идентификатор TGS и время жизни мандата, зашифрованные секретным ключом клиента. -
TGT (который включает идентификатор и сетевой адрес клиента, метку времени KDC, период действия мандата и сессионный ключ клиента или TGS), зашифрованный секретным ключом TGS.