Доброго времени суток всем гуру. Простите чайника, если вопросы откровенно глупые.Стоит следующая задача: реализация 2-х факторной аутентификации для Remote Access VPN.
Дано: Cisco ASA 5520 (IOS 8.0(4)), Домен AD (Win2003), CA (Win2003), FreeRADIUS (Debian), токены (rutoken).
Общая идея, которой руководствовался следующая (см. рис.):
Схема: http://velos.users.photofile.ru/photo/velos/115313786/139110...
1) Выдаем пользователю сертификат и помещаем его на токен, без возможности экспорта закрытого ключа.
2) Выдаем сертификат ASA-е.
3) Создаем туннельную группу с аутентификацией peer-ов с помощью сертификатов.
4) Настраиваем в туннельной группе аутентификацию пользователей через radius.
5) RADIUS осуществляет ntlm-аутентификацию и авторизацию пользователя в AD.
6) RADIUS возвращает на ASA аксесс-лист для пользователя.
Руководствовался следующими документами:
http://www.cisco.com/en/US/products/ps6120/products_configur...
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps...
В настоящий момент получилось реализовать следующее:
Аутентификация Peer-а через сертификат (Асе был выдан сертификат по микрософтовскому шаблону IPSEC, где в поле fqdn было указано её полное доменное имя.). Пользователю также выдается токен с user-сертификатом. Туннель строится, используя этот сертификат (на стороне пользователя Cisco VPN Client).
Для меня остаются не совсем ясны некоторые моменты:
1) Сертификаты используется исключительно для аутентификации peer-ов через ЭЦП, или же открытые/закрытые ключи сторон используются для формирования разделенного секрета через алгоритм Диффи-Хеллмана?
2) В такой схеме получается, что с помощью любого сертификата, выданного внутренним удостоверяющим центром, у которого Key Usage = Signature, возможно установить туннель. Такие сертификаты у нас распространяются в домене автоматически, и у пользователей есть возможность его экспортировать вместе с закрытым ключом. Такая возможность нарушает общую идею 2ФА. Что делать в данном случае? Насколько я понял из примеров cisco, они настраивают на ASA certificate matching rule, с помощью которого по одному из значений атрибута сертификата происходит определение пользователя в VPN-группу. Т.е. необходимо для VPN сертификатов создать отдельный шаблон с каким-нибудь зарезервированным значением какого-либо из атрибутов, и на основании этого значения создать определяющее правило на ASA? Или же есть какой-либо иной способ ограничить сертификаты, которые можно было бы использовать для аутентификации peer-а?
3) Хотелось бы также с помощью сертификата решить проблему временного предоставления доступа: т.е. когда пользователю даётся VPN на какой промежуток времени. (Право доступа для пользователя определяется членством в AD-ой группе и наличием ACL-листа на Freeradius-е). Соответственно, если доступ предоставляется на время, возникает необходимость это где-то учитывать, чтоб потом эти права отнять. Как мне показалось, ограничивать доступ сроком действия сертификата – разумное решение. Но при ближайшем рассмотрении получается так, что срок действия сертификата в MS CA явно можно указать только в шаблоне сертификата. А есть ли возможность определять этот срок непосредственно в запросе?
4) CRL. Изначально конфигурил асу на прошивке 7.0(5). При настройке CRL наблюдались следующие траблы: точка распространения отозванных сертификатов через http, которая была прописана в выданном устройству сертификате содержала доменное имя. ASA успешно его разрешала в IP-адрес, но наотрез отказывалась его загружать. Проблему решила назначение точки CRL вручную, где вместо доменного имени был явно прописан ип-адрес. После обновления прошивки до 8.0(4), ASA наотрез отказывается подгружать crl в любом виде. Не могу понять, с чем это может быть связано. (С других хостов данный crl успешно загружается).
Вариант для распечатки
(ok) on 17-Авг-10, 08:50 
