RADIUS
In 1997, the Internet Engineering Task Force (IETF) finalized the RADIUS protocol specification as RFC 2058. It was superseded by RFC 2138 and later RFC 2865. RFC 2059 was the first RADIUS accounting standard; it was made obsolete by RFC 2139 and later RFC 2866. Note the difference between the RADIUS protocol specification (RFC 2865) and the RADIUS accounting specification (RFC 2866). Although both are IETF standards, RFC 2866 is an informational standard only, and RFC 2865 is a formal IETF standard.
The RADIUS specification contains client and server roles, where the NAS performs the client role. Splitting the functionality provides the foundation for scalability, because a single RADIUS server can serve multiple clients (NASs), resulting in a single data store for user credentials. Two different RADIUS packet types exist: authentication and accounting packets. The NAS sends authentication requests to the RADIUS server to check the user’s identity. This request consists of the user credentials and NAS IP address or identifier. The RADIUS server sends authentication replies that include the reply code and a set of additional attributes. An accounting request is sent to the server when the NAS reports an event, such as the session start and termination. For each successfully processed accounting request, the RADIUS server returns an accounting acknowledgment, which informs the NAS that the information was received. This handshake mechanism avoids packet loss over the UDP protocol. Authorization takes places after successful authentication. For example, your company may have policies for prohibiting access to sensitive information (such as finacial data or source code) over the Internet. In this case, even successful authentication would not grant access to sensitive data.
A typical user session occurs as follows: When a user connects to a NAS, first it verifies that the user is actually registered and that the supplied credentials are correct: this step is called authentication. The NAS forms an authentication request and sends it to the RADIUS server, which then verifies the user’s credentials against the database. The acknowledgment packet is returned to the NAS. The server reply advises the NAS to assign an IP address to the user and to establish a connection between the user and the server that the user intends to connect to, assuming that the authentication was accepted.
As the second step, the NAS determines which services the user is permitted to use and optionally applies specific resource limitations for an individual or group. This step is called authorization. Authorization can be implemented in several ways, such as applying a preconfigured access control list (ACL) to restrict the user’s access to resources and services based on one or more metrics (time of day, transport type, user group).
After a successful authentication and authorization, the NAS establishes a connection between the user and the application server. Now application data can be transmitted, while so far only access and authorization control traffic was exchanged. At this time, accounting starts as follows: the NAS stores the session’s start time and generates an accounting-requests packet for the AAA server. The initiating packet is called "accounting-start," and the terminating packet is called "accounting-stop." During the session, optional accounting update packets can be sent. For each request, the AAA server replies with an accounting-response. A usage record typically consists of the session’s start and stop times, duration, and number of input and output octets and packets transferred. Each AAA session consists of at least two report messages:
Accounting-start request message with the start time
Accounting-stop request message with the stop time and full accounting details
Figure 9-2 illustrates the interaction between the NAS and the RADIUS server.
Figure 9-2. RADIUS Interaction
RADIUS Attributes
RADIUS attributes carry the specific authentication, authorization, accounting, and configuration details for the request and response. Attributes are exchanged between the NAS and the server. Each attribute is associated with a set of properties that specifies how to interpret it. The most important property is the data type, which declares the type of data that the attribute identifies (character string, integer number, IP address, or raw binary data). The information to be transmitted with the request is packaged in a set of attribute/value pairs (AV pairs, or AVP), which consist of attribute numbers and the associated data. RFC 2865 describes the RADIUS protocol and defines the different AAA attributes. Note that RFC 2865 defines attributes 1 through 39 and 60 through 63, whereas 40 through 59 are reserved for accounting and are not defined in RFC 2865. The informational RFC 2866 extends this specification by defining the accounting-specific attributes (40 through 59). RFC 2869 is another informational RFC that extends RFC 2865 by specifying attributes 52 to 55. In summary, RFC 2865 (Standards Track) defines authentication and authorization, and the accounting part is defined in the informational RFCs 2866 and 2869.
Cisco – Testing AAA Authentication (Cisco ASA and IOS)
I always forget the syntax for this, and I’ve been meaning to publish this for a while so here you go. If you have AAA setup and people can’t log in, then the ability to test authentication against a user’s username and password is a good troubleshooting step!
Usually I’m on a Cisco ASA but I’ll tag on the syntax for IOS as well.
Solution
Cisco ASA Test AAA Authentication From Command Line
You will need to know the server group and the server you are going to query, below the ASA is using LDAP, but the process is the same for RADIUS, Kerberos, TACACS+, etc.
Настройка 802.1X на коммутаторах Cisco с помощью отказоустойчивого NPS (Windows RADIUS with AD)
Рассмотрим на практике использование Windows Active Directory + NPS (2 сервера для обеспечения отказоустойчивости) + стандарт 802.1x для контроля доступа и аутентификации пользователей – доменных компьютеров – устройств. Ознакомиться с теорией по стандарту можно в Wikipedia, по ссылке: IEEE 802.1X
Так как “лаборатория” у меня ограничена по ресурсам, совместим роли NPS и контроллера домена, но вам я рекомендую такие критичные сервисы все же разделять.
Стандартных способов синхронизации конфигураций (политик) Windows NPS я не знаю, поэтому будем использовать скрипты PowerShell, запускаемые планировщиком заданий (автор мой бывший коллега). Для аутентификации компьютеров домена и для устройств, не умеющих в 802.1x (телефоны, принтеры и пр), будет настроена групповая политика и созданы группы безопасности.
В конце статьи расскажу о некоторых тонкостях работы с 802.1x – как можно использовать неуправляемые коммутаторы, dynamic ACL и пр. Поделюсь информацией об отловленных “глюках”…
Начнем с установки и настройки failover NPS on Windows Server 2012R2 (на 2016-м все аналогично): через Server Manager -> Add Roles and Features Wizard выбираем лишь Network Policy Server.
или с помощью PowerShell:
Сделаем тоже самое и на втором сервере. Создадим папку для скрипта C:\Scripts на обоих серверах и сетевую папку на втором сервере \\SRV2\NPS-config$
На первом сервере создадим PowerShell скрипт C:\Scripts\Export-NPS-config.ps1 со следующим содержанием:
После этого настроим задание в Task Sheduler: “Export-NpsConfiguration”
Выполнять для всех пользователей — Выполнить с наивысшими правами
Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.
На резервном NPS настроим импорт конфигурации (политик):
создадим скрипт PowerShell:
и задачу на его выполнение каждые 10 минут:
Выполнять для всех пользователей — Выполнить с наивысшими правами
Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.
Теперь, для проверки, добавим в NPS на одном из серверов(!) пару коммутаторов в RADIUS-клиенты (IP и Shared Secret), две политики запросов на подключение: WIRED-Connect (Условие: “Тип порта NAS – Ethernet”) и WiFi-Enterprise (Условие: “Тип порта NAS – IEEE 802.11”), а также сетевую политику Access Cisco Network Devices (Network Admins):
После настройки, спустя 10 минут, все клиенты\политики\параметры должны появиться и на резервном NPS и мы сможем авторизоваться на коммутаторах с помощью учетной записи ActiveDirectory, члена группы domain\sg-network-admins (которую мы создали заранее).
Перейдем к настройке Active Directory – создадим групповую и парольную политики, создадим необходимые группы.
Групповая политика Computers-8021x-Settings:
Создадим группу безопасности sg-computers-8021x-vl100, куда мы будем добавлять компьютеры, которые мы хотим распределять в влан 100 и настроим фильтрацию для созданной ранее групповой политики на эту группу:
Убедиться в том, что политика успешно отработала можно открыв “Центр управления сетями и общим доступом (Параметры сети и Интернет) – Изменение параметров адаптера (Настройка параметров адаптера) – Свойства адаптера”, где мы сможем увидеть вкладку “Проверка подлинности”:
Когда убедились, что политика успешно применяется – можно переходить к настройке сетевой политики на NPS и портов коммутатора уровня доступа.
Создадим сетевую политику neag-computers-8021x-vl100:
Типовые настройки для порта коммутатора (обращаю внимание, что используется тип аутентификации “мультидомен” – Data & Voice, а также есть возможность аутентификации по mac адресу. на время “переходного периода” есть смысл использовать в параметрах:
влан id не “карантинного”, а того же, куда пользовательский компьютер должен попасть, успешно авторизовавшись – пока не убедимся, что все работает как следует. Эти же параметры могут быть использованы и в других сценариях, например, когда в этот порт воткнут неуправляемый коммутатор и вы хотите, чтобы все устройства, подключенные в него и не прошедшие аутентификацию, попадали в определенный влан (“карантинный”).
Убедиться, что компьютер\телефон успешно прошли аутентификацию можно командой:
Теперь создадим группу (например, sg-fgpp-mab ) в Active Directory для телефонов и добавим в нее один аппарат для тестов (в моем случае это Grandstream GXP2160 с мас-адресом 000b.82ba.a7b1 и соотв. учетной записью domain\000b82baa7b1).
Для созданной группы понизим требования парольной политики (используя Fine-Grained Password Policies через Active Directory Administrative Center -> domain -> System -> Password Settings Container) с такими параметрами Password-Settings-for-MAB:
тем самым разрешим использовать мас-адрес устройств в качестве паролей. После этого мы сможем создать сетевую политику для аутентификации 802.1x method mab, назовем ее neag-devices-8021x-voice. Параметры следующие:
- NAS Port Type – Ethernet
- Windows Groups – sg-fgpp-mab
- EAP Types: Unencrypted authentication (PAP, SPAP)
- RADIUS Attributes – Vendor Specific: Cisco – Cisco-AV-Pair – Attribute value: device-traffic-class=voice
Теперь, как и обещал рассмотрим пару не совсем очевидных ситуаций. Например, нам требуется подключить компьютеры\устройства пользователей через неуправляемый коммутатор (свитч). В этом случае настройки порта для него будут выглядеть следующим образом:
P.S. замечен очень странный глюк – если устройство было подключено через такой свитч, а потом его воткнули в управляемый коммутатор, то оно НЕ заработает, пока мы не перезагрузим(!) свитч Пока других способов решения этой проблемы не нашел.
Еще один момент, связанный с DHCP (если используется ip dhcp snooping) – без таких вот опций:
почему-то корректно ip адрес не получить…хотя может это особенность нашего DHCP сервера
А еще Mac OS & Linux (в которых поддержка 802.1x нативная) пытаются пройти аутентификацию пользователем, даже если настроена аутентификация по мас-адресу.
В следующей части статьи рассмотрим применение 802.1x для Wireless (в зависимости от группы, в которую входит учетная запись пользователя, его будем “закидывать” в соответствующую сеть (влан), хотя подключаться они будут к одному SSID).
CCNA Security: Configuring AAA
All users are authenticated using the Radius server (the first method). If the Radius server doesn’t respond, then the router’s local database is used (the second method).
For local authentication, define the username name and password:
Router(config)#username xxx password yyy
Because we are using the list default in the aaa authentication login command, login authentication is automatically applied for all login connections (such as tty, vty, console and aux).
Using the example above, if we do not include the local keyword, we have:
Router(config)#aaa authentication login default group radius
If the AAA server does not reply to the authentication request, the authentication will fail (since the router does not have an alternate method to try).
The group keyword provides a way to group existing server hosts. The feature allows the user to select a subset of the configured server hosts and use them for a particular service.
Configuring Console Access Using Line Password
Let’s expand the configuration example above so that console login is only authenticated by the password set on line con 0.
The named list is CONSOLE. There is only one authentication method (line).
Router(config)#aaa authentication login CONSOLE line
Once a named list (in this example, CONSOLE) is created, it must be applied to a line or interface for it to come into effect. This is done using the login authentication list_name command:
Router(config)#line con 0
Router(config-line)#exec-timeout 0 0
Router(config-line)#password cisco
Router(config-line)#login authentication CONSOLE
The CONSOLE list overrides the default method list default on line con 0. You need to enter the password “cisco” (configured on line con 0) to get console access. The default list is still used on tty, vty and aux.
To have console access authenticated by a local username and password, use the following:
Router(config)#aaa authentication login CONSOLE local
In this case, a username and password have to be configured in the local database of the router. The list must also be applied to the line or interface.
To have no authentication, use the following:
Router(config)#aaa authentication login CONSOLE none
In this case, there is no authentication to get to the console access. The list must also be applied to the line or interface.
Configuring Enable Mode Access Using External AAA Server
You can also easily configure authentication for enable mode (privilege 15) logins.
Router(config)#aaa authentication enable default group radius enable
Only the password will be requested, the username is $enab15$. Hence the username $enab15$ must be defined on the AAA server.
Configure AAA Authorization
Authorization is the process by which you can control what a user can and cannot do. First define a named list of authorization methods. Then apply that list to one or more interfaces (except for the default method list). The first listed method is used. If it fails to respond, the second one is used, and so on.
Exec Authorization
The aaa authorization exec command determines if the user is allowed to run an EXEC shell. This facility might return user profile information such as autocommand information, idle timeout, session timeout, access-list and privilege and other per-user factors. Exec authorization is only carried out over vty and tty lines.
The following example uses Radius Authentication for all users.
Router(config)#aaa authentication login default group radius local
All users who want to log in to the access server have to be authorized using Radius (first method) or local database (second method).
The following example uses Radius Authentication for Exec access.
Router(config)#aaa authorization exec default group radius local
On the AAA server, Service-Type=1 (login) must be selected.
With this example, if the local keyword is not included and the AAA server does not respond, then authorization will never be possible and the connection will fail.
If the Radius server doesn’t reply, the enable password configured locally on the router will have to be configured for the user to gain access.
Configure AAA Accounting
The aaa authorization network command runs authorization for all network-related service requests such as PPP, SLIP and ARAP. This section focuses on PPP, which is most commonly used.
The AAA server checks if a PPP session by the client is allowed. Moreover, PPP options can be requested by the client: callback, compression, IP address, and so on. These options have to be configured on the user profile on the AAA server. Moreover, for a specific client, the AAA profile can contain idle-timeout, access-list and other per-user attributes which will be downloaded by the Cisco IOS software and applied for this client.
Configuring Radius Authorization
In this scenario, the access server is used to accept PPP dialin connections. So first we must configure Radius authentication.
Router(config)#aaa authentication ppp default group radius local
Then we need to configure the Authorization.
Router(config)#aaa authorization network default group radius local
For every dial-in PPP session, accounting information is sent to the AAA server once the client is authenticated and after the disconnect using the keyword start-stop. So let’s configure the start and stop of the Accounting records.
Router(config)#aaa accounting network default start-stop group radius local
Let’s say we only want accounting information to be sent and recorded after a client’s disconnects. We then use the keyword stop and configure the following line.
Router(config)#aaa accounting network default stop group radius local
Until this point, AAA accounting provides start and stop record support for calls that have passed user authentication. But what happens if authentication or PPP negotiation fails? There is no record of authentication. The solution is to use AAA resource failure stop accounting command.
Router(config)#aaa accounting send stop-record authentication failure
Then a stop record is sent to the AAA server. But what if we want to enable full resource accounting, which generates both a start record at call setup and a stop record at call termination? We would then configure the following.
Router(config)#aaa accounting resource start-stop
With this command, a call setup and call disconnect start-stop accounting record tracks the progress of the resource connection to the device. A separate user authentication start-stop accounting record tracks the user management progress. These two sets of accounting records are interlinked using a unique session ID for the call.