how to limit the repeating ldap lookups
Hi. Is it possible to limit the repeating ldap lookups that happen during mschap and tls negotiations? Like having an attribute that I could test for which would tell me that the negotiation is completed? thanks martin
On 26 Aug 2013, at 14:33, Martin Kraus <lists_mk@wujiman.net> wrote:
Hi. Is it possible to limit the repeating ldap lookups that happen during mschap and tls negotiations? Like having an attribute that I could test for which would tell me that the negotiation is completed?
If you list the ldap module after the eap module in the default configuration then the default config already does this. You may also want to consider using the rlm_cache module. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Mon, Aug 26, 2013 at 02:45:29PM +0100, Arran Cudbard-Bell wrote:
Is it possible to limit the repeating ldap lookups that happen during mschap and tls negotiations? Like having an attribute that I could test for which would tell me that the negotiation is completed?
If you list the ldap module after the eap module in the default configuration then the default config already does this.
You may also want to consider using the rlm_cache module.
I'm using TTLS+TLS. I can see that the eap { ok = return } automagically skips to the authentication section but the first two access-requests in the session cause it to return updated status so the ldap lookups are executed. I assume there isn't much I can do about that, right? I then have a separate problem with the inner-tunnel where the inner-eap never returns ok in the authorization section so it keeps on doing the ldap lookups. in the session I have it did 9 separate passes which together with the outer tunnel is 11 ldap passes which in my case is more then 30 ldap lookups for a single user login. There are also these warnings in inner-tunnel WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0xfa098d01f80a8033 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! but the inner tls session seems to be still progressing fine since the last warning is right before the last access-request which results in the access-accept for the user. Is there something I can do about the 9 lookups in the inner-tunnel server? I'll have a look at the rlm_cache as well but I'm just curious as to why is it happening. thanks Martin
Martin Kraus wrote:
I'm using TTLS+TLS.
Then what are you looking up in ldap?
I can see that the eap { ok = return } automagically skips to the authentication section but the first two access-requests in the session cause it to return updated status so the ldap lookups are executed. I assume there isn't much I can do about that, right?
Sure. You can look at the debug output, see what's different between packets N and N+1, and use those differences to selectively run ldap.
I then have a separate problem with the inner-tunnel where the inner-eap never returns ok in the authorization section so it keeps on doing the ldap lookups. in the session I have it did 9 separate passes which together with the outer tunnel is 11 ldap passes which in my case is more then 30 ldap lookups for a single user login.
Again, look at the debug output.
There are also these warnings in inner-tunnel
WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0xfa098d01f80a8033 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
but the inner tls session seems to be still progressing fine since the last warning is right before the last access-request which results in the access-accept for the user.
Read it again. The ONLY time that message is produced is when the EAP session doesn't finish. There are likely 2-3 failed attempts before one success. If you only look at the succes...
Is there something I can do about the 9 lookups in the inner-tunnel server? I'll have a look at the rlm_cache as well but I'm just curious as to why is it happening.
Because that's what you told it to do. The server is pretty dumb that way. Again, look at the debug log to see what's happening. *WHY* are you doing LDAP lookups at all? Can you not delay them? And rlm_cache should help a lot, too. Alan DeKok.
On Tue, Aug 27, 2013 at 05:20:32PM -0400, Alan DeKok wrote:
Again, look at the debug log to see what's happening. *WHY* are you doing LDAP lookups at all? Can you not delay them?
Hi. I'm using groups to authorize users and pull radius profiles for the users. My config is similar to what the default freeradius configuration offers.
And rlm_cache should help a lot, too.
I'm stuck with 2.1.10 on ubuntu:-( Anyway I managed to filter out most of the redundant ldap lookups. the only thing I'm stuck with are lookups during TLS negotiation either in the default server for EAP-TLS or in the inner-tunnel server for EAP-TTLS/EAP-TLS. The handshake takes 8 access-requests and the only way I can see to filter it out is to somehow findout if the EAP-Message AVPs contain something to tell me whether it's about to be done or not. for EAP-TTLS and PEAP the eap module in authorize section returns "ok" which jumps out of the authorize section so the eap module in the authentication section can process it. But for EAP-TLS it returns "handled" so the whole authorize section gets parsed. mk
On 28.08.2013 00:20, Martin Kraus wrote:
On Tue, Aug 27, 2013 at 05:20:32PM -0400, Alan DeKok wrote:
Again, look at the debug log to see what's happening. *WHY* are you doing LDAP lookups at all? Can you not delay them?
Hi. I'm using groups to authorize users and pull radius profiles for the users. My config is similar to what the default freeradius configuration offers.
And rlm_cache should help a lot, too.
I'm stuck with 2.1.10 on ubuntu:-(
Anyway I managed to filter out most of the redundant ldap lookups. the only thing I'm stuck with are lookups during TLS negotiation either in the default server for EAP-TLS or in the inner-tunnel server for EAP-TTLS/EAP-TLS. The handshake takes 8 access-requests and the only way I can see to filter it out is to somehow findout if the EAP-Message AVPs contain something to tell me whether it's about to be done or not.
I'm just quoting a mail from Phil Mayers a few months ago on this list. It contains a check that allows to run the checks in authorize only after the EAP tunnel is established. (Use it only in v2). And remove ldap from the outer tunnel, you don't need it there anyway. -----
..and save some more hits to LDAP by wrapping the call to it in the authorization stage to just the EAP Identity packet
He he he... if I recall correctly I came up with something like: server inner-tunnel { authorize { eap # stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message[0] =~ /^0x02..00061a..$/)) { noop } else { # rest of config goes here } } } For complete thread : http://lists.freeradius.org/pipermail/freeradius-users/2013-June/067100.html Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
On 28.08.2013 9:48, Olivier Beytrison wrote:
On 28.08.2013 00:20, Martin Kraus wrote:
Hi. I'm using groups to authorize users and pull radius profiles for the users. My config is similar to what the default freeradius configuration offers.
Why not just call rlm_ldap from inner-tunnel post-auth section? This will ensure it called only once and only if inner-tunnel authentication succeeds.
On Wed, Aug 28, 2013 at 10:10:32AM +0400, Iliya Peregoudov wrote:
On 28.08.2013 9:48, Olivier Beytrison wrote:
On 28.08.2013 00:20, Martin Kraus wrote:
Hi. I'm using groups to authorize users and pull radius profiles for the users. My config is similar to what the default freeradius configuration offers.
Why not just call rlm_ldap from inner-tunnel post-auth section? This will ensure it called only once and only if inner-tunnel authentication succeeds.
I used to use mschapv2 for authentication so I had to lookup passwords in the authorize section. I'm not sure what would happen if I moved the lookups to post-auth so I'll need to setup some testing environment for it. mk
On Wed, Aug 28, 2013 at 07:48:38AM +0200, Olivier Beytrison wrote:
server inner-tunnel { authorize { eap
# stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message[0] =~ /^0x02..00061a..$/)) { noop } else { # rest of config goes here } } }
The hack I'm currently using for EAP-TLS based on rfc 5216 # EAP-Message - byte 0 = 2 for EAP-Response # byte 1 = Identifier # byte 2-3 = EAP-Message Length including header (for EAP-TLS minimum 6 bytes) # byte 4 = EAP-Type, EAP-TLS = 0x0d (13) # byte 5 = FLAGS (L,M,[SR],R,R,R,R,R) # byte 6-9 = TLS message length (optional if Flag L set) # byte 10+ = TLS data # Empty EAP-Messages are used to acknowledge EAP-Request fragments or are the last message # the client sends at the end of TLS handshake signaling the server has been authenticated # # We would like to do ldap lookups only on the last empty EAP-Message -> not really possible # But we can skip first few empty messages based on the Identifier field if the client # starts at 0x01. If not the we'll have to match all the empty EAP-Message ^0x02..00060d00$ # EAP-Response identifier is copied from the EAP-Request, so the starting point is determined # by NAS asking for EAP-Identity. # # usually 0x01 is the EAP-Identity, 0x02 is NACK to our offered PEAP, 0x03 is the client_hello, # 0x04-0x06 are the EAP-Response that ack server side of the handshake so we skip the first 6 # EAP-Response packets from the client. This is a heuristic, might not work if ( (EAP-Type == EAP-TLS) && (EAP-Message !~ /^0x02([1-9a-f].|0[7-9a-f])00060d00$/) ) { default = return } mk
On 28 Aug 2013, at 14:35, Martin Kraus <lists_mk@wujiman.net> wrote:
On Wed, Aug 28, 2013 at 07:48:38AM +0200, Olivier Beytrison wrote:
server inner-tunnel { authorize { eap
# stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message[0] =~ /^0x02..00061a..$/)) { noop } else { # rest of config goes here } } }
The hack I'm currently using for EAP-TLS based on rfc 5216
# EAP-Message - byte 0 = 2 for EAP-Response # byte 1 = Identifier # byte 2-3 = EAP-Message Length including header (for EAP-TLS minimum 6 bytes) # byte 4 = EAP-Type, EAP-TLS = 0x0d (13) # byte 5 = FLAGS (L,M,[SR],R,R,R,R,R) # byte 6-9 = TLS message length (optional if Flag L set) # byte 10+ = TLS data # Empty EAP-Messages are used to acknowledge EAP-Request fragments or are the last message # the client sends at the end of TLS handshake signaling the server has been authenticated # # We would like to do ldap lookups only on the last empty EAP-Message -> not really possible # But we can skip first few empty messages based on the Identifier field if the client # starts at 0x01. If not the we'll have to match all the empty EAP-Message ^0x02..00060d00$ # EAP-Response identifier is copied from the EAP-Request, so the starting point is determined # by NAS asking for EAP-Identity. # # usually 0x01 is the EAP-Identity, 0x02 is NACK to our offered PEAP, 0x03 is the client_hello, # 0x04-0x06 are the EAP-Response that ack server side of the handshake so we skip the first 6 # EAP-Response packets from the client. This is a heuristic, might not work if ( (EAP-Type == EAP-TLS) && (EAP-Message !~ /^0x02([1-9a-f].|0[7-9a-f])00060d00$/) ) { default = return }
Does anyone have a configuration which gets it down to a single LDAP query for PEAP? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 28 Aug 2013, at 15:01, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 14:49, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
What inner?
MSHCAPv2 - I thought PEAPv0 was only MSCHAPv2? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Wed, Aug 28, 2013 at 03:11:04PM +0100, Arran Cudbard-Bell wrote:
On 28 Aug 2013, at 15:01, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 14:49, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
What inner?
MSHCAPv2 - I thought PEAPv0 was only MSCHAPv2?
and TLS. m. -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 28 Aug 2013, at 15:26, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Wed, Aug 28, 2013 at 03:11:04PM +0100, Arran Cudbard-Bell wrote:
On 28 Aug 2013, at 15:01, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 14:49, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
What inner?
MSHCAPv2 - I thought PEAPv0 was only MSCHAPv2?
and TLS.
Fine, yes, also TLS. But in the wonderful world of Microsoft supplicants PEAP usually specifies PEAP with and MSCHAPv2 inner? and wow did they get rid of the 802.1X profile configuration GUI interface in OSX 10.8? That sucks. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Yes, Alan B had some comments about that IIRC... I think Apple these days expect administrators to use the Apple iPhone Configuration Utility to create a network profile and import that into your 802.1X settings. Bizarre, but there you are. Stefan
-----Original Message----- Fine, yes, also TLS. But in the wonderful world of Microsoft supplicants PEAP usually specifies PEAP with and MSCHAPv2 inner?
and wow did they get rid of the 802.1X profile configuration GUI interface in OSX 10.8? That sucks.
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On Wed, Aug 28, 2013 at 03:42:08PM +0100, Arran Cudbard-Bell wrote:
Fine, yes, also TLS. But in the wonderful world of Microsoft supplicants PEAP usually specifies PEAP with and MSCHAPv2 inner?
Windows 7 supports PEAP+TLS. Unline Network Manager on linux distributions.
and wow did they get rid of the 802.1X profile configuration GUI interface in OSX 10.8? That sucks.
Nope. that profile configuration is still required. mk
On 28/08/13 15:11, Arran Cudbard-Bell wrote:
On 28 Aug 2013, at 15:01, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 14:49, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
What inner?
MSHCAPv2 - I thought PEAPv0 was only MSCHAPv2?
Apparently not; you can apparently run EAP-TLS inside PEAP, which is a new one on me. For PEAP/MSCHAP, under 2.x the link someone posted to my horrible hack works. Or under 3.x, "eap { ok = return }" in the inner-tunnel also works.
On 28 Aug 2013, at 15:38, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 15:11, Arran Cudbard-Bell wrote:
On 28 Aug 2013, at 15:01, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/08/13 14:49, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
What inner?
MSHCAPv2 - I thought PEAPv0 was only MSCHAPv2?
Apparently not; you can apparently run EAP-TLS inside PEAP, which is a new one on me.
For PEAP/MSCHAP, under 2.x the link someone posted to my horrible hack works. Or under 3.x, "eap { ok = return }" in the inner-tunnel also works.
OK. Just wondering if you could really get it down to a single lookup, IIRC you needed the 'known good' NT-Password data for a couple of rounds of MSCHAPv2? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 28/08/13 15:46, Arran Cudbard-Bell wrote:
OK. Just wondering if you could really get it down to a single lookup, IIRC you needed the 'known good' NT-Password data for a couple of rounds of MSCHAPv2?
Nope, just one. The MSCHAP challenge & response arrive at you, you validate them and in turn generate the response2. You might be thinking of the first pass in EAP-MSCHAP, where the client sends EAP-identity and the server sends EAP-MSCHAP challenge, but that's stateless - just a random number. Likewise, the 3rd pass MSCHAP success/fail packet is stateless.
On Wed, Aug 28, 2013 at 03:46:53PM +0100, Arran Cudbard-Bell wrote:
Apparently not; you can apparently run EAP-TLS inside PEAP, which is a new one on me.
Has been running fine here for months. Only real benefit - SoH with EAP-TLS.
For PEAP/MSCHAP, under 2.x the link someone posted to my horrible hack works. Or under 3.x, "eap { ok = return }" in the inner-tunnel also works.
OK. Just wondering if you could really get it down to a single lookup, IIRC you needed the 'known good' NT-Password data for a couple of rounds of MSCHAPv2?
Using PEAP/EAP-TLS, we put the LDAP lookup in the TLS virtual server, where we can lookup the certificate data in LDAP. It hits once, after the cert has verified, and allows other things to deny the auth. LDAP is in the example file. See the sites-available/check-eap-tls file in v3, and the mods-available/eap file, option "virtual_server" in the "tls" section. I backported the patch I wrote to do this to v2 (which is what we are running); I'm not sure if it made it into the released 2.x code (I doubt it). It's an easy patch it anyone wants to do it themselves. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Wed, Aug 28, 2013 at 04:49:42PM +0100, Matthew Newton wrote:
See the sites-available/check-eap-tls file in v3, and the mods-available/eap file, option "virtual_server" in the "tls" section.
I backported the patch I wrote to do this to v2 (which is what we are running); I'm not sure if it made it into the released 2.x code (I doubt it). It's an easy patch it anyone wants to do it themselves.
I just checked - it's in v2 HEAD. See tls section of eap.conf. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Wed, Aug 28, 2013 at 03:46:53PM +0100, Arran Cudbard-Bell wrote:
OK. Just wondering if you could really get it down to a single lookup, IIRC you needed the 'known good' NT-Password data for a couple of rounds of MSCHAPv2?
with if ( (EAP-Type == Identity) || (EAP-Type == NAK) || (EAP-Message =~ /^0x02..00061a..$/) ) { default = return } The only lookup happens on the pass just above the ^EAP-TLS message. Each ^Authorize: line is one Access-Request. The others are Identity, NAK or empty EAP-Response 0x02..00061a.. Authorize: User=test EAP-Type=Identity Packet-Type=Access-Request Proxy= VIRT=default Authorize: User=test EAP-Type=Identity Packet-Type=Access-Request Proxy=LOCAL VIRT=inner-tunnel Authorize: User=test EAP-Type=NAK Packet-Type=Access-Request Proxy=LOCAL VIRT=inner-tunnel Authorize: User=test EAP-Type=MS-CHAP-V2 Packet-Type=Access-Request Proxy=LOCAL VIRT=inner-tunnel EAP-TLS: User=test EAP-Type=MS-CHAP-V2 outer.EAP-Type=PEAP EAP-Message=0x0209004... Packet-Type=Access-Request Proxy=LOCAL VIRT=inner-tunnel Authorize: User=test EAP-Type=MS-CHAP-V2 Packet-Type=Access-Request Proxy=LOCAL VIRT=inner-tunnel Post-Auth: User=test EAP-Type=MS-CHAP-V2 EAP-Message=0x030a0004 Packet-Type=Access-Accept, VIRT=inner-tunnel Post-Auth: User=test EAP-Type=PEAP EAP-Message=0x030b0004 Packet-Type=Access-Accept, VIRT=default Post-Auth: User=test EAP-Type=PEAP EAP-Message=0x030b0004 Packet-Type=Access-Accept, VIRT=default mk
On Wed, Aug 28, 2013 at 02:49:32PM +0100, Arran Cudbard-Bell wrote:
Does anyone have a configuration which gets it down to a single LDAP query for PEAP?
The following is for EAP-TTLS/EAP-TLS and PEAP/EAP-TLS on my setup. # When EAP-TLS runs in EAP-TTLS tunnel the id starts at 0x00 and we skip the NACK so we want # to skip only up to 0x04 # When EAP-TLS runs in PEAP the identifiers don't reset so we need to weed out more messages if ((EAP-Type == EAP-TLS) && (outer.request:EAP-Type == EAP-TTLS) && (EAP-Message !~ /^0x02([1-9a-f].|0[5-9a-f])00060d00$/)) { default = return } elsif ((EAP-Type == EAP-TLS) && (outer.request:EAP-Type == PEAP) && (EAP-Message !~ /^0x02([1-9a-f].|0[d-f])00060d00$/)) { default = return } I found that if I nest ifs then default = return won't skip the authorize section and putting the tests on multiple lines doesn't work so it is this ugly:-) However this really isn't foolproof. I think the identifier is first set by NAS as it sends eap request for identity so if that starts at something weird then this will be totaly off. I don't know if any rfc requires the identifier to start at 0. Then it depends on the size of the information that server is sending to the client. That depends on the number of certificates and MTU and fragment size and who know what else. In my setup with MTU 1500 it fits in 3 Access-Challenge packets and so far it holds. I've checked wpasupplicant and mac osx and there haven't been any problems so far though so I'm going to stick with it. I'll investigate the possibility of using ldap lookups in post-auth but that means no mschapv2 or any other password based auth. mk
On 28/08/13 16:00, Martin Kraus wrote:
I found that if I nest ifs then default = return won't skip the authorize section and putting the tests on multiple lines doesn't work so it is this ugly:-)
Yeah, that's an annoyance of the configurable failover stuff.
However this really isn't foolproof. I think the identifier is first set by NAS as it sends eap request for identity so if that starts at something weird then this will be totaly off. I don't know if any rfc requires the identifier to start at 0.
It doesn't, and you will see cases where this doesn't happen, so I'm afraid it's not totally robust. If you were to upgrade, you could do this all a lot more cleanly; the TLS virtual server solves the problem.
On Wed, Aug 28, 2013 at 12:20:12AM +0200, Martin Kraus wrote:
I'm stuck with 2.1.10 on ubuntu:-(
Without trying to come across as if I'm a stuck record... this is easy to solve. https://lists.freeradius.org/pipermail/freeradius-users/2013-August/067939.h... Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (8)
-
Alan DeKok -
Arran Cudbard-Bell -
Iliya Peregoudov -
Martin Kraus -
Matthew Newton -
Olivier Beytrison -
Phil Mayers -
stefan.paetow＠diamond.ac.uk