Use of IEEE 802.1x standard in data network
802.1x is a standard that is used to authenticate and authorize users and workstations in a data network. Thanks to the 802.1x standard, you can give users access rights to the corporate network and its services, depending on the group or position that owns one or another user. So, having connected to a wireless network or a network outlet anywhere in the corporate network, the user will be automatically placed in the VLAN that is predetermined by the policies of the group to which the user account or his workstation is associated with in AD. The corresponding ACL access list (static or dynamic, depending on user rights) to control access to corporate services will be associated with this VLAN. In addition to access lists, QoS policies can be attached to a VLAN to control bandwidth.
I am mostly a Cisco technician and I want to talk about one of the many IEEE 802.1x models in a data network built on Cisco Systems equipment.
In order to implement this model, you need a minimum set of the following components:
For extended functionality, it will not be superfluous:
The native 802.1x client is present in many operating systems, such as Windows XP / Vista / 7 / CE / Mobile, Linux, Solaris, Apple OS X, and others. But, as practice shows, the zoo of operating systems running user workflows the stations and, therefore, the abundance of built-in motley supplikant in them does not facilitate, but on the contrary several times complicates the implementation and further use of the 802.1x standard in the company. To facilitate your account, it is advisable to use a unified third-party client that you like best, one that would work under all the operating systems that are installed on your users' workstations.
')
I would not recommend using free supplicants that are distributed online, because in practice, they were not functional enough. Regarding the Cisco Secure Services Client offered by Cisco Systems, unfortunately, it is no longer supported, as the quotation from their official website says: “ Cisco announces the end Secure Services Client. The last day to order the affected product (s) is January 27, 2012 ". I'd like to add that I really liked the Juniper Networks Odyssey Access Client , using which you can pre-configure it as you like, create an MSI installation package file and deploy it centrally on user workstations.
To demonstrate the operation of the IEEE 802.1x standard, I’ll provide a diagram of the authorization process in a simplified form, where the numbers indicate the step number:
Nowadays it is difficult to imagine a company whose information infrastructure would not be managed. By managed infrastructure, I mean a domain network. When using the 802.1x standard in a domain environment, one nuance must be taken into account - it is impossible to perform authorization in a data network only by a user account! The thing is that when loading, before displaying the user authorization window, the workstation must go through several stages:
In total, this will not happen if you authorize only by the user account. And the reason is simple, an unauthorized workstation will not be allowed to the data network when downloading, all protocols except EAPoL, which are usually used for normal operation, will be blocked until the moment of authorization. Therefore, if the station has not been authorized on the network before the user’s login, group policies will not be applied to it. If you work in a domain environment, you must first authorize a workstation on the network, so that it goes through all the above steps. What to do after authorization of a workstation is up to you, but there are two options:
Suppose you decide to first authorize the workstation, and then the user according to his credentials in AD. On the one hand, the approach is correct, but on the other, the following problems arise:
The safest and safest option would be to authorize a workstation on the network using a certificate without user authorization. Of course, this does not mean that you need to permanently abandon user authorization. Just for this, it is necessary to approach the authorization process somewhat from the other side - if before we were talking about the procedure of changing VLAN (dynamic VLAN) as the main separator of user rights, then in this case we will be helped by a dynamic access list. As a result, instead of changing the VLAN and IP address, the ACL rules of a specific VLAN will change in accordance with the access rights of a specific user. Unfortunately, this feature is not available everywhere, but at least it is on the ACS version 5.2 access control server.
By the way, here I would like to consider some logical elements of the relationship between the ACS access control server, also known as the Cisco Access Control Server, also known as the RADIUS server, and the credential storage, for example, Active Directory. The ACS server establishes a relationship with AD by type:
ACS Object Group = AD Object Group
Access rights for objects of a particular group are set to ACS. The logic of work is obtained as follows:
If no match is found or the AD server reports that the authorization information is invalid, the switch places the port in the guest VLAN.
Now that it has become more or less clear with the authorization procedure, it is necessary to provide for abnormal situations:
1. The 802.1x client is not included . In the case when the client is not active, the workstation cannot identify itself, it is automatically placed in the guest VLAN with limited access to the data network. The process of performing this function is shown in the figure:
2. The 802.1x client is enabled, but not configured correctly . In the case when the client cannot correctly identify itself, the workstation is automatically placed in the guest VLAN with limited access. The process of performing this function is shown in the figure:
3. RADIUS server is unavailable . In order to increase fault tolerance in case of failure of the authentication server, the workstation is placed in the Failover VLAN with the minimum necessary data access rights to perform the work:
I’ll also note that with the definition of the inaccessibility of the RADIUS server, Cisco Systems made a blunder, namely, after the deadtime timer expired, the switch considers the dead RADIUS server alive and, if configured, starts the reauthorization of all users connected to it. It is not difficult to imagine how users start “sausage” when they are forced to go through authorization again, while the RADIUS server is still dead, although the switchboard considers it alive. As a result, workstations cannot authenticate at all in any VLAN, they remain suspended in the air, cut off from the network, they cannot get into either the guest VLAN or the Failover VLAN.
This error is officially recognized by Cisco, its description can be found on their website:
" CSCir00551 - Misleading radius debug message
Description
Symptom:
The "% RADIUS-4-RADIUS_ALIVE: RADIUS server 172.27.66.89:2295,2296 has returned."
is a little misleading. It is not saying that the server has been returned.
sense of being heard from. It is only saying that RADIUS has marked the server
as it is dead because the timer has been expired, and RADIUS is willing to
re-send messages to this server again.
Conditions:
None
Workaround:
None "
All switch operating systems are affected by this error, up to the most recent versions I have been able to check. In addition, they are all listed in the affected OS list on the official Cisco website. Why still have not corrected this error, it remains only a mystery.
To implement all of the above, you need to do a lot of work, a lot, starting with setting up the ACS server, certificate servers, AD, DHCP, access switches and setting up supplicants at workstations and issuing certificates to them.
Here we will focus on configuring only switches. Settings will vary depending on the newness of IOS.
To configure communication with the RADIUS server, the following commands are required in global configuration mode:
To configure a separate port, use the following commands:
1. General commands:
2. Guest VLAN:
3. Failover VLAN:
Together:
To configure communication with the RADIUS server, the following commands are required in global configuration mode:
To configure a separate port, use the following commands:
1. General commands:
2. Guest VLAN:
3. Failover VLAN:
Together:
In conclusion, I want to note that it is possible to talk about the principles of operation of the 802.1x standard much longer, more and deeper. In this material I tried to set out the most basic, elementary principles of working with this standard. At one time, I would have found this material very useful as a starting point for its future study.
I am mostly a Cisco technician and I want to talk about one of the many IEEE 802.1x models in a data network built on Cisco Systems equipment.
In order to implement this model, you need a minimum set of the following components:
- a switch that will act as an authenticator;
- authentication server (RADIUS server);
- DHCP server;
- 802.1x supplicant (client) on the user's workstation;
For extended functionality, it will not be superfluous:
- server storage user credentials (AD, Samba, etc.);
- certificate servers.
The native 802.1x client is present in many operating systems, such as Windows XP / Vista / 7 / CE / Mobile, Linux, Solaris, Apple OS X, and others. But, as practice shows, the zoo of operating systems running user workflows the stations and, therefore, the abundance of built-in motley supplikant in them does not facilitate, but on the contrary several times complicates the implementation and further use of the 802.1x standard in the company. To facilitate your account, it is advisable to use a unified third-party client that you like best, one that would work under all the operating systems that are installed on your users' workstations.
')
I would not recommend using free supplicants that are distributed online, because in practice, they were not functional enough. Regarding the Cisco Secure Services Client offered by Cisco Systems, unfortunately, it is no longer supported, as the quotation from their official website says: “ Cisco announces the end Secure Services Client. The last day to order the affected product (s) is January 27, 2012 ". I'd like to add that I really liked the Juniper Networks Odyssey Access Client , using which you can pre-configure it as you like, create an MSI installation package file and deploy it centrally on user workstations.
To demonstrate the operation of the IEEE 802.1x standard, I’ll provide a diagram of the authorization process in a simplified form, where the numbers indicate the step number:
Nowadays it is difficult to imagine a company whose information infrastructure would not be managed. By managed infrastructure, I mean a domain network. When using the 802.1x standard in a domain environment, one nuance must be taken into account - it is impossible to perform authorization in a data network only by a user account! The thing is that when loading, before displaying the user authorization window, the workstation must go through several stages:
- Get an IP address;
- Identify the site and domain controller;
- Establish a secure tunnel to AD using the LDAP and SMB protocols;
- Log in to the domain using the Kerberos account of the workstation;
- Download GPO;
- Run the scripts prescribed by the GPO on the workstation.
In total, this will not happen if you authorize only by the user account. And the reason is simple, an unauthorized workstation will not be allowed to the data network when downloading, all protocols except EAPoL, which are usually used for normal operation, will be blocked until the moment of authorization. Therefore, if the station has not been authorized on the network before the user’s login, group policies will not be applied to it. If you work in a domain environment, you must first authorize a workstation on the network, so that it goes through all the above steps. What to do after authorization of a workstation is up to you, but there are two options:
- Leave as it is;
- Perform additional authorization for user credentials.
Suppose you decide to first authorize the workstation, and then the user according to his credentials in AD. On the one hand, the approach is correct, but on the other, the following problems arise:
- If you use the Fast Logon Optimization registration procedure, then group policies and scripts will not have time to apply on the workstation before the user is authorized and moved to another VLAN with the subsequent change of the IP address.
- If you disabled Fast Logon Optimization, then such an unpleasant situation can happen, when there are a lot of group policies and scripts, and the user is so fast that he managed to enter his credentials and get into his VLAN with changing IP address, then the process of correctly enabling the workstation will be interrupted.
- If you use authorization with user credentials, then problems with remote connection to the workstation by the administrator are not excluded. It is possible to change the VLAN, and with it the IP address when another user connects.
The safest and safest option would be to authorize a workstation on the network using a certificate without user authorization. Of course, this does not mean that you need to permanently abandon user authorization. Just for this, it is necessary to approach the authorization process somewhat from the other side - if before we were talking about the procedure of changing VLAN (dynamic VLAN) as the main separator of user rights, then in this case we will be helped by a dynamic access list. As a result, instead of changing the VLAN and IP address, the ACL rules of a specific VLAN will change in accordance with the access rights of a specific user. Unfortunately, this feature is not available everywhere, but at least it is on the ACS version 5.2 access control server.
By the way, here I would like to consider some logical elements of the relationship between the ACS access control server, also known as the Cisco Access Control Server, also known as the RADIUS server, and the credential storage, for example, Active Directory. The ACS server establishes a relationship with AD by type:
ACS Object Group = AD Object Group
Access rights for objects of a particular group are set to ACS. The logic of work is obtained as follows:
- A request for verification of authorization data comes;
- ACS accesses the AD server asking who it is and what AD group it is in;
- AD reports that this is such an object and it is in my group;
- ACS matches the name of the AD group and the locally-created group with the ACS access policies to which it corresponds;
- If a match is found, the ACS tells the switch which access rules to apply to the port according to the specified security criteria on the ACS for that group.
If no match is found or the AD server reports that the authorization information is invalid, the switch places the port in the guest VLAN.
Now that it has become more or less clear with the authorization procedure, it is necessary to provide for abnormal situations:
1. The 802.1x client is not included . In the case when the client is not active, the workstation cannot identify itself, it is automatically placed in the guest VLAN with limited access to the data network. The process of performing this function is shown in the figure:
2. The 802.1x client is enabled, but not configured correctly . In the case when the client cannot correctly identify itself, the workstation is automatically placed in the guest VLAN with limited access. The process of performing this function is shown in the figure:
3. RADIUS server is unavailable . In order to increase fault tolerance in case of failure of the authentication server, the workstation is placed in the Failover VLAN with the minimum necessary data access rights to perform the work:
I’ll also note that with the definition of the inaccessibility of the RADIUS server, Cisco Systems made a blunder, namely, after the deadtime timer expired, the switch considers the dead RADIUS server alive and, if configured, starts the reauthorization of all users connected to it. It is not difficult to imagine how users start “sausage” when they are forced to go through authorization again, while the RADIUS server is still dead, although the switchboard considers it alive. As a result, workstations cannot authenticate at all in any VLAN, they remain suspended in the air, cut off from the network, they cannot get into either the guest VLAN or the Failover VLAN.
This error is officially recognized by Cisco, its description can be found on their website:
" CSCir00551 - Misleading radius debug message
Description
Symptom:
The "% RADIUS-4-RADIUS_ALIVE: RADIUS server 172.27.66.89:2295,2296 has returned."
is a little misleading. It is not saying that the server has been returned.
sense of being heard from. It is only saying that RADIUS has marked the server
as it is dead because the timer has been expired, and RADIUS is willing to
re-send messages to this server again.
Conditions:
None
Workaround:
None "
All switch operating systems are affected by this error, up to the most recent versions I have been able to check. In addition, they are all listed in the affected OS list on the official Cisco website. Why still have not corrected this error, it remains only a mystery.
To implement all of the above, you need to do a lot of work, a lot, starting with setting up the ACS server, certificate servers, AD, DHCP, access switches and setting up supplicants at workstations and issuing certificates to them.
Here we will focus on configuring only switches. Settings will vary depending on the newness of IOS.
Old ios
To configure communication with the RADIUS server, the following commands are required in global configuration mode:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server host 192.168.20.20 auth-port 1645 acct-port 1646 key SecretSharedKey123
radius-server source-ports 1645-1646
radius-server dead-criteria time 5 tries 4
radius-server deadtime 30
dot1x system-auth-controlTo configure a separate port, use the following commands:
1. General commands:
interface GigabitEthernet1/0/1
switchport mode access
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end2. Guest VLAN:
interface GigabitEthernet1/0/1
dot1x guest-vlan 1 // VLAN
dot1x auth-fail vlan 1 //auth-fail VLAN
dot1x auth-fail max-attempts 2
end3. Failover VLAN:
interface GigabitEthernet1/0/1
dot1x critical
dot1x critical vlan 150 //failover VLAN
endTogether:
interface GigabitEthernet1/0/1
switchport mode access
dot1x critical
dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout reauth-period server
dot1x timeout tx-period 5
dot1x reauthentication
dot1x guest-vlan 1 // VLAN
dot1x auth-fail vlan 1 //auth-fail VLAN
dot1x auth-fail max-attempts 2
dot1x critical vlan 150 //failover VLAN
spanning-tree portfast
endNew ios
To configure communication with the RADIUS server, the following commands are required in global configuration mode:
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
radius-server dead-criteria time 5 tries 4
radius-server deadtime 30
radius-server host 192.168.20.20 key SecretSharedKey123
dot1x system-auth-controlTo configure a separate port, use the following commands:
1. General commands:
interface GigabitEthernet1/0/1
switchport mode access
authentication port-control auto
authentication violation protect
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
end
2. Guest VLAN:
authentication event fail action authorize vlan 1
authentication event no-response action authorize vlan 13. Failover VLAN:
authentication event server dead action authorize vlan 150Together:
interface GigabitEthernet0/2
switchport mode access
authentication event fail action authorize vlan 1
authentication event server dead action authorize vlan 150
authentication event no-response action authorize vlan 1
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation protect
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
spanning-tree portfast
endIn conclusion, I want to note that it is possible to talk about the principles of operation of the 802.1x standard much longer, more and deeper. In this material I tried to set out the most basic, elementary principles of working with this standard. At one time, I would have found this material very useful as a starting point for its future study.
Source: https://habr.com/ru/post/138889/
All Articles