Access-Accept / Access-Reject based on LDAP Group & SSID
Hi, I already read plenty of Howtos, manpages and configuration examples and tried to find a Guide for what I'm trying to archive. The best matching I found was http://serverfault.com/questions/397087/auth-type-reject-in-radius-users-fil... and http://wiki.freeradius.org/guide/Mac-Authat but these didn't helped much. In fact they left me more confused than I was before. What I exactly want to archive is RADIUS to check 1) if the group the user is in is allowed to log into Called-Station-Ssid "guest" 2) if the username & password is correct 3) if user has "dialupAccess" set I'm running Ubuntu 14.04.1, FreeRADIUS 2.1.12 and OpenLDAP 2.4.31 I'd start from scratch but have modified dictionary, policy.conf and sites-available/default according to http://wiki.freeradius.org/guide/Mac-Auth Any help is greatly appreciated. Thank you very much in advance! Best regards, Ben Humpert
On Mar 19, 2015, at 12:20 PM, Ben Humpert <ben@an3k.de> wrote:
I already read plenty of Howtos, manpages and configuration examples and tried to find a Guide for what I'm trying to archive.
Most third-party guides aren’t worth the effort. It’s better to UNDERSTAND what’s going on, rather than to follow a guide which may or may not be applicable.
What I exactly want to archive is RADIUS to check 1) if the group the user is in is allowed to log into Called-Station-Ssid “guest"
That’s in the FAQ.
2) if the username & password is correct
The server does that if you configure a user/password. i.e. tell it to look the user up in LDAP.
3) if user has "dialupAccess” set
See the LDAP module configuration for how that works.
I'm running Ubuntu 14.04.1, FreeRADIUS 2.1.12 and OpenLDAP 2.4.31
<sigh> Upgrade to 2.2.6. The Debian / Ubuntu people have fixated on 2.2.12 for reasons I don’t understand.
I'd start from scratch but have modified dictionary, policy.conf and sites-available/default according to http://wiki.freeradius.org/guide/Mac-Auth
Are you doing MAC Auth? If so, then the guide should work. If you’re not doing MAC Auth, then why the heck are you following the MAC auth guide? Alan DeKok.
2015-03-19 18:14 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Mar 19, 2015, at 12:20 PM, Ben Humpert <ben@an3k.de> wrote:
I already read plenty of Howtos, manpages and configuration examples and tried to find a Guide for what I'm trying to archive.
Most third-party guides aren’t worth the effort. It’s better to UNDERSTAND what’s going on, rather than to follow a guide which may or may not be applicable.
What I exactly want to archive is RADIUS to check 1) if the group the user is in is allowed to log into Called-Station-Ssid “guest"
That’s in the FAQ.
http://wiki.freeradius.org/guide/faq Where?
2) if the username & password is correct
The server does that if you configure a user/password. i.e. tell it to look the user up in LDAP.
Server already does it but before checking in which group the user is
3) if user has "dialupAccess” set
See the LDAP module configuration for how that works.
That already works, directly after checking for username/password but before checking in which group the user is.
I'm running Ubuntu 14.04.1, FreeRADIUS 2.1.12 and OpenLDAP 2.4.31
<sigh> Upgrade to 2.2.6. The Debian / Ubuntu people have fixated on 2.2.12 for reasons I don’t understand.
RADIUS 2.1.12 is the latest available in latest LTS Ubuntu.
I'd start from scratch but have modified dictionary, policy.conf and sites-available/default according to http://wiki.freeradius.org/guide/Mac-Auth
Are you doing MAC Auth? If so, then the guide should work. If you’re not doing MAC Auth, then why the heck are you following the MAC auth guide?
No but it was the ONLY guide which explained how to seperate MAC and SSID. I didn't followed it completely, just took the parts I need.
2015-03-19 18:53 GMT+01:00 Ben Humpert <ben@an3k.de>:
2015-03-19 18:14 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Mar 19, 2015, at 12:20 PM, Ben Humpert <ben@an3k.de> wrote:
I already read plenty of Howtos, manpages and configuration examples and tried to find a Guide for what I'm trying to archive.
Most third-party guides aren’t worth the effort. It’s better to UNDERSTAND what’s going on, rather than to follow a guide which may or may not be applicable.
What I exactly want to archive is RADIUS to check 1) if the group the user is in is allowed to log into Called-Station-Ssid “guest"
That’s in the FAQ.
Did you mean http://wiki.freeradius.org/guide/faq#How-do-I-deny-access-to-a-specific-user... That has nothing to do with LDAP!
On Thu, Mar 19, 2015 at 06:53:37PM +0100, Ben Humpert wrote:
2015-03-19 18:14 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Mar 19, 2015, at 12:20 PM, Ben Humpert <ben@an3k.de> wrote:
What I exactly want to archive is RADIUS to check 1) if the group the user is in is allowed to log into Called-Station-Ssid “guest"
That’s in the FAQ.
Try the rlm_ldap page: http://wiki.freeradius.org/modules/Rlm_ldap "Group Support". If you've already followed the part from the mac auth docs about getting Called-Station-SSID, you should be able to do something like if (Called-Station-SSID == "guest") { if (Ldap-Group == "guestgroup") { noop } else { reject } } or similar, to accomplish what you want.
I'm running Ubuntu 14.04.1, FreeRADIUS 2.1.12 and OpenLDAP 2.4.31
<sigh> Upgrade to 2.2.6. The Debian / Ubuntu people have fixated on 2.2.12 for reasons I don’t understand.
RADIUS 2.1.12 is the latest available in latest LTS Ubuntu.
We know that. 2.1.12 is ancient and has plenty of bugs and security issues. If you really want to use it, you're probably better off going to Ubuntu for help. Long term "support" should mean that... Building 2.2.6 on Debian is absolutely trivial. http://wiki.freeradius.org/building/Build#Building-Debian-packages Having said that, unlang like the above will /probably/ be OK on that version. But noone around here is particularly interested, as you've found out :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
2015-03-20 2:15 GMT+01:00 Matthew Newton <mcn4@leicester.ac.uk>:
Try the rlm_ldap page: http://wiki.freeradius.org/modules/Rlm_ldap "Group Support".
If you've already followed the part from the mac auth docs about getting Called-Station-SSID, you should be able to do something like
if (Called-Station-SSID == "guest") { if (Ldap-Group == "guestgroup") { noop } else { reject } }
or similar, to accomplish what you want.
Thank you very much for posting that example. I got what I wanted to archive working. However, it feels like a very dirty hack. Isn't there a better way (maybe in newer versions)?
2.1.12 is ancient and has plenty of bugs and security issues. If you really want to use it, you're probably better off going to Ubuntu for help. Long term "support" should mean that...
Building 2.2.6 on Debian is absolutely trivial. http://wiki.freeradius.org/building/Build#Building-Debian-packages
Having said that, unlang like the above will /probably/ be OK on that version. But noone around here is particularly interested, as you've found out :)
If I would use 2.2.6 wouldn't I have to use the same configuration as I have to use in 2.1.12 or it there are easier and more modular way to implement what I want to archive? Currently I have to "hardcode" every group into the configuration file and everytime I add/remove a group I have to edit the file and restart Radius. It's like Radius without LDAP. I thought of something like if (%{tolower:%{Ldap-Group}} == %{Called-Station-Ssid}) { noop } else { reject } Kind regards, Ben
On 20 Mar 2015, at 10:16, Ben Humpert <ben@an3k.de> wrote:
2015-03-20 2:15 GMT+01:00 Matthew Newton <mcn4@leicester.ac.uk>:
Try the rlm_ldap page: http://wiki.freeradius.org/modules/Rlm_ldap "Group Support".
If you've already followed the part from the mac auth docs about getting Called-Station-SSID, you should be able to do something like
if (Called-Station-SSID == "guest") { if (Ldap-Group == "guestgroup") { noop } else { reject } }
or similar, to accomplish what you want.
Thank you very much for posting that example. I got what I wanted to archive working. However, it feels like a very dirty hack. Isn't there a better way (maybe in newer versions)?
if (Ldap-Group == Called-Station-SSID) { } It's not really clear what you're trying to do...
2.1.12 is ancient and has plenty of bugs and security issues. If you really want to use it, you're probably better off going to Ubuntu for help. Long term "support" should mean that...
Building 2.2.6 on Debian is absolutely trivial. http://wiki.freeradius.org/building/Build#Building-Debian-packages
Having said that, unlang like the above will /probably/ be OK on that version. But noone around here is particularly interested, as you've found out :)
If I would use 2.2.6 wouldn't I have to use the same configuration as I have to use in 2.1.12 or it there are easier and more modular way to implement what I want to archive?
Currently I have to "hardcode" every group into the configuration file and everytime I add/remove a group I have to edit the file and restart Radius. It's like Radius without LDAP. I thought of something like
if (%{tolower:%{Ldap-Group}} == %{Called-Station-Ssid}) { noop } else { reject }
In version 3 you can use LDAP group caching, and the multivalue selector. if (&LDAP-Group[*] == &Called-Station-Id) { } Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
2015-03-20 16:05 GMT+01:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
It's not really clear what you're trying to do...
# Guest, Groups, example.com dn: cn=Guest,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top objectClass: radiusprofile cn: Guest gidNumber: 17068 memberUid: guest radiusCalledStationId: 00-11-22-33-44-55 radiusCalledStationSsid: guest radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 1 radiusTunnelType: VLAN # Developers, Groups, example.com dn: cn=Developers,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top objectClass: radiusprofile cn: Developers gidNumber: 1421 memberUid: marc memberUid: tim memberUid: johnny radiusCalledStationId: 00-11-22-33-44-55 radiusCalledStationId: 22-33-44-55-66-77 radiusCalledStationSsid: developers radiusCalledStationSsid: employees radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 43 radiusTunnelType: VLAN # tim, Users, example.com dn: uid=tim,ou=Users,dc=example,dc=com objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: radiusprofile gidNumber: 0 givenName: Tim sn: Buktu displayName: Buktu, Tim uid: tim homeDirectory: /dev/null loginShell: /bin/false cn: TimBuktu uidNumber: 18459 radiusCalledStationId: 44-55-66-77-88-99 radiusCalledStationSsid: management radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 24 radiusTunnelType: VLAN dialupAccess: Yes # johnny, Users, example.com dn: uid=johnny,ou=Users,dc=example,dc=com objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: radiusprofile gidNumber: 0 givenName: John sn: Doe displayName: Doe, John uid: johhny homeDirectory: /dev/null loginShell: /bin/false cn: JohnDoe uidNumber: 4552 dialupAccess: Yes When a user connects to a wifi access point that NAS sends Called-Station-Id = 00-11-22-33-44-55:SSID in the Access-Request packet. RADIUS converts it (based on rewrite.called_station_id) to Called-Station-Id = 00-11-22-33-44-55 and to Called-Station-Ssid = SSID. After doing the basics (checking if user exists, if password matches, if attribute dialupAccess is set) RADIUS should check if the users group has a radiusCalledStationId attribute matching the Called-Station-Id. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found and Called-Station-Ssid is set RADIUS should now check if the users group has a matching radiusCalledStationSsid attribute. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found RADIUS should finally check the users group for other attributes (eg. radiusTunnelType, etc.) and apply them as long as the user itself doesn't have these attributes set too. In that case the users attributes take precedence. So user tim will always get into VLAN 24 (user attributes precedence) and can get authorized through NAS' with the MAC address 00-11-22-33-44-55, 22-33-44-55-66-77 or 44-55-66-77-88-99 (user and group attributes merged) and is allowed to connect to SSID developers, employees or management (user and group attributes merged). User johnny always gets into VLAN 43 and can get authorized through NAS' with the MAC address 00-11-22-33-44-55 or 22-33-44-55-66-77 and is allowed to connect to SSID developers or employees. Normally I don't have a problem understanding the documentation and how software works but in this case I don't know where to put what kind of code. Should I do everything with unlang in the authorize section of sites-enabled/default (+ policy.conf) or post-auth or modify modules/ldap or the users file ... I guess it's because with freeradius everything is already configured and enabled and I'm flooded with information I don't need (yet). It's very nice and appreciated since you guys already did the configuring job (eap, peap, mschap, etc.) but in my case it's just confusing me. I'm used to start with minimal configurations and slowly adding stuff I need step by step. If anybody is willed to help me but upgrading to 2.2.6 or even 3.0.7 is necessary I for sure will upgrade first and will greatly appreciate any help offered. I'm definitely not asking for the whole configuration but an example of how to get RADIUS to eg. check for radiusCalledStationId first in Group and then in Users and merge both will greatly help. Best regards, Ben
If you don't have the time to *summarize* what you're doing, I don't have time to read the hundreds of lines of ldap dump you posted.
On Mar 20, 2015, at 5:05 PM, Ben Humpert <ben@an3k.de> wrote:
2015-03-20 16:05 GMT+01:00 Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
It's not really clear what you're trying to do...
# Guest, Groups, example.com dn: cn=Guest,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top objectClass: radiusprofile cn: Guest gidNumber: 17068 memberUid: guest radiusCalledStationId: 00-11-22-33-44-55 radiusCalledStationSsid: guest radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 1 radiusTunnelType: VLAN
# Developers, Groups, example.com dn: cn=Developers,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top objectClass: radiusprofile cn: Developers gidNumber: 1421 memberUid: marc memberUid: tim memberUid: johnny radiusCalledStationId: 00-11-22-33-44-55 radiusCalledStationId: 22-33-44-55-66-77 radiusCalledStationSsid: developers radiusCalledStationSsid: employees radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 43 radiusTunnelType: VLAN
# tim, Users, example.com dn: uid=tim,ou=Users,dc=example,dc=com objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: radiusprofile gidNumber: 0 givenName: Tim sn: Buktu displayName: Buktu, Tim uid: tim homeDirectory: /dev/null loginShell: /bin/false cn: TimBuktu uidNumber: 18459 radiusCalledStationId: 44-55-66-77-88-99 radiusCalledStationSsid: management radiusTunnelMediumType: IEEE-802 radiusTunnelPrivateGroupId: 24 radiusTunnelType: VLAN dialupAccess: Yes
# johnny, Users, example.com dn: uid=johnny,ou=Users,dc=example,dc=com objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: radiusprofile gidNumber: 0 givenName: John sn: Doe displayName: Doe, John uid: johhny homeDirectory: /dev/null loginShell: /bin/false cn: JohnDoe uidNumber: 4552 dialupAccess: Yes
When a user connects to a wifi access point that NAS sends Called-Station-Id = 00-11-22-33-44-55:SSID in the Access-Request packet. RADIUS converts it (based on rewrite.called_station_id) to Called-Station-Id = 00-11-22-33-44-55 and to Called-Station-Ssid = SSID. After doing the basics (checking if user exists, if password matches, if attribute dialupAccess is set) RADIUS should check if the users group has a radiusCalledStationId attribute matching the Called-Station-Id. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found and Called-Station-Ssid is set RADIUS should now check if the users group has a matching radiusCalledStationSsid attribute. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found RADIUS should finally check the users group for other attributes (eg. radiusTunnelType, etc.) and apply them as long as the user itself doesn't have these attributes set too. In that case the users attributes take precedence.
So user tim will always get into VLAN 24 (user attributes precedence) and can get authorized through NAS' with the MAC address 00-11-22-33-44-55, 22-33-44-55-66-77 or 44-55-66-77-88-99 (user and group attributes merged) and is allowed to connect to SSID developers, employees or management (user and group attributes merged).
User johnny always gets into VLAN 43 and can get authorized through NAS' with the MAC address 00-11-22-33-44-55 or 22-33-44-55-66-77 and is allowed to connect to SSID developers or employees.
Normally I don't have a problem understanding the documentation and how software works but in this case I don't know where to put what kind of code. Should I do everything with unlang in the authorize section of sites-enabled/default (+ policy.conf) or post-auth or modify modules/ldap or the users file ... I guess it's because with freeradius everything is already configured and enabled and I'm flooded with information I don't need (yet). It's very nice and appreciated since you guys already did the configuring job (eap, peap, mschap, etc.) but in my case it's just confusing me. I'm used to start with minimal configurations and slowly adding stuff I need step by step.
If anybody is willed to help me but upgrading to 2.2.6 or even 3.0.7 is necessary I for sure will upgrade first and will greatly appreciate any help offered. I'm definitely not asking for the whole configuration but an example of how to get RADIUS to eg. check for radiusCalledStationId first in Group and then in Users and merge both will greatly help.
Best regards,
Ben - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
2015-03-20 22:19 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
If you don't have the time to *summarize* what you're doing, I don't have time to read the hundreds of lines of ldap dump you posted.
On Mar 20, 2015, at 5:05 PM, Ben Humpert <ben@an3k.de> wrote:
RADIUS should check if the users group has a radiusCalledStationId attribute matching the Called-Station-Id. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found and Called-Station-Ssid is set RADIUS should now check if the users group has a matching radiusCalledStationSsid attribute. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found RADIUS should finally check the users group for other attributes (eg. radiusTunnelType, etc.) and apply them as long as the user itself doesn't have these attributes set too. In that case the users attributes take precedence.
Ok, went on to 3.0.7 and will try it with that version. Looks much easier now. Didn't knew THAT much has changed. Really like how the ldap module got improved! Great job!
Am 21.03.15 15:45 schrieb(en) Ben Humpert:
Ok, went on to 3.0.7 and will try it with that version. Looks much easier now. Didn't knew THAT much has changed. Really like how the ldap module got improved! Great job! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 21 Mar 2015, at 10:45, Ben Humpert <ben@an3k.de> wrote:
Ok, went on to 3.0.7 and will try it with that version. Looks much easier now. Didn't knew THAT much has changed. Really like how the ldap module got improved! Great job!
Thanks. It got rewritten twice from v2.x.x. Alan did the first pass to untangle the awful spaghetti code, and I did the second pass to make it sane. For what you want to do, i'd recommend turning on the group name caching, and checking the values of the group cache attribute directly at some point after calling ldap in authorize. You may also want to use rlm_cache to temporarily store group memberships if your users are members of a large number of groups and either the memberships are stored in the group objects, or the group membership attributes in the user objects contain DNs. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Mar 20, 2015, at 5:05 PM, Ben Humpert <ben@an3k.de> wrote:
RADIUS should check if the users group has a radiusCalledStationId attribute matching the Called-Station-Id. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found and Called-Station-Ssid is set RADIUS should now check if the users group has a matching radiusCalledStationSsid attribute. If not it should check if the user itself has a matching attribute. If not, Access-Reject. In case a match is found RADIUS should finally check the users group for other attributes (eg. radiusTunnelType, etc.) and apply them as long as the user itself doesn't have these attributes set too. In that case the users attributes take precedence.
Finally I got everything I wanted. However I don't know if how it's done is the right or at least a good way. I would appreciate if someone could quickly check my implementation and comment it :) In server default authorize {} I first sanitize supplied Called-Station-Id (& create Called-Station-Ssid if supplied) and Calling-Station-Id using policies and at the very end I use policies again to check supplied Called-Station-Id, Called-Station-Ssid and Calling-Station-Id values with those stored in LDAP. In server default post-auth {} the first policy is for applying dynamic vlan assignment attributes. policy.ldap_called-station-ssid { if (&Called-Station-Ssid) { if ("%{ldap:ldap:///ou=Groups,dc=home,dc=lan?gidNumber?sub?(&(cn=%{control:LDAP-Group})(memberUid=%{User-Name})(radiusCalledStationSsid=%{Called-Station-Ssid}))}" || "%{ldap:ldap:///ou=Users,dc=home,dc=lan?uidNumber?sub?(&(uid=%{User-Name})(radiusCalledStationSsid=%{Called-Station-Ssid}))}") { noop } else { reject } } else { noop } } policy.ldap_called-station-id and policy.ldap_calling-station-id are the same, respectively. These are checked only once after the first Access-Request package directly after eap so I guess it's fine. The next policy is maybe not a good solution since the LDAP is queried up to eight times. policy.ldap_vlan-assignment { if ("%{ldap:ldap:///ou=Users,dc=home,dc=lan?uidNumber?sub?(&(uid=%{User-Name})(radiusTunnelType=VLAN))}") { update reply { &Tunnel-Medium-Type := "%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelMediumType?sub?(&(uid=%{User-Name}))}" &Tunnel-Private-Group-Id := "%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelPrivateGroupId?sub?(&(uid=%{User-Name}))}" &Tunnel-Type := "%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelType?sub?(&(uid=%{User-Name}))}" } } elsif ("%{ldap:ldap:///ou=Groups,dc=home,dc=lan?gidNumber?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name})(radiusTunnelType=VLAN))}") { update reply { &Tunnel-Medium-Type := "%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelMediumType?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}" &Tunnel-Private-Group-Id := "%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelPrivateGroupId?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}" &Tunnel-Type := "%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelType?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}" } } else { update reply { &Tunnel-Medium-Type := "IEEE-802" &Tunnel-Private-Group-Id := "1" &Tunnel-Type := "VLAN" } } updated } That policy is only executed once directly before the final Access-Accept package is sent. However, if one (existing) user wants to login the LDAP is queried 14 times (worst-case) or 7 times (best-case). Generally said, is that a very good, acceptable or extremely worse amount of queries per user? I also found some configurations I couldn't understand. First is in sites-enabled/default line 494: why is eap not called as "Auth-Type EAP { eap }" like pap, chap and ms-chap? I also noticed that the server looks for a Post-Auth-Type Challenge {} but couldn't find it thus ignoring it (debug output), so I added it to the post-auth section with attr_filter.access_challenge in it. Shouldn't this be the default? At last I got confused by the commented out routine in sites-enabled/default line 502 to 510. Here we have "Auth-Type EAP { eap }" and the attr_filter.access_challenge but doesn't the added Post-Auth-Type Challenge routine do exactly the same (except setting handled = 1)? Thank you very much in advance. Best regards, Ben Humpert
On Mar 20, 2015, at 10:16 AM, Ben Humpert <ben@an3k.de> wrote:
Thank you very much for posting that example. I got what I wanted to archive working. However, it feels like a very dirty hack. Isn't there a better way (maybe in newer versions)?
Use a database.
If I would use 2.2.6 wouldn't I have to use the same configuration as I have to use in 2.1.12 or it there are easier and more modular way to implement what I want to archive?
No.
Currently I have to "hardcode" every group into the configuration file and everytime I add/remove a group I have to edit the file and restart Radius. It's like Radius without LDAP. I thought of something like
if (%{tolower:%{Ldap-Group}} == %{Called-Station-Ssid}) { noop
You can’t lowercase the LDAP group. You’ll have to lowercase the Called-Station-SSID instead. It helps to describe what you’re doing. You asked if you could do LDAP group checks based on Called-Station-SSID. You got an answer. If the LDAP group names are the *same* as the SSID, then you should have said that, too. You’d get a different answer. So… what’s actually going on? Alan DeKok.
2015-03-19 18:14 GMT+01:00 Alan DeKok <aland@deployingradius.com>:
On Mar 19, 2015, at 12:20 PM, Ben Humpert <ben@an3k.de> wrote:
I'm running Ubuntu 14.04.1, FreeRADIUS 2.1.12 and OpenLDAP 2.4.31
<sigh> Upgrade to 2.2.6. The Debian / Ubuntu people have fixated on 2.2.12 for reasons I don’t understand.
I asked on ubuntu-devel-discuss and the answer is simple but sad. There isn't an active maintainer in debian (although someone did bump the version there to 2.2.5), and no one in ubuntu has merged this from debian since may last year. Sorry about that, but time is precious and not everyone is interested in the package. It's probably too late, but if this really matters to you have a look at https://wiki.*ubuntu*.com/FreezeExceptionProcess and make an FFe bug. https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2015-March/015417.htm... I actually did build 3.0.7 packages on a fresh Ubuntu Server 14.04 using http://wiki.freeradius.org/building/Build#Building-Debian-packages but it's the first time I built a package and I really don't know if I did everything right or missed something important. However, the packages are working well on my servers so if it's really that simple I could build and submit the latest stable to debian / ubuntu.
On Mar 23, 2015, at 4:32 PM, Ben Humpert <ben@an3k.de> wrote:
I asked on ubuntu-devel-discuss and the answer is simple but sad.
There isn't an active maintainer in debian (although someone did bump the version there to 2.2.5),
Yeah. Sam Hartman did that at my request. He will likely become the new maintainer. The old maintainer just disappeared. No response to emails, etc. Alan DeKok.
Hi Ben, On Mon, Mar 23, 2015 at 10:32:44PM +0100, Ben Humpert wrote:
I actually did build 3.0.7 packages on a fresh Ubuntu Server 14.04 using http://wiki.freeradius.org/building/Build#Building-Debian-packages but it's the first time I built a package and I really don't know if I did everything right or missed something important. However, the packages are working well on my servers so if it's really that simple I could build and submit the latest stable to debian / ubuntu.
Yes, building the packages for your local system really is that simple. Though submitting them to Debian likely won't be :) Pretty much, as long as you've got the right build packages installed, you can grab the FreeRADIUS source and do freeradius-server$ make deb to build the packages. You do of course need to make sure you rebuild if new security related releases come out, as you won't get updates from the Debian security repository. Thankfully, that's fairly rare. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (5)
-
Alan DeKok -
Albrecht Dreß -
Arran Cudbard-Bell -
Ben Humpert -
Matthew Newton