Аудит Эллес

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

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

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

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

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

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

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

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

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

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

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

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

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

      В случае использования аутентификации Kerberos за нее отвечает KDC. Поэтому Эллес на участнике домена 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

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

log level = 1 auth_json_audit:3@/app/log/inno-samba/auth_json_audit.log

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

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

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

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

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

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

Для регистрации изменений в базе данных контроллера домена Эллес (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 — успешная транзакция (фиксация).

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

Форматы ведения логов

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

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

[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]

Также автоматически поддерживается ведение логов в формате JSON.

Пример записи в логе о событии успешной аутентификации пользователя на контроллере домена Эллес в формате 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).

Настройка отправки событий в централизованную систему мониторинга

Для отправки данных аудита Эллес в централизованную систему мониторинга событий безопасности (Security Information and Event Management, SIEM) могут использоваться утилиты rsyslog и syslog-ng.

Пример настройки отправки событий аудита в централизованную систему:

  1. Добавьте классы отладки для аудита требуемых событий с указанием уровней логирования в значение параметра log level в файле /app/inno-samba/etc/smb.conf.

    Например:

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

  2. При использовании rsyslog:

    • убедитесь, что соответствующий сервис активен и работает в системе:

      sudo systemctl status rsyslog.service

    • создайте файл с конфигурацией для rsyslog, например — /etc/rsyslog.d/samba_audit.conf;

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

      module(load="imfile" PollingInterval="10")

input(type="imfile"
      File="/app/inno-samba/var/log.samba"
      Tag="samba-audit"
      Severity="info"
      Facility="local3")

if ($syslogfacility-text == "local3" and ($msg contains '{"timestamp": "')) then {
    action(type="omfwd" target="10.0.18.132" port="514" protocol="tcp")
}

    • перезапустите сервис rsyslog:

      sudo systemctl restart rsyslog.service

  3. При использовании syslog-ng:

    • убедитесь, что соответствующий сервис активен и работает в системе:

      sudo systemctl status syslog-ng.service

    • создайте файл с конфигурацией для syslog-ng, например — /etc/syslog-ng/conf.d/samba_audit.conf;

    • добавьте в файл требуемые настройки; например:

      source samba_src {
       file("/app/inno-samba/var/log.samba" default-facility(local3) default-priority(notice) flags(no-parse));
};
filter samba_fltr {
       match("dsdbChange" value("MESSAGE")) or match("Authorization" value("MESSAGE")) or match("Authentication" value("MESSAGE")) or match("passwordChange" value("MESSAGE"));
};
rewrite samba_rw {
       subst("{\"timestamp\":", "samba_audit: {\"timestamp\":", value("MESSAGE"), flags("global"));
};
destination samba_dest {
       tcp("10.0.18.132" port(514));
};
log {
       source(samba_src);
       filter(samba_fltr);
       rewrite(samba_rw);
       destination(samba_dest);
};

    • перезапустите сервис syslog-ng:

      sudo systemctl restart syslog-ng

  4. Настройте обработку событий аудита на стороне централизованной системы мониторинга.

Анализ записей в логах в формате 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; возможные значения для Эллес:

    • 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 — тип аутентификации не реализован в Эллес;

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

    • 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 — действие выполняется Эллес с использованием системной учетной записи;

    • 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 соответствует событию смены пароля (сhange);

    • 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 — версия.

Атрибуты событий, связанных с управлением предварительной аутентификацией Kerberos (UserAccountKerberosPreAuthChange)

Действия по отключению и включению предварительной аутентификации для учетных записей фиксируются логах Эллес в рамках классов отладки auth_audit и auth_json_audit с уровнем логирования 2 или выше.

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

  • dn — DN учетной записи, для которой было изменено состояние флага UF_DONT_REQUIRE_PREAUTH атрибута userAccountControl;

  • oldValue — значение атрибута userAccountControl до изменения состояния флага UF_DONT_REQUIRE_PREAUTH;

  • newValue — значение атрибута userAccountControl после изменения состояния флага UF_DONT_REQUIRE_PREAUTH;

  • version — версия.

Пример записи в формате JSON:

{
  "timestamp": "2025-06-27T14:20:13.247670+0300",
  "type": "UserAccountKerberosPreAuthChange",
  "UserAccountKerberosPreAuthChange": {
    "version": {
      "major": 1,
      "minor": 0
    },
    "dn": "CN=User1,CN=Users,DC=samdom,DC=example,DC=com",
    "oldValue": 512,
    "newValue": 4194816
  }
}