February 2009 - Freeradius-Users - lists.freeradius.org

Re: authenticating to ldaps/tls
by Thibault Le Meur 12 Feb '09

12 Feb '09

Peter Param a écrit : > it is an LDAP server answering on LDAPS connections (LDAP+SSL on port 636) ...but it also supports the latter even tho an acl is set to not allow port 389 > > use start_tls=no fails also, Maybe but keep it to no > it seems to have a problem with the cert and/or cert directory: > > rlm_ldap: attempting LDAP reconnection > rlm_ldap: (re)connect to ldap1.stvincents.com.au:636, authentication 0 > rlm_ldap: setting TLS mode to 1 > rlm_ldap: could not set LDAP_OPT_X_TLS option Success > ?? this is confusing... could that mean that your ldap library wasn't compiled with ssl support... I'm not sure see http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg09575.html (but this is a rather old post) > rlm_ldap: setting TLS CACert Directory to /etc/openssl/certs/ > rlm_ldap: could not set LDAP_OPT_X_TLS_CACERTDIR option to /etc/openssl/certs/ > ------------------ cacertfile = /etc/openssl/certs/SVMHS_CA_SSL_Server.cer ----------------- The doc states that tls_cacertfile is a a PEM-encoded file: I think your CAcert is a DER encoded one (extension.cer usually is). ----------- cacertdir = /etc/openssl/certs/ ----------- The doc states that tls_cacertdir is in "hash format" (see openssl verify) Also check that the directory and files are accessible/readable by the user running the radius server. My 2 cents,...

1 0

Re: authenticating to ldaps/tls
by Peter Param 12 Feb '09

12 Feb '09

it is an LDAP server answering on LDAPS connections (LDAP+SSL on port 636) ...but it also supports the latter even tho an acl is set to not allow port 389 use start_tls=no fails also, it seems to have a problem with the cert and/or cert directory: rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap1.stvincents.com.au:636, authentication 0 rlm_ldap: setting TLS mode to 1 rlm_ldap: could not set LDAP_OPT_X_TLS option Success rlm_ldap: setting TLS CACert Directory to /etc/openssl/certs/ rlm_ldap: could not set LDAP_OPT_X_TLS_CACERTDIR option to /etc/openssl/certs/ cheers Peter >>> Thibault.LeMeur(a)supelec.fr 12/02/2009 9:04 pm >>> Peter Param a écrit : > Hi all, > > I'm trying to authenticate to a LDAPS backend but failing. Any suggestions? > Is it an LDAP server answering on LDAPS connections (LDAP+SSL on port 636) or an LDAP server answering on LDAP connections that are then secured by Start-TLS (LDAP on port 389 + Start-TLS) ? These are 2 different options. > ldap people_search { > server = "ldap1.stvincents.com.au" > port = 636 > ==> This implies an ldaps server > identity = "cn=admin,o=org,c=au" > password = *** > filter = "(cn=%u)" > basedn = "ou=people,ou=darlinghurst,ou=nsw,o=schs,c=au" > tls { > tls_mode = yes > # to the LDAP database by using the StartTLS extended > # operation. > # > # The StartTLS operation is supposed to be > # used with normal ldap connections instead of > # using ldaps (port 689) connections > start_tls = yes > ==> this is not compliant with and ldaps server use start_tls=no By the way, Alan and other Gurus, I think there is a small typo in the comment: # using ldaps (port 689) connections Should be # using ldaps (port 636) connections HTH, Thibault - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been virus scanned and although no viruses were detected by the system, St Vincents & Mater Health Sydney accepts no liability for any consequential damage resulting from email containing any computer viruses. **********************************************************************

1 0

authenticating to ldaps/tls
by Peter Param 12 Feb '09

12 Feb '09

Hi all, I'm trying to authenticate to a LDAPS backend but failing. Any suggestions? My freeradius version: —------------------------ radiusd: FreeRADIUS Version 2.1.1, for host i686-pc-linux-gnu, built on Nov 21 2008 at 07:54:33 My ldap module settings: —--------------------------- ldap people_search { server = "ldap1.stvincents.com.au" port = 636 identity = "cn=admin,o=org,c=au" password = *** filter = "(cn=%u)" basedn = "ou=people,ou=darlinghurst,ou=nsw,o=schs,c=au" tls { tls_mode = yes # to the LDAP database by using the StartTLS extended # operation. # # The StartTLS operation is supposed to be # used with normal ldap connections instead of # using ldaps (port 689) connections start_tls = yes cacertfile = /etc/openssl/certs/SVMHS_CA_SSL_Server.cer <note: chained CA cert> cacertdir = /etc/openssl/certs/ #certfile = /etc/openssl/certs/spud-jr.cer # keyfile = /path/to/radius.key # randfile = /path/to/rnd # Certificate Verification requirements. Can be: # "never" (don't even bother trying) # "allow" (try, but don't fail if the cerificate # can't be verified) # "demand" (fail if the certificate doesn't verify.) # # The default is "allow" require_cert = "allow" } -X output messages: —--------------------- [people_search] performing user authorization for pparam [people_search] expand: (cn=%u) -> (cn=pparam) [people_search] expand: ou=people,ou=darlinghurst,ou=nsw,o=schs,c=au -> ou=people,ou=darlinghurst,ou=nsw,o=schs,c=au rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap1.stvincents.com.au:636, authentication 0 rlm_ldap: setting TLS mode to 1 rlm_ldap: could not set LDAP_OPT_X_TLS option Success rlm_ldap: setting TLS CACert File to /etc/openssl/certs/SVMHS_CA_SSL_Server.cer rlm_ldap: could not set LDAP_OPT_X_TLS_CACERTFILE option to /etc/openssl/certs/SVMHS_CA_SSL_Server.cer rlm_ldap: setting TLS CACert Directory to /etc/openssl/certs/ rlm_ldap: could not set LDAP_OPT_X_TLS_CACERTDIR option to /etc/openssl/certs/ rlm_ldap: starting TLS rlm_ldap: ldap_start_tls_s() rlm_ldap: could not start TLS Success rlm_ldap: (re)connection attempt failed [people_search] search failed rlm_ldap: ldap_release_conn: Release Id: 0 ++[people_search] returns fail Using Post-Auth-Type Reject WARNING: Unknown value specified for Post-Auth-Type. Cannot perform requested action. Delaying reject of request 0 for 1 seconds Going to the next request ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been virus scanned and although no viruses were detected by the system, St Vincents & Mater Health Sydney accepts no liability for any consequential damage resulting from email containing any computer viruses. **********************************************************************

2 1

Auth User update time on mysql
by Oguzhan Kayhan 12 Feb '09

12 Feb '09

Hello i am keeping session information in mysql only.. What i notice is, when a user logs in, only after a few mins i see the sql tables are updated about this user. So, if i check max-session number via sql too, user can log in a few times because, the user can not be found as online on sql side... Is there a wait limit on sql update? If so, is there a way to lower this timing?

1 0

FreeRADIUS with some HP Multifunction printers
by A.L.M.Buxey＠lboro.ac.uk 11 Feb '09

11 Feb '09

hi, I wonder if anyone can help or has seen such behaviour. We are running FreeRADIUS on site extensively - for wireless and wired authentication. the perennial issue of printers + 802.1X has raised its head again - and this time we're trying to hit it head on - configure them to use 802.1X ! (ie dont use 'MAC auth bypass', or sticky-mac with port security etc - treat them like computers) verily, we created userIDs for the printers in the Active Directory (same as normal users - and they happily use 802.1X for wifi and wired). however, we have hit a problem - when configuring some HP printers to use PEAP, it 'just doesnt work(tm)' :-( the devices in question are M5035 and M6040 MFP devices, I've attached the output of the radiusd -X after the 'ready' line - as said, this all works for other devices.... anyway, the 'interesting' line as far as i'm concerned after seeing these debugs for many years is [peap] Session established. Decoding tunneled attributes. [peap] Got something weird. [peap] Tunneled data is invalid. [eap] Handler failed in EAP/peap [eap] Failed in EAP select ++[eap] returns invalid hmmm.....I ponder if this is a PEAPv1/v2 thing going on? confirmations welcome! (can I capture the PEAP type via a debug print statement?) alan

3 6

Filter ldap group´s
by Martin Silvero 11 Feb '09

11 Feb '09

Hi my problem is I am trying to configure authentication with ldap + VLAN. according to the group the user is connected to what I want to send a VLAN, you need to know to begin testing is where I set this filter, I set in to ldap file? I already created some rules in the authorize section of inner-tunnel file: if(Ldap-Group == "xxx" && Tmp-Inreger-0 > 0) { update reply { #set VLAN attributes for that case Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-Id = 5 } #"Tmp-integer-0" is another rule that uses the Mac's customers How to configure the filter ldap groups? thanks!! and sorry for my english.

1 0

add: I Can't compile freeradius2.1.3 with RHEL4
by 张̍ 11 Feb '09

11 Feb '09

the problem is always listen.c:99:1: directives may not be used inside a macro argumentlisten.c:98:54: unterminated argument list invoking macro "rad_assert" in main/src/listen.c By the way,I have try to install 2.1.3 on serval machine with RHEL4U7 but face the same problem. _________________________________________________________________ 怎样买车票更方便？微软春节搜索，第一时间为您提供火车票信息！ http://piao.live.com/?form=PANER01

3 2

Override pam_auth in virtual server
by Markus Gaugusch 11 Feb '09

11 Feb '09

Hi, I'm using freeradius 2.1.1 (openSUSE 11.1 version). I want to implement two virtual hosts, both using pam authentication, but different pam config. According to the comments in modules/pam, pam_auth can be overridden in authorize config, but unfortunately I don't know how. I just wrote the pam_auth = radiusd_svn into the authorize (also tried authenticate) section, but got the following errors: server svn-external { modules { Module: Checking authenticate {...} for more modules to load /etc/raddb/sites-enabled/svn-extern[269]: Entry is not a reference to a module /etc/raddb/sites-enabled/svn-extern[236]: Errors parsing authenticate section. } } server svn-external { modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load /etc/raddb/sites-enabled/svn-extern[141]: Entry is not a reference to a module /etc/raddb/sites-enabled/svn-extern[68]: Errors parsing authorize section. } } Any hints? :) Markus

2 1

Enabling hashed passwords
by Andrew Gin 11 Feb '09

11 Feb '09

Hi I've trawled looking for a solution for this, but there doesn't seem to be a clearcut answer. I am using Freeradius 1.1.7. I'm trying to make it so that in the users file, passwords are stored as a SHA hash. So my users file looks like this: asdf SHA-Password == 3da541559918a808c2402bba5012f6c60b27661c When I try to login, it with the -X option, it says: rad_recv: Access-Request packet from host 127.0.0.1:3381, id=73, length=89 User-Name = "asdf" User-Password = "asdf" NAS-Identifier = "vty0" NAS-Port = 2356 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "::ffff:192.168.1.10" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "asdf", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 modcall[authorize]: module "files" returns notfound for request 0 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 0 modcall: leaving group authorize (returns ok) for request 0 auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [asdf] (from client 127.0.0.1 port 2356 cli ::ffff:192.168.1.10) Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 73 to 127.0.0.1 port 3381 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 73 with timestamp 4993eaec Nothing to do. Sleeping until we see a request. However when I change the users file to: asdf User-Password == asdf With the -X option, I can now login: rad_recv: Access-Request packet from host 127.0.0.1:3414, id=60, length=89 User-Name = "asdf" User-Password = "asdf" NAS-Identifier = "vty0" NAS-Port = 2389 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "::ffff:192.168.1.10" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "asdf", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry asdf at line 4 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "pap" returns updated for request 0 modcall: leaving group authorize (returns updated) for request 0 rad_check_password: Found Auth-Type pap auth: type "PAP" Processing the authenticate section of radiusd.conf modcall: entering group PAP for request 0 rlm_pap: login attempt with password asdf rlm_pap: Using clear text password "asdf". rlm_pap: User authenticated successfully modcall[authenticate]: module "pap" returns ok for request 0 modcall: leaving group PAP (returns ok) for request 0 Login OK: [asdf] (from client 127.0.0.1 port 2389 cli ::ffff:192.168.1.10) Sending Access-Accept of id 60 to 127.0.0.1 port 3414 Service-Type = Administrative-User Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 60 with timestamp 4993edaf Nothing to do. Sleeping until we see a request. --- Is it as simple as changing User-Password to SHA-Password? There are various solutions which require changing the pap encryption_scheme attribute but I think these were made obsolete? It is this line at which they differ: success: modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry asdf at line 4 modcall[authorize]: module "files" returns ok for request 0 modcall[authorize]: module "pap" returns updated for request 0 fail: modcall[authorize]: module "eap" returns noop for request 0 modcall[authorize]: module "files" returns notfound for request 0 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 0 I had a look in the code just to see why it was failing and file_authorize (in rlm_files.c) calls paircmp (in valuepair.c). The relevant section goes: /* * Not found, it's not a match. */ if (auth_item == NULL) { /* * Didn't find it. If we were *trying* * to not find it, then we succeeded. */ if (check_item->operator == T_OP_CMP_FALSE) return 0; else return -1; <-SHA-Password quits here } When the password is User-Password, auth_item is NOT null, processing continues. But when SHA-Password is used, it returns -1. Have I missed something obvious, or is this just a red herring? My config is quite large, but here are the relevant parts: authorize { preprocess chap mschap suffix eap files pap } authenticate { Auth-Type PAP { pap } ... } modules { pap { auto_header = yes }

2 1

outer identity anonymous is being rejected
by Godfrey Peart 11 Feb '09

11 Feb '09

My FR 2.1 is set to authenticate users via PEAP + EAP-TTLS, this works fine but some users are being rejected because their wireless client allows the setting of an outer identity: anonymous or something else, which is not a valid username. So it's being rejected. How do I get the inner identity which contains a valid username to be processed instead of the outer identity. I've seen some posts about using* Autz-type INNER* options but have merely succeded in breaking my test system when tryng it out. At present this is my users file: #If you are not in either group, no access is allowed #FreeRADIUS 2.1 #These are the groups we are checking for Lunar Building staff DEFAULT Ldap-Group == "lunar-staff" Aruba-User-Role = "employee" DEFAULT Ldap-Group == "lunar-member" Aruba-User-Role = "member" DEFAULT SQL-Group == "Guests" Aruba-User-Role = "guest" DEFAULT Ldap-group != "lunar-staff", Auth-Type := Reject DEFAULT Ldap-group != "lunar-member", Auth-Type := Reject #End

2 1