Логирование Samba

Сервер Samba позволяет гибко настраивать логирование для выявления и фиксации возможных проблем в работе службы каталогов, а также мониторинга различных событий, связанных с аутентификацией, авторизацией и внесением изменений в базу данных службы.

Доступны следующие возможности настройки:

Основным способом управления логированием является задание соответствующих настроек в конфигурационном файле smb.conf.

Настройка бэкендов для логирования

Одновременно на сервере Samba может вестись логирование с использованием нескольких различных бэкендов. При этом для каждого из них может быть задан свой уровень логирования.

Для этого служит параметр logging, который задается в разделе [global] файла smb.conf на сервере Samba в следующем формате:

logging = backend1[:option][@loglevel] backendN[:option][@loglevel]

В приведенной строке с параметром logging:

  • backend — один из доступных бэкендов; может быть указано несколько значений, разделенных пробелом; возможные значения:

    • syslog — запись в системный журнал;

    • file — запись в файл, указанный в параметре log file, либо в стандартные лог-файлы Samba в каталоге /var/log/samba/;

    • systemd — запись в журнал (journal) systemd;

    • lttng — трассировка с использованием инструментов фреймворка с открытым исходным кодом LTTng;

    • gpfs — аудит файлов в файловой системе GPFS;

    • ringbuf — запись в кольцевой буфер (ring buffer); для задания размера буфера (по умолчанию — 1 МБ) может использоваться опция size в формате: logging = ringbuf:size=NBYTES;

      Данный вариант логирования может быть полезен при анализе ошибок, которые связаны с временными эффектами и не могут быть воспроизведены при записи логов в файлы с указанием высоких уровней отладки.

  • [:option] — дополнительные опции, специфичные для указанного бэкенда;

  • [@loglevel] — уровень логирования.

    Данный параметр является необязательным. Если он не установлен для указанного бэкенда, в бэкенд отправляются все сообщения.

    Уровень логирования, установленный для определенного бэкенда, переопределяет общий уровень логирования, заданный с помощью параметра log level.

Если задан параметр logging, его значение переопределяет значения параметров syslog и syslog only, которые являются устаревшими и не должны использоваться для настройки логирования.

Значение по умолчанию :

logging =

Пример задания параметра:

logging = syslog@1 file

Настройка места размещения, имени и максимального размера лог-файлов

При записи логов в файлы в smb.conf с помощью параметра log file в разделе [global] может быть указано имя одного статического файла, в который будет сохраняться информация обо всех события, либо с помощью подстановок может быть настроено создание отдельных лог-файлов для различных сущностей и объектов, обслуживаемых Samba.

Например, для создания отдельного лог-файла для каждого подключенного хоста с именем в формате <NetBIOS_name>.log в каталоге /var/log/samba/ следует задать параметр следующим образом:

log file = /var/log/samba/%m.log

Примеры подстановок (см. полный список в разделе "Variable Substitutions" man-страницы с описанием файла smb.conf):

  • %m — NetBIOS-имя клиентской машины;

  • %M — интернет-имя клиентской машины;

  • %I — IP-адрес клиентской машины;

  • %i — локальный IP-адрес, с которым установил соединение клиент;

  • %T — текущие дата и время;

  • %U — имя пользователя сессии.

Для ограничения максимального размера лог-файлов Samba может использоваться параметр max log size в разделе [global]. Значение параметра задается в килобайтах. При превышении заданного лимита к имени текущего лог-файла добавляется постфикс .old и создается новый файл.

В процессе ротации Samba перезаписывает архивированный ранее лог-файл.

Например, чтобы ограничить максимальный размер лог-файла значением 10 МБ, необходимо задать параметр следующим образом:

max log size = 10000

Настройка уровня логирования

Для задания уровня логирования (уровня отладки) служит параметр log level в разделе [global] файла smb.conf.

Уровень задается в виде целого числа в диапазоне от 0 до 10, где 0 соответствует отключению вывода отладочной информации, а 10 — обеспечивает вывод максимального объема информации об ошибках и проблемах, которые могут возникать в процессе работы Samba. Оптимальным для получения отладочной информации является уровень 3. Уровни выше 3 предназначены преимущественно для выявления внутренних ошибок Samba. Их использование может привести к существенному снижению производительности сервера.

Также параметр log level позволяет задавать различные уровни логирования для отдельных классов отладки. При необходимости наряду с уровнем логирования может быть указан файла, в который должна вести запись отладочной информации. Для этого к имени класса отладки добавляется часть @PATH.

В текущей реализации доступны следующие классы отладки: all, tdb, printdrivers, lanman, smb, rpc_parse, rpc_srv, rpc_cli, passdb, sam, auth, winbind, vfs, idmap, quota, acls, locking, msdfs, dmapi, registry, scavenger, dns, ldb, tevent, auth_audit, auth_json_audit, kerberos, drs_repl, smb2, smb2_credits, dsdb_audit, dsdb_json_audit, dsdb_password_audit, dsdb_password_json_audit, dsdb_transaction_audit, dsdb_transaction_json_audit, dsdb_group_audit, dsdb_group_json_audit.

Некоторые модули при первом использовании регистрируют динамические классы отладки. Например: catia, dfs_samba4, extd_audit, fileid, fruit, full_audit, media_harmony, preopen, recycle, shadow_copy, unityed_media, virusfilter.

Примеры использования параметра для настройки уровня логирования:

  • установка единого уровня логирования 3 для всех классов отладки:

    log level = 3

  • установка общего уровня логирования 1, а для классов auth и winbind — 5:

    log level = 1 auth:5 winbind:5

  • установка общего уровня логирования 1, а для класса full_audit — 3 с указанием файла для ведения записи:

    log level = 1 full_audit:3@/var/log/audit.log

При выполнении команд Samba используется уровень логирования, установленный параметром log level в smb.conf. Он может быть переопределен с помощью опции -d. Например:

samba-tool drs showrepl -d 3

Настройка ведения журналов аудита для событий аутентификации, авторизации и изменения базы данных

Samba поддерживает логирование событий аутентификации и авторизации, а также изменений в базе данных. Это позволяет фиксировать, например, неудачные запросы аутентификации и события сброса пароля.

Данная возможность настраивается на уровне отдельного сервера Samba, то есть в логи попадают только события, относящиеся к данному конкретному серверу. Для организации централизованного хранения всех логов требуется настроить единый сервер системных журналов, настроить Samba таким образом, чтобы запись данных аудита велась в демон syslog, а также настроить отправку логов демоном syslog на общий сервер.

Для мониторинга лог-файлов и выполнения определенных действий на основе результатов их анализа могут использоваться дополнительные утилиты.

При работе в конфигурации, предназначенной для рядового участника домена, Samba может формировать некоторую отладочную информацию. Однако полноценная поддержка всех возможностей логирования доступна только в конфигурации для роли контроллера домена AD.

Регистрация событий аутентификации и авторизации

Samba поддерживает регистрацию успешных и неуспешных событий аутентификации, а также успешных событий авторизации.

В контексте использования Samba под аутентификацией понимается проверка комбинации имени пользователя и пароля, а под авторизацией — начало сессии.

Следующие примеры показывают, в каких случаях Samba регистрирует события аутентификации и авторизации:

  1. При входе пользователя в домен центр распространения ключей Kerberos (KDC), работающий на контроллере домена, фиксирует событие аутентификации.

    Если в домене работают несколько контроллеров, запрос аутентификации регистрируется только на контроллере, который обслуживает данный запрос.

  2. При подключении к общему ресурсу на участнике домена:

    • участник домена регистрирует событие авторизации;

    • при использовании аутентификации Kerberos центр распространения ключей (KDC) на контроллере домена Samba фиксирует событие аутентификации;

      В случае использования аутентификации Kerberos за нее отвечает KDC. Поэтому Samba на участнике домена AD не может регистрировать такое событие аутентификации.

    • при использовании аутентификации через NT LAN Manager (NTLM) участник домена регистрирует событие аутентификации.

    При использовании NTLM всегда регистрируется пара событий — событие аутентификации и событие авторизации. Однако при использовании Kerberos регистрируется только одно событие на контроллере домена в момент выдачи билета TGT (Ticket Granting Ticket). После этого каждый раз при получении доступа к какой-либо службе регистрируется событие авторизации.

Для регистрации событий аутентификации и авторизации используются следующие классы отладки:

  • auth_audit — регистрация в стандартном формате;

  • auth_json_audit — регистрация в формате JSON.

Пример включения ведения журналов аудита для событий аутентификации и авторизации в обоих форматах:

log level = 1 auth_audit:3 auth_json_audit:3

Для классов auth_audit и auth_audit_json доступны следующие уровни логирования (каждый последующий уровень включает все предшествующие ему):

  • 2 — неуспешные события аутентификации;

  • 3 — успешные события аутентификации;

  • 4 — успешные события авторизации;

  • 5 — успешные анонимные события аутентификации и авторизации.

Регистрация изменений в базе данных

Для регистрации изменений в базе данных контроллера домена Samba (sam.ldb) используются следующие классы отладки:

  • dsdb_audit — регистрация в стандартном формате;

  • dsdb_json_audit — регистрация в формате JSON.

Для регистрации изменений в составе групп используются следующие классы отладки:

  • dsdb_group_audit — регистрация в стандартном формате;

  • dsdb_group_json_audit — регистрация в формате JSON.

Для классов dsdb_audit, dsdb_json_audit, dsdb_group_audit, dsdb_group_json_audit и dsdb_json_audit доступны следующие уровни логирования:

  • 5 — внесение изменений в базу данных;

  • 5 — регистрация изменений, полученных через механизм репликации с другого контроллера домена.

События изменения и сброса паролей регистрируются в рамках следующих классов отладки:

  • dsdb_password_audit — регистрация в стандартном формате;

  • dsdb_password_json_audit — регистрация в формате JSON.

Каждое изменение пароля также регистрируется как событие аутентификации через классы отладки auth_audit и auth_audit_json.

Для классов dsdb_password_audit и dsdb_password_json_audit доступны следующие уровни логирования:

  • 5 — успешные события изменения и сброса пароля.

Для регистрации неуспешных транзакций, завершающихся откатом, и событий подготовки фиксации данных (prepare commit) используются следующие классы отладки:

  • dsdb_transaction_audit — регистрация в стандартном формате;

  • dsdb_transaction_json_audit — регистрация в формате JSON.

Для классов dsdb_transaction_audit и dsdb_transaction_json доступны следующие уровни логирования:

  • 5 — неуспешная транзакция (откат);

  • 10 — успешная транзакция (фиксация).

В Samba возможны откаты транзакций. Они редко отражают что-либо помимо неуспешного завершения отдельной операции (например, в результате попытки создания записи, которая конфликтует с существующими). Записи о транзакции формируются и фиксируются в системных логах до ее завершения. Такое логирование информации о транзакциях позволяет выявлять операции с паролями и операции по внесению изменении в sam.ldb, которые закончились откатом и фактически не были выполнены.

По умолчанию для всех классов отладки установлен уровень логирования 0:

log level = 0

Пример установки различных уровней логирования для отдельных классов отладки:

log level = 1 dsdb_json_audit:5 dsdb_password_json_audit:5 dsdb_group_json_audit:5 dsdb_transaction_json_audit:5

Настройка формата ведения логов

По умолчанию Samba использует стандартный формат ведения логов. Его использование не требует наличия каких-либо дополнительных библиотек.

Пример записи в логе о событии успешной аутентификации пользователя на контроллере домена Samba в стандартном формате:

[2017/07/04 21:07:41.410381,  4, pid=21757] ../auth/auth_log.c:848(log_successful_authz_event_human_readable)
  Successful AuthZ: [SMB2,krb5] user [SAMDOM]\[Administrator] [S-1-5-21-469703510-2364959079-1506205053-500] at [Di, 04 Jul 2017 21:07:41.410364 CEST] Remote host [ipv4:10.99.0.81:58828] local host [ipv4:10.99.0.1:445]

Если при сборке Samba в системе была установлена библиотека jansson, также автоматически поддерживается ведение логов в формате JSON.

Для проверки поддержки формата JSON выполните на сервере Samba следующую команду:

smbd -b | grep HAVE_JSON_OBJECT

Если в выводе присутствует строка HAVE_JSON_OBJECT, формат поддерживается. В противном случае сборка Samba выполнялась без поддержки JSON.

Пример записи в логе о событии успешной аутентификации пользователя на контроллере домена Samba в формате JSON:

[2017/07/04 21:07:41.410434,  4, pid=21757] ../auth/auth_log.c:220(log_json)
  {"type": "Authorization", "timestamp": "2017-07-04T21:07:41.410408+0200", "Authorization": {"version": {"major": 1, "minor": 0}, "sid": "S-1-5-21-469703510-2364959079-1506205053-500", "serviceDescription": "SMB2", "localAddress": "ipv4:10.99.0.1:445", "remoteAddress": "ipv4:10.99.0.81:58828", "transportProtection": "SMB", "authType": "krb5", "domain": "SAMDOM", "account": "Administrator", "logonServer": "DC1", "accountFlags": "0x00000210"}}

Для управления форматом основные группы событий поддерживают два класса отладки — класс для ведения записи в стандартном формате (например, auth_audit) и класс для ведения записи в формате JSON (например, auth_json_audit).

Анализ записей в логах в формате JSON

Каждое событие описывается определенным набором атрибутов, соответствующим его типу.

В общем случае запись в формате JSON состоит из следующих базовых атрибутов (для удобства восприятия в примере ниже добавлены переносы на новую строку и отступы; реальные записи всегда форматируются в виде одной строки):

{
  "type": one of "Authentication", "Authorization", "dsdbChange", "dsdbTransaction", "passwordChange", "replicatedUpdate", "groupChange",
  "timestamp": 2023-01-12T22:50:50.000000+00:00,
  type: { data }
}

Атрибут type указывает на таблицу в базе данных.

Далее приводится описание атрибутов для основных таблиц, соответствующих типам событий.

Некоторые атрибуты могут присутствовать в записях даже в том случае, если они неприменимы. Например, если Netlogon не используется (в соответствии с serviceDescription), атрибут netlogonComputer будет иметь значение null, а атрибут netlogonNegotiateFlags — значение 0x00000000. Прочие атрибуты, относящиеся к Netlogon, будут иметь аналогичные пустые значения.

Общие атрибуты

Общим для всех записей является атрибут version, состоящий из двух частей:

  • мажорная версия, которая увеличивается при изменении значения полей;

  • минорная версия, которая увеличивается при добавлении поля.

Изменения в перечне возможных значений обычно не приводят к изменению версии. Это распространяется на все данные, предоставляемые клиентами. Также это относится, например, к атрибуту passwordType, набор поддерживаемых форматов которого может меняться с течением времени без изменения версии в JSON.

Атрибуты событий аутентификации (Authentication)

Для описания событий аутентификации в JSON используется следующий набор атрибутов:

  • authDescription — тип аутентификации; возможные значения:

    • simple bind/TLS, simple bind — простая привязка LDAP с каналом TLS или без него;

    • guest — анонимный запрос SMB1;

    • bare-NTLM — запрос SMB с использованием протокола NT1;

    • plaintext — запрос SMB1 в формате обычного текста;

    • interactive — аналог физического входа на конкретной рабочей станции;

    • network — проверка подлинности запроса/ответа по сети;

    • Unknown Auth Description, Unknown Pre-authentication — события KDC;

    • ServerAuthenticate — запрос/ответ компьютера при входе с использованием Netlogon;

    • LDAP Modify — смена пароля;

      Данное событие не относится к аутентификации в строгом смысле. Однако для удобства оно регистрируется именно здесь.

  • becameAccount — имя учетной записи, с использованием которой был выполнен вход (может не совпадать со значением, предоставленным клиентом);

  • becameDomain — имя домена, в который выполнен вход;

  • becameSid — идентификатор безопасности (SID) учетной записи, прошедшей аутентификацию;

  • clientAccount — имя учетной записи, представленное клиентом;

  • clientDomain — имя домена, предоставленное клиентом;

  • duration — время (в микросекундах), в течение которого выполнялась аутентификация (вплоть до момента записи значения в поле);

  • eventId — идентификатор события Windows;

  • localAddress — адрес сервера и используемый порт;

  • logonId — сформированный случайным образом 64-битный идентификатор, предназначенный для отслеживания событий входа на различных этапах;

  • logonType — тип входа Windows; возможные значения для Samba:

    • 2 — интерактивный (то есть вход выполняется на текущем компьютере);

    • 3 — сетевой (то есть вход выполняется по сети);

    • 8 — сетевой с использованием нехешированных паролей (то есть вход выполняется по сети и при этом пароль передается в пакет проверки подлинности в его нехешированной форме);

  • mappedAccount — имя учетной записи клиента, преобразованное в имя учетной записи AD;

  • mappedDomain — имя домена клиента, преобразованное в имя домена AD;

  • netlogonComputer — имя компьютера, заявленное при аутентификации через Netlogon RPC;

  • netlogonNegotiateFlags — флаги Netlogon, согласуемые в процессе взаимодействия сервера и клиента (см. описание);

  • netlogonSecureChannelType — тип безопасного канала, используемого для входа по протоколу Netlogon (см. описание);

  • netlogonTrustAccount — учетная запись, используемая для аутентификации по протоколу Netlogon;

  • netlogonTrustAccountSid — идентификатор безопасности (SID) учетной записи, используемой для аутентификации по протоколу Netlogon;

  • passwordType — тип алгоритма/протокола пароля (например, HMAC-SHA256, NTLMv2, arcfour-hmac-md5);

  • remoteAddress — заявленный адрес (и порт) удаленного клиента;

  • serviceDescription — тип службы (например, LDAP, SMB2, NETLOGON);

  • status — сообщение NT STATUS;

    В случае успешного завершения аутентификации атрибут имеет значение NT_STATUS_OK.

    В случае неуспешного завершения процедуры аутентификации атрибут может иметь, например, одно из следующих значений:

    • NT_STATUS_ACCESS_DENIED — доступ запрещен без указания причины (наиболее вероятная причина — некорректные учетные данные);

    • NT_STATUS_WRONG_PASSWORD — неверный пароль;

    • NT_STATUS_NO_SUCH_USER — пользователь не существует;

    • NT_STATUS_NO_SUCH_DOMAIN — домен не существует;

    • NT_STATUS_ACCOUNT_RESTRICTION — учетная запись защищена либо ее использование ограниченно иным образом;

    • NT_STATUS_DOWNGRADE_DETECTED — клиент, возможно, предпринимает какие-либо действия для использования некорректных способов аутентификации;

    • NT_STATUS_INVALID_SERVER_STATE — сервер, возможно, используется не по назначению;

    • NT_STATUS_INVALID_INFO_CLASS — сервер, возможно, используется не по назначению;

    • NT_STATUS_INVALID_PARAMETER — клиент получил некорректные данные;

    • NT_STATUS_NETWORK_CREDENTIAL_CONFLICT — в процессе входа произошли изменения; возможно, имеет место гонка в рамках изменения учетных данных либо при согласовании данных шифрования возникла ошибка;

    • NT_STATUS_NOT_IMPLEMENTED — тип аутентификации не реализован в Samba;

    • NT_STATUS_NOT_SUPPORTED — тип аутентификации либо способ его использования со стороны клиента не поддерживается Samba;

    • NT_STATUS_INVALID_SYSTEM_SERVICE — выбранная служба аутентификации недоступна;

    • NT_STATUS_INTERNAL_ERROR — сервер не может завершить выполнение аутентификации по причине внутренней ошибки;

    • NT_STATUS_NO_MEMORY — сервер не может завершить выполнение аутентификации по причине нехватки памяти.

  • version — версия;

  • workstation — заявленное имя клиентской рабочей станции.

Атрибуты событий авторизации (Authorization)

Для описания успешных событий авторизации в JSON используется следующий набор атрибутов:

  • account — имя авторизуемой учетной записи;

  • accountFlags — битовое поле атрибутов учетной записи (см. описание);

  • authType — тип авторизации (например, krb5, NTLMSSP, simple bind);

  • domain — имя домена;

  • localAddress — адрес сервера и используемый порт;

  • logonServer — сервер, на котором была выполнена аутентификация учетной записи;

  • remoteAddress — адрес удаленного клиента;

  • serviceDescription — тип службы (например, LDAP, SMB2, DCE/RPC);

  • sessionId — уникальный идентификатор (GUID) сессии;

  • sid — идентификатор безопасности (SID) авторизуемой учетной записи;

  • transportProtection — тип защиты, используемой в канале (например, SMB, TLS, SEAL, NONE);

  • type — тип события (Authorization);

  • version — версия.

Атрибуты событий, связанных с изменениями в базе данных (dsdbChange)

Для описания событий, связанных с внесением значимых изменений в базу данных службы каталогов, в JSON используется следующий набор атрибутов:

  • attributes — список изменяемых атрибутов;

    Значение данного поля может рассматриваться в качестве аналога описания изменения в формате LDIF.

    Например:

    • пример описания изменения в JSON:

      "dsdbChange": {
  "operation": "Modify",
  "dn": "@SAMBA_DSDB",
  "attributes": {
   "backupDate": {"actions": [
     {"action": "add",
      "values": [
        {"value": "2023-01-14T09-43-55.333333"}
       ]
     }
   ]
  }}}

    • описание того же изменения в LDIF:

      dn: @SAMBA_DSDB
changetype: modify
add: backupDate
backupDate: 2023-01-14T09-43-55.333333

    Для атрибутов, значения которых являются секретами, указывается тег: redacted: true.

    Если длина значения превышает 1024 байт, часть, выходящая за пределы ограничения, отсекается. Вместо нее отображаются …​ и флаг truncated: true. Например:

    "values": [
  {"value": "It was the best of times, it was the worst of times, it was the age...",
   truncated: true
  }
]

    В блоке attributes могут отображаться следующие атрибуты:

    • action — тип операции по изменению LDAP; возможные значения: add, replace, delete;

    • redacted — признак значения-секрета;

    • values — список значений, к которым применяется операция;

      Каждый элемент представляет собой отдельный объект, содержащий значение либо ключ base64 (если значение содержит непечатаемые символы).

    • values[].value — данные, которые могут быть усечены и/или кодированы в формате Base64;

    • values[].base64 — признак того, что данные кодированы в формате Base64;

    • values[].truncated — признак того, что данные усечены до 1024 байт.

  • dn — уникальное составное имя (DN) изменяемого объекта;

  • operation — операция LDAP, соответствующая выполняемому действию по изменению данных; возможные значения: Modify, Add, Delete;

  • performedAsSystem — признак системного или пользовательского действия; возможные значения:

    • true — действие выполняется Samba с использованием системной учетной записи;

    • false — действие выполняется от имени пользователя;

  • remoteAddress — адрес пользователя, инициировавшего операцию;

  • sessionId — уникальный идентификатор (GUID) сессии аутентификации;

  • status — строка, указывающая на успешное завершение действия или невозможность его выполнения по той или иной причине; выводимая информация соответствует кодам ответа LDAP, которые фиксируются в атрибуте statusCode;

    Примеры значений:

    • "Success";

    • "Operations error";

    • "Protocol error";

    • "Time limit exceeded";

    • "Size limit exceeded";

    • "Unsupported critical extension";

    • "No such attribute";

    • "Undefined attribute type";

    • "Constraint violation";

    • "Attribute or value exists";

    • "Invalid attribute syntax";

    • "No such object";

    • "Alias problem";

    • "Invalid DN syntax";

    • "insufficient access rights";

    • "Unwilling to perform";

    • "Naming violation";

    • "Object class violation";

    • "Not allowed on non-leaf";

    • "Not allowed on RDN";

    • "Entry already exists".

  • числовой код, соответствующий статусу в атрибуте status — в общем случае в качестве значения атрибута приводится код ответа LDAP в соответствии с RFC 4511;

  • transactionId — уникальный идентификатор (GUID) транзакции, в рамках которой выполняется действие (задается только в том случае, если действие является частью транзакции);

  • userSid — идентификатор безопасности (SID) пользователя, инициировавшего операцию;

  • version — версия.

Атрибуты событий, связанных с транзакциями (dsdbTransaction)

Транзакция объединяет несколько операций по изменению данных. В случае успешного выполнения всех частей транзакции, изменения фиксируются и становятся постоянными. Если какая-либо операция в рамках транзакций завершается неуспешно, все предшествующие операции откатываются, даже если они уже были зарегистрированы в качестве событий в таблице dsdbChange.

Каждой транзакции присваивается уникальный идентификатор (GUID); операции по изменению базы данных, являющиеся частью транзакции, содержат данный идентификатор в качестве значения атрибута transactionId.

Для описания событий, связанных с транзакциями, в JSON используется следующий набор атрибутов:

  • action — текущий этап транзакции; возможные значения: begin, commit, rollback;

  • duration — продолжительность транзакции в микросекундах (вплоть до момента записи значения в поле);

  • transactionId — уникальный идентификатор (GUID) транзакции;

  • version — версия.

Атрибуты событий, связанных с изменением пароля (passwordChange)

Для описания событий, связанных с изменением пароля, в JSON используется следующий набор атрибутов:

  • action — тип операции (смена или сброс пароля); возможные значения: Change, Reset;

  • dn — уникальное составное имя (DN) пользователя, пароль которого изменяется или сбрасывается;

  • eventId — идентификатор события Windows:

    • 4723 соответствует событию смены пароля (Change);

    • 4724 соответствует событию сброса пароля (reset);

  • remoteAddress — удаленный адрес пользователя, выполняющего операцию;

  • sessionId — идентификатор сессии базы данных;

  • status — текст ошибки;

  • statusCode — код ошибки;

  • transactionId — уникальный идентификатор (GUID) транзакции, в рамках которой выполняется операция (если операция является частью транзакции);

  • userSid — идентификатор безопасности (SID) пользователя, инициировавшего операцию;

  • version — версия.

Атрибуты событий, связанных с изменением группы (groupChange)

Для описания событий, связанных с изменением группы, в JSON используется следующий набор атрибутов:

  • action — тип операции (удаление, добавление или смена основной группы); возможные значения: Removed, Added, PrimaryGroup;

  • eventId — идентификатор события Windows:

    • 4728 соответствует добавлению пользователя в глобальную группу безопасности;

    • 4729 соответствует удалению пользователя из глобальной группы безопасности;

    • 4732 соответствует добавлению пользователя в локальную группу безопасности;

    • 4733 соответствует удалению пользователя из локальной группы безопасности;

    • 4746 соответствует добавлению пользователя в локальную группу;

    • 4747 соответствует удалению пользователя из локальной группы;

    • 4751 соответствует добавлению пользователя в глобальную группу;

    • 4752 соответствует удалению пользователя из глобальной группы;

    • 4756 соответствует добавлению пользователя в универсальную группу безопасности;

    • 4757 соответствует удалению пользователя из универсальной группы безопасности;

    • 4761 соответствует добавлению пользователя в универсальную группу;

    • 4762 соответствует удалению пользователя из универсальной группы;

  • group — уникальное составное имя (DN) группы;

  • remoteAddress — удаленный адрес пользователя, выполняющего операцию;

  • sessionId — идентификатор сессии базы данных;

  • status — текст ошибки;

  • числовой код, соответствующий статусу в атрибуте status, — в общем случае в качестве значения атрибута приводится код ответа LDAP в соответствии с RFC 4511;

  • transactionId — уникальный идентификатор (GUID) транзакции, в рамках которой выполняется операция (если операция является частью транзакции);

  • user — уникальное составное имя (DN) пользователя, членство в группе которого изменяется в рамках операции;

  • userSid — идентификатор безопасности (SID) пользователя, инициировавшего операцию;

  • version — версия.