freeradius static ip assignment

Basic Configuration Howto

• Latest Changes

Define a Client IP

Define a user and password, start the server in debugging mode, simple test, troubleshooting, more testing, quick links.

• Concepts for beginners
• Basic Configuration
• Pre-built packages
• Building from source code
• Contributing with GitHub
• Browse the Source
• Main web site

Always use radiusd -X when debugging!

Always start with the "default" configuration. It will work everywhere, and do almost everything you need. The only change you will need to make is to define users and passwords.

Making a lot of changes to the configuration files is the best way to break the server. Don't do that.

For initial testing from localhost with radtest , the server comes with a default definition for 127.0.0.1 and ::1

For testing from external machines, edit /etc/raddb/clients.conf and add an entry. There are many examples and the syntax is easy:

Edit /etc/raddb/ users and create an example user account as the first entry. i.e. at the top of the file, such as:

At this point you should be able to manually start radiusd . You should do this with the debugging enabled so that you can see what happens:

The location and the name of the FreeRADIUS server executable may vary, for example it could be /usr/sbin/freeradius . But the -X parameter is essential, always use it!

Lots of output will scroll by, and it will eventually say:

Sometimes people want to change default port to run on 1645, the old RADIUS port (the new one is 1812), if replacing a legacy RADIUS server. Other than that, it's possible that the EAP Module initial setup will fail.

Once the FreeRADIUS server is operational, you can use radtest to test an account from the command line:

Where testing is the user name configured above, and password is the password for the user. These can be real user names and passwords, of course.

You should see output like:

The key is to get an 'Access Accept' response.

At this point you should have text-file authentication working in FreeRADIUS. Also based on the default settings, the authentication methods now work for the testing user

If you made changes to the default configuration, odds are that one or more of these authentication methods will stop working.

The next step is to add more users, and/or to configure directories and databases.

If you don't get an Access-Accept, go back and check everything.

Read the relevant documentation including comments, and read the debug messages!

See also the Troubleshooting guide.

For configuring EAP, see the external EAP Howto . It offers a step-by-step guide which is guaranteed to work.

The initial setup is usually sufficient, but if you get an error, then read the debug messages . Check the docs, check that you have followed the above steps to the letter, and try again. Try posting the output into the Network RADIUS Debug colorizer , it will group the debug output into request/reply sections, and will colorize portions of text that you should pay attention to . While many of the debug messages can be ignore (they are for more in-depth debugging), a number of them contain detailed descriptions of what is going on. Read them, and follow the instructions.

If you need to edit configuration files , read them carefully and edit them as little as possible. See man radiusd for a guide. Start with radiusd.conf.

If you have a Windows PC handy you may also wish to use NTradPing (downloadable from MasterSoft) to send test packets instead of radtest. If you do this, or test from any other machine, remember your PC (or other machine) needs to be in your NAS list in clients.conf too!

• Configuration files

Last edited by Arran Cudbard-Bell , 2012-09-14 14:13:36

Delete this Page

FreeRADIUS Documentation

Configuration ip address data type.

The ip address data type contains IP addresses and netmasks. Both numerical IP addresses and host names are allowed.

The configuration directives which take IP addresses and host names follow a fixed naming scheme, as given below.

In some cases (e.g. with clients), an IP address network and mask can be used.

• Skip to content
• Skip to search
• Skip to footer

Configure a RADIUS Server and WLC for Dynamic VLAN Assignment

Available languages, download options.

• PDF (906.6 KB) View with Adobe Reader on a variety of devices

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document introduces the concept of dynamic VLAN assignment. The document describes how to configure the wireless LAN controller (WLC) and a RADIUS server to assign wireless LAN (WLAN) clients into a specific VLAN dynamically.

Prerequisites

Requirements.

Ensure that you meet these requirements before you attempt this configuration:

Have basic knowledge of the WLC and Lightweight Access Points (LAPs)

Have functional knowledge of the AAA server

Have thorough knowledge of wireless networks and wireless security issues

Have basic knowledge of Lightweight AP Protocol (LWAPP)

Components Used

The information in this document is based on these software and hardware versions:

Cisco 4400 WLC that runs firmware release 5.2

Cisco 1130 Series LAP

Cisco 802.11a/b/g Wireless Client Adapter that runs firmware release 4.4

Cisco Aironet Desktop Utility (ADU) that runs version 4.4

CiscoSecure Access Control Server (ACS) that runs version 4.1

Cisco 2950 series switch

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Dynamic VLAN Assignment with RADIUS Server

In most WLAN systems, each WLAN has a static policy that applies to all clients associated with a Service Set Identifier (SSID), or WLAN in the controller terminology. Although powerful, this method has limitations because it requires clients to associate with different SSIDs in order to inherit different QoS and security policies.

However, the Cisco WLAN solution supports identity networking. This allows the network to advertise a single SSID, but allows specific users to inherit different QoS or security policies based on the user credential.

Dynamic VLAN assignment is one such feature that places a wireless user into a specific VLAN based on the credentials supplied by the user. This task of assigning users to a specific VLAN is handled by a RADIUS authentication server, such as CiscoSecure ACS. This can be used, for example, to allow the wireless host to remain on the same VLAN as it moves within a campus network.

Therefore, when a client attempts to associate to a LAP registered with a controller, the LAP passes the credentials of the user to the RADIUS server for validation. Once the authentication is successful, the RADIUS server passes certain Internet Engineering Task Force (IETF) attributes to the user. These RADIUS attributes decide the VLAN ID that should be assigned to the wireless client. The SSID (WLAN, in terms of WLC) of the client does not matter because the user is always assigned to this predetermined VLAN ID.

The RADIUS user attributes used for the VLAN ID assignment are:

IETF 64 (Tunnel Type)—Set this to VLAN.

IETF 65 (Tunnel Medium Type)—Set this to 802

IETF 81 (Tunnel Private Group ID)—Set this to VLAN ID.

In this section, you are presented with the information to configure the features described in this document.

Network Diagram

This document uses this network setup:

These are the configuration details of the components used in this diagram:

The IP address of the ACS (RADIUS) server is 172.16.1.1.

The Management Interface address of the WLC is 172.16.1.30.

The AP-Manager Interface address of the WLC is 172.16.1.31.

The DHCP server address 172.16.1.1 is used to assign IP addresses to the LWAPP. The internal DHCP server on the controller is used to assign the IP address to wireless clients.

VLAN10 and VLAN11 are used throughout this configuration. The user1 is configured to be placed into the VLAN10 and user2 is configured to be placed into VLAN11 by the RADIUS server.

Note:  This document only shows all the configuration information related to user1. Complete the same procedure explained in this document for the user2.

This document uses 802.1x with LEAP as the security mechanism.

Note:  Cisco recommends that you use advanced authentication methods, such as EAP-FAST and EAP-TLS authentication, in order to secure the WLAN. This document uses LEAP only for simplicity.

Configuration

Prior to the configuration, this document assumes that the LAP is already registered with the WLC. Refer to Wireless LAN Controller and Lightweight Access Point Basic Configuration Example for more information. Refer to Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC) for information about the registration procedure involved.

Configuration Steps

This configuration is separated into three categories:

RADIUS Server Configuration

Configure the switch for multiple vlans, wlc configuration, wireless client utility configuration.

This configuration requires these steps:

Configure the WLC as an AAA Client on the RADIUS Server

Configure the Users and the RADIUS (IETF) Attributes Used for Dynamic VLAN Assignment on the RADIUS Server

Configure the aaa client for the wlc on the radius server.

This procedure explains how to add the WLC as a AAA client on the RADIUS server so that the WLC can pass the user credentials to the RADIUS server.

Complete these steps:

From the ACS GUI, click Network Configuration .

Click the Add Entry section under the AAA Clients field.

Enter the AAA Client IP Address and Key.

The IP address should be the Management Interface IP address of the WLC.

Make sure that the key you enter is the same as the one configured on the WLC under the Security window. This is the secret key used for communication between the AAA client (WLC) and the RADIUS server.

Choose RADIUS (Cisco Airespace) from the Authenticate Using field for the authentication type.

This procedure explains how to configure the users in the RADIUS server and the RADIUS (IETF) attributes used to assign VLAN IDs to these users.

From the ACS GUI, click User Setup .

In the User Setup window, enter a username in the User field and click Add/Edit .

On the Edit page, enter the necessary user information as shown here:

In this diagram, notice that the password you provide under the User Setup section should be the same as the one provided at the client side during the user authentication.

Scroll down the Edit page and find the IETF RADIUS Attributes field.

In the IETF RADIUS Attributes field, check the check boxes next to the three Tunnel attributes and configure the attribute values as shown here:

Note:  In the initial configuration of the ACS server, IETF RADIUS attributes might not be displayed.

Choose Interface Configuration > RADIUS (IETF) in order to enable IETF attributes in the user configuration window.

Then, check the check boxes for attributes 64, 65, and 81 in the User and Group columns.

Note:  In order for the RADIUS server to dynamically assign the client to a specific VLAN, it is required that the VLAN-ID configured under the IETF 81 (Tunnel-Private-Group-ID) field of the RADIUS server exist on the WLC.

Check the Per User TACACS+/RADIUS attribute check box under Interface Configuration > Advanced Options in order to enable the RADIUS server for per user configurations.

Also, because LEAP is used as the Authentication protocol, ensure that LEAP is enabled in the System Configuration window of the RADIUS server as shown here:

Configure the ACS with Cisco Airespace VSA Attributes for Dynamic VLAN Assignment

In the latest ACS versions, you can also configure the Cisco Airespace [VSA (Vendor-Specific)] attribute to assign a successfully authenticated user with a VLAN interface name (not the VLAN ID) as per the user configuration on the ACS. In order to accomplish this, perform the steps in this section.

Note:  This section uses ACS 4.1 version to configure the Cisco Airespace VSA attribute.

Configure the ACS Group with Cisco Airespace VSA Attribute Option

From the ACS 4.1 GUI, click Interface Configuration from the navigation bar. Then, select RADIUS (Cisco Airespace) from the Interface Configuration page in order to configure the Cisco Airespace attribute option.

From the RADIUS (Cisco Airespace) window, check the User check box (Group check box if needed) next to Aire-Interface-Name in order to display it on the User Edit page. Then, click Submit .

Go to the user1's Edit page.

From the User Edit page, scroll down to the Cisco Airespace RADIUS Attributes section. Check the check box next to the Aire-Interface-Name attribute and specify the name of the dynamic interface to be assigned upon successful user authentication.

This example assigns the user to admin VLAN.

Click Submit .

In order to allow multiple VLANs through the switch, you need to issue these commands to configure the switch port connected to the controller:

Switch(config-if)# switchport mode trunk

Switch(config-if)# switchport trunk encapsulation dot1q

Note:  By default, most of the switches allow all VLANs created on that switch via the trunk port.

These commands vary for a Catalyst operating system (CatOS) switch.

If a wired network is connected to the switch, then this same configuration can be applied to the switch port that connects to the wired network. This enables the communication between the same VLANs in the wired and wireless network.

Note:  This document does not discuss inter-VLAN communication. This is beyond the scope of this document. You must understand that for inter-VLAN routing, a Layer 3 switch or an external router with proper VLAN and trunking configurations is needed. There are several documents that explain inter-VLAN routing configuration.

Configure the WLC with the Details of the Authentication Server

Configure the dynamic interfaces (vlans), configure the wlans (ssid).

It is necessary to configure the WLC so it can communicate with the RADIUS server to authenticate the clients, and also for any other transactions.

From the controller GUI, click Security .

Enter the IP address of the RADIUS server and the Shared Secret key used between the RADIUS server and the WLC.

This Shared Secret key should be the same as the one configured in the RADIUS server under Network Configuration > AAA Clients > Add Entry. Here is an example window from the WLC:

This procedure explains how to configure dynamic interfaces on the WLC. As explained earlier in this document, the VLAN ID specified under the Tunnel-Private-Group ID attribute of the RADIUS server must also exist in the WLC.

In the example, the user1 is specified with the Tunnel-Private-Group ID of 10 (VLAN =10) on the RADIUS server. See the IETF RADIUS Attributes section of the user1 User Setup window.

You can see the same dynamic interface (VLAN=10) configured in the WLC in this example. From the controller GUI, under the Controller > Interfaces window, the dynamic interface is configured.

Click Apply on this window.

This takes you to the Edit window of this dynamic interface (VLAN 10 here).

Enter the IP Address and default Gateway of this dynamic interface.

Note:  Because this document uses an internal DHCP server on the controller, the primary DHCP server field of this window points to the Management Interface of the WLC itself. You can also use an external DHCP server, a router, or the RADIUS server itself as a DHCP server to the wireless clients. In such cases, the primary DHCP server field points to the IP address of that device used as the DHCP server. Refer to your DHCP server documentation for more information.

Click Apply .

Now you are configured with a dynamic interface in your WLC. Similarly, you can configure several dynamic interfaces in your WLC. However, remember that the same VLAN ID must also exist in the RADIUS server for that particular VLAN to be assigned to the client.

This procedure explains how to configure the WLANs in the WLC.

From the controller GUI, choose WLANs > New in order to create a new WLAN.

The New WLANs window is displayed.

Enter the WLAN ID and WLAN SSID information.

You can enter any name to be the WLAN SSID. This example uses VLAN10 as the WLAN SSID.

Click Apply in order to go to the Edit window of the WLAN SSID10.

Normally, in a wireless LAN controller, each WLAN is mapped to a specific VLAN (SSID) so that a particular user that belongs to that WLAN is put into the specific VLAN mapped. This mapping is normally done under the Interface Name field of the WLAN SSID window.

In the example provided, it is the job of the RADIUS server to assign a wireless client to a specific VLAN upon successful authentication. The WLANs need not be mapped to a specific dynamic interface on the WLC. Or, even though the WLAN to dynamic interface mapping is done on the WLC, the RADIUS server overrides this mapping and assigns the user that comes through that WLAN to the VLAN specified under the user Tunnel-Group-Private-ID field in the RADIUS server.

Check the Allow AAA Override check box in order to override the WLC configurations by the RADIUS server.

Enable the Allow AAA Override in the controller for each WLAN (SSID) configured.

When AAA Override is enabled, and a client has AAA and controller WLAN authentication parameters that conflict, client authentication is performed by the AAA (RADIUS) server. As part of this authentication, the operating system moves clients to a VLAN returned by the AAA server. This is predefined in the controller interface configuration.

For instance, if the corporate WLAN primarily uses a Management Interface assigned to VLAN 2, and if the AAA Override returns a redirect to VLAN 100, the operating system redirects all client transmissions to VLAN 100 even if the physical port to which VLAN 100 is assigned. When AAA Override is disabled, all client authentication defaults to the controller authentication parameter settings, and authentication is only performed by the AAA server if the controller WLAN does not contain any client-specific authentication parameters.

This document uses ADU as the client utility for the configuration of the user profiles. This configuration also uses LEAP as the authentication protocol. Configure the ADU as shown in the example in this section.

From the ADU Menu bar, choose Profile Management > New in order to create a new profile.

The example client is configured to be a part of SSID VLAN10. These diagrams show how to configure a user profile on a client:

Activate the user profile you have configured in the ADU. Based on the configuration, you are prompted for a username and password. You can also instruct the ADU to use the Windows username and password for authentication. There are a number of options from which the client can receive authentication. You can configure these options under the Security > Configure tab of the user profile you have created.

In the previous example, notice that user1 is assigned to the VLAN10 as specified in the RADIUS server.

This example uses this username and password from the client side to receive authentication and to be assigned to a VLAN by the RADIUS server:

User Name = user1

Password = user1

This example shows how the SSID VLAN10 is prompted for the username and password. The username and password are entered in this example:

Once the authentication and the corresponding validation is successful, you receive success as the status message.

Then, you need to verify that your client is assigned to the proper VLAN as per the RADIUS attributes sent. Complete these steps in order to accomplish this:

From the controller GUI, choose Wireless > AP .

Click Clients , which appears on the left corner of the Access Points (APs) window.

The client statistics are displayed.

Click Details in order to identify the complete details of the client, such as IP address, the VLAN to which it is assigned, and so forth.

This example displays these details of the client, user1:

From this window, you can observe that this client is assigned to VLAN10 as per the RADIUS attributes configured on the RADIUS server.

Note:  If the dynamic VLAN assignment is based on the Cisco Airespace VSA Attribute setting, the Interface name will display it as admin as per this example on the client details page.

Use this section to confirm that your configuration works properly.

debug aaa events enable —This command can be used to ensure successful transfer of the RADIUS attributes to the client via the controller. This portion of the debug output ensures a successful transmission of RADIUS attributes:

Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[0]: attribute 64, vendorId 0, valueLen 4 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[1]: attribute 65, vendorId 0, valueLen 4 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[2]: attribute 81, vendorId 0, valueLen 3 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[3]: attribute 79, vendorId 0, valueLen 32 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Received EAP Attribute (code=2, length=32,id=0) for mobile 00:40:96:ac:e6:57 Fri Jan 20 02:25:08 2006: 00000000: 02 00 00 20 11 01 00 18 4a 27 65 69 6d e4 05 f5 ........J'eim...00000010: d0 98 0c cb 1a 0c 8a 3c ........44 a9 da 6c 36 94 0a f3 <D..l6... Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[4]: attribute 1, vendorId 9, valueLen 16 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[5]: attribute 25, vendorId 0, valueLen 28 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 processing avps[6]: attribute 80, vendorId 0, valueLen 16 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Tunnel-Type 16777229 should be 13 for STA 00:40:96:ac:e6:57 Fri Jan 20 02:25:08 2006: 00:40:96:ac:e6:57 Tunnel-Medium-Type 16777222 should be 6 for STA 00:40:96:ac:e6:57 Fri Jan 20 02:30:00 2006: 00:40:96:ac:e6:57 Station 00:40:96:ac:e6:57 setting dot1x reauth timeout = 1800

These commands can also be useful:

debug dot1x aaa enable

debug aaa packets enable

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Note:  Dynamic VLAN assignment does not work for web authentication from a WLC.

Related Information

• EAP Authentication with RADIUS Server
• Cisco Wireless LAN Controller Configuration Guide, Release 4.0
• Technical Support & Documentation - Cisco Systems

Revision History

Was this Document Helpful?

Contact Cisco

• (Requires a Cisco Service Contract )

This Document Applies to These Products

• Aironet Wireless LAN Client Adapters

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode .

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

FreeRadius user auth & assigned IP

• Oldest to Newest
• Newest to Oldest
• Reply as topic

When a user connects using OVPN they are assigned an IP from the IPv4 tunnel range

When using FR for authentication I can assign each user an IP address.

How does the FR assigned IP address relate the the OVPN tunnel IP address?

For example: My OVPN tunnel is 172.30.50.0/24 and when connecting I am allocated 172.30.50.2

If I then assign 192.168.0.1 in the FR settings my user is assigned this address and not the tunnel address.

Should the FR address be an IP from the OVPN tunnel?

@McMurphy If you want to assign permanent OpenVPN IP's which do not change use: VPN - OpenVPN - Client Specific Overrides to do that.

When I did this I duplicated the Common Names used in the OpenVPN Certificates across OpenVPN - Client Specific Overrides, FreeRadius - Users and Users under User Manager to keep the confusion limited.

I think you are not assigning an IP to each user in FreeRadius - leave blank - you use the IP assigned in the above Client Specific Overrides what the FR Authentication Server is doing is verifying the certificate, common name, password and IP. I believe - been a long time since I set this up - the password is the Free Radius contribution.

@The-Party-of-Hell-No

Thanks for the pointer, I finally got it working using FR. The IPs were being assigned correctly however I had my subnet masks wrong. It has to match the tunnel.

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/client-parameters-radius.html#static-ip-address

• First post Last post Go to my next post

Looks like your connection to Netgate Forum was lost, please wait while we try to reconnect.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

freeradius: assign IP from specific pool filtered by user

I'm new here.

I have a freeradius 3 with sqlippool and LDAP authentication (with a "guest" file-configured user), all working fine. I have 2 sqlippools:

-guest_pool

I want to do the following:

if the user is "guest" then offer an IP from guest_pool, else offer from main_pool. My idea is to have the guests and the other users in differents vlans.

¿How can I tell to the radius dhcp "if the user is guest offer from guest_pool?

Sory for my bad english.

• 1 See man unlang, it describes the policy language that you can use to implement custom logic. –  Arran Cudbard-Bell Commented Jan 14, 2019 at 15:28

I solved it!

Thanks to Arran Cudbard-Bell for the clue!

First, created a table called "userhardaddr" with username and mac(PK) both varchar.

In (radius conf dir)/sites-enabled/defaul (section post-auth) I made a "REPLACE" query:

This replace the user for a connected MAC in the table if exist. If not exist, REPLACE creates the row as in INSERT.

Then, in sites-enabled/dhcp (discover and request sections):

With this I get the user name from the DB according to the mac address.

In the IF statement I compare the value returned by the query to "guest" and assign the corresponding IP pool.

Thanks again.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged dhcp users freeradius ..

• The Overflow Blog
• Ryan Dahl explains why Deno had to evolve with version 2.0
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• If a body in free fall, according to general relativity is weightless, that is, not experiencing force, how does the object gain kinetic energy?
• Why is global state harder to test? Doesn't reset the global state at the beginning of each test solves the problem?
• Does the overall mAh of the battery add up when batteries are parallel?
• Would it take less thrust overall to put an object into higher orbit?
• Why do only 2 USB cameras work while 4 USB cameras cannot stream at once?
• Why are swimming goggles typically made from a different material than diving masks?
• For applying to a STEM research position at a U.S. research university, should a resume include a photo?
• A consequence of Firoozbakht's conjecture?
• Series of discrete groups with a Lie group limit
• How common is it for external contractors to manage internal teams, and how can we navigate this situation?
• How to make two alignments in the environment align?
• Is the Shroud of Turin about 2000 years old?
• Voisin's proof of some properties of locally constant sheaves (Proposition 3.9)
• Why don't liquid aerosols rapidly vanish by evaporation?
• How to add content security headers in Next.js which are configurable from cms side? where to add?
• Seven different digits are placed in a row. The products of the first 3, middle 3 and last 3 are all equal. What is the middle digit?
• Why would an incumbent politician or party need to be re-elected to fulfill a campaign promise?
• Inconsistent width of relational operators in newtxmath
• block diagonal matrix
• Retroactively specifying `-only` or `-or-later` for GPLv2 in an adopted project
• Strange bearings of Shimano FH-MT410-B
• Can objective morality be derived as a corollary from the assumption of God's existence?
• Second Argument of \fontsize{}{}\selectfont Not Working in a Pspicture
• Are ～渋る and ～惜しむ any different as verbal suffixes?

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

FreeRadius LDAP group check

I want to implement 802.1x. The computers belonging to Microsoft domey will be authenticated. The switch port will be configured in VLAN according to the computer's group membership. Simple configuration. Works well ;) FreeRadius 3.0.19

Question: due to AD complexity, is it possible to assign the same VLAN to computers from different groups?

Currently I'm doing it as follows: in post-auth

I want to allocate the same VLAN to groups such as VLAN16_BSTO1 and VLAN16_ADMCE1 and others starting with VLAN16_

I cannot use the operator in the condition "if" =~ . FreeRadius does not start! Is it possible to check the group name so as not to create many "if" conditions? In my case these conditions will be about 800 :)

anyone can help me, tell me how to config can solve this problem, thanks.

• Edited answer with possible workaround. You should remove your other 'answer' as it's not actually answering the question, and use comments for followups or clarifications. –  Arran Cudbard-Bell Commented Jan 12, 2020 at 18:16

2 Answers 2

Enable cacheable_name in the LDAP module configuration - https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/ldap#L326

And uncomment the line setting the cache attribute: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/ldap#L333

Then you can alter the condition to pattern match on group memberships LDAP-Cached-Membership[*] =~ /.*foo.*/ .

What cacheable_name and cacheable_dn do, is create a list of all group memberships stored in the LDAP directory for that particular user, and write those values out to local attributes. You can use the wildcard selector [*] to apply a pattern match to all the values of LDAP-Cached-Membership .

One caveat is that the LDAP module must have been called at least once before you use the condition, as it needs to create the list of groups.

Edited to specify use of LDAP-Cached-Membership.

I just wanted thank Arran!

For anyone else the following syntax got it working:

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged freeradius or ask your own question .

• The Overflow Blog
• Ryan Dahl explains why Deno had to evolve with version 2.0
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Feedback requested: How do you use tag hover descriptions for curating and do...
• What does a new user need in a homepage experience on Stack Overflow?

Hot Network Questions

• How common is it for external contractors to manage internal teams, and how can we navigate this situation?
• What prevents applications from misusing private keys?
• Publishing extension work for a previous research (in Chemical physics)
• What is this surface feature near Shackleton crater classified as?
• Is the Garmin Edge 530 still a good choice for a beginner in 2024?
• How can flyby missions work?
• Would it take less thrust overall to put an object into higher orbit?
• I can't select a certain record with like %value%
• A consequence of Firoozbakht's conjecture?
• Would weightlessness (i.e. in thrill rides, planes, skydiving, etc.) be different on a Flat Earth?
• What might cause these striations in this solder joint?
• Did anyone ever ask Neil Armstrong whether he said "for man" or "for a man?"
• Find all pairs of positive compatible numbers less than 100 by proof
• For applying to a STEM research position at a U.S. research university, should a resume include a photo?
• Strange bearings of Shimano FH-MT410-B
• How does DS18B20 temperature sensor get the temperature?
• Is this misleading "convenience fee" legal?
• If a body in free fall, according to general relativity is weightless, that is, not experiencing force, how does the object gain kinetic energy?
• Do linguists have a noun for referring to pieces of commendatory language, as a sort of antonym of 'pejoratives'?
• The beloved shepherd isn't Solomon?
• Why is global state harder to test? Doesn't reset the global state at the beginning of each test solves the problem?
• Does the overall mAh of the battery add up when batteries are parallel?
• Are ～渋る and ～惜しむ any different as verbal suffixes?
• How to make outhouses less icky?

Assign Static IP Address to authenticated user

the problem that I face with it is how can I assign a static IP address to authenticated users through 2FA?

In my scenario, IP Addresses are assigned to domain users via Dial-in tab > Static IP Address.

Through radius authentication should map domain ‘msradiusframedipaddress’ attribute to radius ‘Framed-IP-Address’ and then assign it to authenticated users, but the problem is Microsoft stores IP Address (Dial-in tab > Static IP Address) in decimal and it must be converted to IPv4 dot-formated before map to radius ‘Framed-IP-Address’.

My question is how can I overcome with this issue. Is there anyway to assign IP via privacyIdea, regardless of its own freeradius?

You could use the additional user attributes to manage IP addresses for users and pass this via RADIUS. https://privacyidea.readthedocs.io/en/latest/webui/user_attributes.html

Exploring the Unseen:

Join my journey through the world of it administration, freeradius, ldap and dynamic vlan assignment.

A long time ago I was interested in find out how I can use my installed FreeRadius to dynamically assign a VLAN based on an Actice Directory Group. First I’ll show my current setup:

• Microsoft Active Directory Domain Controller (Windows Server 2012 R2)
• FreeRadius (openSUSE Leap 15.3) – Installation instruction https://stangneth.com/2021/05/26/freeradius-on-opensuse/
• HP ProCurve 2810-24G
• Client (Windows 10 21H2)

Inhaltsverzeichnis

• 1 Active Directory group
• 2 FreeRadius config
• 3 Switch Setup

Active Directory group

After creating a local security group in Active Directory I assigned it to a User.

FreeRadius config

Edit the FreeRadius LDAP config in post-auth section to assign the VLAN based on this group.

Restart the FreeRadius Server and check if the auth is successfull.

The result should us provide the Tunnel-Private-Group-Id.

Sent Access-Request Id 196 from 0.0.0.0:40761 to 127.0.0.1:1812 length 136 User-Name = „mustermann“ MS-CHAP-Password = „Start123“ NAS-IP-Address = 172.16.0.249 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = „Start123“ MS-CHAP-Challenge = 0x6bd3b0199158881b MS-CHAP-Response = 0x0001000000000000000 Received Access-Accept Id 196 from 127.0.0.1:1812 to 127.0.0.1:40761 length 99 MS-CHAP-MPPE-Keys = 0x0000000000000000f0fdf MS-MPPE-Encryption-Policy = Encryption-Allowed MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = „1“

Switch Setup

Configure the radius server on the network switch. Be sure to setup the file /etc/raddb/clients.conf !

Now we can enable eap-radius authentication for port-access. In this example for the port-range 1-10.

On my Switch I have to be sure that GVRP is enabled. I’ve done this step within the menu.

• 2. Switch-Configuration
• 7. VLAN Menu…
• 1. VLAN Support

Also I have created a „Dead-VLAN“ with ID 666. This will be assigned if the client dont response with a valid username/password combination.

The ports can be monitored with the following command.

 Port Access Authenticator Status

  Port-access authenticator activated [No] : Yes

       Auths/  Unauth   Untagged Tagged           Cntrl

  Port Guests  Clients  VLAN     VLANs  Port COS  Dir

  —- ——- ——– ——– —— ——— —–

  2    1/0     0        10       No     No        both

Keine Kommentare zu FreeRadius, LDAP and dynamic VLAN assignment

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kommentar *

• Active Directory
• Exchange Server
• Debian 11 auf Debian 12 aktualisieren
• Verbesserung der PowerShell-Sicherheit durch die Aktivierung des Constrained Language Mode
• PowerShell-Skripte signieren
• FSMO-Rollen verschieben und alten Domänencontroller herabstufen
• VMware ESXi 8.x aktualisieren
• Basis Sicherheit auf einem Debian-Server
• Apache2 als Reverse Proxy mit ModSecurity und OWASP Ruleset auf Debian
• Datenschutzrichtlinie

Wir verwenden Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wir tun dies, um das Surferlebnis zu verbessern und (nicht) personalisierte Werbung anzuzeigen. Das Einwilligen in diese Technologien ermöglicht es uns, Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website zu verarbeiten. Das Nicht-Einwilligen oder das Zurückziehen der Einwilligung kann sich nachteilig auf bestimmte Funktionen und Eigenschaften auswirken.

Kubernetes Blog

Kubernetes v1.31: new kubernetes cpumanager static policy: distribute cpus across cores.

In Kubernetes v1.31, we are excited to introduce a significant enhancement to CPU management capabilities: the distribute-cpus-across-cores option for the CPUManager static policy . This feature is currently in alpha and hidden by default, marking a strategic shift aimed at optimizing CPU utilization and improving system performance across multi-core processors.

Understanding the feature

Traditionally, Kubernetes' CPUManager tends to allocate CPUs as compactly as possible, typically packing them onto the fewest number of physical cores. However, allocation strategy matters, CPUs on the same physical host still share some resources of the physical core, such as the cache and execution units, etc.

While default approach minimizes inter-core communication and can be beneficial under certain scenarios, it also poses a challenge. CPUs sharing a physical core can lead to resource contention, which in turn may cause performance bottlenecks, particularly noticeable in CPU-intensive applications.

The new distribute-cpus-across-cores feature addresses this issue by modifying the allocation strategy. When enabled, this policy option instructs the CPUManager to spread out the CPUs (hardware threads) across as many physical cores as possible. This distribution is designed to minimize contention among CPUs sharing the same physical core, potentially enhancing the performance of applications by providing them dedicated core resources.

Technically, within this static policy, the free CPU list is reordered in the manner depicted in the diagram, aiming to allocate CPUs from separate physical cores.

Enabling the feature

To enable this feature, users firstly need to add --cpu-manager-policy=static kubelet flag or the cpuManagerPolicy: static field in KubeletConfiuration. Then user can add --cpu-manager-policy-options distribute-cpus-across-cores=true or distribute-cpus-across-cores=true to their CPUManager policy options in the Kubernetes configuration or. This setting directs the CPUManager to adopt the new distribution strategy. It is important to note that this policy option cannot currently be used in conjunction with full-pcpus-only or distribute-cpus-across-numa options.

Current limitations and future directions

As with any new feature, especially one in alpha, there are limitations and areas for future improvement. One significant current limitation is that distribute-cpus-across-cores cannot be combined with other policy options that might conflict in terms of CPU allocation strategies. This restriction can affect compatibility with certain workloads and deployment scenarios that rely on more specialized resource management.

Looking forward, we are committed to enhancing the compatibility and functionality of the distribute-cpus-across-cores option. Future updates will focus on resolving these compatibility issues, allowing this policy to be combined with other CPUManager policies seamlessly. Our goal is to provide a more flexible and robust CPU allocation framework that can adapt to a variety of workloads and performance demands.

The introduction of the distribute-cpus-across-cores policy in Kubernetes CPUManager is a step forward in our ongoing efforts to refine resource management and improve application performance. By reducing the contention on physical cores, this feature offers a more balanced approach to CPU resource allocation, particularly beneficial for environments running heterogeneous workloads. We encourage Kubernetes users to test this new feature and provide feedback, which will be invaluable in shaping its future development.

This draft aims to clearly explain the new feature while setting expectations for its current stage and future improvements.

Further reading

Please check out the Control CPU Management Policies on the Node task page to learn more about the CPU Manager, and how it fits in relation to the other node-level resource managers.

Getting involved

This feature is driven by the SIG Node . If you are interested in helping develop this feature, sharing feedback, or participating in any other ongoing SIG Node projects, please attend the SIG Node meeting for more details.