Directory services (на основе курса Google IT Support Professional)
Directory services – сервисы по управлению политиками, примеры – Active Directory (proprietary, not free), OpenLDAP (open, free), Astra Linux Directory, FreeIPA. Оба они и ряд других сервисов полагаются (в основном) на открытые стандарты – в основном x.500 с протоколами Directory Access Protocol (DAP, в последующем Lightweight DAP – LDAP), Directory System Protocol (DSP) и другими. Позволяют создавать иерархическую древовидную структуру (data information tree, структура удобная для получения данных, но не очень для записи, похожа на файловую систему) с помощью Organization Units (OU, аналогия в ФС – папка), на подобии файловой системы (forest -> domains -> group of resources). По умолчанию OU не созданы и их нужно создать, чтобы в последующем применить GPO политики на них. Непосредственно объектами (entity) присваиваются уникальные distinguish name (DN, в аналогии ФС – полный путь к файлу).
Things organized in a directory server by a hierarchical model of objects and containers
Древовидная структура directory service предоставляет возможность наследия и вложенности, когда атрибуты и свойства родительского объекта наследуются подчиненными.
Преимущества использования directory services:
- централизация ААА – Directory services представляют централизованный сервис AAA. Сюда входит не только доступ к конкретной машине, но и предоставление доступа к приложениям, файлам и прочим сетевым ресурсам.
- централизация политик и разнообразие,
- автоматизация за счет удаленного применения,
- в Directory Service так же встроены возможности Configuration Management – можно следить за софтом на пк/принтерах и даже периферийных устройствах, настраивать софт и прочее.
Active Directory (AD) – родной для Windows directory service. Может работать не только с Windows, но и с Linux, OSX и прочими машинами/серверами не на базе Windows используя LDAP.
OpenLDAP – бесплатный открытый аналог AD. Может так же как и AD работать с разными ОС, используя LDAP. Хотя и для Windows безусловно лучше AD. Управление возможно командами или phpldapadmin (web аналог GPMC).
Rbac – Role based access control – даем привилегии на основе роли пользователя, а не учетной записи. Очень важный аспект в directory services. Политики могут назначаться по принадлежности к группе или вышестоящей группе (inherit), а не по учетной записи. Очень круто, говорю как своего рода сисадмин. На практике преимущества будут заметны от такого подхода уже при 50 пользователях (в wiki 500) в нескольких разных (по правам) группах.
Instead of assigning access for each user account individually, RBAC is a more efficient and easier-to-manage approach.
LDAP – lightweight directory access protocol. Основной протокол в Directory services. Он используется для получения информации в Directory services используя сеть, операций CRUD, аутентификации и авторизации клиента в Directory services (bind operation) и другими операциями с directory services. LDAP используется и AD и OpenLDAP. LDAP создает записи, имеющие какую то информацию (например: учетка такая то, группа такая то, в домене таком то) которые называются LDAP entries. Тут о формате LDAP.
Самые частые операции между клиентом и LDAP сервером:
- LDAP bind operation – процесс аутентификации пользователя в Directory Services. Бывают три типа аутентификации – anonymous (по сути без аутентификации вовсе), simple (без шифрования), SASL (simple authentication & security level – с шифрованием, обычно с использованием Kerberos, хотя могут быть согласованы и другие способы между клиентом и сервером).
In anonymous bind, credentials aren't actually required. Simple bind uses simple username and password authentication and is usually not encrypted. Lastly, SASL incorporates some added security layers to protect credentials.
- StartTLS – дает возможность работать с LDAP используя LDAPv3 поверх TLS
- Search – для поиска и получения записей из LDAP
- Add/delete/modify – для модификации данных
- Unbind – закрытие соединения с LDAP сервером
DC – Domain Controller – контроллер домена, имеет функционал базы данных домена, аутентификатора, DNS, backup для всей этой инфы через replication (RPC over IP or mail smtp).
A Domain Controller holds a replica of the Active Directory database + represents a gpo server + Kerberos authentication server
DC могут работать почти во всех случаях (кроме ряда операций, в таких случаях один master-slave, называется это FSMO) одновременно в режиме read-write, а не один master, остальные slave. Комп узнает адрес контроллера делая запрос в DNS на запись SRV.
Client discover the address of a domain controller through DNS query, asking for the SRV record for the domain.
Компьютер не в домене находятся в Workgroup, такие компьютеры не управляются через AD. Для подключения/присоединения компа к домену (join to the domain) нужна настройка как на домене (знает о компе), так и на компе (знает о домене). После подключения к домену нужна перезагрузка.
SamAccountName – SAM – это username при создании учетки в AD. Учетки должны быть уникальны в пределах домена.
AD с версиями Windows Server обрастал новыми фичами, новая версия AD увеличивает functional level (FL). В зависимости от уровня поддерживается тот или иной функционал (чем выше уровень, тем больше фич). Требования к рабочим станциям functional level не накладывает, но накладывает к серверам-контроллерам домена. Уровни функциональности бывают для Forest (FFL) и Domain (DFL) (уровент может быть выше Forest, но не ниже).
Группы в AD
Группы бывают двух типов – security (доступ к каким то ресурсам), destribution (списки мейл рассылки).
Security groups can be used to provide access to resources, while distribution groups are only used for email communication.
group nesting – группу можно добавить в родительскую группу (иерархия типа отдел в департамент), что может быть крайне полезно при назначении прав.
Group scope бывает трех видов (domain local – группа для предоставления разрешений в домене, global – role based группа, universal – группа распространяется на весь forest, используется чаще всего для объединения global групп разных доменов одного forest между собой, но может объединять и просто учетки/domain local группы в одном лесу)
Пароли и авторизация
-
Kerberos (от греческого трехголового пса Цербера, защищающего ворота подземного мира) – протокол аутентификации по сети, который используется для аутентификации (клиента-сервера, сервера-сервера, причем обоих), обеспечивает безопасность шифрования учетных данных (аутентификация в незащищенной среде) и прочее. Основан на симметричном шифровании. У Microsoft есть своя реализация с допилами. В своей работе использует “tickets” – своего рода токен, который подтверждает твою личность для определенного сервиса, не требуя login/password, ticket валиден какое-то время, а потом переобновляется. Опубликован еще в далеком 1980. Kerberos лучше NTLM (например в контексте поддержки сервисам на локальном компе авторизации на удаленных хостах, поддержки mutual authentication, которая обеспечивается tickets – которых нет в NTLM). Использует синхронное шифрование (напр. AES или древний RC4) и checksum для защиты от подслушивания и повторения сообщений. Для Kerberos аутентификации обязателен tcp/ip канал, синхронизированное между хостом и сервером (сервером-сервером) время, рабочий dns для резолва сервера, SPN).
- Схема работы Kerberos сложна (см. ниже) и имеет single point of failure в лице kerberos сервера – за что kerberos не любят. Кроме того, если поломать kerberos сервер, атакующий может представиться любым пользователем в любом сервисе, который использует kerberos для аутентификации.
- Для корректной авторизации должно совпадать UTC время (не обязательно timezone) в пределах 5 минут между ПК на котором авторизовывается пользователь и контроллером домена – это требование накладывает Kerberos. Чаще всего проблем никаких нет т. к. для синхронизации используется один time server.
- AD/компы чаще всего не хранят пользовательские пароли, а хранят hash от них
- AD блочит аккаунт после определенного количества неуспешных авторизаций.
- После сброса пароля администратором могут не открываться зашифрованные файлы, если использовался NTFS EFS (encrypting file system).
Как работает kerberos:
После первой аутентификации-авторизации пользователя на компе его пользовательские данные сохраняются в виде секретного симметричного ключа шифрования (Kerberos client software) на локальном ПК и последующие ААА процедуры (по крайней мере до истечения пароля) возможны без связи с контроллером AD.
Далее kerberos клиент отправляет kerberos серверу kerberos AS (Authentication Server) сообщение, в котором указывается ID пользователя, который проходит аутентификацию, при это пароль и секретный ключ не передаются. Сервер проверяет наличие такого ID в базе (например, в базе AD). Если есть, сервер генерирует секретный ключ на основе hash пароля, который есть в базе (key distribution center server). Сервер AS использует этот ключ для шифрования сообщения, которое включает client TGS (ticket granting service) session key. Это секретный ключ, который используется для шифрования данных в последующем. Так же AS отправляет сообщение с TGT (ticket granting ticket), которое зашифровано TGS secret key (используется для дешифрование второго сообщение), TGT включает информацию по client ID, ticket validity period, client granting service session key (ради чего все затевалось). После получения TGT клиент может получить доступ к сервису в рамках kerberos realm – клиент в рамках request ticket запрашивает у TGS сервера доступ к сервису по ID/name сервиса, в сообщение так же включается authenticator message (зашифрованные с помощью TGS key (получен ранее от AS) client ID + timestamp). TGS, получив такое сообщение дешифрует TGT используя TGS key, далее ключ используется для дешифрование authenticator message, проверяется совпадение на client ID. Если совпадает – сервер отсылает два сообщения: client to server ticket (client id, address, validity period, client-server session key зашифрованный service secret key), client-server session (зашифрован TGS session key). После этого клиент (наконец то) имеет достаточно информации чтобы аутентифицировать себя на SS (Service Server). Клиент отправляет 2 сообщения SS: encrypted client-server ticket полученный от TGS, новый authenticator с client ID + timestamp (зашифрован client-server session key). SS расшифровывает первое сообщения, используя свой secret key, который дает в результате client-server session key. Этот ключ используется для декодирования сообщения authenticator. Сравниваются client ID (в authenticator и в client-server ticket). Если совпадают и клиент авторизован для этого сервиса – SS отправляет сообщение с timestamp клиенту, которое зашифровано client-server session key. Клиент дешифрует это сообщение и проверяет timestamp. Если все ок – МОЖНО ПОЛЬЗОВАТЬСЯ СЕРВИСОМ О БОЖЕ.
Kerberos issues tickets, which represent authentication and authorization tokens. Where the authentication server handles authentication of the user, the ticket granting service determines authorization for a given service. Once authenticated, a Kerberos client receives a ticket-granting ticket from the authentication server. This TGT can then be presented to the ticket-granting service in order to be granted access to a resource.
Trust модель Kerberos проблемная – нужно в Kerberos сервере прописать доверие между клиентами и сервисами. Неизвестные для Kerberos клиенты не смогут получить доступ “по умолчанию” (BYOD слажна).
GPO
AD является репозиторием для политик GPO (Group Policy Obdject), которые могут применятся на компьютеры (в момент загрузки)/пользовательские аккаунты (в момент подключения)/события (logon/logoff/events)/софт (какой ставить и запускать можно, а какой нет) и проч – по сути роль CMS. Многие политики GPO как для OS, так и для приложений представляют собой значения в реестреWindows (windows registry). Политики GPO применяются к объектам – доменам, сайтам, OU. С помощью WMI (Windows Management Instrumentation) политики могут применятся к конкретным компам на основе сложных условий (например, наличия на компе определенного hardware/software), но WMI довольно напряжен из-за того что 1) требует ответа от компа 2) сложно настраивается. Политики по сути есть настройки, но с точки зрения терминологии и фактически это разные вещи – политики применяются AD и не могуит изменятся пользователем, а настройки, которые применяются через AD могут изменятся пользователем. т. е. например можно задать обои на рабочем столе по умолчанию через настройку и тогда пользователь при желании сможет их сменить. А вот если задать через политику – не сможет.
A policy is enforced by AD, while a preference can be modified by a local user.A preference can be set via GPO, which allows you to modify default options, while still allowing users to change them.
Чтобы применять политики к группе ПК создается OU, которая как то эти ПК объединяет и применяют GPO к этой OU. По умолчанию есть Default Domain (Controller) Policy, которые применяются ко всему домену. GPO хранятся в SYSVOL директории (там же могут быть и loging/logoff scripts), которая реплицируется между всеми контроллерами домена. Политики создаются/редактируются/просматриваются через GPMC (Group Policy Management Console) или AGPM (Advanced Group Policy Management – GMPC + доп. допилы Microsoft к нему, например VCS для GPO) . Перед внедрением новых политик GPO зачастую происходит тестирование этих политик (куда применятся) и backup предыдущих политик – все это можно сделать в GPMC. Примерный алгоритм: тестирование -> генерация бекапа политики на основе теста -> накатываем из бекапа на продакшн, предварительно делаем бекап этого продакшн. В настройках политики можно прочитать подробное описание этой политики. Если политика не определена, то она не применяется. Не бывает GPO которые имеют доступы к особым настройкам, каждый имеет доступ к одним и тем же. Подробно про разные политики GPO можно почитать в GPSR – Group Policy Settings Reference. В актуальном файле excel описано более 4к разных политик.
Применение GPO может происходить не мгновенно по разным причинам:
1) чтобы сильно не увеличивать по времени процедуру авторизации logon на компьютере (Fast Logon Optimization)
2) применятся могут только изменения в GPO, а не сам GPO
3) компьютеру нужна перезагрузка для применения политики
4) комп подключен к другому ad-контроллеру (не на котором произошло изменение) и репликация идет с задержкой или поломалась
Такие изменения произойдут, но со временем. Можно ускорить процедуру заставив применить GPO прямо сейчас через команду gpuupdate/force. Если добавит в конце еще /sync то произойдет logout и перезагрузка ПК.
Может быть создан профиль по умолчанию (например политики безопасности для всей компании), а в других, более специфичных GPO конфликтные этому профилю настройки (например кому то разрешать использовать макросы в excel). В случае применения нескольких GPO к одному объекту с одинаковыми настройками, установятся настройки той, которая имеет меньший номер (обратная ACL логика – применяется последним GPO с меньшим precedence номером, а не большим). В случае применения нескольких GPO к одному объекту выигрывает та, которая применена к самому специфичному, меньшему контейнеру (внизу иерархии).
Order of enforcement of GPOs Site --> Domain --> OU
Пример на скрине – первая политика будет применена последней, соответственно то, что описано в ней будет замещать все остальное, если оно конфликтит с другим.
Для понимания того какие политики применены к ПК и/или пользователю делается RSoP report (Resultant Set of Policy) – через AD он запускается, вызывается на удаленном компе, исполняется и отчет высылается обратно в AD GPMC (есть и другие способы генерации RSoP, например на локальном пк – gpresult /R в powershell). Там можно посмотреть какой GPO применил какую настройку в результате.
Resultant Set of Policy, report will generate a report that contains a list of policies that will be applied to a given machine. It takes into account inheritance and precedence information.