Конфигурирование Коммутатора Cisco и устройств ASA/VPN для аутентификации с W2008R2 NPS RADIUS
Вы могли просто сохранить защищенный паролем закрытый ключ на карте флэш-памяти с интерфейсом USB и использование это в Вашей аутентификации. Не уверенный, как Вы сделали бы это легким для пользователя (зависит от Вашей ОС), но это - опция.
Как указано, Вы, вероятно, не хотите, чтобы это было единственной аутентификацией, поскольку она может быть украдена, потеряна и т.д. Но это было бы дешево и проводит подсчет как часть трех факторной аутентификации, которую я предполагаю, то, чего Вы пытаетесь достигнуть.
При ответе на "что-то еще" часть вопроса - я использовал продукт Шарнира PINsafe в течение нескольких лет, который дает то, что они называют 2,5 факторной аутентификацией. Это не вполне дает то, что Вы ищете, но после начальных инвестиций в продукт, у Вас нет стоимости распределения никаких устройств, но довольно безопасно против всех кроме самых тщательно продуманных клавиатурных перехватчиков. Если бы Вы волновались по поводу этого, то Вы, вероятно, не искали бы дешевое решение :-)
You're going to want to stick with creating/ordering Network Policies to do what you're trying to do. Just use the one default Connection Request Policy that is wide open, and then secure via the NPs.
You can "divide the two" as you say, by limiting each Network Policy you've created with sufficient conditions, such that in combination, multiple conditions together achieve your objectives. It looks like you've specified only one condition on each policy - network group membership. As you've discovered, this won't work. When your RADIUS-enabled device asks your RADIUS server to authenticate your user, the RADIUS server forwards the users' credentials to AD, which successfully matches the credentials (cause they're vague at this point), and returns a positive to the RADIUS server, which in turn tells the device to allow the authentication. I'm forgetting all the proper RADIUS lingo here - but basically that's what's happening.
So, stack another condition (or more) onto your policy to get what you want. Sounds like you want the switch policy to work with users in the Domain\NetworkGroup, and only on your switches (these requests should never come from your ASA's IP, or some printer or user workstation or whatever). Under conditions, look under the RADIUS client section - ClientFriendlyName, or ClientIPv4Address, for example. If the conditions include that the request is coming only from one of your predefined switch IPs or names, it won't "authenticate" requests coming from your ASA IP.
Do the same for your vpn policy too. You should be good from there. You may want to start with clean Network Policies though. I don't think you're going to be able to use the settings to update non-compliant clients without some more work (and whole other policy type too).
Also, you can look at your RADIUS logs if you want more info on what its actually doing. I believe they're under system32\logfiles. You may have to enable it on your NPS server, if its not already. You can google for tools to help you read the log files, as they're not really user friendly. In a pinch, MS has an article that lists all the fields, in order. Look for the tools though (IASlogviewer? or something like that?).
Не уверенный, если это поможет, поскольку я, никогда не имею не устанавливают VPN, но это - то, как мы устанавливаем наши переключатели для использования аутентификации RADIUS с нашими логинами AD для управления коммутаторами и маршрутизаторами. Я должен обновить сообщение для включения дальнейших настроек для консольного порта также.
http://murison.wordpress.com/2010/11/11/cisco-radius-configuration-with-server-2008-r2/
Мы используем единственную политику для всех устройств с помощью regex для имени устройства, но можно создать отдельную политику для каждого устройства для начинаний с и для тестирования.