- Freeradius-Users - lists.freeradius.org

Unique dictionary entries
by Christopher Fowler 17 Nov '05

17 Nov '05

1. Radiusd version: [cfowler@cfowler sbin]$ radiusd -v radiusd: RADIUS version 1.6.7 21-Jul-2003 Compilation flags: USE_SYSLOG ATTRIB_NMC COMPAT_1543 linux 2. Users File [cfowler@cfowler sbin]$ cat /etc/raddb/users joe Ens-Auth-Type = "user", Ens-Auth-Password = "rad" Ens-Auth-Command = "shell", Ens-Auth-Acl = "1" [cfowler@cfowler sbin]$ 3. Debug output [cfowler@cfowler sbin]$ sudo radiusd -fx Starting - reading configuration files ... Ready to process requests. radrecv: Packet from host 192.168.2.137 code=1, id=27, length=55 User-Name = "joe" Service-Type = Login-User Ens-Auth-Type = "\001" Tunnel-Server-Auth-Id:1 = "" Ens-Auth-Command = "\001" Ens-Auth-Acl = "\001" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 NO SUCH USER FOUND: "joe" Unknown user: [joe] (from nas local/S0) Sending Reject of id 27 to 192.168.2.137 4. Problem. I've got my Radius server to support special dictionary entries. you can see the 'Ens-' entries. When my client tries to grab information from the Radius server the server does not see 'joe' in the users file. At one time I had this working about 2 years ago and now I need to use it again. Can anyone tell my what I've done wrong in my users file that would make radiusd not see the user 'joe'? Thanks, Chris

2 1

FreeRadius EAP-TLS issue
by Hamid Salim 17 Nov '05

17 Nov '05

Hi, I am just wondering if anyone has encountered the same issue. I have set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. For some reason I am getting: auth: Failed to validate the user. Login incorrect: [radiustst/<no User-Password attribute>] (from client testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) complete listing is attached. I am using certificates and SSL session is created successfully, then why FreeRadius is expecting a userid/password? Any help will be appreciated. Thanks Hamid. ============= Complete Listing ================= Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, length=1247 User-Name = "radiustst" NAS-IP-Address = 129.10.56.156 Called-Station-Id = "00-20-a6-4a-12-21" Calling-Station-Id = "00-10-c6-38-af-7b" NAS-Identifier = "APtest3" State = 0xb9a67433435733a42f7cbd528aa6ae7a Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020504510d800000044716030104170b000307000304000301308202fd30820266a003 020102020102300d06092a864886f70d01010405003054310b3009060355040613025553 310b3009060355040813024d413120301e060355040a13174e6f7274686561737465726e 20556e6976657273697479311630140603550403130d4543454175746853657276657230 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b30 09060355040613025553310b3009060355040813024d413120301e060355040a13174e6f 7274686561737465726e20556e6976657273697479311230100603550403130972616469 7573 EAP-Message = 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b9983d b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399c3 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d76 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175a0 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d1304 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e6572617465 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f828157 2f5e EAP-Message = 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf3743 0ee64b68e9a158a4563054310b3009060355040613025553310b3009060355040813024d 413120301e060355040a13174e6f7274686561737465726e20556e697665727369747931 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf3300d 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e2d 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf00 d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57dae0 c423 EAP-Message = 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f27465 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000f0 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df74 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e2f 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e69 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1a3 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5fdd 8f7c EAP-Message = 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d80 af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf869886 11a6916269516c4e5b6bf006d943609a71740a4d3a60 Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae Processing the authorize section of radiusd.conf modcall: entering group authorize for request 8 modcall[authorize]: module "preprocess" returns ok for request 8 radius_xlat: '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' rlm_detail: /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% m%d expands to /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 modcall[authorize]: module "auth_log" returns ok for request 8 rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 8 rlm_eap: EAP packet type response id 5 length 253 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 8 users: Matched entry radiustst at line 54 modcall[authorize]: module "files" returns ok for request 8 modcall: group authorize returns updated for request 8 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 8 rlm_eap: Request found, released from the list rlm_eap: EAP/tls rlm_eap: processing type tls rlm_eap_tls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate chain-depth=1, error=0 --> User-Name = radiustst --> BUF-Name = ECEAuthServer --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer --> verify return:1 chain-depth=0, error=0 --> User-Name = radiustst --> BUF-Name = radiustst --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer --> verify return:1 TLS_accept: SSLv3 read client certificate A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify TLS_accept: SSLv3 read certificate verify A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 modcall[authenticate]: module "eap" returns handled for request 8 modcall: group authenticate returns handled for request 8 Sending Access-Challenge of id 71 to 129.10.56.156:6001 EAP-Message = 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9c2 4322bdbd6ca0af149ba46d197f153a7f4f32 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x70ed13d02f1854999ba5b4513143d53d Finished request 8 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, length=167 User-Name = "radiustst" NAS-IP-Address = 129.10.56.156 Called-Station-Id = "00-20-a6-4a-12-21" Calling-Station-Id = "00-10-c6-38-af-7b" NAS-Identifier = "APtest3" State = 0x70ed13d02f1854999ba5b4513143d53d Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 9 modcall[authorize]: module "preprocess" returns ok for request 9 radius_xlat: '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' rlm_detail: /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% m%d expands to /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 modcall[authorize]: module "auth_log" returns ok for request 9 rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 9 rlm_eap: EAP packet type response id 6 length 33 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 9 users: Matched entry radiustst at line 54 modcall[authorize]: module "files" returns ok for request 9 modcall: group authorize returns updated for request 9 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 9 rlm_eap: Request found, released from the list rlm_eap: EAP/tls rlm_eap: processing type tls rlm_eap_tls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 eaptls_process returned 7 rlm_eap_tls: Received unexpected tunneled data after successful handshake. rlm_eap: Handler failed in EAP/tls rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 9 modcall: group authenticate returns invalid for request 9 auth: Failed to validate the user. Login incorrect: [radiustst/<no User-Password attribute>] (from client testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for 1 seconds Finished request 9 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, length=167 Sending Access-Reject of id 72 to 129.10.56.156:6001 EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 5 ID 68 with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping until we see a request.

3 2

Query local active session database (radutmp)
by TK Lew 17 Nov '05

17 Nov '05

hi :: Is it possible to query freeradius local session database (radutmp) to check for simultaneous use.? If exists delete it using radzap command and then only accept the Accouting Start packet which then eventually written to radutmp. I can write the script to delete but I have not ideas how to configure the radiusd.conf for my environment ( if it is can be done ). / Thanks BR

4 5

php account stats
by Jean Gaudreau 17 Nov '05

17 Nov '05

I'm looking for a script in php that can produce some stats from MySQL. Anyone ? Thanks Jean

2 1

RE: "Pool-Name" check item causes Access-Reject
by Dan Russell 17 Nov '05

17 Nov '05

Try putting the Pool-Name attribute in the radgroupcheck table. That's how I have it in mine and it works fine there. Daniel Russell Lead Technician In-House IT Services PH (03) 50210044 FX (03) 50210066 > -----Original Message----- > From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius- > users-bounces(a)lists.freeradius.org] On Behalf Of Gerret Apelt > Sent: Wednesday, 16 November 2005 11:23 PM > To: FreeRadius users mailing list > Subject: "Pool-Name" check item causes Access-Reject > > Hi List, > > My setup: Debian Sarge (2.6.8) > Debian package freeradius-mysql 1.0.5-2 > FreeRADIUS Version 1.0.5, for host , built on Oct 16 2005 at 11:56:56 > > I am successfully authentiating dialup users with Freeradius; the > users live in a MySQL db. Their IP addresses are assigned by a Patton > RAS's internal pool. I want to take this task away from the RAS and > have Freeradius ippool take over. Associating a pool with a user is > causing that user's access request to be rejected wher it worked > before. > > Following the docs, I have the files db.ipindex and db.ippol set up, > and the main_pool is configured in radiusd.conf. user 'gerret' is the > gunea pig with the following radcheck table entries: > > | 1354 | gerret | User-Password | == | testpw | > | 1491 | gerret | Pool-Name | == | main_pool | > > Now here's the tail of two "radtest gerret testpw localhost 0 testing123" > runs: > > 1) With row 1491 not present: > > modcall[authorize]: module "sql" returns ok for request 2 > modcall: group authorize returns ok for request 2 > rad_check_password: Found Auth-Type Local > auth: type Local > auth: user supplied User-Password matches local User-Password > Login OK: [gerret] (from client localhost port 0) > > > 2) with boths rows present: > > rlm_sql (sql): No matching entry in the database for request from user > [gerret] > rlm_sql (sql): Released sql socket id: 3 > modcall[authorize]: module "sql" returns notfound for request 1 > modcall: group authorize returns ok for request 1 > auth: No authenticate method (Auth-Type) configuration found for the > request: Rejecting the user > auth: Failed to validate the user. > Login incorrect: [gerret/testpw] (from client localhost port 0) > Delaying request 1 for 1 seconds > Finished request 1 > > I have tried setting explicit "Auth-Type = Local" in an additional > radcheck item to no avail. All mysql queries return the same data in > both cases. > > *cry for help* > > thanks guys > > Gerret > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html

2 1

Mini-mini-HowTo freeradius vs. ActiveDirectory
by Völker, Christian 17 Nov '05

17 Nov '05

Yohoo! Ok, I got it running. My freeradius authenticates vs. our ActiveDirectory (MS Win 2003 Server). Here is a short summary, written as HowTo. It's version 0.0.1beta ;-) _*Mini HowTo*_ *Authenticate freeradius vs. ActiveDirectory* Nov. 2005 *Author:* Christian Völker, c.voelker "at/@" knebb "dot/." de Feel free to contact. This is only a very mini and small version to help you getting the freeradius- server authenticating vs. ActiveDirectory. *Disclaimer:* I'm not responsible for anything if you follow these instructions. Do it at your own risk. I'm a linux specialist (RHCE, Novell CNI and CLP,...) and don't have much knowledge about the windows stuff. So I can't explain any of these things going on there ;) *Situation:* We want to authenticate administrators of our network-devices against our existing ActiveDirectory. ActiveDirectory can communicate via the LDAP-protocol. But the user attributes of the MS-users aber different from the "normal" Unix-UIDs in (Open)LDAP. So you can't easily switch between OpenLDAP and AD. Additionally, there should be a failover if one of our AD servers is going down. *Prerequisites:* _freeradius_ Here I used 1.0.1-1.RHEL on a RedHat Enterprise Linux AS release 3, running in a virtual machine under VMWare (don't care, a real machine would be fine also ;-)) _ActiveDirectory_ Of course, you will need AD running. Here, is it an MS-Windows 2003 Server. _Linux_ I've installed it on a RedHat Enterprise Linux AS release 3 system, any other system would be ok also. What we don't need is ntlm_auth, winbindd or kerberos. *Preface:* _PAP/CHAP..._ Alan DeKok wrote in the mailing list: -----------mail----------- This is done via simple LDAP bind, which AD supports. It works for PAP authentication. It doesn't work for CHAP, MSCHAP, or PEAP. -----------end mail----------- Don't assk me for any disadvantages, my knowledge about the MS products is very low. _failover_ Another statement from Alan DeKok (Dec, 15, 2004) -----------mail----------- > However, when I am using redundant, I cannot have this redundancy for > Ldap-Group lookups. Yes. That's an issue. -----------end mail----------- So there is no functionality for Ldap-groups with failover. Below I can show you a workaround from Dustin Doris. *How-To* _/etc/raddb/radiusd.conf_ I don't understand all of the features. All I changed were the ldap parms. So take a look at my /etc/raddb/radius.conf. Some explanations are commented with "#": I only changed parts in the ldap section. So the rest should be left as default. -----------file----------- ldap { # servername or ip # should be resolvable with dns and reverse DNS server = "ads2.example.com" # Usually AD doesn't allow anonymous requests # so you have to create a proxy users for the requests # you should enter the full DN here identity = "cn=proxy,ou=service,dc=example,dc=com" # also the password for the proxy user should be given here # It's cleartext, so it could be a security flaw password = 'password' # this is the basedn, where freeradius starts with it's search # without the "ou=" it didn't work here (don't know why!) basedn = "ou=all_users,dc=example,dc=com" # the filterparm tells radius where to look for the username # due of AD it's not the usual OpenLDAP, you have to # use the login name of AD. It's called "sAMAaccountname" # if you don't trust, take a look at AD with a ldap browser # Our AD is very huge, the servers are very slow # I encoutered problems by checking the groupmembership when users # are member in many groups # so I added the AND (&) and filtered against objectClass=person # additionally I increased again the timeout values # Now everything runs fine filter = "(&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person))" # the groupname_attribute describes, which object type the # groups are. In my case all groups are stored as # cn=... # I'm not sure about this, but it's working here groupname_attribute = "cn" # Also I had to check the meaning of the filters. # I hadn't found any explanation of this parm # so I will explain my understanding of this parm # "|" and "&" are logical operators for "OR" and "AND" # %{Ldap-UserDn} is a variable, self-explanation # The following statement looks only for the objectClasses group # and top which I figured out in our AD setup for the groups groupmembership_filter = "(|(&(objectClass=group)(member=%{Ldap-UserDn}))(&(objectClass=top)(uniquemember=%{Ldap-UserDn})))" # Here freeradius becomes the info at which attribute he should # take a look for the group membership # In AD it's called "memberOf", not "LDAP-Group" groupmembership_attribute = memberOf # For debugging purposes, set it to 0xFFFF, default is 0x0000 ldap_debug = 0xFFFF # We want to use secure transactions # I don't know, if we need to configure openssl for this feature start_tls = yes # default, unchanged dictionary_mapping = ${raddbdir}/ldap.attrmap # we have many users, so I increased this value # match it to your situation ldap_connections_number = 50 # I had to increase the timeout about a multiple of 10 # Our AD servers aren't very fast, but perhaps it's normal # If you run in problems, increase it timeout = 40 timelimit = 30 net_timeout = 10 # Our AD is very huge, the servers are very slow # I encoutered problems by checking the groupmembership when users # are member in many groups # take a look at the "filter" statement # additionally I increased again the timeout values # Now everything runs fine # timeout = 400 # timelimit = 300 # net_timeout = 100 } -----------end file----------- _/etc/raddb/users_ Next, you have to edit the /etc/raddb/users file. Freeradius will go through this file to check what to do with special users or requests. All entries have the following syntax. <username> <items to check> [<item to do>,] <item to do> If the request from the client matches the first line, radius will do the following line(s). At the moment, I told freeradius to recognize the groups and did not configure with the right priv-level. My file looks like this: -----------file----------- DEFAULT Ldap-Group == "Cisco_RO", NAS-Identifier =~ "^as5300" Auth-Type := LDAP, Service-Type = Login, Cisco-AVPair = "shell:priv-lvl=7" DEFAULT Ldap-Group == "Cisco_RW", NAS-IP-Address =~ "^192\.168\.21\.[0-9]+$" Auth-Type := LDAP, Service-Type = Login, Cisco-AVPair = "shell:priv-lvl=15" DEFAULT Auth-Type := Reject Reply-Message = "Access denied." -----------end file----------- "DEFAULT" matches all users. First match counts. In my example, all users are checked if they are member of the group "Cisco-RO". If so, other items will not be checked (you have to add "PassTrough = yes"). In the above example it's not a good idea to put members of "Cisco_RW" also in the group "Cisco_RO". In this case, radius will never come to "Cisco_RW". Again, first match. First entry only matches NAS-devices which begin with as5300, in the second only devices from 192.168.21.0 up to 192.168.21.9. If you need assistance in the regular expressions, take a look at "man grep". _/etc/raddb/clients.conf_ -----------file----------- client 127.0.0.1 { secret = default_secret shortname = localhost } client 192.168.0.0/16 { secret = secret shortname = network } -----------end file----------- All clients authenticating against freeradius need to have the (shared) secret as the server. You have to configure your clients. *Test it* Now start your freeradius server with the appropriate command and start some tests. Use user from your AD. Pay attention on your groups. -----------shell----------- radtest cv 'ADpassword' localhost 0 default_secret Sending Access-Request of id 227 to 127.0.0.1:1812 User-Name = "cv" User-Password = "ADpassword" NAS-IP-Address = ldaptest NAS-Port = 0 rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=227, length=51 Service-Type = Login-User Cisco-AVPair = "shell:priv-lvl=15" -----------end shell----------- When you see the "Access-Accept", everything is fine :) If not, you have to start your server with the "-X" parameter for debugging. You can change the call in the script under /etc/init.d. Perhaps it's a good idea to enable the ldap-debug in the radiusd.conf. *failover* If you need some explanation, take a look at the "configurable_failover" doc. You have to enable two ldap modules: ldap ldap1 { server = "server1..." [...] } ldap ldap2 { server = "server2..." [...] } instantiate { [...] ldap1 ldap2 } authorize { [...] #ldap redundant { ldap1 { fail = 1 ok = return } ldap2 { fail = 1 ok = return } } authenticate { [...] Auth-Type LDAP { redundant { ldap1 { fail = 1 ok = return } ldap2 { fail = 1 ok = return } } } This config runs fine, even with ldap groups as long as the second server is reachable. If it fails, the request will fail. So it's not that what we want. You have to use the following workaround: In your users file you have to add an prefix for each ldap group like this: DEFAULT ldap1-Ldap-Group == "cisco-users" [...] DEFAULT ldap2-Ldap-Group == "cisco-users" [...] In this case everything works fine. But you have to add two entries in the users.

1 0

FR and Pgsql
by Paul Khavkine 17 Nov '05

17 Nov '05

Hi Folks. I'm setting up FreeRADIUS with Postgres for accounting and there's one thing i can't seem to figure out. When a Start record gets written to radacct table, AcctStopTime is not being set to anything. The field is empty. Since AcctStopTime is of type "timestamp with time zone" it does not seem to equal to NULL or '0' or anything at all. radius=# select * from radacct where acctstoptime = NULL; radacctid | acctsessionid | acctuniqueid | username | realm | nasipaddress | nasportid | nasporttype | acctstarttime | acctstoptime | acctsessiontime | acctauthentic | connectinfo_start | connectinfo_stop | acctinputoctets | acctoutputoctets | calledstationid | callingstationid | acctterminatecause | servicetype | framedprotocol | framedipaddress | acctstartdelay | acctstopdelay -----------+---------------+--------------+----------+-------+--------------+-----------+-------------+---------------+--------------+-----------------+---------------+-------------------+------------------+-----------------+------------------+-----------------+------------------+--------------------+-------------+----------------+-----------------+----------------+--------------- (0 rows) radius=# select * from radacct where acctstoptime = 0; radacctid | acctsessionid | acctuniqueid | username | realm | nasipaddress | nasportid | nasporttype | acctstarttime | acctstoptime | acctsessiontime | acctauthentic | connectinfo_start | connectinfo_stop | acctinputoctets | acctoutputoctets | calledstationid | callingstationid | acctterminatecause | servicetype | framedprotocol | framedipaddress | acctstartdelay | acctstopdelay -----------+---------------+--------------+----------+-------+--------------+-----------+-------------+---------------+--------------+-----------------+---------------+-------------------+------------------+-----------------+------------------+-----------------+------------------+--------------------+-------------+----------------+-----------------+----------------+--------------- (0 rows) How do you buidl a query to fetch a list of sessions without AcctStopTime (sessions in progress for example) ? This is on PgSQL 8.1.0. Thanx Paul

2 1

generic x99 DES parity question
by Greg Woods 16 Nov '05

16 Nov '05

I am still trying to get the rlm_x99_token to work. I am now testing with a SecureNet Key token (A "generic" in the x99passwd file). This token I know how to manually program, so I can guarantee that I know the DES key and have entered it properly in the x99passwd file. The user interface is, I enter my username and the pseudo-password "challenge" into the VPN client's authentication dialog box. A new box is presented containing the 8-digit challenge. I enter this challenge into the token and enter the response into the Password field of the dialog box. This is properly transmitted back to freeradius, but freeradius denies access each time. I think I'm pretty close, but I can't figure out what I'm doing wrong. I have used the "crcalc" program that comes with the rlm_x99_token module to verify that the calculated response to the challenge, which requires entering the DES key as stored in the x99passwd file, matches the one generated by the token and the one in the freeradius debug output, so I can rule out typing the response incorrectly. The freeradius logs do show that the correct response is presented, but access is still denied. Here is the x99.conf file (with comments stripped): x99_token { pwdfile = /etc/x99passwd syncdir = /etc/x99sync.d challenge_prompt = "Challenge: %s\n Response: " challenge_length = 8 challenge_delay = 180 softfail = 5 hardfail = 0 allow_sync = yes fast_sync = yes allow_async = yes challenge_req = "challenge" resync_req = "resync" ewindow_size = 5 ewindow2_size = 5 ewindow2_delay = 60 } Here are the logs produced by the x99 module code. I am wondering if the "incorrect parity" message is why this isn't working (I've tried a number of randomly-generated keys and they all get the parity complaint). "crcalc" also complains about the parity but nevertheless calculates the correct response. Or is there something in my config file that I'm missing? Module: Instantiated x99_token (x99_token) modcall[authorize]: module "x99_token" returns noop for request 0 rlm_x99_token: pw_present: found password attributes 2, 2 rlm_x99_token: Sending Access-Challenge. modcall[authorize]: module "x99_token" returns handled for request 1 rlm_x99_token: autz: Found response to access challenge modcall[authorize]: module "x99_token" returns ok for request 2 rad_check_password: Found Auth-Type x99_token auth: type "x99_token" rlm_x99_token: pw_present: found password attributes 2, 2 rlm_x99_token: x99_mac: DES key has incorrect parity rlm_x99_token: auth: unable to calculate async response for [woods], to challenge DISABLED modcall[authenticate]: module "x99_token" returns fail for request 2 Login incorrect (rlm_x99_token): [woods/cf229d55] (from client vpn-spare port 1051 cli 128.117.8.131) modcall[authorize]: module "x99_token" returns noop for request 3 rlm_x99_token: pw_present: found password attributes 2, 2 rlm_x99_token: Sending Access-Challenge. modcall[authorize]: module "x99_token" returns handled for request 4

1 0

Re: RE: FreeRadius EAP-TLS issue
by Hamid Salim 16 Nov '05

16 Nov '05

I used OpenSSL, what are the special attributes that you mention? is it OID? Thanks. Hamid. Guy Davies wrote: >Hi Hamid, > >What CA did you use to create the client certs? If it was OpenSSL, did >you ensure that you included the special attributes that the MS >supplicant expects? There are a few HOWTO's around and they pretty much >all reference this special value. > >If you used the M$ Certificate Services, it is automatically added. > >Rgds, > >Guy > >-----Original Message----- >From: freeradius-users-bounces(a)lists.freeradius.org >[mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of >Brian A. Seklecki >Sent: 16 November 2005 17:02 >To: Hamid Salim >Cc: freeradius-users(a)lists.freeradius.org >Subject: Re: FreeRadius EAP-TLS issue > > >If it was regular TLS, i'd tell you to "openssl s_client -connect >foo:123 -cacert /blah". > >Are you sure that you have imported and "trusted" your CA's cetificate >on both the client and the server? > >This is when I let the other guys make suggestions. > >I was just curious of EAP-TLS with client certificates was simply a way >of delivering the username to the client, letting the client >authenticate the server and the server authenticate the identity of the >client, and then providing for another password based mechanism. > >Or if certificate TLS handshake was sufficient for authorization and >authentication... > >For example, Apache SSL can be told to verify client certificates, but >htaccess would still be required. > >With SMTP, client and server SSL verification can be compelled, but for >SMTP AUTH for relay, username/password authentication would still be >required. > > >~BAS > >On Wed, 16 Nov 2005, Hamid Salim wrote: > >> It should not be asking/expecting any userid/password pair. I have >> installed the certificates on the supplicant machine which should be >> sufficient to authenticate without any password requirements. I am not > >> sure why the certs are not working??? >> >> >> Brian A. Seklecki wrote: >> >> >>> >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> >>> ...that's what I get when I try an invalid password in my EAP + Cisco >> 1200 >>> + LDAP + PEAP/MS-CHAPv2 configuration. >>> >>> Let me ask...how is the client certificate method supposed to work? >>> >>> Is the username embeded the CN/CommonName attribute of the >>> certificate >> and >>> the user is prompted for a password which you setup in authenticate >{} ? >>> >>> Is that any more secure than using PEAP/MS-CHAPv2 ? >>> >>> ~BAS >>> >>> >>> On Wed, 16 Nov 2005, Hamid Salim wrote: >>> >>>> Hi, >>>> I am just wondering if anyone has encountered the same issue. I have > >>>> set up my enviornment for EAP-TLS, with windows XP SP2 as a >supplicant. >>>> For some reason I am getting: >>>> >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>>> client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>>> >>>> complete listing is attached. I am using certificates and SSL >>>> session is created successfully, then why FreeRadius is expecting a >>>> userid/password? >>>> >>>> Any help will be appreciated. >>>> >>>> Thanks >>>> Hamid. >>>> >>>> ============= Complete Listing ================= Going to the next >>>> request Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>>> length=1247 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> >> 0x020504510d800000044716030104170b000307000304000301308202fd30820266a0 >> 03 >>>> >> 020102020102300d06092a864886f70d01010405003054310b30090603550406130255 >> 53 >>>> >> 310b3009060355040813024d413120301e060355040a13174e6f727468656173746572 >> 6e >>>> >> 20556e6976657273697479311630140603550403130d45434541757468536572766572 >> 30 >>>> >> 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b >> 30 >>>> >> 09060355040613025553310b3009060355040813024d413120301e060355040a13174e >> 6f >>>> >> 7274686561737465726e20556e69766572736974793112301006035504031309726164 >> 69 >>>> 7573 >>>> EAP-Message = >>>> >> 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b998 >> 3d >>>> >> b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399 >> c3 >>>> >> 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d >> 76 >>>> >> 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175 >> a0 >>>> >> 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d13 >> 04 >>>> >> 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e65726174 >> 65 >>>> >> 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f8281 >> 57 >>>> 2f5e >>>> EAP-Message = >>>> >> 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf37 >> 43 >>>> >> 0ee64b68e9a158a4563054310b3009060355040613025553310b300906035504081302 >> 4d >>>> >> 413120301e060355040a13174e6f7274686561737465726e20556e6976657273697479 >> 31 >>>> >> 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf330 >> 0d >>>> >> 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e >> 2d >>>> >> 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf >> 00 >>>> >> d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57da >> e0 >>>> c423 >>>> EAP-Message = >>>> >> 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f274 >> 65 >>>> >> 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000 >> f0 >>>> >> 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df >> 74 >>>> >> 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e >> 2f >>>> >> 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e >> 69 >>>> >> 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1 >> a3 >>>> >> 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5f >> dd >>>> 8f7c >>>> EAP-Message = >>>> >> 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d >> 80 >>>> >> af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf8698 >> 86 >>>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 8 >>>> modcall[authorize]: module "preprocess" returns ok for request 8 >>>> radius_xlat: >>>> >> >'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% >> Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>>> 15 >>>> modcall[authorize]: module "auth_log" returns ok for request 8 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm >NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 8 >>>> rlm_eap: EAP packet type response id 5 length 253 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 8 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 8 >>>> modcall: group authorize returns updated for request 8 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 8 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>>> chain-depth=1, error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = ECEAuthServer >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> verify return:1 >>>> chain-depth=0, >>>> error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = radiustst >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> verify return:1 >>>> TLS_accept: SSLv3 read client certificate A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>>> TLS_accept: SSLv3 read client key exchange A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>>> TLS_accept: SSLv3 read certificate verify A >>>> rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished >>>> TLS_accept: SSLv3 read finished A >>>> rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] >>>> TLS_accept: SSLv3 write change cipher spec A >>>> rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished >>>> TLS_accept: SSLv3 write finished A >>>> TLS_accept: SSLv3 flush data >>>> (other): SSL negotiation finished successfully SSL Connection >>>> Established eaptls_process returned 13 >>>> modcall[authenticate]: module "eap" returns handled for request 8 >>>> modcall: group authenticate returns handled for request 8 Sending >>>> Access-Challenge of id 71 to 129.10.56.156:6001 >>>> EAP-Message = >>>> >> 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9 >> c2 >>>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Finished request 8 >>>> Going to the next request >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 9 >>>> modcall[authorize]: module "preprocess" returns ok for request 9 >>>> radius_xlat: >>>> >> >'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% >> Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>>> 15 >>>> modcall[authorize]: module "auth_log" returns ok for request 9 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm >NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 9 >>>> rlm_eap: EAP packet type response id 6 length 33 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 9 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 9 >>>> modcall: group authorize returns updated for request 9 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 9 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> eaptls_process returned 7 >>>> rlm_eap_tls: Received unexpected tunneled data after successful >>>> handshake. >>>> rlm_eap: Handler failed in EAP/tls >>>> rlm_eap: Failed in EAP select >>>> modcall[authenticate]: module "eap" returns invalid for request 9 >>>> modcall: group authenticate returns invalid for request 9 >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>>> client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for > >>>> 1 seconds Finished request 9 Going to the next request Waking up in >>>> 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>>> EAP-Message = 0x04060004 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> --- Walking the entire request list --- Waking up in 1 seconds... >>>> --- Walking the entire request list --- Cleaning up request 5 ID 68 >>>> with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp >>>> 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d >>>> Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up >>>> request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping >>>> until we see a request. >>>> - >>>> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html >>>> >>> >>> l8* >>> -lava >>> >>> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >>> >> > >l8* > -lava > >x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >- >List info/subscribe/unsubscribe? See >http://www.freeradius.org/list/users.html > >This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. > > >

1 0

RE: FreeRadius EAP-TLS issue
by Guy Davies 16 Nov '05

16 Nov '05

Hi Hamid, What CA did you use to create the client certs? If it was OpenSSL, did you ensure that you included the special attributes that the MS supplicant expects? There are a few HOWTO's around and they pretty much all reference this special value. If you used the M$ Certificate Services, it is automatically added. Rgds, Guy -----Original Message----- From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Brian A. Seklecki Sent: 16 November 2005 17:02 To: Hamid Salim Cc: freeradius-users(a)lists.freeradius.org Subject: Re: FreeRadius EAP-TLS issue If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 -cacert /blah". Are you sure that you have imported and "trusted" your CA's cetificate on both the client and the server? This is when I let the other guys make suggestions. I was just curious of EAP-TLS with client certificates was simply a way of delivering the username to the client, letting the client authenticate the server and the server authenticate the identity of the client, and then providing for another password based mechanism. Or if certificate TLS handshake was sufficient for authorization and authentication... For example, Apache SSL can be told to verify client certificates, but htaccess would still be required. With SMTP, client and server SSL verification can be compelled, but for SMTP AUTH for relay, username/password authentication would still be required. ~BAS On Wed, 16 Nov 2005, Hamid Salim wrote: > It should not be asking/expecting any userid/password pair. I have > installed the certificates on the supplicant machine which should be > sufficient to authenticate without any password requirements. I am not > sure why the certs are not working??? > > > Brian A. Seklecki wrote: > > >> >> rlm_eap_tls: Received unexpected tunneled data after successful >> handshake. >> >> ...that's what I get when I try an invalid password in my EAP + Cisco > 1200 >> + LDAP + PEAP/MS-CHAPv2 configuration. >> >> Let me ask...how is the client certificate method supposed to work? >> >> Is the username embeded the CN/CommonName attribute of the >> certificate > and >> the user is prompted for a password which you setup in authenticate {} ? >> >> Is that any more secure than using PEAP/MS-CHAPv2 ? >> >> ~BAS >> >> >> On Wed, 16 Nov 2005, Hamid Salim wrote: >> >>> Hi, >>> I am just wondering if anyone has encountered the same issue. I have >>> set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. >>> For some reason I am getting: >>> >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>> client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>> >>> complete listing is attached. I am using certificates and SSL >>> session is created successfully, then why FreeRadius is expecting a >>> userid/password? >>> >>> Any help will be appreciated. >>> >>> Thanks >>> Hamid. >>> >>> ============= Complete Listing ================= Going to the next >>> request Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>> length=1247 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> > 0x020504510d800000044716030104170b000307000304000301308202fd30820266a0 > 03 >>> > 020102020102300d06092a864886f70d01010405003054310b30090603550406130255 > 53 >>> > 310b3009060355040813024d413120301e060355040a13174e6f727468656173746572 > 6e >>> > 20556e6976657273697479311630140603550403130d45434541757468536572766572 > 30 >>> > 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b > 30 >>> > 09060355040613025553310b3009060355040813024d413120301e060355040a13174e > 6f >>> > 7274686561737465726e20556e69766572736974793112301006035504031309726164 > 69 >>> 7573 >>> EAP-Message = >>> > 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b998 > 3d >>> > b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399 > c3 >>> > 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d > 76 >>> > 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175 > a0 >>> > 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d13 > 04 >>> > 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e65726174 > 65 >>> > 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f8281 > 57 >>> 2f5e >>> EAP-Message = >>> > 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf37 > 43 >>> > 0ee64b68e9a158a4563054310b3009060355040613025553310b300906035504081302 > 4d >>> > 413120301e060355040a13174e6f7274686561737465726e20556e6976657273697479 > 31 >>> > 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf330 > 0d >>> > 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e > 2d >>> > 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf > 00 >>> > d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57da > e0 >>> c423 >>> EAP-Message = >>> > 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f274 > 65 >>> > 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000 > f0 >>> > 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df > 74 >>> > 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e > 2f >>> > 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e > 69 >>> > 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1 > a3 >>> > 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5f > dd >>> 8f7c >>> EAP-Message = >>> > 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d > 80 >>> > af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf8698 > 86 >>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 8 >>> modcall[authorize]: module "preprocess" returns ok for request 8 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% > Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>> 15 >>> modcall[authorize]: module "auth_log" returns ok for request 8 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 8 >>> rlm_eap: EAP packet type response id 5 length 253 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 8 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 8 >>> modcall: group authorize returns updated for request 8 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 8 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>> chain-depth=1, error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = ECEAuthServer >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> chain-depth=0, >>> error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = radiustst >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> TLS_accept: SSLv3 read client certificate A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>> TLS_accept: SSLv3 read client key exchange A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>> TLS_accept: SSLv3 read certificate verify A >>> rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished >>> TLS_accept: SSLv3 read finished A >>> rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] >>> TLS_accept: SSLv3 write change cipher spec A >>> rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished >>> TLS_accept: SSLv3 write finished A >>> TLS_accept: SSLv3 flush data >>> (other): SSL negotiation finished successfully SSL Connection >>> Established eaptls_process returned 13 >>> modcall[authenticate]: module "eap" returns handled for request 8 >>> modcall: group authenticate returns handled for request 8 Sending >>> Access-Challenge of id 71 to 129.10.56.156:6001 >>> EAP-Message = >>> > 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9 > c2 >>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Finished request 8 >>> Going to the next request >>> Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 9 >>> modcall[authorize]: module "preprocess" returns ok for request 9 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% > Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>> 15 >>> modcall[authorize]: module "auth_log" returns ok for request 9 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 9 >>> rlm_eap: EAP packet type response id 6 length 33 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 9 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 9 >>> modcall: group authorize returns updated for request 9 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 9 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> eaptls_process returned 7 >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> rlm_eap: Handler failed in EAP/tls >>> rlm_eap: Failed in EAP select >>> modcall[authenticate]: module "eap" returns invalid for request 9 >>> modcall: group authenticate returns invalid for request 9 >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>> client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for >>> 1 seconds Finished request 9 Going to the next request Waking up in >>> 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>> EAP-Message = 0x04060004 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> --- Walking the entire request list --- Waking up in 1 seconds... >>> --- Walking the entire request list --- Cleaning up request 5 ID 68 >>> with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp >>> 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d >>> Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up >>> request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping >>> until we see a request. >>> - >>> List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html >>> >> >> l8* >> -lava >> >> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >> > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0