Где хранятся пароли и настройки учетных записей пользователей домена windows

Хранение и шифрование паролей Microsoft Windows

Про взлом паролей windows было написано немало статей, но все они сводились к использованию какого-либо софта, либо поверхностно описывали способы шифрования LM и NT, и совсем поверхностно описывали syskey. Я попытаюсь исправить этот неодостаток, описав все подробности о том где находятся пароли, в каком виде, и как их преобразует утилита syskey.

Существует 2 возможности получения пароля — через реестр, или получив прямой доступ к файлам-кустам реестра. В любом случае нужны будут либо привелегии пользователя SYSTEM, либо хищение заветных файлов, например, загрузившись из другой ОС. Здесь я не буду описывать возможности получения доступа, но в целях исследования нагляднее будет выбрать первый вариант, это позволит не заострять внимание на структуре куста реестра. А запуститься от системы нам поможет утилита psExec от sysinternals. Конечно, для этих целей можно использовать уязвимости windows, но статья не об этом.

V-блок

Windows до версии Vista по умолчанию хранила пароль в двух разных хэшах — LM и NT. В висте и выше LM-хэш не хранится. Для начала посмотрим где искать эти хэши, а потом разберемся что из себя они представляют.

Пароли пользователей, а так же много другой полезной информации хранится в реестре по адресу HKLM\SAM\SAM\Domains\Account\users\[RID]\V
, известном как V-блок. Раздел SAM находится в соответствующем файле c:\Windows\System32\config\SAM. RID — уникальный идентификатор пользователя, его можно узнать, например заглянув в ветку HKLM\SAM\SAM\Domains\Account\users\names\<имя пользователя> (параметр Default, поле — тип параметра). Например, RID учетной записи «Администратор» всегда 500 (0x1F4), а пользователя «Гость» — 501 (0x1f5). Доступ к разделу SAM по умолчанию возможен только пользователю SYSTEM, но если очень хочется посмотреть — запускаем regedit c правами системы:

PsExec.exe -s -i -d regedit.

Чтобы наблюдать V-блок в удобном виде можно, например, экспортировать его в текстовый файл (File-Export в Regedit).
Вот что мы там увидим:

От 0x0 до 0xCC располагаются адреса всех данных, которые находятся в V-блоке, их размеры и некоторая дополнительная информация о данных. Чтобы получить реальный адрес надо к тому адресу, что найдем прибавить 0xCC. Адреса и размеры хранятся по принципу BIG ENDIAN, т.е понадобится инвертировать байты. На каждый параметр отводится по 4 байта, но фактически все параметры умещаются в одном-двух байтах. Вот где искать:

Адрес имени пользователя — 0xС
Длина имени пользователя — 0x10
Адрес LM-хэша — 0x9с
Длина LM-хэша — 0xa0
Адрес NT-хэша — 0xa8
длина NT-хэша — 0xac

В данном случае имя пользователя найдется по смещению 0xd4 + 0xcc и его длина будет 0xc байт.
NT-хэш будет располагаться по смещению 0x12c + 0xcc и его размер (всегда один и тот же) = 0x14.

Еще одна деталь, касающаяся хранения паролей — как к NT- так и к LM-хэшу всегда добавляются спереди 4 байта, назначение которых для меня загадка. Причем 4байта будут присутствовать даже если пароль отключен. В данном случае видно, что длина LM хэша =4 и если посмотреть на его адрес, можно эти 4 байта увидеть несмотря на то что никакого LM-хэша нет.
Поэтому при поиске смещений хэшей смело прибавляем 4 байта к адресу, а при учете размеров — вычитаем. Если удобнее читать код — вот примерно так будет выглядеть поиск адресов с учетом инверсии, лишних четырех байтов и прибавления стартового смещения 0xcc (код C#)

int lmhashOffset = userVblock[0x9c] + userVblock[0x9d] * 0x100 + 4 + 0xcc;
int nthashOffset = userVblock[0xa8] + userVblock[0xa9] * 0x100 + 4 + 0xcc;
int lmhashSize = userVblock[0xa0] + userVblock[0xa1] * 0x100 — 4;
int nthashSize = userVblock[0xac] + userVblock[0xad] * 0x100 — 4;
int usernameOffset = userVblock[0xc] + userVblock[0xd] * 0x100 + 0xcc;
int usernameLen = userVblock[0x10] + userVblock[0x1a] * 0x100;
userVblock — значение HKLM\SAM\SAM\Domains\Account\users\\V в виде массива байт.
Еще про V-блок можно почитать тут.

Алгоритмы

Теперь разберемся в алгоритмах шифрования.
Формирование NT-хэша:
1. Пароль пользователя преобразуется в Unicode-строку.
2. Генерируется MD4-хэш на основе данной строки.
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.
Формирование LM-хэша:
1. Пароль пользователя преобразуется в верхний регистр и дополняется нулями до длины 14 байт.
2. Полученная строка делится на две половинки по 7 байт и каждая из них по отдельности шифруется алгоритмом DES. В итоге получаем хэш длиной 16 байт (состоящий из двух независимых половинок длиной по 8 байт).
3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.

4. В windows 2000 и выше оба полученых хэша дополнительно шифруются алоритмом RC4 с помощью ключа, известного как «системный ключ» или bootkey, сгенерированого утилитой syskey, и шифруются довольно хитрым образом.

Рассмотрим общую последовательность действий для получения исходного пароля и каждый шаг в отдельности
1. Получаем bootkey, генерируем на его основе ключи для RC4, расшифровываем хэши с помощью RC4
2. Получаем ключи для DES из RID’ов пользователей, расшифровываем хэши DES’ом
3. Полученые хэши атакуем перебором.

Bootkey

Системный ключ (bootkey) разбит на 4 части и лежит в следующих разделах реестра:

HKLM\System\CurrentControlSet\Control\Lsa\JD
HKLM\System\CurrentControlSet\Control\Lsa\Skew1
HKLM\System\CurrentControlSet\Control\Lsa\GBG
HKLM\System\CurrentControlSet\Control\Lsa\Data

Раздел system находится в файле c:\Windows\System32\config\system

Следует отметить, что раздел CurrentControlSet является ссылкой на один из разделов controlset и создается в момент загрузки системы. Это значит что не получится его найти в файле system, если система неактивна. Если вы решили искать ключ в файле — необходимо узнать значение ContolSet по умолчанию в HKLM\SYSTEM\Select\default.
например если HKLM\SYSTEM\Select\default = 1 — вместо HKLM\System\CurrentControlSet\ ищем в HKLM\System\controlset001\

У каждого ключа реестра есть некий скрытый атрибут, известный как «class». Regedit его так просто не покажет, однако его можно увидеть, например, если экспортировать эти ключи реестра в текстовые файлы. В winapi для получения этого атрибута есть функция RegQueryInfoKey.
Фрагменты хранятся в строковом представлении шестнадцатеричных чисел, причем по принципу BIG ENDIAN (т.е не строка задом наперед, а число).
Например мы обнаружили вот такие записи:

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD
Class Name: 46003cdb = <0xdb,0x3c,0x00,0x46>
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Skew1
Class Name: e0387d24 = <0x24,0x7d,0x38,0xe0>
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\GBG
Class Name: 4d183449 = <0x49,0x34,0x18,0x4d>
Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Data
Class Name: 0419ed03 =

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

Далее элементы этого массива переставляются на основе некоторого константного массива p

key[i] = scrambled_key[p[i]];

В нашем примере получится массив:

этот массив и есть так называемый bootkey. Только в шифровании паролей будет учавствовать не он а некий хэш на основе bootkey, фрагментов f-блока и некоторых констант. Назовем его Hashed bootkey.

Hashed bootkey

для получения Hashed bootkey нам понадобятся 2 строковые константы (ASCII):

string aqwerty = «!@#$%^&*()qwertyUIOPAzxcvbnmQQQQQQQQQQQQ)(*@&%\0»;
string anum = «0123456789012345678901234567890123456789\0»;
Также понадобится F-блок пользователя (HKLM\SAM\SAM\Domains\Account\users\\F), а именно его 16 байт: F[0x70:0x80]

На основе этих значений, склееных в один большой массив формируем MD5 хэш, который будет являться ключем для шифрования RC4

rc4_key = MD5(F[0x70:0x80] + aqwerty + bootkey + anum).

Последним шагом для получения hashed bootkey будет rc4 шифрование( или дешифрование — в rc4 это одна и та же функция) полученым ключем фрагмента F-блока F[0x80:0xA0];

Hashed bootkey у нас в руках, осталось научиться с ним правильно обращаться.

Дешифруем пароли с помощью Hashed Bootkey

для паролей LM и NT нам понадобятся еще 2 строковые константы —

string almpassword = «LMPASSWORD»;
string antpassword = «NTPASSWORD»;

а так же RID пользователя в виде 4х байт (дополненый нулями) и первая половина Hashed Bootkey (hashedBootkey[0x0:0x10]);
Все это склеивается в один массив байт и считается MD5 по правилам:
rc4_key_lm = MD5(hbootkey[0x0:0x10] +RID + almpassword);
rc4_key_nt = MD5(hbootkey[0x0:0x10] +RID + antpassword);

полученый md5 хэш — ключ для rc4, которым зашифрованы LM и NT хэши в V-блоке пользователя

userLMpass = RC4(rc4_key_lm,userSyskeyLMpass);
userNTpass = RC4(rc4_key_lm,userSyskeyNTpass);

На этом этапе мы получили пароли пользователя в том виде в каком они хранились бы без шифрования syskey, можно сказать, что самое сложное позади. Переходим к следующему шагу

На основе четырех байт RID’а пользователя с помощью некоторых перестановок и побитовых операций создаем 2 ключа DES. Вот функции, которые осуществляют обфускацию (С#):
private byte[] str_to_key(byte[] str) <
byte[] key = new byte[8];
key[0] = (byte)(str[0] >> 1);
key[1] = (byte)(((str[0] & 0x01) << 6) | (str[1] >> 2));
key[2] = (byte)(((str[1] & 0x03) << 5) | (str[2] >> 3));
key[3] = (byte)(((str[2] & 0x07) << 4) | (str[3] >> 4));
key[4] = (byte)(((str[3] & 0x0F) << 3) | (str[4] >> 5));
key[5] = (byte)(((str[4] & 0x1F) << 2) | (str[5] >> 6));
key[6] = (byte)(((str[5] & 0x3F) << 1) | (str[6] >> 7));
key[7] = (byte)(str[6] & 0x7F);
for (int i = 0; i < 8; i++) <
key[i] = (byte)(key[i] << 1);
>
des_set_odd_parity(ref key);
return key;
>

private byte[] sid_to_key1(byte[] rid) <
byte[] s = new byte[7];
s[0] = (byte)(rid[0] & 0xFF);
s[1] = (byte)(rid[1] & 0xFF);
s[2] = (byte)(rid[2] & 0xFF);
s[3] = (byte)(rid[3] & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];

private byte[] sid_to_key2(byte[] rid) <
byte[] s = new byte[7];
s[0] = (byte)((rid[3]) & 0xFF);
s[1] = (byte)(rid[0] & 0xFF);
s[2] = (byte)((rid[1]) & 0xFF);
s[3] = (byte)((rid[2]) & 0xFF);
s[4] = s[0];
s[5] = s[1];
s[6] = s[2];

Ну здесь особо комментировать нечего, кроме функции des_set_odd_parity(ref key) — это одна из функций библиотеки openssl, задача которой добавить некоторые «биты нечетности», используется для повышения стойкости ключа к атакам.

Далее разбиваем NT (или LM) хэш на 2 части по 8 байт и дешифруем DES’ом -одна половина зашифрована ключем сформированым функцией sid_to_key1, вторая — sid_to_key2.
obfskey_l = userNTpass[0x0:0x7]
obfskey_r = userNTpass[0x8:0xF]
byte[] deskey1 = sid_to_key1(RID);
byte[] deskey2 = sid_to_key2(RID);
byte[] md4hash_l = DES(obfskey_l, deskey1);
byte[] md4hash_r = DES(obfskey_r, deskey2);

После склеивания двух половин мы получим md4 хэш -в случае NT, или LanMan (DES) — в случае LM. Полученый хэш полностью готов к атаке перебором.
Кстати, md4 Хэш от пустого пароля — 31d6cfe0d16ae931b73c59d7e0c089c0

Исследование проведено на основе исходного кода ophcrack-3.3.1, а так же статьи Push the Red Button:SysKey and the SAM

Cached Credentials: вход в Windows под сохраненными учетными данными при недоступности домена

16.02.2022
itpro
Active Directory, Групповые политики
комментариев 15

Когда доменный пользователь входит в Windows, по умолчанию его учетные данные (Cached Credentials: имя пользователя и хэш пароля) сохраняются на локальном компьютере. Благодаря этому, пользователь сможет войти на локальный компьютер, даже если контроллеры домена AD недоступны, выключены или на компьютере отключен сетевой кабель. Функционал кэширования учетных данных доменных аккаунтов удобен для пользователей ноутбуков, которые могут получить доступ к своим локальным данным на компьютере, когда нет доступа к корпоративной сети.

Сохраненный кэш доменной учетной записи в Windows

Вход на компьютер под кэшированными данными для пользователя доступен, если он ранее хотя бы один раз авторизовался на этом компьютере, и пароль в домене не был сменен с момента входа. Пароль пользователя в cashed credentials никогда не истекает. Если доменная политика паролей вынудит пользователя изменить пароль, сохраненный пароль пользователя в локальном кэше компьютера не изменится, пока пользователь не войдет на компьютер под новым паролем. Т.е. если пароль пользователя в AD был изменен после последнего входа на компьютер, и компьютер находился все время в офлайн режиме без доступа в сеть, то пользователь сможет войти на этот компьютер под старым паролем.

Если домен Active Directory недоступен, Windows проверяет, что введенные имя пользователя и пароль соответствуют сохраненному локальному хэшу и разрешает локальный вход на компьютер.

Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл %systemroot%\System32\config\SECURITY). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

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

Настройка Cached Credentials с помощью групповых политик

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

По-умолчанию в Windows 10 /Windows Server 2016 сохраняются учетные данные для 10 пользователей. Чтобы изменить это количество, используется параметр GPO Interactive logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно задать значение от 0 до 50.

При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Compute configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.

В этом случае при входе пользователя в трее будет появляться уведомление:

• ValueName: ReportControllerMissing
• Data Type: REG_SZ
• Values: TRUE

Безопасность кэшированных учетных данных в Windows

Локальное кэширование учетных данных несет ряд рисков безопасности. Злоумышленник, получив физический доступ к компьютеру/ноутбуку с кэшированными данными, может с помощью брутфорса расшифровать хэш пароля (тут все зависит от сложности и длины пароля, для сложных паролей время подбора огромное). Поэтому не рекомендуется использовать кеширование для учетных записей с правами локального администратора (или, тем более, доменного администратора).

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

Для доменов с функциональным уровнем Windows Server 2012 R2 или выше можно добавить учетные записи администраторов домена в группу Protected Users. Для таких пользователей запрещено локальное сохранение кэшированных данных для входа.

Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).

Для мобильных пользователей – CashedLogonsCount = 1
Для обычных компьютеров – CashedLogonsCount = 0

Такие политики снизят вероятность получения хэша привелигированных пользователей с персональных компьютеров.

Предыдущая статья Следующая статья

Cпособы выгрузки учетных записей из кэша домена ⁠ ⁠

В этой статье будет рассмотрена атака с целью получения учетных записей из кэша домена и различные техники для извлечения хэшей паролей через эксплуатацию пользователя домена.

Domain Cache credential (DCC2)

Microsoft Windows хранит информацию о предыдущей авторизации пользователей локально. Соответственно, эти сведения используются в случае, если сервер авторизации (logon server) окажется недоступным. Эта технология носит название Domain Cache credential (или по другому MSCACHE или MSCASH хэш), которая сортирует хэши паролей пользователей, чтобы вы не смогли выполнить атаки навроде pass-the-hash. Для генерации хэшей используется алгоритм MSCACHE, хранящихся локально в реестре операционной системы Windows (по умолчанию, последние 10 хэшей).

Существует две версии MSCASH/MSCACHE (или DCC):

MSCACHEV1 или DCC1, используемый до Vista и Server 2003

MSCACHEV2 или DCC2, используемый после Vista и Server 2003

Переходим к рассмотрению техник для извлечения хэшей.

Metasploit – первый инструмент в нашем списке, помогающий пентестеру извлекать MSCACHE хэши, хранимые в реестре. Соответствующий модуль извлекает хэши домена, которые были закэшированы в результате настройки групповой политики (GPO). По умолчанию Windows хранит информацию о 10 последних успешных авторизаций:

По результатам отработки модуля выгружаются хэши паролей из DCC2/MSCACHE, как показано на рисунке ниже:

Этот тип хэшей также можно извлечь при помощи Python и библиотек impacket. Перед использованием данной техники следует сохранить ветви реестра system и security на локальной машине при помощи следующих команд:

reg save hklm\system c:\system

reg save hklm\security c:\secuirty

Рисунок: Сохранение ветвей реестра на локальную машину

Далее скопируйте полученные файлы туда, где установлен impacket. В нашем случае копирование происходит в систему с Kali Linux. Затем для извлечения DCC2/MSCACHE хэшей используем следующую команду:

python secretsdump.py -security -system system LOCAL

Результат отработки скрипта показан на рисунке ниже:

Рисунок: Выгрузка хэшей при помощи скрипта secretsdump.py

Ни для кого не секрет, что mimikatz – одна из наилучших утилит в арсенале пентестера для извлечения учетных записей в ОС Windows. С целью извлечения DCC2 / MSCACHEv2 хэшей необходимо установить mimikatz на скомпрометированной машине и выполнить следующую команду:

Результат выполнения вышеуказанных команд показан на рисунке ниже:

Рисунок: Выгрузка хэшей при помощи mimikatz

Переходим к следующей технике. В PowerShell Empire есть модуль для извлечения MSCACHEV2 хэшей из реестра скомпрометированной машины. Загрузите и запустите Empire в вашей локальной системе, скомпрометируйте целевой хост с целью использования пост-модуля, а затем введите следующую команду:

set agent <agent_id>

Результаты работы модуля по выгрузке MSCACHEv2 хэшей показаны на рисунке ниже:

Рисунок: Результат выгрузки хэшей при помощи модуля в PowerShell Empire

Как и в случае с Powershell Empire, вы можете использовать утилиту Koadic для извлечения DCC2 хэшей при помощи следующего модуля:

set MIMICMD lsadump::cache

Результаты работы этого модуля показаны на рисунке ниже:

Рисунок: Извлечение хэшей при помощи Koadic

Как и в примере с impacket вы можете воспользоваться скриптом mscache.py для извлечения MSCACHEV2 хэшей. Загрузите скрипт с github, и во время запуска в качестве параметров укажите пути к выгруженным файлам (как рассматривалось в разделе с impacket):

python mscache.py —security /root/Desktop/security –system /root/Desktop/system

Результаты работы скрипта показаны на рисунке ниже:

Рисунок: Выгрузка хэшей при помощи скрипта mscache.py

Расшифровка полученных хэшей

Как мы уже знаем, эти хэши не используются во время атак pass the hash, и нам нужна утилита john the ripper для расшифровки:

john —format=mscasch2 —wordlist=/usr/share/wordlists/rockyou.txt mhash

В результате получаем пароль в открытом виде для указанного хэша. Старайтесь не путаться между понятиями DCC2 и MSCACHEV2/MSCASH. Эти хэши идентичные и могут извлекаться при помощи вышеуказанных техник.

1.4K постов 25.1K подписчика

Правила сообщества

Обязательно к прочтению для авторов:

1. Если вы добавляете пост, утверждающий об утечке данных или наличии дыр в системе, предоставьте ссылку на источники или технически подкованное расследование. Посты из разряда «Какой-то банк слил данные, потому что мне звонили мошенники» будут выноситься в общую ленту.
2. Все вопросы «Как обезопасить сервер\приложение\устройство» — в лигу «Компьютер это просто».

Обязательно к прочтению для всех:

Добавление ссылки разрешено если она не содержит описание коммерческих (платных) продуктов и/или идентификаторов для отслеживания перехода и для доступа не нужен пароль или оплата в т.ч. интернет-ресурсы, каналы (от 3-х тематических видео), блоги, группы, сообщества, СМИ и т.д.

Запрещены политические holy wars.

По решению модератора или администратора сообщества пользователь будет забанен за:

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

2. Публикацию поста/комментария не соответствующего тематике сообщества, в том числе обсуждение администраторов и модераторов сообщества, для этого есть специальное сообщество.

3. За обвинение в киберпреступной деятельности.

4. За нарушение прочих Правил Пикабу.

А контрится все это, насколько я помню, банальным убиранием прав дебага. И выдачей их крайне на ограниченное время.

Один раз мимикатц здорово помог в одной фирме. Был конфликт со старыми админами, каша с юрлицами, крч работать надо, а дела старые админы не передавали. В итоге дернули из файла гибернации локального админа, поставили кейлоггер, а юзеры позвали одного из старых админов пофиксить какой-то косяк. Как итог на руках доменный админ))

Всегда нравилось описание хакерских утилит, которые банально ловятся Касперским.

А ломается брутфорсом также долго как и 20 лет назад лофткряком?

А сейчас хеши цельные или если пароль 16 символов то хеши насколько я помню было два по 8?

Меня хотят засудить за пост о тухляке в сети разливаек :(⁠ ⁠

Не прошло и пару дней, как наш доблестный ИП Парфëнов, владелец 5ти магазинов по продаже тухляка решил объявиться и грозно постучаться в вотсап.

Говорит, что хочет засудить по закону о коммерческой тайне.

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

Добрый день, А. А. , не мне вас учить как составлять досудебную претензию. Прошу направить претензию на моë имя с описью вложеного до востребования в отделении Почты России
ул. 8 Марта, 57, 620063. Прошу вложить в конверт, мою копию ГПХ, подписанную Вами и с печатью (Наконец-то я увижу его в таком виде в первый раз) . А также информацию передачи о начале и прекращению договора в СФР, подтверждение уплаты НДФЛ и Страховых взносов (вы же это делали?). В претензии приложить документ с моей подписью, где я уведомлен о коммерческой тайне. Приложить перечень что в компании считается коммерческой тайной.

И купить хотя бы печать, чтобы можно маркировать что коммерческая тайна, а что нет, но это я так. Вы же не упустили этот момент?

Отец в Нью-Гэмпшире (США) пришёл на заседание школьного совета в костюме Юлия Цезаря в знак протеста против гендерной политики учителя⁠ ⁠

Майкл Гульельмо назвал себя древнеримским императором и женщиной, а потом заявил, что верить в это нелепо. Мужчина призвал к отставке директора школы и преподавателя, который с недавних пор приходит на уроки в женской одежде.

«Ваш долг — действовать в интересах детей. Учить правде, а не лжи. Фактам, а не выдумкам. Биологии, а не социальной повестке. Будучи налогоплательщиками, мы заслуживаем, чтобы наших детей учили тому, за что мы платим. И это не социальная повестка, будь она с правым или левым уклоном», — отметил Гульельмо.

Ответ на пост «Не судите по одежке»⁠ ⁠

В общем дело было так…
Работала я вахтами на Крайнем Севере.Изначально работала поваром, пекарем, зав. производством, а вот потом стала правой рукой основной начальницы и числилась в конторе, как инспектор или контролёр, кому как нравится.

Работа была не хитрая, связанная с многочисленными разъездами и перелетами с места на место.По приезду на точку, мне нужно было заполнить определённые документы, проследить за качеством еды,выяснить потребности столовой и составить заявку, прощупать микроклимат между начальником и подчиненными, не забижают ли кого, ну и принять меры, если нужно конечно. Обычно, просто так не посылали, если мне дали задание, значит ,, первые звоночки,, уже прозвенели.

Контора наша была очень большая, точки были раскиданы по всему северу,и в лицо меня почти никто не знал( до первой проверки)

Отправили меня как то на Ванкор, там уже пол года, как была открыта новая столовая и было много жалоб, как от работяг, что еда плохая, так и от коллектива, что начальство гнилое. Мне нужно было выяснить, что не так, кто виноват и виновных отправить домой.

Посадили нас на вертолёт, летела я и одна дородная дама повар. Мне было 23 года, в авиационной куртке из овчины на два размера больше, я выглядела не очень.Дама же была увешана золотом и в норковой шубе до пят, вид, ну очень представительный.На точке конечно были предупреждены, что прилетит проверяющий и повар, но кто и как выглядит никто не знал.

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

Я спокойно ушла в балок, расположилась, и когда подошло время ужина, пошла в столовую.Думаю постою-ка в очереди среди работяг, послушаю, посмотрю чем кормят и вообще,чем мои коллеги занимаются.

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

Я достала свои документы, напялила халат и пошла с ревизией.В пресловутой подсобке, где по идее должен был быть склад,было много народу и веселье шло полным ходом.Начальница и её приближенные распивали крепкие алкогольные напитки и только песни ещё не горланили.Мадам в шубе сидела с раскрасневшейся мордой и видимо, так и не сказала, что она повар на замену, а не контролёр.

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

Где хранятся пароли и настройки учетных записей пользователей домена windows

Есть два контроллера домена, А и Б. На А находятся все роли FSMO и глобальный каталог. Я выключаю А. Затем создаю учетную запись пользователя в консоли active directory пользователи и компьютеры. У меня при создании появляется сообщение с предупреждением, что глобальный каталог не доступен и по этому не удасться проверить уникальность имени создаваемого объекта, но объект всеравно создается без проблем. Так же я создаел учетку для компа и даже завел рабочую станцию в домен. После чего перезагрузил Б и убедился, что все нововведения остались. После этого запустил А и убедился, что репликация прошла от Б к А. Т.е. все созданные учетные записи компьютеров и пользователей были перенесены на А. Объясните пожалуйста (если можно с пруфлинками) — почему в отсутсвии глобального каталога были созданы новые объекты и где они хранились, пока А был не доступен?

Ответы

ГК — это раздел AD "только для чтения" — грубо говоря с миру по нитке (частичная копия всех объектов каждого домена леса AD)

в вашем случае объекты вы создавали в разделе AD — ваш домен, а не в ГК

PS: В вашей конфигурации рекомендую сделать ГК оба КД, для отказоустойчивости