FreeRadius/eDirectory/802.1X authentication issue
Greetings everyone, I'm a brand new member and am hoping to find some help with a bizarre problem. First, I'm not an expert when it comes to RADIUS. I work for a school district and I inherited this setup from someone else who left the district over a year ago. I have a fair understanding of how certificates work, but I'm not an expert in that area either. Here is some background on our setup: Network: Mixture of Windows 2000/2003 and Novell NetWare 6.5 servers. FreeRADIUS v1.1.0 is running on SuSE Linux Enterprise Server 10 SP2. Wireless infrastructure: We use Aruba wireless technology, with an Aruba 2400 controller at our district office and 3 school sites (with more to come). FreeRADIUS is configured to use LDAP authentication to eDirectory, and with EAP-TLS for the wireless. Workstations use PEAP and are configured not to validate server certificates. Wireless authentication happens by first logging in to a workstation and having Windows then pass the credentials on to RADIUS and authenticating to eDirectory. I will paste relevant portions of the debug output from "radiusd -X" below. Here is a description of the bizarre problem: I have 2 user accounts; let's call them UserA and UserB. I have 2 laptops; let's call them Laptop1 and Laptop2. Laptop1 (my laptop) is a Gateway M465 with an Intel Pro/Wireless 3945ABG card. Laptop2 (one of my user's laptops) is a Dell Latitude XT with Dell Wireless 1490 Dual Band WLAN mini-card. Both are Mini-PCI cards. UserA (me) can successfully authenticate on both laptops. UserB can successfully authenticate on Laptop1, but not on Laptop2. The fact that UserA can successfully authenticate on both tells me it's not a laptop configuration issue, and the fact that UserB can successfully authenticate on Laptop1 tell me it's not a user account issue. Also, using NTRadPing (or radtest on the RADIUS server itself), I can successfully authenticate as both users, with or without the Windows DOMAIN\ in front. That leaves me with nothing to go on. I will paste the relevant sections of the debug outputs from each user on each laptop and point out where the errors are. I have even gone so far as to set up FreeRADIUS from scratch on a test Unix machine, with no luck. In the debug output I'm pasting below, the only difference I can see between Laptop1 and Laptop2 is that Laptop2 is passing credentials with the DOMAIN\ in front, where Laptop1 is not. That in itself is odd, because both laptops are joined to our Windows domain and both laptops' users log in to the domain. But in any case, that part doesn't seem to be the problem, because FreeRADIUS is stripping the DOMAIN\ part off when it passes the authentication request on to eDirectory. I even got a 3rd user and laptop in for testing, and the results were the same as with Laptop2 - UserA can authenticate successfully on Laptop3, but UserB and UserC cannot authenticate on Laptop3. The other strange thing is that if, on the XP client, I drill down in to the properties for the wireless profile and un-check the "Automatically use my Windows logon name and password" option, Windows will prompt me for credentials, and then they will be accepted! Software-wise, the only difference between Laptop1 and Laptop2 and 3 is that Laptop1 has Service Pack 2 for XP, and the other two have SP3. But that still doesn't explain the fact that UserA can successfully authenticate on all 3 laptops. Any help will be greatly appreciated. Debug output from UserA authenticating on Laptop1: rad_recv: Access-Request packet from host 20.1.3.140:32958, id=219, length=236 User-Name = "UserA" NAS-IP-Address = 20.1.3.140 NAS-Port = 1 NAS-Identifier = "20.1.3.140" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "0018DE9626C1" Called-Station-Id = "000B8640C280" Service-Type = Login-User Framed-MTU = 1100 EAP-Message = 0x020a00261900170301001b14ecbd30fd1fe2c1fd3a31b577ef8f94002d7c99243e71e0 e82f99 State = 0x3167f4c59e25cac9b6ac583bfa7fb3d0 Aruba-Essid-Name = "STAFF" Aruba-Location-Id = "TestAP" Message-Authenticator = 0xa1cbcfee4810f80e40407ef46b9d5d39 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: 'UserA' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'UserA' modcall[authorize]: module "copy.user-name" returns ok for request 8 radius_xlat: '^(host/.*)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'UserA' modcall[authorize]: module "add-dollar-sign" returns ok for request 8 radius_xlat: '^(.*[\/]+)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'UserA' modcall[authorize]: module "strip-realm-name" returns ok for request 8 modcall[authorize]: module "chap" returns noop for request 8 modcall[authorize]: module "mschap" returns noop for request 8 rlm_realm: No '@' in User-Name = "UserA", 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 10 length 38 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 DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 8 rlm_ldap: - authorize rlm_ldap: performing user authorization for UserA radius_xlat: '(cn=UserA)' radius_xlat: 't=pusd' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in t=pusd, with filter (cn=UserA) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user UserA authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 8 modcall: leaving 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/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 8 modcall: leaving group authenticate (returns ok) for request 8 Sending Access-Accept of id 219 to 20.1.3.140 port 32958 MS-MPPE-Recv-Key = 0xacee5bfc2803579cd0ff5f2b474927b528067e3bb6acb22a5439eaff089f62cb MS-MPPE-Send-Key = 0xc74619156767ed997ea2729c106a9339a89b919857e4bf804d0aeb8d3f7c8455 EAP-Message = 0x030a0004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "UserA" Finished request 8 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 210 with timestamp 48481cbd Cleaning up request 1 ID 212 with timestamp 48481cbd Cleaning up request 2 ID 213 with timestamp 48481cbd Cleaning up request 3 ID 214 with timestamp 48481cbd Cleaning up request 4 ID 215 with timestamp 48481cbd Cleaning up request 7 ID 216 with timestamp 48481cbd Cleaning up request 5 ID 217 with timestamp 48481cbd Cleaning up request 6 ID 218 with timestamp 48481cbd Cleaning up request 8 ID 219 with timestamp 48481cbd Nothing to do. Sleeping until we see a request. Debug output from UserB authenticating on Laptop1 looks the same, so I will skip posting it due to message size limits. Debug output from UserA authenticating on Laptop2 is the same as on Laptop1, so I won't paste it here either. Debug output from UserB authenticating on Laptop2: rad_recv: Access-Request packet from host 20.1.3.140:32958, id=243, length=307 User-Name = "DOMAIN\\UserB" NAS-IP-Address = 20.1.3.140 NAS-Port = 2 NAS-Identifier = "20.1.3.140" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "001FE105CE94" Called-Station-Id = "000B8640C280" Service-Type = Login-User Framed-MTU = 1100 EAP-Message = 0x020700631900170301005829c9dcbbb4696aec2f16239d4758e609a7c5e8134ec07054 e82abd940b225525b8c4af125b0fd0e3075ea216e190fe99ea4b1ab41b495eb6302d1ec3 093d645d827da48ec5b4edba302bb21c8e6f17721a3aab9d313924ca State = 0x6f3c13804ea9765ef5dfa905d68a4808 Aruba-Essid-Name = "STAFF" Aruba-Location-Id = "TestAP" Message-Authenticator = 0xaabdf4b276bf583e2e7373c80b31cf41 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 6 modcall[authorize]: module "preprocess" returns ok for request 6 radius_xlat: 'DOMAIN\\UserB' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "copy.user-name" returns ok for request 6 radius_xlat: '^(host/.*)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "add-dollar-sign" returns ok for request 6 radius_xlat: '^(.*[\/]+)' rlm_attr_rewrite: Changed value for attribute Stripped-User-Name from 'DOMAIN\\UserB' to 'UserB' modcall[authorize]: module "strip-realm-name" returns ok for request 6 modcall[authorize]: module "chap" returns noop for request 6 modcall[authorize]: module "mschap" returns noop for request 6 rlm_realm: No '@' in User-Name = "DOMAIN\UserB", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 6 rlm_eap: EAP packet type response id 7 length 99 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 6 users: Matched entry DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 6 rlm_ldap: - authorize rlm_ldap: performing user authorization for DOMAIN\UserB radius_xlat: '(cn=UserB)' radius_xlat: 't=pusd' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in t=pusd, with filter (cn=UserB) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user DOMAIN\UserB authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 6 modcall: leaving group authorize (returns updated) for request 6 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 rlm_eap_peap: Tunneled data is valid. PEAP: Setting User-Name to DOMAIN\UserB PEAP: Adding old state with 89 6c Processing the authorize section of radiusd.conf modcall: entering group authorize for request 6 modcall[authorize]: module "preprocess" returns ok for request 6 radius_xlat: 'DOMAIN\\UserB' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "copy.user-name" returns ok for request 6 radius_xlat: '^(host/.*)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "add-dollar-sign" returns ok for request 6 radius_xlat: '^(.*[\/]+)' rlm_attr_rewrite: Changed value for attribute Stripped-User-Name from 'DOMAIN\\UserB' to 'UserB' modcall[authorize]: module "strip-realm-name" returns ok for request 6 modcall[authorize]: module "chap" returns noop for request 6 modcall[authorize]: module "mschap" returns noop for request 6 rlm_realm: No '@' in User-Name = "DOMAIN\UserB", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 6 rlm_eap: EAP packet type response id 7 length 76 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 6 users: Matched entry DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 6 rlm_ldap: - authorize rlm_ldap: performing user authorization for DOMAIN\UserB radius_xlat: '(cn=UserB)' radius_xlat: 't=pusd' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in t=pusd, with filter (cn=UserB) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user DOMAIN\UserB authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 6 modcall: leaving group authorize (returns updated) for request 6 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 6 (This appears to be where the problem is) rlm_mschap: Told to do MS-CHAPv2 for UserB with NT-Password rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 6 modcall: leaving group MS-CHAP (returns reject) for request 6 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 6 modcall: leaving group authenticate (returns reject) for request 6 auth: Failed to validate the user. PEAP: Tunneled authentication was rejected. rlm_eap_peap: FAILURE modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 Sending Access-Challenge of id 243 to 20.1.3.140 port 32958 EAP-Message = 0x010800261900170301001b39a19f38fd5c0b590dbba6327b62b4410446d5c8341d1831 b1dea1 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x7421d199fd849fb3bbcd35bd05c281b1 Finished request 6 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 20.1.3.140:32958, id=244, length=246 User-Name = "DOMAIN\\UserB" NAS-IP-Address = 20.1.3.140 NAS-Port = 2 NAS-Identifier = "20.1.3.140" NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "001FE105CE94" Called-Station-Id = "000B8640C280" Service-Type = Login-User Framed-MTU = 1100 EAP-Message = 0x020800261900170301001bf3eab0cca7796ad13f102214334fada4a48b4ea56c555b31 27decb State = 0x7421d199fd849fb3bbcd35bd05c281b1 Aruba-Essid-Name = "STAFF" Aruba-Location-Id = "TestAP" Message-Authenticator = 0x2458e54cc6a52e081b42407e963f6571 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 7 modcall[authorize]: module "preprocess" returns ok for request 7 radius_xlat: 'DOMAIN\\UserB' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "copy.user-name" returns ok for request 7 radius_xlat: '^(host/.*)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'DOMAIN\\UserB' modcall[authorize]: module "add-dollar-sign" returns ok for request 7 radius_xlat: '^(.*[\/]+)' rlm_attr_rewrite: Changed value for attribute Stripped-User-Name from 'DOMAIN\\UserB' to 'UserB' modcall[authorize]: module "strip-realm-name" returns ok for request 7 modcall[authorize]: module "chap" returns noop for request 7 modcall[authorize]: module "mschap" returns noop for request 7 rlm_realm: No '@' in User-Name = "DOMAIN\UserB", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 7 rlm_eap: EAP packet type response id 8 length 38 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 7 users: Matched entry DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 7 rlm_ldap: - authorize rlm_ldap: performing user authorization for DOMAIN\UserB radius_xlat: '(cn=UserB)' radius_xlat: 't=pusd' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in t=pusd, with filter (cn=UserB) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user DOMAIN\UserB authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 7 modcall: leaving group authorize (returns updated) for request 7 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 7 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. (Another problem here) rlm_eap_peap: Had sent TLV failure, rejecting. rlm_eap: Handler failed in EAP/peap rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 7 modcall: leaving group authenticate (returns invalid) for request 7 auth: Failed to validate the user. Delaying request 7 for 1 seconds Finished request 7 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 20.1.3.140:32958, id=244, length=246 Sending Access-Reject of id 244 to 20.1.3.140 port 32958 EAP-Message = 0x04080004 Message-Authenticator = 0x00000000000000000000000000000000 --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 237 with timestamp 48481e9b Cleaning up request 1 ID 238 with timestamp 48481e9b Cleaning up request 2 ID 239 with timestamp 48481e9b Cleaning up request 5 ID 240 with timestamp 48481e9b Cleaning up request 3 ID 241 with timestamp 48481e9b Cleaning up request 4 ID 242 with timestamp 48481e9b Cleaning up request 6 ID 243 with timestamp 48481e9b Cleaning up request 7 ID 244 with timestamp 48481e9b Nothing to do. Sleeping until we see a request. Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 UserA@powayusd.com <mailto:bnewall@powayusd.com>
rlm_mschap: Told to do MS-CHAPv2 for UserB with NT-Password
rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
(Cached) password for that user on that laptop is wrong. Changing that wrong password will require a bit of registry hacking: http://support.microsoft.com/default.aspx?scid=kb;en-us;823731 Ivan Kalik Kalik Informatika ISP
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Ivan Kalik Sent: Tuesday, June 10, 2008 5:35 PM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
rlm_mschap: Told to do MS-CHAPv2 for UserB with NT-Password
rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
(Cached) password for that user on that laptop is wrong.
No, it's not. The laptop is not storing the password; it's using the login credentials each time. The "Use Windows login credentials" (or whatever it's called; can't remember off the top of my head) option is checked. In fact, if I un-check it and have Windows prompt me for the credentials, then the authentication works properly! (With or without the domain name.) And it's the same username/password that I use to log on to the laptop. It's very strange that it works fine when I have Windows prompt for the credentials, but won't when I have it use the login credentials. Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
Hi,
No, it's not. The laptop is not storing the password; it's using the login credentials each time. The "Use Windows login credentials" (or whatever it's called; can't remember off the top of my head) option is checked. In fact, if I un-check it and have Windows prompt me for the credentials, then the authentication works properly! (With or without the domain name.) And it's the same username/password that I use to log on to the laptop. It's very strange that it works fine when I have Windows prompt for the credentials, but won't when I have it use the login credentials.
thats because it IS cached - it gets cached in a different HIVE area. still an EAPOL though. this is proved by what you've just stated. run a regedit and look for lurking EAPOL. the RADIUS logs dont lie. alan
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Tuesday, June 10, 2008 11:08 PM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
Hi,
on to the laptop. It's very strange that it works fine when I have Windows prompt for the credentials, but won't when I have it use the login credentials.
thats because it IS cached - it gets cached in a different HIVE area. still an EAPOL though. this is proved by what you've just stated. run a regedit and look for lurking EAPOL. the RADIUS logs dont lie.
I'll take another look if I can get my hands on the laptop again. But it still doesn't make sense that a different user (me) has no problem logging in. Plus, these laptops were brand new, and when I tested User3's account on User2's laptop and vice versa, I had the same problem. That was the first time either user had logged in to the other's laptop, and I know I logged in with the correct password; otherwise, I wouldn't have been able to log in to Novell or Windows. Yet, they would still fail to authenticate wirelessly. I'm convinced that it has SOMETHING to do with how Windows is passing the credentials through to FreeRadius, rather than a FreeRadius problem; I'm just not sure where to troubleshoot. Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
Newall, Bryce wrote:
I'm convinced that it has SOMETHING to do with how Windows is passing the credentials through to FreeRadius, rather than a FreeRadius problem; I'm just not sure where to troubleshoot.
You'll know from reading this list where *my* biases are. For most problem interactions with external devices, it's usually the external devices that are buggy. For behavior that's internal to the server, it's often administrator misconfiguration. For some rare cases, it's a FreeRADIUS bug. Alan DeKok.
On Tue, Jun 10, 2008 at 07:32:45PM -0700, Newall, Bryce wrote:
login credentials each time. The "Use Windows login credentials" (or whatever it's called; can't remember off the top of my head) option is checked. In fact, if I un-check it and have Windows prompt me for the credentials, then the authentication works properly! (With or without
reset the users profile. we've had the same problem here and that fixed it.
the domain name.) And it's the same username/password that I use to log on to the laptop. It's very strange that it works fine when I have Windows prompt for the credentials, but won't when I have it use the login credentials.
Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Wednesday, June 11, 2008 2:00 AM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
On Tue, Jun 10, 2008 at 07:32:45PM -0700, Newall, Bryce wrote:
login credentials each time. The "Use Windows login credentials" (or whatever it's called; can't remember off the top of my head) option is checked. In fact, if I un-check it and have Windows prompt me for the credentials, then the authentication works properly! (With or without
reset the users profile. we've had the same problem here and that fixed it.
Tried that first thing; no luck, unfortunately. And again, these were brand new laptops with brand new profiles, so that shouldn't have mattered, but I did it anyway just to be safe. I am looking into setting up a test RADIUS server with FreeRADIUS 2.0.5, since the current server is running 1.1.0. As I mentioned before, though, I don't know a lot about RADIUS, and would love to find some HOW-TO's to help me make it work. We need to have FreeRADIUS speak LDAP with Novell eDirectory, and be able to authenticate wireless clients using EAP-TLS (or even EAP-TTLS, but we're using TLS right now). Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
Newall, Bryce wrote:
I am looking into setting up a test RADIUS server with FreeRADIUS 2.0.5, since the current server is running 1.1.0. As I mentioned before, though, I don't know a lot about RADIUS, and would love to find some HOW-TO's to help me make it work.
As would I. This isn't a RADIUS thing. It's a Windows thing. FreeRADIUS is at the mercy of the Windows system, which is doing weird things. And that's not just me blaming everything on other people's software. There's really no other conclusion possible from your description.
We need to have FreeRADIUS speak LDAP with Novell eDirectory, and be able to authenticate wireless clients using EAP-TLS (or even EAP-TTLS, but we're using TLS right now).
Er... EAP-TLS means that it won't normally do user lookups in LDAP. And you should ugprade to 2.0.5. It makes 1.1.0 look as bad as IAS. Alan DeKok.
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, June 11, 2008 10:30 AM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
We need to have FreeRADIUS speak LDAP with Novell eDirectory, and be able to authenticate wireless clients using EAP-TLS (or even EAP-TTLS, but we're using TLS right now).
Er... EAP-TLS means that it won't normally do user lookups in LDAP.
See why I say I don't know a whole lot about how all this works?? :) So it sounds like I don't even need LDAP, but it's helpful for at least testing the RADIUS configuration with a program like NTRadPing to make sure it's working correctly before jumping into the EAP-TLS setup.
And you should ugprade to 2.0.5. It makes 1.1.0 look as bad as IAS.
SLES 10 SP2 still ships with FreeRADIUS 1.1.0. Go figure. Any suggestions as to where to find some good HOWTO docs? I went through the FreeRADIUS Wiki, but it wasn't very complete. Thanks! Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
Newall, Bryce wrote:
See why I say I don't know a whole lot about how all this works?? :) So it sounds like I don't even need LDAP, but it's helpful for at least testing the RADIUS configuration with a program like NTRadPing to make sure it's working correctly before jumping into the EAP-TLS setup.
Yes.
And you should ugprade to 2.0.5. It makes 1.1.0 look as bad as IAS.
SLES 10 SP2 still ships with FreeRADIUS 1.1.0. Go figure. Any suggestions as to where to find some good HOWTO docs? I went through the FreeRADIUS Wiki, but it wasn't very complete.
The configuration files that the server comes with are pretty complete. To be honest, it's pretty much impossible to write any good HOWTO's for RADIUS. With tiny edits (as documented and explained in the configs), the default configuration works with PAP, CHAP, MS-CHAP, Digest, EAP-MD5, EAP-MSCHAPv2, PEAP, EAP-TTLS.... Follow the explanations in the config files, and add support for LDAP, SQL, ... Any HOWTO will be not much more than "read the config files, and follow their instructions". Alan DeKok.
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, June 11, 2008 1:14 PM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
Newall, Bryce wrote:
See why I say I don't know a whole lot about how all this works?? :) So it sounds like I don't even need LDAP, but it's helpful for at least testing the RADIUS configuration with a program like NTRadPing to make sure it's working correctly before jumping into the EAP-TLS setup.
Yes.
Dumb question perhaps, but without configuring LDAP, how does EAP-TLS know where to send authentication requests? Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
Dumb question perhaps, but without configuring LDAP, how does EAP-TLS know where to send authentication requests?
EAP-TLS is certificate based authentication. All you need in order to get authenticated is a valid certificate. Do you mean authorization? Ivan Kalik Kalik Informatika ISP
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Ivan Kalik Sent: Thursday, June 12, 2008 12:20 PM To: FreeRadius users mailing list Subject: RE: FreeRadius/eDirectory/802.1X authentication issue
Dumb question perhaps, but without configuring LDAP, how does EAP-TLS know where to send authentication requests?
EAP-TLS is certificate based authentication. All you need in order to get authenticated is a valid certificate. Do you mean authorization?
Ahh, your answer just made our current RADIUS configuration more understandable to me! As I may have mentioned, I inherited this setup from someone else who left the district. The way it is currently working, we do not have to install certificates on a laptop. The "Validate server certificate" option on our laptops' wireless configuration is turned off. The idea was to keep it as simple as possible for users, yet maintain some semblance of security. Apparently, the way we're doing it right now is using EAP-TLS with PEAP authentication, which is passing the user's credentials through an encrypted tunnel to the RADIUS server, which is in turn passing the credentials through to eDirectory via LDAP. At least, I *think* I'm explaining that correctly. :) I'd like to maintain that setup with FreeRADIUS 2.0.5, but I'm still having a hard time following the configuration and authentication path with the current 1.1.0 setup. Thanks! Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
See why I say I don't know a whole lot about how all this works?? :) So it sounds like I don't even need LDAP, but it's helpful for at least
I know it is possible to use EAP-TLS, and then use some attribute from the certificate and query LDAP about it. If that's the case in your configuration, you should be able to see that from the config files in your $raddb directory. You can post the config if you have questions. Matt On Wed, Jun 11, 2008 at 6:44 PM, Newall, Bryce <bnewall@powayusd.com> wrote:
-----Original Message----- From: freeradius-users-bounces+bnewall=powayusd.com@lists.freeradius.org [mailto:freeradius-users- bounces+bnewall=powayusd.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, June 11, 2008 10:30 AM To: FreeRadius users mailing list Subject: Re: FreeRadius/eDirectory/802.1X authentication issue
We need to have FreeRADIUS speak LDAP with Novell eDirectory, and be able to authenticate wireless clients using EAP-TLS (or even EAP-TTLS, but we're using TLS right now).
Er... EAP-TLS means that it won't normally do user lookups in LDAP.
See why I say I don't know a whole lot about how all this works?? :) So it sounds like I don't even need LDAP, but it's helpful for at least testing the RADIUS configuration with a program like NTRadPing to make sure it's working correctly before jumping into the EAP-TLS setup.
And you should ugprade to 2.0.5. It makes 1.1.0 look as bad as IAS.
SLES 10 SP2 still ships with FreeRADIUS 1.1.0. Go figure. Any suggestions as to where to find some good HOWTO docs? I went through the FreeRADIUS Wiki, but it wasn't very complete.
Thanks!
Bryce Newall Systems Administrator Poway Unified School District (858) 679-2576 bnewall@powayusd.com
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
A.L.M.Buxey@lboro.ac.uk -
Alan DeKok -
Ivan Kalik -
Matt Causey -
Newall, Bryce -
Phil Mayers