У меня есть сервер OpenVPN, который аутентифицируется в Active Directory и поэтому запрашивает у каждого пользователя имя пользователя и кодовую фразу.
Вдобавок к этому он также требует, чтобы у каждого пользователя был сертификат клиента и ключ клиента (+ server ca.crt).
Вопрос
Я хотел бы, чтобы каждый пользователь входил в систему со своим именем пользователя AD и парольной фразой, и чтобы все клиенты использовали один и тот же клиентский сертификат и клиентский ключ.
Причина, по которой мне нужен общий клиентский сертификат и ключ, заключается в простоте управления и защите сети от взлома пароля.
Один из способов - просто создать одного такого клиента
cd /etc/openvpn/easy-rsa/2.0/
. /etc/openvpn/easy-rsa/2.0/build-key client1
и раздайте это каждому пользователю.
Верно ли это в этих условиях? Или клиентский сертификат и ключ надо создавать особым образом?
Во-первых, я согласен с Ингмаром Хаппом, вы не хотите передавать один-единственный ключ группе пользователей. На самом деле это не часть хорошей стратегии безопасности. Кроме того, как он упоминает, настроить ЦС и подписать / отозвать ключи с помощью easy-rsa довольно просто, и ИМО стоит дополнительных «человеческих ресурсов» (если хотите) для правильной установки / обслуживания ключей, вместо того, чтобы передавать один. .
Но в любом случае "технический" ответ - добавить
дубликат-cn
в ваш файл server.conf.
Вы не должны этого делать, потому что, как только ваш единственный ключ будет скомпрометирован по какой-либо причине (украденный ноутбук, троян, сотрудник, покидающий компанию и т. Д.), Вам нужно будет дать каждому пользователю новый, что, скорее всего, приведет к увеличению затрат времени. чем вы сохранили изначально, создав только один.
Если вы хотите избежать сложностей, связанных с созданием центра сертификации и подписанием (и отзывом) клиентских сертификатов (хотя со сценарием easy-rsa это действительно не так сложно), OpenVPN также поддерживает статические ключи (сгенерированные с помощью openvpn --genkey
), с которыми очень просто обращаться (хотя они также будут использоваться для шифрования вместо TLS).