If FreeRADIUS is configured to use threads, then nothing is wrong. Newer Linux kernels / procps utilities report one thread by default. To view all threads, execute `ps` command with one of the following options:
-* Old `ps` version / kernel (2.4):
+=== Old `ps` version / kernel (2.4):
* `ps -efm`
* `ps auxm`
-* Old `ps` version / kernel (2.6):
+=== New `ps` version / kernel (2.6):
* `ps -efl`
* `ps auxH`
== History
-WPA was created by the The Wi-Fi Alliance, an industry trade group, which owns the trademark to the Wi-Fi name and certifies devices that carry that name.
+WPA was created by the The Wi-Fi Alliance, an industry trade group, which owns the trademark to the Wi-Fi name and certifies devices that carry that name.
WPA is designed for use with an IEEE 802.1X authentication server, which distributes different keys to each user; however, it can also be used in a less secure *"pre-shared key" (PSK)* mode, where every user is given the same passphrase. The design of WPA is based on a Draft 3 of the IEEE 802.11i standard.
The Wi-Fi Alliance created WPA to enable introduction of standard-based secure wireless network products prior to the IEEE 802.11i group finishing its work. The Wi-Fi Alliance at the time already anticipated the WPA2 certification based on the final draft of the IEEE 802.11i standard, therefore the tags on the frame fields (Information Elements or IEs) are intentionally made different from 802.11i to avoid the confusion in unified WPA/WPA2 implementations.
-Data is encrypted using the RC4 (cipher), with a 128-bit key and a 48-bit initialization vector (IV). One major improvement in WPA over WEP is the Temporal Key Integrity Protocol (TKIP), which dynamically changes keys as the system is used. When combined with the much larger IV, this defeats the well-known related-key attack on WEP.
+Data is encrypted using the RC4 (cipher), with a 128-bit key and a 48-bit initialization vector (IV). One major improvement in WPA over WEP is the Temporal Key Integrity Protocol (TKIP), which dynamically changes keys as the system is used. When combined with the much larger IV, this defeats the well-known related-key attack on WEP.
In addition to authentication and encryption, WPA also provides vastly improved payload integrity. The cyclic redundancy check (CRC) used in WEP is inherently insecure; it is possible to alter the payload and update the message CRC without knowing the WEP key. A more secure message authentication code (usually known as a MAC, but here termed a *MIC* for "Message Integrity Code") is used in WPA, an algorithm named "Michael". The MIC used in WPA includes a frame counter, which prevents replay attack being executed;
* Network Configuration with WPA (http://www.wi-fiplanet.com/tutorials/article.php/3552826)
* Apple Airport and Wi-Fi Network Security (http://theworld.com/~reinhold/airport.html)
* EAP types supported under WPA-Enterprise (http://www.wi-fi.org/OpenSection/eap.asp)
-* Linux WPA/WPA2/IEEE 802.1X Supplicant (http://hostap.epitest.fi/wpa_supplicant/)
-* SmithMicro Quicklink Mobile Software (http://www.smithmicro.com/default.tpl?sku=QLMWA0EE&group=product_full)
-* Steve Gibson's Perfect Passwords(https://www.grc.com/passwords/)
+* Linux WPA/WPA2/IEEE 802.1X Supplicant (http://hostap.epitest.fi/wpa_supplicant/)
+* SmithMicro Quicklink Mobile Software (http://www.smithmicro.com/default.tpl?sku=QLMWA0EE&group=product_full)
+* Steve Gibson's Perfect Passwords(https://www.grc.com/passwords/)
* GRC's Ultra High Security Password Generators(http://darkvoice.dyndns.org/wlankeygen/ Online WEP-/WPA-Key Generator)
// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
errors to be found at compile time.
Use `const` everywhere. Once you throw a few into your code, and have it save
-you from stupid bugs, you’ll blindly throw in `const` everywhere. It’s a
+you from nonsensical bugs, you’ll blindly throw in `const` everywhere. It’s a
life-saver.
== Use C compiler warnings
= FreeRADIUS Dependencies
Some external dependencies must be installed before building or
-running FreeRADIUS. The core depends on two mandatory libraries:
+running FreeRADIUS. The core depends on two libraries:
`libtalloc` for memory management and `libkqueue` for event
handling.
also means that it is very hard to know if an issue encountered is
still a problem or if it is fixed in the latest release.
-Therefore, whilst the distribution-supplied packages can often be
+Therefore, while the distribution-supplied packages can often be
the most convenient to install, we do not usually recommend using
them.
possible. Full instructions on building and installing from source
code follow.
-The mandatory xref:howto:installation/dependencies.adoc[dependencies]
+The required xref:howto:installation/dependencies.adoc[dependencies]
must be installed before FreeRADIUS can be built. These dependencies
are `libtalloc` and `libkqueue`, which FreeRADIUS uses for memory
management, and platform-independent event handling.
== EAP Sub-Types
-=== LEAP
+=== LEAP
The Lightweight Extensible Authentication Protocol (LEAP) is a proprietary EAP method developed by Cisco Systems.
There is no native support for LEAP in any Windows operating system but is supported by third party supplicants. The protocol is known to be vulnerable to dictionary attacks however Cisco still maintains that LEAP can be secure if sufficiently complex passwords are used. Newer protocols like EAP-TTLS and EAP-PEAP do not have this problem and can operate on Cisco and non-Cisco Access Points.
-=== EAP-TLS
+=== EAP-TLS
*EAP-TLS*, defined in RFC 2716, is an IETF open standard, and is well-supported among wireless vendors. It offers a good deal of security, since TLS is considered the successor of the SSL standard. It uses PKI to secure communication to the RADIUS authentication server which provides excellent security however the overhead of client-side certificates can make it seem daunting to set up.
EAP-TLS is the original standard wireless LAN EAP authentication protocol. It is considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software including Microsoft. The requirement for a client-side certificate, however unpopular it may be, is what gives EAP-TLS its authentication strength and illustrates the classic convenience vs. security trade-off. A compromised password is not enough to break into EAP-TLS enabled systems because the hacker still needs to have the client-side certificate. When the client-side certificates are housed in smartcards, this offers the most security available because there is no way to steal a certificate's private key from a smartcard without stealing the smartcard itself. It is significantly more likely that physical theft of a smartcard would be immediately noticed and the smartcard revoked and a new card issued than that password theft would be noticed and the password changed or account disabled. Up until April of 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo. There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source. EAP-TLS is natively supported in MAC OS 10.3 and above, Windows 2000 SP4, Windows XP, Windows Mobile 2003 and above, and Windows CE 4.2 as well as by many Open Source EAP Clients.
-=== EAP-MD5
+=== EAP-MD5
*EAP-MD5*, defined in RFC 3748, is another IETF open standard, but offers minimal security. The MD5 hash function is vulnerable to dictionary attacks, and does not support mutual authentication or key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise.
-=== EAP-TTLS
+=== EAP-TTLS
*EAP-Tunneled Transport Layer Security*, or *EAP-TTLS*, was co-developed by Funk Software and Certicom. It is widely supported across platforms, and offers very good security, using PKI certificates only on the authentication server.
EAP TTLS is also described in an IETF internet draft, "draft-funk-eap-ttls-v0-04.txt http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v0-04.txt". Note that this an individual submission and not standardized in the IETF.
-=== EAP-IKEv2
+=== EAP-IKEv2
EAP-IKEv2 is an EAP authentication method based on the Internet Key Exchange Protocol version 2 (IKEv2). It provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:
* *Passwords* - low-entropy bit strings that are known to both the server and the peer.
* *Symmetric keys* - high-entropy bit strings that known to both the server and the peer.
-It is possible to use a different authentication credential (and thereby technique) in each direction. For example that the EAP server authenticates itself using public/private key pair and the EAP client using symmetric key. In particular, the following combinations are expected to be used in practice:
+It is possible to use a different authentication credential (and technique) in each direction. For example that the EAP server authenticates itself using public/private key pair and the EAP client using symmetric key. In particular, the following combinations are expected to be used in practice:
|===
|EAP server |EAP peer
EAP-IKEv2 is described in an IETF internet draft, http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-11.txt draft-tschofenig-eap-ikev2-11.txt. Prototype implementation can be found at http://eap-ikev2.sourceforge.net page.
-=== PEAP
+=== PEAP
*Protected Extensible Authentication Protocol* is a joint proposal by Cisco Systems, Microsoft and RSA Security as an open standard. It is already widely available in products, and provides very good security. It is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication.
*PEAPv0/EAP-MSCHAPv2
*PEAPv1/EAP-GTC
-==== PEAPv0/EAP-MSCHAPv2
+==== PEAPv0/EAP-MSCHAPv2
PEAPv0/EAP-MSCHAPv2 is the technical term for what people most commonly refer to as "PEAP". Whenever the word PEAP is used, it almost always refers to this form of PEAP since most people have no idea there are so many flavors of PEAP. Behind EAP-TLS, PEAPv0/EAP-MSCHAPv2 is the second most widely supported EAP standard in the world. There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source. PEAPv0/EAP-MSCHAPv2 is natively supported in MAC OS 10.3 and above, Windows 2000 SP4, Windows XP, Windows Mobile 2003 and above, and Windows CE 4.2. The server side implementation of PEAPv0/EAP-MSCHAPv2, called IAS (Internet Authentication Service), is also included in Windows 2003 server. PEAPv0/EAP-MSCHAPv2 enjoys universal support and is known as the PEAP standard.
This version of PEAP is defined through IETF Internet Draft "draft-kamath-pppext-peapv0-00 http://www.watersprings.org/pub/id/draft-kamath-pppext-peapv0-00.txt". Note that this is an expired draft.
-==== PEAPv1/EAP-GTC
+==== PEAPv1/EAP-GTC
-PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2. It allows the use of an inner authentication protocol other than Microsoft's MSCHAPv2. EAP-GTC (Generic Token Card) is defined in RFC 3748. It carries a text challenge from the authentication server, and a reply which is assumed to be generated by a security token. EAP-GTC does not protect the authentication data in any way.
+PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2. It allows the use of an inner authentication protocol other than Microsoft's MSCHAPv2. EAP-GTC (Generic Token Card) is defined in RFC 3748. It carries a text challenge from the authentication server, and a reply which is assumed to be generated by a security token. EAP-GTC does not protect the authentication data in any way.
Even though Microsoft (along with RSA and Cisco) co-invented the PEAP standard, Microsoft never added support for PEAPv1 in general, which means PEAPv1/EAP-GTC has no native Windows OS support. Since Cisco has always favored the use of its own less secure proprietary LEAP and EAP-FAST protocols over PEAP and markets them as simpler certificate-less solutions, standardized PEAP is rarely promoted by Cisco. With no interest from Microsoft to support PEAPv1 and little interest from Cisco to promote PEAP in general, PEAPv1 authentication is rarely used. There is no native OS support for this EAP protocol.
This version of PEAP is defined through the IETF internet draft "draft-josefsson-pppext-eap-tls-eap-05 http://www.watersprings.org/pub/id/draft-josefsson-pppext-eap-tls-eap-05.txt." Note that this is an expired draft.
-=== EAP-FAST
+=== EAP-FAST
_EAP-FAST (Flexible Authentication via Secure Tunneling)_ is a method designed by Cisco Systems to fix the weaknesses of LEAP. Use of server certificates is optional in EAP-FAST. EAP-FAST uses a Protected Access Credential (PAC). The PAC can be provisioned manually or dynamically in Phase 0 of EAP-FAST. EAP-FAST has three phases. Phase 0 is an optional phase. In Phase 1 the client and the AAA server uses the PAC to establish TLS tunnel. In Phase 2, the client sends user information across the tunnel.
== Password changes
-From FreeRADIUS version 3.0.0 the mschap module supports password
+From FreeRADIUS version 3 the mschap module supports password
changes.
There are two options, ntlm_auth and local.
of CoA/Disconnect packets for all ongoing sessions in the `radacct` table may be
possible, but great care should be taken to not overwhelm a NAS’s limited CPU
resources since disconnected devices will likely be trying to reauthenticate
-whilst other are still being disconnected. Either approach to terminating
+while other are still being disconnected. Either approach to terminating
existing sessions will of course result in an interruption of connectivity for
users.
NOTE: Recall that if `sqlippool` is invoked without a `IP-Pool.Name` check
attribute then no action is taken. Also recall that if `sqlippool` is invoked
-whilst the attribute configured in the `attribute_name` configuration item
+while the attribute configured in the `attribute_name` configuration item
(e.g. `Framed-IP-Address`) already exists then no action is taken.
optimised implementation of a worker queue:
`SELECT FOR UPDATE ...`::
-Selects rows whilst exclusively locking them to prevent simultaneous locking
+Selects rows while exclusively locking them to prevent simultaneous locking
reads and writes of those same rows. When connections are simultaneously
selecting an IP address from a pool this pragma is what provides the guarantee
of uniqueness of the IP selected for each authentication request.
blocked connections block waiting for the next free IP address to be allocated.
And so on until they have all been serviced or their query times out... In the
absence of this pragma concurrent authentication requests are unnecessarily
-serialised whilst their IP addresses are allocated resulting in poor
+serialised while their IP addresses are allocated resulting in poor
performance.
Here are some comments regarding the main database engines in relation to this
selection cannot always be guaranteed.
Ingress nodes (relays, proxies, etc.) typically balance reads across all
-cluster nodes (master and slave) whilst sending writes to one or more masters.
+cluster nodes (master and slave) while sending writes to one or more masters.
For many workloads this guarantees an appropriate level of data coherency,
however for an IP pool allocation implementation this is insufficient since we
must guarantee that no two nodes may concurrently `SELECT` the same IP address
## Getting the tokens
-Follow the link here(https://dev.twitter.com/docs/auth/tokens-devtwittercom) signing up
+Follow the link here(https://dev.twitter.com/docs/auth/tokens-devtwittercom) signing up
for an account and creating a new application if necessary.
## Understanding how signing works
## Dictionary attributes
-Add the following to your custom dictionary
+Add the following to your custom dictionary
```text
ATTRIBUTE Twitter-API-Method <next #> integer
ATTRIBUTE Twitter-API-URL <next #> string
ATTRIBUTE Twitter-API-Data <next #> string
-
+
VALUE Twitter-API-Method GET 1
VALUE Twitter-API-Method POST 2
VALUE Twitter-API-Method PUT 3
# Note: Unless you're using twitter as part of an authorisation scheme, you should
# use a detail reader/writer pair to provide a buffer in case the twitter
# API becomes unavailable/unreachable. You don't want authentication to be
-# delayed whilst waiting for a twitter API request to time out.
+# delayed while waiting for a twitter API request to time out.
#
twitter {
oauth_consumer_key = ''
* AOS Release 6.6.x
** OmniSwitch 6250
** OmniSwitch 6450
-
+
**AOS Release 7**
* AOS Release 7.3.2.R01
** OmniSwitch 6900
By default all access to the switch is limited to "console access" (User: admin, Password: switch)
Except for SSH if the switch obtained an IP address via DHCP, then SSH will be available for initial remote configuration (that is the case below).
- -> show aaa authentication
+ -> show aaa authentication
Service type = Default
Authentication = denied
- Service type = Console
+ Service type = Console
1st authentication server = local
Service type = Telnet
Authentication = Use Default,
If you just use the configuration above, you'll see the following error message:
Benny$ ssh readadmin@192.168.2.106
- readadmin's password for keyboard-interactive method:
-
+ readadmin's password for keyboard-interactive method:
+
PTY allocation request failed on channel 0
Instead the entry needs to look like this:
The result should look like this:
Benny$ ssh readadmin@192.168.2.106
- readadmin's password for keyboard-interactive method:
-
-
+ readadmin's password for keyboard-interactive method:
+
+
Welcome to the Alcatel-Lucent OmniSwitch 6450
- Software Version 6.6.3.451.R01 Service Release, December 20, 2012.
-
+ Software Version 6.6.3.451.R01 Service Release, December 20, 2012.
+
Copyright(c), 1994-2012 Alcatel-Lucent. All Rights reserved.
-
+
OmniSwitch(TM) is a trademark of Alcatel-Lucent registered
in the United States Patent and Trademark Office.
-
- ->
- -> vlan 20 enable
+
+ ->
+ -> vlan 20 enable
ERROR: Authorization failed. No functional privileges for this command
- -> show vlan
- stree mble src
+ -> show vlan
+ stree mble src
vlan type admin oper 1x1 flat auth ip tag lrn name
-----+-----+------+------+------+------+----+-----+-----+------+----------
- 1 std on on on on off on off on VLAN 1
+ 1 std on on on on off on off on VLAN 1
10 std on off on on off off off on VLAN 10
-
+
Although we just want to give "read-only" access to the OmniSwitch, we'll need to allow "read-write" for the access method, in this case SSH. The domains/command family values are simply added to the read-only or read-write entries.
You can get the values for the various commands/domains either via the CLI or by using the "Bitmap Calculator" that is accessible through the WebView of the AOS.
-> show aaa priv hexa ?
^
- WEBMGT VRRP VLAN UDLD TFTP-CLIENT TELNET SYSTEM STP SSH
- SNMP SESSION SCP-SFTP RMON RIP RDP QOS PORT-MAPPING
- POLICY PMM NTP NONE MODULE LOOPBACK-DETECTION LLDP
- LINKAGG IPV6 IPMS IPMR IP-ROUTING IP-HELPER IP INTERFACE
- HEALTH FILE DSHELL DOMAIN-SYSTEM DOMAIN-SERVICE
- DOMAIN-SECURITY DOMAIN-POLICY DOMAIN-PHYSICAL
- DOMAIN-NETWORK DOMAIN-LAYER2 DOMAIN-ADMIN DNS DHCP-SERVER
- DEBUG CONFIG CHASSIS BRIDGE AVLAN ALL AIP AAA 802.1Q <cr>
+ WEBMGT VRRP VLAN UDLD TFTP-CLIENT TELNET SYSTEM STP SSH
+ SNMP SESSION SCP-SFTP RMON RIP RDP QOS PORT-MAPPING
+ POLICY PMM NTP NONE MODULE LOOPBACK-DETECTION LLDP
+ LINKAGG IPV6 IPMS IPMR IP-ROUTING IP-HELPER IP INTERFACE
+ HEALTH FILE DSHELL DOMAIN-SYSTEM DOMAIN-SERVICE
+ DOMAIN-SECURITY DOMAIN-POLICY DOMAIN-PHYSICAL
+ DOMAIN-NETWORK DOMAIN-LAYER2 DOMAIN-ADMIN DNS DHCP-SERVER
+ DEBUG CONFIG CHASSIS BRIDGE AVLAN ALL AIP AAA 802.1Q <cr>
(AAA & Configuration Mgr Command Set)
-
-
- -> show aaa priv hexa ssh
+
+
+ -> show aaa priv hexa ssh
0x00000002 0x00000000
-> show aaa priv hexa telnet
Please don't forget that you'll have to add the following command on your OmniSwitch if you want Telnet to query the Radius.
- -> aaa authentication telnet freeradius local
+ -> aaa authentication telnet freeradius local
### MAC-ADDRESS Authentication (aka non-supplicant authentication)
Read this if you want to authenticate MAC-ADDRESSES through the Radius server.
-> aaa radius-server "freeradius" host 192.168.2.103 key verysecret
-> vlan port mobile 1/2
- -> vlan port 1/2 802.1x enable
+ -> vlan port 1/2 802.1x enable
-> aaa authentication 802.1x freeradius
-> aaa authentication mac freeradius
...
! 802.1x :
802.1x 1/2 direction both port-control auto quiet-period 60 tx-period 30 supp-timeout 30 server-timeout 30 max-req 2 re-authperiod 3600 no reauthentication
- 802.1x 1/2 captive-portal session-limit 12 retry-count 3
- 802.1x 1/2 supp-polling retry 2
+ 802.1x 1/2 captive-portal session-limit 12 retry-count 3
+ 802.1x 1/2 supp-polling retry 2
802.1x 1/2 captive-portal inactivity-logout disable
802.1x 1/2 supplicant policy authentication pass group-mobility default-vlan fail block
802.1x 1/2 non-supplicant policy block
This is a secure (802.1x enabled) starting point, but we want to look at MAC-ADDRESS (non-supplicant) authentication first.
- -> 802.1x 1/2 non-supplicant policy authentication pass default-vlan fail block
+ -> 802.1x 1/2 non-supplicant policy authentication pass default-vlan fail block
It is important to note the "policy authentication" keyword, as otherwise the MAC-ADDRESS will not be sent for verification to the Radius. In case of success we'll place the user in default-vlan, if not block.
In case that the authentication failed, you can verify the same on AOS CLI:
- -> show 802.1x non-supplicant
-
- Slot MAC MAC Authent Classification Vlan
- Port Address Status Policy Learned
+ -> show 802.1x non-supplicant
+
+ Slot MAC MAC Authent Classification Vlan
+ Port Address Status Policy Learned
-----+-----------------+----------------+-------------------+--------
- 01/02 00:1e:ec:aa:aa:aa Failed Basic-Blk 1
+ 01/02 00:1e:ec:aa:aa:aa Failed Basic-Blk 1
Now we add an entry to the /etc/freeradius/users for that MAC-ADDRESS:
001EECAAAAAA Cleartext-Password := "001EECAAAAAA"
-
+
The authentication should now be successful, verify like this:
- -> show 802.1x non-supplicant
-
- Slot MAC MAC Authent Classification Vlan
- Port Address Status Policy Learned
+ -> show 802.1x non-supplicant
+
+ Slot MAC MAC Authent Classification Vlan
+ Port Address Status Policy Learned
-----+-----------------+----------------+-------------------+--------
- 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Dft VLAN 1
-
+ 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Dft VLAN 1
+
Now let us assume that you want to place the user in a different VLAN (Dynamic VLAN Assignment) via Radius.
There are two ways to do that ... (VLAN 20 is our plan)
Here is the confirmation:
- -> show 802.1x non-supplicant
-
- Slot MAC MAC Authent Classification Vlan
- Port Address Status Policy Learned
+ -> show 802.1x non-supplicant
+
+ Slot MAC MAC Authent Classification Vlan
+ Port Address Status Policy Learned
-----+-----------------+----------------+-------------------+--------
- 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Auth Svr 20
+ 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Auth Svr 20
2.) Use the standardised way (IEEE)
Here is the confirmation:
- -> show 802.1x non-supplicant
-
- Slot MAC MAC Authent Classification Vlan
- Port Address Status Policy Learned
+ -> show 802.1x non-supplicant
+
+ Slot MAC MAC Authent Classification Vlan
+ Port Address Status Policy Learned
-----+-----------------+----------------+-------------------+--------
- 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Auth Svr 20
+ 01/02 00:1e:ec:aa:aa:aa Authenticated Basic-Auth Svr 20
### 802.1X Authentication (aka supplicant authentication)
***
Brainstorm/TODO by Benny:
-* **DONE:** Authorise the user access to the switch via RADIUS
-* **DONE:** Authorise MAC (non-supplicant)
+* **DONE:** Authorize the user access to the switch via RADIUS
+* **DONE:** Authorize MAC (non-supplicant)
* **DONE:** Dynamic VLAN Assignment / VSA
* **DONE:** Dynamic VLAN Assignment / IEEE
-* Authorise 802.1x (supplicant)
-* Authorise Captive Portal
+* Authorize 802.1x (supplicant)
+* Authorize Captive Portal
* Bandwidth Management
* service-type (call check, framed user)
* radius test tool
aaa accounting nested
-results in sending a second accounting start message, possibly causing problems with total usage counters. Cisco NAS devices issue an Accounting Start packet when the user is authenticated, and again when a PPP session is initiated. They send an Accounting Stop packet at the end of the PPP session, and a second at the conclusion of the call (usually nearly simultaneously). Because of this, programs such as RadiusReport may see this as two connections, and would account for approximately twice the total time used. Not using this nested command causes the NAS device to send an Accounting Stop packet followed almost immediately by an Accounting Start packet when a PPP connection is chosen, thereby eliminating the overlap. This is particularly useful for those organizations interested in monitoring user usage accurately.
+results in sending a second accounting start message, possibly causing problems with total usage counters. Cisco NAS devices issue an Accounting Start packet when the user is authenticated, and again when a PPP session is initiated. They send an Accounting Stop packet at the end of the PPP session, and a second at the conclusion of the call (usually nearly simultaneously). Because of this, programs such as RadiusReport may see this as two connections, and would account for approximately twice the total time used. Not using this nested command causes the NAS device to send an Accounting Stop packet followed almost immediately by an Accounting Start packet when a PPP connection is chosen, eliminating the overlap. This is particularly useful for those organizations interested in monitoring user usage accurately.
More information about this process can be seen [here](http://www.cisco.com/en/US/docs/ios/12_1/security/command/reference/srdacct.html#wp1022328).
Example Packet (Access-Request):
```text
-Framed-MTU = 1480
-NAS-IP-Address = 192.168.0.1
-NAS-Identifier = "hp-e-its-dev8021X-sw1"
-User-Name = "user"
-Service-Type = Framed-User
-Framed-Protocol = PPP
-NAS-Port = 2
-NAS-Port-Type = Ethernet
-NAS-Port-Id = "2"
-Called-Station-Id = "00-14-38-fb-94-3e"
-Calling-Station-Id = "00-18-8b-1f-ea-c3"
-Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
-Tunnel-Type:0 = VLAN
-Tunnel-Medium-Type:0 = IEEE-802
-Tunnel-Private-Group-Id:0 = "700"
-EAP-Message = 0x0201000a0175736572
+Framed-MTU = 1480
+NAS-IP-Address = 192.168.0.1
+NAS-Identifier = "hp-e-its-dev8021X-sw1"
+User-Name = "user"
+Service-Type = Framed-User
+Framed-Protocol = PPP
+NAS-Port = 2
+NAS-Port-Type = Ethernet
+NAS-Port-Id = "2"
+Called-Station-Id = "00-14-38-fb-94-3e"
+Calling-Station-Id = "00-18-8b-1f-ea-c3"
+Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
+Tunnel-Type:0 = VLAN
+Tunnel-Medium-Type:0 = IEEE-802
+Tunnel-Private-Group-Id:0 = "700"
+EAP-Message = 0x0201000a0175736572
Message-Authenticator = 0x5128a826dfedf51040215eb6fef398df
```
* Unauthorised VLAN - If no _port-access_ authentication mechanisms have managed to successfully authenticate the device, the _unauth-vid_ will be set as the PVID. Although the port will be shown as _closed_, traffic will be able to flow to/from the connected device on this VLAN. The idea behind this feature is to allow administrators to disseminate resources to connecting users (Installation packages for 802.1X supplicants, instructions etc...), allowing them to configure their computer for the local network and complete authentication successfully.
-* Authorised VLAN - If the client successfully completed authentication and no VLAN was specified by the RADIUS server, the _auth-vid_ will be set as the PVID. If no VLAN was specified by the RADIUS server, and no auth-vid was set, the client is assigned to the untagged VLAN configured for the port.
+* Authorized VLAN - If the client successfully completed authentication and no VLAN was specified by the RADIUS server, the _auth-vid_ will be set as the PVID. If no VLAN was specified by the RADIUS server, and no auth-vid was set, the client is assigned to the untagged VLAN configured for the port.
### Dynamic VLAN Assignment
Note: It is not possible to specify the ingress untagged VLAN with RFC 4675 attributes, so RFC 3580 attributes must be used instead.
-##### Ingress-Filters VSA is ignored by all HP ProCurve switches
+##### Ingress-Filters VSA is ignored by all HP ProCurve switches
The default switching 'philosophy' of ProCurve switches is to filter ingress packets based on the egress VLAN membership of a port, this goes against the 802.1Q standard, which requires that frames be allowed to ingress, even if their tag does not match a VLAN the port is a member of.
Supporting this attribute (i.e. allowing promiscuous ingress) would break the ProCurve switching philosophy, and so this attribute is ignored.
Egress-VLANID = `%{expr: 0x31000000 + 451}`
```
-This entry will assign the port to the single tagged VLAN of ID 451. With use of an [expr](https://freeradius.org/radiusd/man/rlm_expr.html), it is possible to use integer addition to show the composition of the bit string, with the leading `0x31` for tagged VLAN, the `0x000` padding and the VLAN ID.
+This entry will assign the port to the single tagged VLAN of ID 451. With use of an [expr](https://freeradius.org/radiusd/man/rlm_expr.html), it is possible to use integer addition to show the composition of the bit string, with the leading `0x31` for tagged VLAN, the `0x000` padding and the VLAN ID.
Exemple for single untagged and multiple tagged VLANs, MAC-based:
### Dynamic CoS (802.1p) Remapping
|===
-|RADIUS Attribute |Times Used|Description |Value String | Value
+|RADIUS Attribute |Times Used|Description |Value String | Value
|HP-COS (11.40) |1 |Assign 802.1p priority to all inbound packets on port |- |``<CoS_0><CoS_1><CoS_2><CoS_3><CoS_4><CoS_5><CoS_6><Cos_7>``
|===
Unfortunately there is no method to disable this bridging feature so if reliable accounting times are required it is recommended not to enable DHCP-Snooping.
|===
-|RADIUS Attribute |Times Used|Description |Value String | Value
+|RADIUS Attribute |Times Used|Description |Value String | Value
|Framed-IP-Address |1 |IP Address learned via DHCP-Snooping |- |``<ip_oct1>.<ip_oct2>.<ip_oct3>.<ip_oct4>``
|===
Note: The Acct-Delay-Time attribute included in Accounting-Requests is not properly incremented, so accounting times really will be off by ~60 seconds
-### GVRP and Dynamic VLAN assignment
-
+### GVRP and Dynamic VLAN assignment
+
In addition to being able to assign statically configured VLANs, GVRP learned VLANs are also available for dynamic assignment.
#### Enable the use of GVRP learned VLANs with dynamic VLAN assignment
For authentication to succeed, Access-Accept packets must also contain a Service-Type attribute corresponding to the desired privilege level.
|===
-|Access Level | RADIUS Attribute |Times Used|Description |Value String | Value
+|Access Level | RADIUS Attribute |Times Used|Description |Value String | Value
|Operator |Service-Type |1 |The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. |NAS-Prompt-User |7
|Manager |Service-Type |1 |The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. |Administrative-User|6
|No Access/Access reject|Service-Type |1 |To deny access, either send an Access-Reject, or omit the Service-Type attribute (only works when Privilege-Mode is enabled).|- |-
RFC3576 operation is currently supported on all K and W branch switches. It is considered to be a 'premium' feature, so is unlikely to be backported, or included in lower end switch models.
-A RADIUS request with a Code of either 40 (Disconnect Request) or 43 (CoA Request) is sent to UDP port 3799 (default) on the switch.
+A RADIUS request with a Code of either 40 (Disconnect Request) or 43 (CoA Request) is sent to UDP port 3799 (default) on the switch.
This request must include attributes that identify the NAS, attributes that identify the session, and in the case of CoA, attributes that form the new authorisation profile.
RFC 3576 also recommends that an Event-Timestamp attribute be present for replay protection purposes, and that there be a maximum (default) delta of 300 seconds between the NAS time and the Event-Timestamp attribute included in the request.
At least one of these attribute/attribute sets must be present in the CoA request else the NAS will return a CoA-NAK (Missing-Attribute). No authorisation attributes must be included in the disconnect message else the NAS will return a DM-NAK (Unsupported-Attribute).
|===
-|RADIUS Attribute |Times Used|Description
+|RADIUS Attribute |Times Used|Description
|Session-Timeout |1 |Number of seconds between client re-authentication (integer)
|Tunnel-Type=VLAN,Tunnel-Medium-Type=IEEE-802,Tunnel-Private-Group-Id=<int> |1 |PVID assignment/alteration
|Egress-VLANID |1+ |Tagged VLAN assignment (octets)
needs this to be present for the handset to validate the RADIUS server
certificate. The RADIUS server must have the URI defined but the CA need
not have…however it is best practice for a CA to have a revocation URI.
-Note that whilst the Windows Mobile client cannot actually use the CRL
+Note that while the Windows Mobile client cannot actually use the CRL
when doing 802.1X it is recommended that the URI be an actual working
URL and contain a revocation format file as there may be other OS
behaviour at play and future OSes that may do something with that URI.
One of the most common reasons for overriding return codes is to implement
special behaviour on failure.
-To minimise external dependencies, for this exercise we will use the
+To minimize external dependencies, for this exercise we will use the
xref:reference:raddb/mods-available/sometimes.adoc[sometimes] module to simulate an
unreliable external database.
projects / thirdparty / freeradius-server.git / commitdiff
