Автор: Сгибнев Михаил
В ходе повседневной работы может сложиться ситуация, когда необходимо предоставить пользователю возможность удаленной работы. Одним из распространенных решений является доступ к внутренней сети организации с помощью Cisco VPN Client и маршрутизатора Cisco. Его основное преимущество по сравнению с Cisco AnyConnect — простая реализация поддержки аутентификации пользователей с помощью сертификатов.
Материалов по настройке Cisco VPN Client в Интернете довольно много, но когда встала необходимость аутентифицировать пользователя с использованием eToken, я обнаружил катастрофическую нехватку документации, которую и хочу сейчас несколько восполнить.
Основным преимуществом eToken, как мне показалось, является то, что при имеющемся развернутом Microsoft AD, пользователю и для аутентификации удаленного доступа и для аутентификации на рабочей станции требуется помнить только пароль на eToken.
Для реализации задуманного нам будет необходимы следующие вещи:
- eToken_PKI_Client — обеспечивает поддержу eToken и должен быть установлен как
на сервере CA, так и на клиентской машине - Cisco VPN Client
- Microsoft Server Enterprise 2003 (обратите внимание — Enterprise, в противном случае вы не сможете создавать шаблоны для CA)
- Simple Certificate Enrollment Protocol (SCEP) Add-on for Certificate Services
- Маршрутизатор Cisco 1811, с установленным IOS adventerprisek9 (если вы не хотите использовать AnyConnect, то номер версии не важен)
Так же, можно воспользоваться системой eToken TMS, которая интегрируясь со службой каталога Microsoft Active Directory может намного упростить жизнь системному администратору. Но она, при всех своих плюсах, является платным продуктом. При ее использовании создаются специализированные шаблоны, позволяющие упростить процедуру получения сертификата пользователем.
Итак, приступаем к настройке CA.
При установке непосредственно самого Certification Authority необходимо выбрать тип Enterprise Root CA. Если вы выберете Standalone CA, то не сможете работать с шаблонами CA, что не позволит вам создавать пользовательские сертификаты. Если в вашей организации уже имеется enterprise CA, и сертификаты пользователей планируется создавать на нем, то можно установить stand-alone CA, который будет заниматься непосредственно работой с SCEP.
[ad name=»Google Adsense»]
После установки необходимо добавить к CA поддержку протокола SCEP,
с помощью которого маршрутизатор будет забирать сертификат с сервера CA.
Особое внимание обращаю на существующие ограничения:
- В имени сервера не должно быть знаков, отличных от букв и цифр (никаких &,*, :, ;, ‘, «,)
- SCEP Add-on может запускаться от имени системного пользователя или локального пользователя. В последнем случае, пользователь должен быть членом группы IIS_WPG и должен иметь права Read и Enroll для шаблона IPSec (Offline request)
Для повышения безопасности, я вам рекомендую использовать «Challenge Phrase Option»
Поля заполняются произвольно. Поле «Name» должно в дальнейшем соответствовать имени trustpoint на маршрутизаторе, поэтому советую проявить сдержанность и избежать экзотики.
Теперь настала пора конфигурировать маршрутизатор. Его конфигурация будет довольно проста:
!
hostname vpn
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$vaB9$RNy7FWElMOHj0b1qPh59a.
!
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
username vpnclients priv 0 secret XXX
!
aaa session-id common
clock timezone MSK 3
clock summer-time MSD recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
ip domain name my.ru
ip host cert.my.ru 192.168.1.2
ip name-server 192.168.1.2
!
!
crypto isakmp policy 10
encr aes 256
hash md5
group 2
crypto isakmp client configuration address-pool local VPNpool
!
!
crypto isakmp client configuration group VPNClients
dns 10.1.5.2 10.1.2.1
domain my.ru
acl split
firewall are-u-there
include-local-lan
split-dns my.ru
crypto isakmp profile Remote-VPN
match identity group VPNClients
!
!
crypto ipsec transform-set myset esp-3des esp-sha-hmac
!
crypto dynamic-map dynmap 10
set transform-set myset
set isakmp-profile Remote-VPN
reverse-route
!
!
!
crypto map vpn local-address FastEthernet0
crypto map vpn client authentication list userauthen
crypto map vpn isakmp authorization list groupauthor
crypto map vpn client configuration address respond
crypto map vpn 10 ipsec-isakmp dynamic dynmap
!
!
interface FastEthernet0
description --- External ---
crypto map vpn
!
!
ip access-list extended split
permit ip 10.0.0.0 0.255.255.255 any
permit ip 172.16.0.0 0.15.255.255 any
permit ip 192.168.0.0 0.0.255.255 any
!
ip local pool VPNpool 192.168.1.100 192.168.1.200
!
ntp server 10.255.255.3
Если вы укажете строку crypto map vpn client authentication list userauthe, то при соединении пользователя дополнительно будет запрашиваться логин/пароль. Для этого создан пользователь vpnclients, но при не обходимости не составит труда прикрутить это к Radius.
Во всех изученных мной примерах использовался des, но схема реально заработала только при использовании 3des. Обязательно синхронизируйте время на сервере CA и на маршрутизаторе, иначе начнутся ошибки при работе с сертификатами. Например при настройке Web SSL возможна ситуация создания self-signed сертификата, так как срок действия полученного еще не начался (маршрутизатор не успел получить точное время). Та же самая картина может быть и в нашем случае. Как написано в документации, имея в сертификате установленный параметр OU (Organisation Unit) можно регулировать доступ, задавая имя группы (На приведенном ниже скриншоте — IT).
В нашем случае, пользователь должен иметь атрибут OU = VPNClients. Настройка trustpoint выглядит так:
!
crypto pki trustpoint cert
enrollment mode ra
enrollment url http://cert.my.ru:80/certsrv/mscep/mscep.dll
usage ike
serial-number none
subject-name cn=vpn.my.ru,o=Rogaikopyta
crl query ldap://cert.my.ru
revocation-check crl
auto-enroll
!
Запрашиваем сертификат сервера:
crypto pki authenticate cert
Обращаю ваше внимание на то, что перед получением своего сертификата, необходимо получить пароль, пройдя по ссылке http://cert.my.ru:80/certsrv/mscep/mscep.dll:
Получаем свой сертификат нижеприведенной командой:
crypto pki enroll cert
После получения сертификата мы можем приступить к самой нелегкой части пути — получению пользовательский сертификатов.
Все дальнейшие действия будут проводиться на сервере.
Нам потребуется добавить в раздел Cerificate Templates шаблон Enrollment Agent, для чего нажимаем правой кнопкой мыши на этот пункт, выбираем «New -> Cerificate Template to Issue» и в появившемся окне выбираем необходимый нам шаблон. Этот шаблон нам понадобится для генерации сертификата администратора, подписывающего сертификаты пользователей.
Также необходимо создать шаблон для пользователей.
- Щелкаем правой кнопкой на шаблон «Smartcard Logon», выбираем пункт «Dublicate Template».
- В открывшемся окне «Properties of New Template» на вкладке «General» указываем имя шаблона, в данном случае это «eToken Smartcard Logon».
- Устанавливаем галочку на пункте «Publish certificate in Active Directory».
- На вкладке «Request Handling» поле «Purpose» должно иметь значение «Signature and Encryption» и установлен параметр «Enroll subject whitout requiring any user input». Нажав на кнопку «CSPs…» выбираем из списка доступных криптопровайдеров «eToken Base Cryptographic Provider».
- Нажимаем «OK»
- На вкладке «Issuance Requirements» должен быть отмечен пункт «This number of authorized signatures»
- Нажимаем «OK»
Действия по добавлению шаблона в раздел Cerificate Templates аналогичны указанным выше.
Выписываем сертификат администратора и устанавливаем его:
Выписываем сертификат клиента. Обращаю внимание, что у меня апплет ActiveX отказался наботать на IE 7/8, используйте 6 версию.
При записи сертификата будет запрошен пароль на eToken. Возможно, клиенту может понадобиться сертификат сервера, если возникнет ошибка при чтении сертификата клиента на его компьютере. Скачайте его с CA и установите его в хранилище сертификатов браузера того компьютера, за которым будет работать удаленный пользователь.
По сравнению со сделанным, настройка клиента выглядит достаточно примитивно:
[ad name=»Google Adsense»]
Запустите Cisco VPN Client и выберите пункт меню «New», после чего введите указанные настройки: адрес сервера 193.33.122.56, имя записи и описание заполните произвольно. Укажите тип аутентификации — «Certificate Autentification» и выберите из выпадающего списка свой сертификат (eToken должен быть подключен к компьютеру)
Сохраните конфигурацию, нажав кнопку «Save». Затем выделите сохраненную конфигурацию и нажмите кнопку «Connect»
В процессе установки соединения будет запрошен пароль eToken:
Если соединение установлено, то замочек замкнется:
Вот, собственно, и все. Процесс наступания на грабли, до получения работоспособной схемы, у меня длился всю рабочую неделю, надеюсь что вам повезет больше.
Используемая литература:
Configuration Examples and TechNotes
Журнал Системный Администратор Июль 2008
[ad name=»Google Adsense»]
Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!
спасибо, что поделились опытом, это ценная информация!
у вас сказано:
«Как написано в документации, имея в сертификате установленный параметр OU (Organisation Unit) можно регулировать доступ, задавая имя группы. В нашем случае, пользователь должен иметь атрибут OU = VPNClients. »
Не нашел такого параметра в CA. Можете уточнить этот момент?
Добрый день! Этот параметр будет работать при использовании Microsoft Active Directory Certificate Services. В данном случае, OU=Department. Посмотрите, я добавил еще один скриншот, как раз после упоминания об этом моменте.
да, статья некоторое время назад помогла!
Спасибо, Михаил 🙂
задача была немножко другая. MS CA, Win2003, Radius Server, mscep.dll(для связки CA и Cisco). Cisco ASA 5510, Cisco Vpn Client. Alladin E-token Pro.
по началу связал Asa с AD через Radius, по мануалу:
PIX/ASA 7.x and Cisco VPN Client 4.x with Windows 2003 IAS RADIUS (Against Active Directory) Authentication Configuration Example
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806de37e.shtml
проверил, работает. можно заходить в сеть через vpn, используя свои данные из AD.
пошел дальше — разобрался с e-token-шаблоном в CA, по мануалу. Прописал сертификат на ключ. Немного повозился там же, сделал ауторизацию по этому же ключу на RDP виндового сервера, после того как юзер уже попал во внутреннюю сеть, тоже через CA. понравилось =)))
Дальше лучше — разобрался с конфигом ASA, таки связав железку с Win CA через SCEP. тоже помогли солюшены:
ASA/PIX 8.x and VPN Client IPSec Authentication Using Digital Certificates with Microsoft CA
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080930f21.shtml
IPSec Between PIX and Cisco VPN Client Using Smartcard Certificates
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094e69.shtml
Итого. Научился связывать ASA с CA. Разобрался с интеграцией Cisco и AD. Разобрался с ключами — выписал сотрудникам сертификаты и раздал алладиновские ключи. Все перешли с ms vpn-client на cisco vpn-client =)
Благодаря этому всему была реализованна поставленная цель:
поднять VPN с использованием E-Tokens и сертификатов по IPSEC между удаленными клиентами и Cisco Asa, предоставить клиентам доступ во внутреннюю сеть компании, в частности корпоративный терминальный сервер Win2003. С этими же ключами и сертификатами создать защищенное RDP соединение внутри сети через впн, используя CA. Т.е. настроить вход по RDP по Etokens. Удалось.
Получили 2ую линию обороны. Таким образом: первая аутентификация через Radius, используя AD login/password, затем уже проверка сертификата через CA. Затем мы в сети идем на RDP уже только с проверкой сертификата на ключе. Немного сумбурно, но думаю понятно 🙂 Естественно все настройки, тестирования, подготовка и закупка Asa и ключей, разворачивание CA — заняли немало времени. Но я хочу сказать — это было очень интересно и полезно. Жаль только, что данный солюшен удалось внедрить лишь один раз, в одном проекте. Мало кто заморачивается подобным образом, видимо. Ну ладно)) Да будет Мир на всей Земле!
Где-то полтора года назад столкнулся с необходимостью реализации описанного Вами решения. (Очень не хватало тогда вашей статьи 🙂 Информация на этот счет действительно отсутствовала в интернете). В целом всё получилось за исключением этого момента. Если в crypto pki trustpoint-е настраивал проверку CRL в базе Active Directory
crl query ldap://cert.my.ru
revocation-check crl
то CRL не проверялся и подключение не устанавливалось. Обошел это удалив
crl query ldap://cert.my.ru
и указав в качестве точки публикации CRL публичный ресурс в самом сертификате. Для себя решил, что дело в том, что для чтения из AD необходимо аутентификация иначе получить CRL не получится. Как настроить маршрутизатор на аутентификацию при запросе CRL информации не нашел. Но вы описываете работающее решение с
crl query ldap://
Если не сложно скажите в где я ошибаюсь?
Небольшой офтопик, возможно кому-то будет интересно. С выходом Windows 2008 актуальность данного решения значительно снизилась. Из моей практики, чаще всего после подключения к VPN, пользователь подключался по RDP на терминальный где и работал. В Windows 2008 парни из Microsoft научили RDS «работать» с сертификатами. Причем возможна обоюдная проверка сертификатов (и пользователя и сервера), а новые шаблоны сертификатов позволяют настроить хранение пользовательского сертификата только на ключе (в Win 2003 он автоматически копировался в личное хранилище пользователя).
Вот если бы сюда еще и авторизацию пользователей через IAS прикрутить, а не через local.
А то как в данной схеме временно запретить вход одному пользователю или определенной группе пользователей?
Добрый день Михаил,
статья интересная, спасибо!
применили ваш конфиг на своей Cisco 1841.
к сожалению пока не работает.
В deb сообщает:
Oct 5 17:02:54 PERM: ISAKMP:(0:49:HW:2): processing a CT_X509_SIGNATURE cert
Oct 5 17:02:55 PERM: ISAKMP:(0:49:HW:2): peer’s pubkey is cached
Oct 5 17:02:55 PERM: ISAKMP:(0:49:HW:2): failed to find usage restriction in ext.
Oct 5 17:02:55 PERM: ISAKMP (0:268435505): Unable to get subject name from certificate!
В это время на Cisco VPN Client в логах:
Unexpected payload type found
Failed to validate the payloads
Marking IKE for deletion
DEL_REASON_IKE_NEG_FAILED
по советам из Инет
1. cинхронизировали время на Cisco и СА
2. выключили firewall
3. исключили NAT
4. используется Cisco VPN Client 5.0.0.7
Посоветуйте пожалуйста что еще сделать, чтоб схема заработала!!
Удачного дня!
Добрый день! Мне кажется, у Вас чего-то не хватает в самом сертификате, смотрите его свойства.
добавили в конфигурацию Cisco настройку:
crypto ipsec security-association idle-time 600
и проблема решилась.
еще раз спасибо за статью!
Сразу оговорюсь: опыт настройки Cisco — 4 дня 🙁 Настраиваю Cisco 2821
Если я пишу:
test(config)#crypto isakmp client configuration group VPNClients
test(config-isakmp-group)#crypto isakmp profile Remote-VPN
То получаю сообщение:
a profile is deemed incomplete until it has match identity statements
И в результате, моя конфа выглядит так:
crypto isakmp client configuration group VPNClients
dns 10.1.5.2 10.1.2.1
domain alatus.co
acl split
firewall are-u-there
include-local-lan
split-dns alatus.co
crypto isakmp profile Remote-VPN
match identity group VPNClients
Так и должно быть?
Не согласитесь помочь (за плату) в настройке описанной Вами связки?