July 2006 - Freeradius-Users - lists.freeradius.org

Problem with distributed proxy nodes - how do I pass back "unavailable" when upstream is down temporarily?
by Andrew O'Brien 19 Jul '06

19 Jul '06

Hi all, I'm fairly new to using radius for authentication so please excuse any incorrect terminology. I'll give a brief overview of what I've got and then describe where I want to go but don't know how :) Setup ===== I'm using freeradius 1.1.0 on a mixture of debian woody and sarge boxes. There is a central radius server which holds all user auth and optionally proxies some realms to LDAP etc - works like a charm. I've also got a number of remote dumb proxy freeradius nodes running at the other end of volatile links, say modem dialup, that connect back to the central area for monitoring purposes. They are configured to proxy NULL realms and DEFAULT back to the central server. Auth requests come from cisco switches etc on the local LAN for each node. Again - works a treat. A star radius network if you like. The problem comes when the link between the remote node and central server drops for a while. Local requests come in, the node tries to contact central node, can't connect, temporarily marks the central server as dead but then gives back an "unauthorised" message. This means that the devices on the local node LAN never fail over to local auth and we're effectively locked out of those devices :) Question ======== So, how can I pass back a different radius message that causes the local LAN devices to fall over to local auth instead of radius in the case where the upstream is dead? Alternatively, I could have a single account on the node itself with a particular realm that doesn't get proxied but the intent of this setup is to only allow device-specific local accounts to be used when the radius is completely down. How would you do this? Perhaps a completely different approach rather than dump proxying is necessary? Any feedback at all would be appreciated. Thanks! -- Andrew O'Brien

1 0

Map LDAP Attribute to RADIUS Attribute
by Paul Asadoorian 19 Jul '06

19 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All: I am running FreeRADIUS version 1.1.2 on Debian Linux (Stable x86). I am trying to map an LDAP attribute to a RADIUS attribute. A little background, we have a RADIUS client that needs to make decisions based on an LDAP attribute (we'll call it User-Category). Based on the value of this attribute the end user will be given rights on the network. So, I setup my ldap.attrmap with *only* the following line: replyItem User-Category orgPrimaryAffiliation I setup the following config for rlm_ldap: server = "ldapserver.org.com" identity = "cn=Radius_admin,ou=Special Users,dc=org,dc=com" password = 12345 basedn = "dc=org,dc=com" filter = "(&(objectclass=*) (orgShortid=%{Stripped- User-Name:-%{User-Name}}))" base_filter = "(objectclass=*)" # port = 636 port = 389 The following debug logs show the successful authentication of the user and the mapping of the attributes: rad_recv: Access-Request packet from host 127.0.0.1:32904, id=192, length=58 User-Name = "mytestuser" User-Password = "12345" NAS-IP-Address = 255.255.255.255 NAS-Port = 1812 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module "preprocess" returns ok for request 4 modcall[authorize]: module "chap" returns noop for request 4 modcall[authorize]: module "mschap" returns noop for request 4 rlm_realm: No '@' in User-Name = "mytestuser", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 4 rlm_ldap: - authorize rlm_ldap: performing user authorization for mytestuser radius_xlat: '(&(objectclass=*) (orgShortid=mytestuser))' radius_xlat: 'dc=org,dc=com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=org,dc=com, with filter (& (objectclass=*) (orgShortid=mytestuser)) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: Adding orgPrimaryAffiliation as User-Category, value student & op=11 rlm_ldap: Setting Auth-Type = ldap rlm_ldap: user mytestuser authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 4 modcall: leaving group authorize (returns ok) for request 4 rad_check_password: Found Auth-Type ldap auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 4 rlm_ldap: - authenticate rlm_ldap: login attempt by "mytestuser" with password "12345" rlm_ldap: user DN: orgUUID=53d66879-e0a0- da8f-4c49-514b567713ad,ou=People,dc=org,dc=com rlm_ldap: (re)connect to ldapserver.org.com:389, authentication 1 rlm_ldap: bind as orgUUID=53d66879-e0a0- da8f-4c49-514b567713ad,ou=People,dc=org,dc=com/12345 to ldapserver.org.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user mytestuser authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 4 modcall: leaving group LDAP (returns ok) for request 4 Sending Access-Accept of id 192 to 127.0.0.1 port 32904 Finished request 4 The problem is that I never see the RADIUS server return the "User- Category" attribute back to the RADIUS client. It seems to only want to send the "Access-Accept" or "Access-Reject" message with no User- Category value. I tried including the "User-Category" in the request with no luck. I also modified the "attrs" file to include this attribute: DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, Framed-IP-Address == 255.255.255.254, Framed-IP-Netmask == 255.255.255.255, Framed-Protocol == PPP, Framed-Protocol == SLIP, Framed-Compression == Van-Jacobson-TCP-IP, Framed-MTU >= 576, Framed-Filter-ID =* ANY, Reply-Message =* ANY, User-Category =* ANY, Proxy-State =* ANY, Session-Timeout <= 28800, Idle-Timeout <= 600, Port-Limit <= 2 But no luck there either. Any help is greatly appreciated. Thank You, Paul - -- Paul Asadoorian Email: paul(a)pauldotcom.com Web: http://pauldotcom.com IRC: #pauldotcom | irc.freenode.net Fingerprint: 2693 0204 8497 2E5F 4853 11D5 1153 6151 487F E094 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEvjotEVNhUUh/4JQRAqM/AKCWYfgBERhaBQ/xKUDMGD552JPB4QCfTP+v knyeEwAg7Annq9xXcdwK8s0= =Gzks -----END PGP SIGNATURE-----

4 9

multiple group membership & processing
by rabbtux rabbtux 19 Jul '06

19 Jul '06

greetings, I have users that should only be able to use 2 of 10 APs(chillispot nas). I found that when I create the following, the user can only login to the desired AP. Radcheck table fred User-Password := mypass radgroupcheck table cust1 Called-Station-ID == 00-13-10-94-AF-3C usergroup fred cust1 1 This works great, however, how do I expand this so that fred's login works for two Called-Station-IDs? Do I create another group with a different priority? Can't seem to get both groups to work as a logical OR. Thanks

1 0

Authenticating Against a Trusted Domain
by Josh 19 Jul '06

19 Jul '06

Does anyone know of some documentation on authenticating freeradius against a trusted domain? For example: We have a domain (ourdomain) that has a trust established with another domain (anotherdomain). I'm attempting to get freeradius to send auth requests to anotherdomain by way of ourdomain (which holds the trust). We are able to do this with file shares. For instance, we have a file server connected to ourdomain and users within anotherdomain that have NTFS permissions on the file server. The file server receives the connection, asks ourdomain for authentication, ourdomain then asks its trusted anotherdomain... and the result comes back allowing access. In addition, we have users on laptops connected to ourdomain but using their anotherdomain usernames to access the shares. They simply supply 'ANOTHERDOMAIN\user_name' as the username and the DCs on ourdomain forward the request up the trust. I haven't been successful with using Samba (which is connected to ourdomain)... I can get Samba to authenticate users on ourdomain but not the trusted anotherdomain. I figured I would give LDAP a try but can't find any documentation on the correct LDAP requests for freeradius. Any pointers? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

freeradius server and PPP
by Moustapha Ould Maouloud 19 Jul '06

19 Jul '06

Hello, I have in my LAN an access controller Colubris CN3200 (IP : 192.168.10.80), router (gw) IP : 192.168.10.1/80.x.x.x, and I authenticate it on a remote radius server (IP 63.x.x.x). In server side i have this (radiusd -X) : rad_recv: Access-Request packet from host 80.x.x.x:10901, id=64, length=251 Acct-Session-Id = "7592eefb" NAS-Port = 0 NAS-Port-Type = Wireless-802.11 User-Name = "noven-ac1" Calling-Station-Id = "00-03-52-01-FC-33" Called-Station-Id = "00-03-52-01-FC-33" Framed-IP-Address = 192.168.1.1 User-Password = "novenac1" NAS-Identifier = "noven.Vincennes.0" NAS-IP-Address = 192.168.10.81 Framed-MTU = 1496 Connect-Info = "HTTPS" Service-Type = Administrative-User WISPr-Location-Name = "noven.Noven-WiFi" WISPr-Location-ID = "noven2/Noven-WiFi" Message-Authenticator = 0xa4619c3e1b4b1f7f5a877de95f208ab0 Processing the authorize section of radiusd.conf ..... ...... Sending Access-Accept of id 64 to 80.x.x.x:10901 Framed-Protocol := PPP Service-Type := Framed-User Framed-MTU := 1500 Colubris-AVPair += "transport-page=https://192.168.10.82/Noven/transport.html" Colubris-AVPair += "session-page=https://192.168.10.82/Noven/session.html" ........ My problem is that the response from the radius server does not reach my AC (IP 192.168.10.81) although the answer was indeed turned over to my router (IP : 80.x.x.x) !!! Perhaps I need to install a PPP or PPPoE server ? I have no idea ... Someone can help me ? Please Thanks; Moustapha Maouloud --------------------------------- Avez-vous essayé le nouveau Yahoo! Mail ? Plus rapide, plus efficace... simplement révolutionnaire ! Découvrez-le.

3 2

RE: rlm_ippool and tcp TIME_WAIT state
by Sebastien Cantos 19 Jul '06

19 Jul '06

Hi, Ive noticed that rlm_ippool is nearly always reassigning an IP address that has just been releasing for a new connexion. This cause some TCP connexion problems because of the TIME_WAIT state. Scenario: 1/ one device connects using source port 1024 (ppp) and gets an IP address from freeradius 2/ this device disconnects, the ip is freed from the pool 3/ another devices connects using source port 1024 and gets the same ip address as before 4/ the connexion is impossible to the server because the connexion of last device is still in TIME_WAIT state How can I make sure an IP address is not assigned before some time period (240 seconds, time period of the TIME_WAIT state) after being released ? Regards, Neopost Diva 127 avenue Joseph Pierre Boitelet BP50 84302 CAVAILLON Cedex FRANCE Sébastien, Cantos IT Manager <mailto:s.cantos@neopost.com%3c!--123mms_/email--%3e> s.cantos(a)neopost.com Phone: + 33 4 90 76 08 08 Fax: + 33 1 40 39 23 23 <http://www.neopost.com> http://www.neopost.com The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The Internet cannot guarantee the integrity of this message. Neopost shall not therefore be liable for the message if modified. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact <mailto:postmaster.diva@neopost.com> postmaster.diva(a)neopost.com and then delete this message.

2 3

Problem with secrets
by David Goodenough 19 Jul '06

19 Jul '06

I just hit a really odd problem with a secrets. We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails. Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing). This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case. The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded). A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply. I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them. It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right. I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2). David

3 5

3com problem with service-type
by Nuno Cervaens 19 Jul '06

19 Jul '06

Hi guys, I have a lot of hp switches and a lot of 3com switches. I have users that I want them to have Administrator privilege and others that will have NAS-Prompt privilege. So, my users files should be like this, so it can work for both brands: userA Password = pass Service-Type = 7, 3Com-User-Access-Level = 1 userB Password = pass Service-Type = 6, 3Com-User-Access-Level = 3 The problem is that 3COM doesnt accept a service-type =7! It only accepts Service-Type = 6! So the 3COM rejects the access-accept from RADIUS for userA. I know that I can use huntgroups and create for each huntgroup a different account for the same user with different attributes, but I dont want to use huntgroups because I already use it for Mac-address authentication (and apparently a same NAS-IP-Address cannot belong to more than 1 huntgroup as RADIUS returns the first huntgroup that matches the NAS-IP-Address). Does anyone has a solution for my problem? Thanks, Nuno

1 0

3com problem with service-type
by Nuno Cervaens 19 Jul '06

19 Jul '06

Hi guys, I have a lot of hp switches and a lot of 3com switches. I have users that I want them to have Administrator privilege and others that will have NAS-Prompt privilege. So, my users files should be like this, so it can work for both brands: userA Password = pass Service-Type = 7, 3Com-User-Access-Level = 1 userB Password = pass Service-Type = 6, 3Com-User-Access-Level = 3 The problem is that 3COM doesnt accept a service-type =7! It only accepts Service-Type = 6! So the 3COM rejects the access-accept from RADIUS for userA. I know that I can use huntgroups and create for each huntgroup a different account for the same user with different attributes, but I dont want to use huntgroups because I already use it for Mac-address authentication (and apparently a same NAS-IP-Address cannot belong to more than 1 huntgroup as RADIUS returns the first huntgroup that matches the NAS-IP-Address). Does anyone has a solution for my problem? Thanks, Nuno

1 0

3com problem with service-type
by Nuno Cervaens 19 Jul '06

19 Jul '06

Hi guys, I have a lot of hp switches and a lot of 3com switches. I have users that I want them to have Administrator privilege and others that will have NAS-Prompt privilege. So, my users files should be like this, so it can work for both brands: userA Password = pass Service-Type = 7, 3Com-User-Access-Level = 1 userB Password = pass Service-Type = 6, 3Com-User-Access-Level = 3 The problem is that 3COM doesnt accept a service-type =7! It only accepts Service-Type = 6! So the 3COM rejects the access-accept from RADIUS for userA. I know that I can use huntgroups and create for each huntgroup a different account for the same user with different attributes, but I dont want to use huntgroups because I already use it for Mac-address authentication (and apparently a same NAS-IP-Address cannot belong to more than 1 huntgroup as RADIUS returns the first huntgroup that matches the NAS-IP-Address). Does anyone has a solution for my problem? Thanks, Nuno

1 0