- Freeradius-Users - lists.freeradius.org

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

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

16 Nov '05

I am not sure if I completly follow: ">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?" But I used 'how to EAP/TLS' from the FreeRadius web site. It is my understanding (which may be incorrect) that I do not need a passoword. It is something real simple that i have overlooked, but ofcourse challenging to discover! Any comments/help appreciated. Hamid. Brian A. Seklecki wrote: > >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 = >>>> >> 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. >>>> - >>>> 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 >

1 0

Re: FreeRadius EAP-TLS issue
by Brian A. Seklecki 16 Nov '05

16 Nov '05

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 = >>> > 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. >>> - >>> 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

1 0

Attribute question
by Jorge Pomoro 16 Nov '05

16 Nov '05

Hi, is there an attribute for limit the numbers of connections of one user? and after the last connection no longer the user can connect thanks

1 0

[Was: Problem with rlm_mschap from CVS] rlm_mschap: Unknown expansion string
by Luca Corti 16 Nov '05

16 Nov '05

Hello, I've checked out the exec.c fixes, but now there seem to be problems with variables passwed to ntlm_auth. Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 30 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: Told to do MS-CHAPv2 for myuser with NT-Password radius_xlat: '--username=myuser' radius_xlat: Running registered xlat function of module mschap for string 'Challenge:-00' rlm_mschap: Unknown expansion string "Challenge:-00" radius_xlat: '--challenge=' radius_xlat: Running registered xlat function of module mschap for string 'NT-Response:-00' rlm_mschap: Unknown expansion string "NT-Response:-00" radius_xlat: '--nt-response=' hex decode of failed! (only got 0 bytes) Exec-Program output: Exec-Program: returned: 1 rlm_mschap: External script failed. rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 30 modcall: leaving group MS-CHAP (returns reject) for request 30 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 30 modcall: leaving group authenticate (returns reject) for request 30 auth: Failed to validate the user. PEAP: Got tunneled reply RADIUS code 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Processing from tunneled session code 0x813a1d0 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Tunneled authentication was rejected. rlm_eap_peap: FAILURE Here is my ntlm_auth configuration: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username={Stripped-User-Name:-%{User-Name:-None}} --challenge={mschap:Challenge:-00} --nt-response={mschap:NT-Response:-00}" thanks -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: The keyboard isn't plugged in

4 7