В моем журнале событий, когда мой маршрутизатор пытается использовать Radius для аутентификации, я получаю следующее:
"" "Пользователь не может быть аутентифицирован с помощью протокола аутентификации Challenge Handshake Authentication Protocol (CHAP). Для этой учетной записи пользователя не существует обратимо зашифрованного пароля. Чтобы убедиться, что обратимо зашифрованные пароли включены, проверьте политику паролей домена или настройки пароля на учетная запись пользователя. "" "
Однако я включил это для учетной записи, которую использую в свойствах пользователя в AD. Есть ли другое место, где это нужно включить, или, может быть, мне нужно подождать, пока он реплицирует или перезапустит службу (кроме Radius)? Сервер IAS - это тот же компьютер, что и контроллер домена, и я внес изменения на этой машине, поэтому думаю, что они сразу же вступят в силу.
Кроме того, насколько небезопасно «обратимо зашифрованные пароли»?
Редактировать:
Я также должен, наверное, сказать, почему я делаю это, если есть лучший способ. Я настраиваю маршрутизатор Cisco на конечную точку для инициируемых клиентом туннелей L2TP / IPSec. Я хочу пройти аутентификацию с помощью AD, поэтому, если есть лучший способ обработки аутентификации, дайте мне знать :-) В идеале я мог бы использовать встроенный Windows VPN Client.
Ссылка mh правильная - если что-то сохранено таким образом, чтобы его можно было восстановить, его следует рассматривать не лучше, чем открытый текст. Поскольку это реализовано в AD, включение обратимого шифрования означает, что любой (или что угодно) с правами администратора домена может расшифровать пароли, потому что у них есть доступ к глобальному секрету LSA, который является единственной частью используемого процесса, которая является секретной в любом смысле, все остальное может быть прочитано из AD кем угодно или содержится в DLL, которой можно манипулировать \ реконструировать.
С точки зрения атаки, если у кого-то есть права администратора домена, игра уже окончена, но с точки зрения внутренней безопасности это также означает, что администраторы домена могут расшифровывать пароли в исходный простой текст, что не очень хорошо. По крайней мере, я бы не хотел столкнуться с расследованием безопасности, где ключевым доказательством были записи журнала событий, показывающие, что пользователь входит и выходит с использованием пароля, который технически я мог бы знать, если бы захотел.
Есть интересный набор записей в блоге Нильса Тьюзинка на тему, начиная с Вот.
Есть много лучших альтернатив с точки зрения аутентификации (сертификаты X.509, токены одноразового пароля, смарт-карты ...), но сможете ли вы их использовать или нет, зависит от вашего приложения и клиентской системы, которую необходимо использовать пользователям. Если у вас есть полный контроль над средой, вы сможете найти решение, которое позволит вам избежать их использования, но их правильная реализация может быть дорогостоящей, а ваши пользователи могут посчитать их неудобными.
Отредактировано после вашего обновления Я бы посоветовал использовать интегрированные сертификаты AD, это потребует немного усилий, но конечный результат будет надежным, и вы сможете повторно использовать эту возможность для множества других вещей.
Страница Microsoft TechNet об этом (Вот) в основном говорит:
«Хранение паролей с использованием обратимого шифрования по сути то же самое, что и хранение версий паролей в открытом виде. По этой причине эту политику никогда не следует включать, если только требования приложений не перевешивают необходимость защиты информации о паролях».
Причина, по которой он не работала, по всей видимости, заключалась в том, что необходимо сбросить пароль. Я смог сделать это через Active Directory.
Кроме того, кажется, я могу настроить маршрутизатор и сервер Radius для использования ms-chap-v2, для которого не требуется хранить пароли с обратимым шифрованием.