http://uinc.ru/articles/29/index.shtml :
===== Начало цитаты =====
Вообще считается (так и сообщается переходом на ее использование, а также по официальным заявлениям Microsoft), что отменить использование утилиты syskey нельзя. На самом деле отключить ее можно (правда не совсем корректно), изменив следующие ключи реестра:
HKLM\SAM\Domains\Account\F
необходимо обнулить содержимое этого ключа. Эта структура хранит SID компьютера, а также другую системную информацию. Здесь же хранится копия статуса ключа SecureBoot.
необходимо также присвоить значение 0. Этот ключ хранит режим syskey:
1 - ключ в реестре
2 - ключ вводится пользователем
3 - ключ на дискете
Обнуление этих двух ключей отключает syskey для системы Windows NT 4.0. Для Windows 2000 нужно поправить еще один ключ:
HKLM\security\Policy\PolSecretEncryptionKey\
здесь хранится еще одна копия режима работы syskey.
===== Конец цитаты =====
Хотя, надо признаться, прогнал я. Я менял ключ прямо в винде. И сделал контрольный логин. А lsass взял да и восстановил ключик.
Кроме того. Если пытаться отключить syskey с линуховской дискеты (http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html), то XP-ха восстанавливает один из ключей при загрузке (а может и все - не проверял), что приводит к тому, что измененный хэш пароля оказывается инвалидным. Еще вопрос: где еще она хранит состояние syskey-я?
Если убить syskey (не отключить, а убить сам ключ). В реестре он хранится в HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\F, то на вход пользователей с пустыми паролями это не влияет (а на остальных еще как).
В связи с этим вопрос: как отключить пароль админу не снимая сискей, если есть доступ на запись в sam.
Известно, в V-блоке HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4 по смещению 9c хранится смещение (относительно конца заголовка V-блока, то бишь 0xcc от начала) хешей паролей (сначала LM, потом NT), зашифрованные DES-ом ключами получаемыми из RID-а (1F4 для админа). Но это без syskey.
У кого есть инфа о структуре HKLM\SAM\SAM\Domains\Account\F или/и V-блока для аккаунта в SAM или/и вообще по работе syskey - пишите
Почти по теме: а разве SysKey можно отключить?04.11.02 21:45 Автор: HandleX <Александр М.> Статус: The Elderman
http://uinc.ru/articles/29/index.shtml :
===== Начало цитаты =====
Вообще считается (так и сообщается переходом на ее использование, а также по официальным заявлениям Microsoft), что отменить использование утилиты syskey нельзя. На самом деле отключить ее можно (правда не совсем корректно), изменив следующие ключи реестра:
HKLM\SAM\Domains\Account\F
необходимо обнулить содержимое этого ключа. Эта структура хранит SID компьютера, а также другую системную информацию. Здесь же хранится копия статуса ключа SecureBoot.
необходимо также присвоить значение 0. Этот ключ хранит режим syskey:
1 - ключ в реестре
2 - ключ вводится пользователем
3 - ключ на дискете
Обнуление этих двух ключей отключает syskey для системы Windows NT 4.0. Для Windows 2000 нужно поправить еще один ключ:
HKLM\security\Policy\PolSecretEncryptionKey\
здесь хранится еще одна копия режима работы syskey.
===== Конец цитаты =====
Хотя, надо признаться, прогнал я. Я менял ключ прямо в винде. И сделал контрольный логин. А lsass взял да и восстановил ключик.
Кроме того. Если пытаться отключить syskey с линуховской дискеты (http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html), то XP-ха восстанавливает один из ключей при загрузке (а может и все - не проверял), что приводит к тому, что измененный хэш пароля оказывается инвалидным. Еще вопрос: где еще она хранит состояние syskey-я?
Если дело только в реестре, то можно попробовать включить SysKey на NT4 с включенным RegMon ;-)06.11.02 05:46 Автор: HandleX <Александр М.> Статус: The Elderman
Самое интересное, что если консоль получена без логина, то даже SYSTEM не может ничего сделать с юзерами на компе.
Например так:
HKEY_USERS\.DEFAULT\Control Panel\Desktop\SCRNSAVE.EXE -> cmd.exe
Logoff и дождаться консоли, после этого на
net user administrator password
следует
System error 5: Access denied
Причем с разрешениями это не связано: если получить SYSTEM с помощью debploit или getad, то все прокатывает. Также это не связано с restricted desktop-ами, т.к. если на том же desktop-е создать консоль другого пользователя, он может все делать:
runas /user:administrator cmd.exe
и из новой консоли
net user что_угодно
Какое то время я пытался с этим всем раздуплиться. Но щас бросил