РЕДАКТИРОВАТЬ: Кто-нибудь действительно может ответить на вопрос? Спасибо, мне не нужен контрольный журнал, я БУДУ знать все пароли, и пользователи не могут их изменить, и я буду продолжать это делать.
Это не для взлома!
Недавно мы перешли со старого и заржавевшего домена Linux / Samba в активный каталог. У нас был собственный небольшой интерфейс для управления учетными записями. Он всегда хранил пароли всех пользователей и всех учетных записей служб в открытом виде в безопасном месте (конечно, многие из вас, конечно, не подумают, что это безопасно, но без реальных эксплойтов это никто не сможет прочитать) и отключил изменение пароля на контроллер домена самба. Кроме того, ни один пользователь не может выбирать собственные пароли, мы создаем их с помощью pwgen. Мы не меняем их каждые 40 дней или около того, а только каждые 2 года, чтобы вознаграждать сотрудников за то, что они действительно их изучили, а НЕ записывали.
Нам нужны пароли, например, войдите в учетные записи пользователей и измените настройки, которые слишком сложны для групповых политик или для помощи пользователям.
Конечно, это могут быть противоречивые правила, но я хочу продолжить их в AD. Теперь я вручную сохраняю новые учетные записи и их созданные PWGEN (pwgen создает хорошо звучащие случайные слова с хорошим количеством гласных, согласных и чисел) в старый текстовый файл, который старые сценарии использовали для автоматического сохранения.
Как мне вернуть эту функциональность в AD?
Я вижу, что в учетных записях AD есть «обратимое шифрование», вероятно, для систем аутентификации с ответом на запрос, которым нужен пароль в открытом виде, хранящийся на сервере.
Есть ли скрипт, который отображает все эти пароли? Это было бы прекрасно. (Опять же: я надеюсь, что мой DC не будет скомпрометирован.)
Или я могу установить плагин для пользователей и компьютеров AD, который будет получать уведомление о каждом новом пароле и сохранять его в файле?
На клиентах, которые возможны с GINA-dll, они могут получать уведомления о паролях и открытый текст.
Мне кажется, что вы оказываете поддержку пользователям, входя в систему с их учетными записями - зная их пароли? Как вы сказали, это очень плохая идея по многим причинам.
Я знаю, что некоторым пользователям oldschool это нравится, они просто пожимают плечами и просят вас исправить это удаленно и дать вам свой пароль. Но просто скажи нет. Никто не должен знать свой пароль, кроме самих себя - основной принцип.
Большинство вещей можно исправить из другого пользовательского контекста, вашего собственного. Те, кто действительно не может, и должны делать это с пользователем, вошедшим в систему в интерактивном режиме, требуют, чтобы пользователь сделал это и остался и наблюдал, как персонал исправляет что-то через учетную запись этого пользователя.
Удаленно есть RDP Shadow, Remote Help и аналогичные интерактивные решения, в которых пользователь контролирует ситуацию, и никому не нужно знать его или ее пароль, чтобы помочь с какой-либо проблемой, связанной с рабочим столом. При использовании групповых политик в таком поведении практически нет необходимости, поскольку большинство вещей легко настраивается администратором.
Если вы предоставляете другим людям доступ к чужим учетным записям - вы также теряете контрольный журнал и ответственность за действия, совершенные пользователями в системе, - которые могут легко выйти за пределы авторизованной группы администраторов.
Я бы не был так уверен, что мой DC в безопасности. Если бы я был злоумышленником или тестером на проникновение, я все равно не собирался сначала преследовать ваш DC. Я иду за вашими рабочими станциями и серверами. Базовый вектор атаки:
Если вы не все Vista / Windows Server 2008 / Windows 7, это основной шаблон атаки, используемый большинством пентестеров. Причина, по которой эти 3 ОС нарушают шаблон, заключается в том, что атака DLL-инъекцией против LSA Secrets не работает против этих ОС.
С учетом всего вышесказанного вы не должны использовать обратимое шифрование и должны отключить хеши LM. Вам нужны хэши NTLM. И вы не хотите хранить эти пароли в открытом виде.
То, что вы делаете, - действительно очень плохая идея. Если вы не хотите, чтобы пользователям приходилось управлять паролями, вы можете инвестировать в систему токенов запроса / ответа для AD, которая будет стоить вам минимальных денег.
Честно говоря, я не думаю, что ваши доводы в пользу этого обоснованы. Как администратор, я получаю большую дозу хибиджи-би от мысли о том, что знаю пароль пользователя. Это их личная территория, и вы просите их оказать вам ОГРОМНОЕ доверие. Даже помимо этого, если когда-либо произойдет утечка конфиденциальных данных, вы сразу попадете под подозрение, так как вы узнаете пароли пользователей. Отсутствие поддающегося проверке контрольного журнала - это колоссальный красный флаг безопасности. Правило 1 - «защити себя», и если это означает, что придется принять некоторые неудобства, то пусть так и будет.
Я думаю, что есть альтернативные решения, которые позволят добиться того, чего вы хотите, не прибегая к такой крайности, как знание паролей. Вы смотрели предпочтения групповой политики? Каковы ваши навыки написания сценариев? Использование методов грубой силы обычно является явным признаком того, что стандартный подход не используется оптимально, поэтому я думаю, что вам было бы гораздо лучше вернуться и переосмыслить то, что вы делаете.
Подотчетность, ведение журнала и отслеживание.
Мы боролись с менеджментом по этому поводу в течение нескольких лет. Генеральный директор и президент годами отказывались менять свой пароль, и каждый ИТ-специалист, приходивший и уходивший за 7 с лишним лет, знал их пароли. Даже если вы «доверяете» всем, очень небезопасно для нескольких людей, которые больше не являются сотрудниками, иметь доступ к мощным учетным записям. Не говоря уже о том, что все они знают, что другие знают пароли, и их можно безопасно использовать.
Мы снова и снова призываем пользователей никогда не сообщать свои пароли даже нам. Это начало предотвращения «взлома социальных сетей». Сколько из ваших пользователей сообщат свой пароль кому-то, кто звонит и говорит, что они одни из новых ИТ-специалистов?
Если нам абсолютно необходимо войти в учетную запись пользователя, чтобы что-то сделать, мы просим их войти в систему и использовать дробовик или изменить их пароль. Как только мы меняем их пароль, мы несем ответственность за их учетную запись, и они перестают нести ответственность, пока мы не дадим им новый пароль, с пометкой учетной записи, что пользователь должен изменить пароль при следующем входе в систему. Это сохраняет регистрацию и отслеживание. Со всем тем плохим, незаконным и неэтичным, что пользователи могут делать в Интернете. Если они смогут обвинить многих других, знающих их пароли, это может создать множество проблем.
Сейчас мы работаем над устранением всех логинов общих учетных записей, например, для общих компьютеров. Если он нам нужен, у этой учетной записи очень ограниченные права и нет доступа в Интернет.
Есть причина, по которой пароли так важны. Они предназначены не только для защиты ваших данных, они существуют для защиты вас и ваших пользователей и т. Д. Найти примеры или провести мозговой штурм несложно. Воспроизведение разговоров в уме. «Все они знали мой пароль, и один из них вошел в мой компьютер, прочитал электронное письмо от моей любовницы и сказал моей жене:« Есть много, много возможных соображений конфиденциальности, помимо безопасности.
Брайан
p.s. очень стараюсь не спорить. Хотя я не ответил на вопрос, но выступил против того, чтобы делать то, что предлагается. Я бы также рекомендовал не говорить такие вещи, цитата из вопроса - "РЕДАКТИРОВАТЬ: Кто-нибудь действительно может ответить на вопрос? Спасибо, мне не нужен контрольный журнал, я БУДУ знать все пароли, и пользователи не могут их изменить, и я будет продолжать делать это. Это не для взлома! "
Чтобы ответить на вопрос, прочтите это: http://blog.teusink.net/2009/08/passwords-stored-using-reversible.html
Внизу статьи описано, как получить сохраненный обратимый пароль. Не пробовал, поэтому не знаю, как это сделать, как описано, но он должен работать.
В остальном я согласен с остальными людьми, которые кричат о волке по поводу предложения использовать обратимое шифрование. Это просто небезопасно.
Я думаю, что вопросы аудита, подотчетности и общей безопасности были должным образом решены, поэтому я попробую другой ответ :)
Eсть Служба уведомлений о смене пароля который можно установить на всех контроллерах домена, который будет безопасно пересылать все изменения паролей принимающей службе.
Это было разработано для Identity Integration Server (теперь Identity Lifecycle Manager) в качестве цели, но должна быть возможность написать свою собственную цель или даже использовать MIIS / MILM для получения пароля и пересылки его через другой соединитель в вашу собственную систему.
Вам нужно будет получить хэши (LM или NTLM) и провести на них словарную атаку. Обнаружить кого-нибудь с умеренно сложным паролем практически невозможно. Не включайте «обратимое шифрование» - вам нужно изменить способ управления паролями.
Разблокировать администратора может решить часть вашей проблемы, не требуя знания пароля.
Есть множество способов сделать это, которые, как я видел, использовались людьми, проникшими на наши серверы. Самый популярный метод - сбросить хэши паролей в файл, используя что-то вроде pwdump4, а затем прогнать полученные хэши через радужную таблицу. Существуют некоторые ограничения на длину пароля, которые значительно усложняют этот подход, поэтому все наши административные пароли состоят из 16 или более символов.
После того, как вы вложились в хороший набор радужных таблиц (их можно найти за хорошие деньги во многих местах в Интернете, и если это действительно направление вашей деятельности для вас, стоимость не должна быть проблемой), то свалка и -decrypt для большинства пользователей может быть выполнен менее чем за 30 минут.
Мы сделали это один раз, чтобы понять, насколько легко угадываются пароли наших пользователей. Примерно 30% паролей были взломаны в течение 5 минут после начала простой атаки по словарю, а около 80% были взломаны с помощью самогенерируемой таблицы Rainbow Table менее чем за день. Это было .... 3 года назад, так что дела пошли быстрее. Результаты были представлены высшему руководству, которое быстро согласилось усилить (хорошо, фактически создать) политики паролей.
Как уже писали другие, ваша политика и практика в лучшем случае неортодоксальны. Ранее упомянутый администратор разблокировки кажется достойным компромиссом (без каламбура). Заявленная вами цель знать свои пароли пользователей, чтобы обеспечить поддержку в их профиле пользователя Windows. Хорошо. Если вашим пользователям нужна поддержка и им нужно быть в другом месте, попросите их заблокировать их рабочую станцию. Затем с помощью Unlock Administrator вы можете разблокировать станцию и остаться в своем профиле пользователя.
Вы теряете возможность подходить к любой рабочей станции, но вам больше не нужно знать их пароль. Это похоже на достойный компромисс между безопасностью и простотой поддержки.
У Microsoft есть продукт ILM, который может копировать пароли, возможно, в чужое хранилище LDAP.
Получите L0phtcrack и запустите его против DC. Это может занять ЧАСЫ, но он сможет получить большинство паролей.
На самом деле я наткнулся на это, потому что искал то же самое, но мои мотивы знать пароли пользователей совершенно разные.
Я переношу решение бывшего администратора сети с использованием IIS для клиентского FTP-хостинга, недавно мы обнаружили, что наш ftp-сервер IIS был подвергнут грубому принуждению и на нем размещалось шпионское ПО. Пароли пользователей не были задокументированы, просто сбрасывались, если кто-то забыл, поэтому я перехожу к другому решению (FileZilla), которое не использует AD. Мне нужно воссоздать все эти учетные записи AD с одинаковыми паролями (за исключением скомпрометированных учетных записей), чтобы сделать миграцию прозрачной для конечных пользователей. Поскольку для FileZilla нет утилиты миграции IIS, моя единственная надежда - взломать пароли пользователей.
Я открыт для любых предложений о том, как добиться этого, не взламывая пароли пользователей.