Как клиенты Linux, присоединенные к домену, отправляют события безопасности в AD (KDC)

Вопрос 1. Как и где генерируются события в клиенте Linux? Я хочу знать, какие файлы генерируют упомянутые выше события безопасности, чтобы я мог более внимательно их изучить и при необходимости изменить.

Клиенты AD не отправляют явные события безопасности. (Разрешить им генерировать произвольные события было бы... небезопасно.) Все, что регистрируется как событие на контроллере домена, регистрируется самим контроллером домена и является результатом какого-либо другого действия, выполняемого клиентом с контроллером домена.

Например, контроллер домена будет регистрировать событие 4768 только тогда, когда он обрабатывает фактическое сообщение Kerberos AS-REQ (для выдачи исходного билета Kerberos); если клиент проходит аутентификацию, например, используя старый протокол Netlogon вместо Kerberos, контроллер домена не регистрирует 4768.

Наша проблема заключается в некоторых значениях (полях) в этих событиях (например, TargetUserName показывает имя хоста вместо имени пользователя — нам нужно, чтобы оно отображало имя пользователя, чтобы наш агент SSO мог прочитать статус пользователя).

Идентификатор пользователя, вошедшего в систему в этом событии, не выбирается клиентом произвольно, а является точным идентификатором пользователя, учетные данные которого были только что проверены контроллером домена. Таким образом, если идентификатор пользователя — «компьютер $», это буквально означает, что контроллер домена выдал билет для учетной записи компьютера «компьютер $», а не для какой-либо учетной записи человека.

Вопрос 2. Каким методом клиент Linux сообщает KDC (AD) о том, что пользователь домена вошел в систему/вышел из системы/активен/изменил группы и т. д.?

AD не осуществляет централизованный учет сеансов, поэтому фактические события «входа в систему» ​​не отправляются. Ближайшим является событие «аутентифицировано через Kerberos» или «аутентифицировано через протокол Netlogon», указывающее, что учетные данные были проверены, но это не так. действительно указывают на то, что сеанс был установлен. Аналогично, вообще не существует событий «активен» или «вышел из системы», пользователь входит в систему, если у него есть действительный TGT Kerberos.

Если вы видите события входа/выхода из клиентов Windows, они, скорее всего, соответствуют сеансу, создаваемому на DC , а не на клиенте; более конкретно, я подозреваю, что они соответствуют клиенту Windows, подключающемуся кSysvolобщий файловый ресурс, размещенный на вашем контроллере домена, для загрузки файлов пользовательских объектов групповой политики. Клиент Linux, использующий Winbind, вообще не будет просматривать объект групповой политики; хотя клиент, работающий с SSSD, может.

Нет событий «изменения группы» — контроллер домена информирует клиентов о том, в каких группах состоит пользователь, а не наоборот. (Членство в локальной группе не сообщается DC и не влияет на какие-либо решения по безопасности за пределами локального компьютера — при доступе, например, к файловому серверу через SMB, используются только группы, предоставленные DC, перечисленные в PAC вашего билета Kerberos.)

Использует ли он таблицу ключей (/etc/krb5.keytab) для хоста для связи или использует файл токена пользователя, созданный в /tmp/krb5cc_****_ ?

Оба. Клиент AD использует свои учетные данные компьютера (krb5.keytab или «машинный пароль» LSA) для получения информации о пользователе (например, сопоставления имен пользователей с UID и обратно) и загрузки групповой политики на уровне компьютера, в то время как программы, вызываемые пользователем, будут полагаться на собственные учетные данные пользователя Kerberos ($KRB5CCNAME или учетные данные LSA для каждого пользователя) для доступа к файловым серверам, выполнения единого входа через Интернет и т. д.

Одним из основных отличий является то, что в большинстве клиентов Linux AD стандартная связь с каталогом LDAP обрабатывается одной службой (SSSD или Winbind), которая затем всегда использует учетные данные компьютера для получения информации, например, если вы запускаетеls -laдля вывода списка файлов UID/GID их владельцев преобразуются SSSD/Winbind с использованием учетных данных компьютера , тогда как в Windows те же самые коммуникации выполняются непосредственно процессом, которому нужны данные, например, если вы добавляете пользователя в списки ACL файлов через На вкладке «Безопасность» именно Explorer.exe выполняет фактический поиск LDAP, используя учетные данные пользователя .