Re: Can FreeRADIUS proxy accounting requests to multiple systems?
On Thu, 12 Jun 2008, Ivan Kalik wrote: I hope you are using the same database to store authentication data for your users. The FreeRADIUS servers are both querying (replicated) LDAP servers for authentication (and authorization) data. And that both are witing accounting data into the same radacct table. No: they're each writing the accounting data to local files. No database there. If that is so, you don't need to proxy accounting from one radius server to the other - they already have a complete picture. Just configure them both to proxy accounting to the NMS. I think that what you're saying is that with a slightly different configuration than I have, what I'm trying to do should be quite simple. -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Can FreeRADIUS proxy accounting requests to multiple systems?
On Thu, 12 Jun 2008, Alan DeKok wrote: I'm looking to have both of these systems proxy incoming accounting data to each other, ... That should be easy. See the detail file readers in raddb/sites-available/copy-acct-to-home-server. Ok. I've been looking in the right place for that. I'd also like to have them proxy the accounting data to a third system (commercial appliance type of system, though I understand that it does use FreeRADIUS as its RADIUS server) ... It's one of 3 products, all of which are (so far as I know) years out of date in their version of FreeRADIUS. It's not as bad as you think: radiusd: FreeRADIUS Version 1.1.6, for host i686-redhat-linux-gnu, built on Sep 26 2007 at 13:14:25 Copyright (C) 2000-2007 The FreeRADIUS server project. ... It's not FreeRADIUS-2.x, but it's also not years out of date. :-) I'm sure it's good enough to receive accounting-request data, and process them as intended. (no need for it to proxy back to my RADIUS servers as I intend that they'll already be proxying between each other.) ... (... I expect that the NMS would get from each RADIUS server only accounting-request packets that weren't already proxied from the partner RADIUS server, to avoid it receiving duplicate data). That can be done. You just have to set it up carefully. If all else fails, add attributes to the accounting packet saying where it was proxied to, and then don't re-proxy it there... Brilliant! Thanks for that. You will need two versions of copy-acct-to-home-server, one for each destination. Ok, that helps clarify things already. Set up one first and get it working. Then set up another one and get it working. Agreed. Then, ensure that requests sent to one server don't end up getting proxied through 2 other servers back to itself. Right. The NMS thing won't be proxying back to the other two anyway, but I do want to be sure those two don't create a proxying loop ... -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP authenication issues - sort of
I'm not anywhere near expert enough with FreeRADIUS to be able to point you to the solution to your problem, but I think I can at least help you understand some of the behaviour you're seeing ... On Thu, 12 Jun 2008, Capelle, Mark (PCMC-GB) wrote: Thu Jun 12 13:21:54 2008 : Auth: Login incorrect (rlm_ldap: User not found): [DOMAIN\\nonworkinguser/via Auth-Type = EAP] (from client WLANCTRLR1 port 0) This part is very significant of course. Can you perform an LDAP search for the user, using the same credentials and search filters as are used by FreeRADIUS? If I try the samba authentication from a command line on the FreeRADIUS server, it completes successfully: That suggests to me that your non-working user exists in the directory, but not in the container that FreeRADIUS is looking for it in its LDAP configuration. For example does the user exist in the basedn you have configured RADIUS to look in? If I test authentication of the user using radtest, it works fine and is able to find the user: ... Follow the RADIUS server's -X output when you do that and compare to when an authentication request comes in from the WLAN controller. You'll find that radtest isn't performing any form of EAP authentication so your PEAP setup isn't being tested with that. To test thoroughly you'll probably want to use a utility such as wpa_supplicant's eapol_test. I'm sorry I can't help more than that but I hope I'll have helped you gather more information and test more closely to what you want to be testing. -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Can FreeRADIUS proxy accounting requests to multiple systems?
Me again ...
I have two FreeRADIUS-2.0.3 systems provinding AAA for our wireless
networks and a couple of other (less widely used) services. The NAS
devices are configured with both, and which one is likely receive
access-request or accounting-request packets at any given time from any
given NAS is essentially undefined (though they appear to be functioning
in a mostly failover fashion, rather than any sort of load-balancing,
given that there is a large majority of traffic going to one of the two
FreeRADIUS servers).
I'm looking to have both of these systems proxy incoming accounting
data to each other, so that they both have complete, up-to-date data
regarding which users are presently authenticated on which services, but
I'd also like to have them proxy the accounting data to a third system
(commercial appliance type of system, though I understand that it does
use FreeRADIUS as its RADIUS server) which might act as our wireless
network management system (we're presently evaluating it).
It would use this accounting data to correlate end-user systems (by MAC
addresses obtained from NAS devices) with user account names (from the
RADIUS accounting data).
I've been trying to understand the comments in
raddb/sites-available/copy-acct-to-home-server, raddb/proxy.conf, and
the relevant parts of raddb/radiusd.conf, but I'm not sure I have yet
understood whether what I want can be done: proxy accounting-request
packets from both production RADIUS servers to each other AND to the
wireless network management system (though I expect that the NMS would
get from each RADIUS server only accounting-request packets that weren't
already proxied from the partner RADIUS server, to avoid it receiving
duplicate data).
I've started setting up proxy.conf as indicated below my signature, and I
expect I'll need a sites-enabled/copy-acct-to-home-server, but I'm pretty
sure that the proxy.conf as I now have it would not proxy the requests
to both the partner RADIUS server and the wireless network management
system at the same time (not failover nor load-balance, but proxy
to both simultaneously). I'm hoping that someone can offer guidance.
Desired flow of accounting-request packets:
+-+
+| RADIUS2 |
+-+ +-+| +-+
| NAS || RADIUS1 |+
+-+ +-+| +-+
+| WIFINMS |
+-+
OR
+-+
+| RADIUS1 |
+-+ +-+| +-+
| NAS || RADIUS2 |+
+-+ +-+| +-+
+| WIFINMS |
+-+
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
--- old/proxy.conf.20080612 2008-03-27 12:47:55.0 -0500
+++ proxy.conf 2008-06-12 13:16:39.0 -0400
@@ -57,7 +57,7 @@
#
# allowed values: {yes, no}
#
- default_fallback = no
+ default_fallback = yes
}
@@ -114,7 +114,7 @@
# acct - Handles Accounting-Request packets
# auth+acct - Handles Access-Request packets at port,
# and Accounting-Request packets at port + 1
- type = auth
+ type = acct
#
# Configure ONE OF the following two entries:
@@ -146,7 +146,7 @@
# Usually 1812 for type auth, and 1813 for type acct.
# Older servers may use 1645 and 1646.
#
- port = 1812
+ port = 1813
#
# The shared secret use to encrypt and sign packets between
@@ -306,6 +306,30 @@
# Useful range of values: 3 to 10
num_answers_to_alive = 3
}
+home_server radius2 {
+ type = acct
+ ipaddr = radius2
+ port = 1813
+ secret = testing123
+ response_window = 20
+ zombie_period = 40
+ revive_interval = 120
+ status_check = status-server
+ check_interval = 30
+ num_answers_to_alive = 3
+}
+home_server wifinms {
+ type = acct
+ ipaddr = wifinms
+ port = 1813
+ secret = testing123
+ response_window = 20
+ zombie_period = 40
+ revive_interval = 120
+ status_check = status-server
+ check_interval = 30
+ num_answers_to_alive = 3
+}
##
@@ -320,7 +344,7 @@
# 10 'realm sections, and one home_server_pool section to tie the
# two together.
#
-home_server_pool my_auth_failover {
+home_server_pool
Re: RADIUS with LDAP: changing LDAP filter based on RADIUS request
On Mon, 9 Jun 2008, Ivan Kalik wrote:
man unlang - attribute lists.
***
The list: prefix is optional, and if omitted, is assumed to refer
to the request list.
***
Ah yes ... That helps a lot. Thank you.
However, having fixed references to %{CU-LDAP-Filter} so they now refer
to %{control:CU-LDAP-Filter} (since I've assigned a value to that
attribute in an update control statement), I see now that it does
indeed refer to the value I've set, but by the time that's handed to
rlm_ldap, punctuation characters have been replaced with hexadecimal
(escape) representations:
...
+++- entering case 192.168.198.20
expand: %{Stripped-User-Name} -
expand: %{User-Name} - j_doe
expand:
((cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca)))
-
((cn=j_doe)(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca)))
[control] returns noop
+++- case 192.168.198.20 returns noop
++- switch %{NAS-IP-Address} returns noop
++? if (%{control:CU-LDAP-Filter} != )
expand: %{control:CU-LDAP-Filter} -
((cn=j_doe)(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca)))
? Evaluating (%{control:CU-LDAP-Filter} != ) - TRUE
++? if (%{control:CU-LDAP-Filter} != ) - TRUE
++- entering if (%{control:CU-LDAP-Filter} != )
+++- entering redundant-load-balance group redundant-load-balance
rlm_ldap: - authorize
rlm_ldap: performing user authorization for j_doe
expand: %{control:CU-LDAP-Filter} -
\28\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29
expand: ou=people,dc=concordia,dc=ca - ou=people,dc=concordia,dc=ca
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 host1:389, authentication 0
rlm_ldap: bind as cn=rad_admin,ou=AdminRoles,dc=concordia,dc=ca/**SANITIZED**
to host1:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=people,dc=concordia,dc=ca, with filter
\28\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29
rlm_ldap: ldap_search() failed: Bad search filter:
\28\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29
rlm_ldap: search failed
rlm_ldap: ldap_release_conn: Release Id: 0
[ldap_host1] returns fail
...
Notice the expand: %{control:CU-LDAP-Filter} line once it's in rlm_ldap.
I suspect that this is happening in the update block, but I can't be
sure of that (or how to avoid it). I've tried to read all documentation
that refers to update, but haven't yet found any enlightenment.
My update block corresponding to the above is (in sites-enabled/default):
switch %{NAS-IP-Address} {
case 192.168.198.20 {
# test
update control {
CU-LDAP-Filter =
((cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca)))
}
}
...
}
The CU-LDAP-Filter variable is then referenced in the instance(s) of the
ldap module configuration:
ldap ldap_host1 {
...
filter = %{control:CU-LDAP-Filter}
...
}
Hrmmm ... I see from further reading (man unlang again!) that there is
a 253 character limit on the assignment of string values. The above
sample is below that limit but the filter values I'm intending to
ultimately use will be well beyond that, so this seems like it perhaps
isn't the best way to get what I'm after.
I'll see if there's some way I could simplify the variable portion of my
LDAP search filter, but I'm bothered by the escaping of punctuation
characters. Is there a way to un-escape those when the variable is
referred to later?
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list
RADIUS with LDAP: changing LDAP filter based on RADIUS request
expand: %{NAS-IP-Address} - 192.168.198.20
++- entering switch %{NAS-IP-Address}
+++- entering case 192.168.198.20
expand: %{Stripped-User-Name} -
expand: %{User-Name} - j_doe
expand: ((cn=%{%{Stripped-User-Name}:-%{User-Name}})**LDAP QUERY1 FILTER
TRIMMED**) - ((cn=j_doe)**LDAP QUERY1 FILTER TRIMMED**)
[control] returns noop
+++- case 192.168.198.20 returns noop
++- switch %{NAS-IP-Address} returns noop
++? if (%{CU-LDAP-Filter} != )
expand: %{CU-LDAP-Filter} -
? Evaluating (%{CU-LDAP-Filter} != ) - FALSE
++? if (%{CU-LDAP-Filter} != ) - FALSE
++[expiration] returns noop
++[logintime] returns noop
rlm_pap: WARNING! No known good password found for the user.
Authentication may fail because of this.
++[pap] returns noop
rad_check_password: Found Auth-Type EAP
auth: type EAP
+- entering group authenticate
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
rlm_eap: RT Modif EAP-Type = 21 EAP-LENGTH = 1
++[eap] returns handled
EAP-Message = 0x01d300061520
Message-Authenticator = 0x
State = 0x1c870d031c541859b55d17dd8af5914a
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 232 with timestamp +4
Ready to process requests.
Note that of the above, I believe the following is relevant to my
question:
expand: %{NAS-IP-Address} - 192.168.198.20
++- entering switch %{NAS-IP-Address}
+++- entering case 192.168.198.20
expand: %{Stripped-User-Name} -
expand: %{User-Name} - j_doe
expand: ((cn=%{%{Stripped-User-Name}:-%{User-Name}})**LDAP QUERY1 FILTER
TRIMMED**) - ((cn=j_doe)**LDAP QUERY1 FILTER TRIMMED**)
[control] returns noop
+++- case 192.168.198.20 returns noop
++- switch %{NAS-IP-Address} returns noop
++? if (%{CU-LDAP-Filter} != )
expand: %{CU-LDAP-Filter} -
? Evaluating (%{CU-LDAP-Filter} != ) - FALSE
++? if (%{CU-LDAP-Filter} != ) - FALSE
This corresponds to the following from the authorize section in my
sites-enabled/default file:
switch %{NAS-IP-Address} {
case 192.168.198.20 {
# test
update control {
CU-LDAP-Filter =
((cn=%{%{Stripped-User-Name}:-%{User-Name}})(***LDAP QUERY TRIMMED FOR
BREVITY***))
}
}
}
We see that the line where I intend to assign a value to CU-LDAP-Filter
is indeed encountered and the variables referred to in that line are
expanded correctly, but it seems as though the assignment to
CU-LDAP-Filter isn't done: if (%{CU-LDAP-Filter} != ) is evaluated
as FALSE.
I suspect that my update statement is likely incorrect, since the only
mention of it in the debug output is:
[control] returns noop
Can anyone help me with this? I've read as much of the relevant
documentation as I'm aware exists, especially man unlang without which
I certainly wouldn't have gotten even this far, but I'd be very grateful
if someone could point me to further documentation that would help with
what I'm trying to do ...
Thanks ...
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: using different LDAP queries to authorize for different services
On Thu, 3 Apr 2008, Alan DeKok wrote:
You have to change the reference to ldap in sites-available/default.
to the instance name. e.g. ldap_wireless.
...
In 2.0, you don't really need Autz-Type. I would suggest pretending
that it doesn't exist. Instead, use unlang.
...
The sections are processed top to bottom, as a linear list. If you
want to make the server do your bidding, write if/else statements
using unlang.
i.e. write the conditions you want to match in plain english, and what
you want it to do. Then, translate that pretty much directly into
unlang.
and in a response to a different message:
What is the proper way to call a specific LDAP module based on
NAS-IP-Address (or huntgroup, probably)?
authorize {
...
if (NAS-IP-Address == 1.2.3.4) {
ldap_1
}
elsif (NAS-IP-Address == 3.4.5.6) {
ldap_2
}
...
}
Or, use switch. See man unlang.
...
Don't use the users file for things like this. It doesn't know
about modules, or module order. The unlang parser does know.
On the one hand, OH!!! I think I'm starting to understand, but on the
other hand, I appear to still not be doing it quite right. I put into
the authorize section of sites-available/default:
...
#
# The ldap module will set Auth-Type to LDAP if it has not
# already been set
#ldap
# wireless
if (NAS-Port-Type == Wireless-802.11) {
ldap_wireless
}
...
I also tried NAS-IP-Address with the same result so far, but I can
clearly see from the debug output that this part is now functioning as
expected. If the user does not match the search filter configured in my
ldap_wireless instance of the ldap module, this section returns
notfound, otherwise it returns ok.
However, then the request carries on to the inner-tunnel of the TTLS
transaction (whether or not the outer authorization succeeded or returned
not found; is it possible to equate notfound to fail or reject?).
If I configure sites-available/inner-tunnel's authorization section as
above, when it gets to that point, debug output says:
++? if (NAS-Port-Type == Wireless-802.11)
(Attribute NAS-Port-Type was not found)
The user is rejected shortly after, even when the ldap search is
expected to succeed, with the following in debug output:
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
In other words, despite having found the user in the ldap_wireless
search in sites-available/default, the inner-tunnel seems to not receive
sufficient information about the request to decide to use the
ldap_wireless module, leaving the RADIUS server with no way to
authenticate the user. This is despite ldap_wireless in
sites-available/default having produced:
rlm_ldap: checking if remote access for j_doe is allowed by cn
rlm_ldap: Added User-Password = {SSHA}*SANITIZED*QDmffXBQkU42Wt9x*SANITIZED*==
in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user j_doe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
+++[ldap_wireless] returns ok
++- if (NAS-Port-Type == Wireless-802.11) returns ok
ie. we have a password and have already determined authorization for
this user.
And also despite the debug output of the request arriving at inner-tunnel
*appearing* to contain items sufficient for me to select on:
User-Name = j_doe
NAS-IP-Address = 127.0.0.1
Calling-Station-Id = 02-00-00-00-00-01
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = CONNECT 11Mbps 802.11b
EAP-Message =
0x02050070150017030100207ec2e216f79ef34a114bb34054277beb1a45fd25505d975be42b62d449e1be8c1703010040ca0cbb9c6b5abfef1e656ccc100c8350cae810edc08d9b6c3135dabbcac32a2ef26c2a3824cb7eaf7423d00c83432cfaceb08721d92faa5c3579908e3be88ba3
State = 0x6f66f2676b63e70a05f25e914c848f96
Message-Authenticator = 0x314bc723b23efd033689667de8c0ca7a
If I put in inner-tunnel:
authorize {
...
ldap
...
}
Then it seems to authorize access for users that ldap_wireless in
default didn't find. I can get the intended result for *this* service
with inner-tunnel containing instead:
authorize {
...
ldap_wireless
...
}
but that doesn't help me for other services for which I want to use
RADIUS.
Help?
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: using different LDAP queries to authorize for different services
from all
of these experiments and from the help I've gotten on the mailing list, I
have only scratched the surface of what there is to know about FreeRadius,
and I would likely write yet more partially-correct-at-best third-party
documentation that folks really shouldn't follow. :-(
Honestly, it's not that difficult. Find *something* in the outer
request that is there only for wireless requests. Key off of that in
the *inner* tunnel to select the users from the correct LDAP instance.
I had the first part of that right: I was looking for a unique
attribute. I appreciate the time you've taken to teach me *where* I
should have been looking for that attribute.
if (outer.NAS-Port-Type == foo) {
ldap_foo
}
elsif (outer.NAS-Port-Type == bar) {
ldap_bar
}
That's EXACTLY what I need to do, yes.
Once again, thanks for ALL the help. I think I now have everything I
need to do exactly what I want.
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
using different LDAP queries to authorize for different services
I'm back. Small reminder, since it appears that list members are helping a sufficient number of folks that remembering my particular setup would be non-trivial: - I'm running FreeRADIUS-2.0.3 (rlm_pap is patched as was discussed on this mailing list), with TTLS/PAP using OpenLDAP as the source of user authorization and authentication. - My configuration files are nearly stock, with the exception of the necessary configuration to get the ldap module talking to the LDAP server. - This setup has been running like this now for a couple of days without any trouble. What I'm aiming to accomplish, however, is that the FreeRADIUS server will authorize users for different services based on a slightly different LDAP query. The users are in various groups, which can be checked by supplying an LDAP query filter that checks the memberOf attribute; Users in group wireless should be permitted to use the wireless service; users in group vpn should be able to use the VPN service; users in both groups could use either, and users in neither group should be refused for either, etc. I've been trying to configure this by adding instances of the ldap module configuration (ldap ldap_wireless for example) in the modules section of radiusd.conf, and setting Autz-Type in the users file based on the NAS-IP-Address (huntgroups would likely be more appropriate for our wireless access points, but at the moment I'm trying to do this one step at a time, and in fact am testing with only 127.0.0.1 as the NAS-IP-Address anyway). Running radiusd in debug mode shows that the ldap module is using the configuration for its un-named instance (the default one from the stock config files, with minimal configuration to permit it to lookup users in our LDAP). I can tell the difference in which LDAP module configuration stanza is used by the query filter shown in the debug output. If the correct way to accomplish what I'm trying for is documented somewhere, I may have overlooked it, so I would appreciate it if someone could point me at it. I'm happy to read documentation, especially if it leads me to better understand how to accomplish desired tasks. Otherwise, if someone can see from the above what I'm doing wrong, I'd certainly appreciate any advice, suggestions or other useful input. Thanks again in advance ... -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: using different LDAP queries to authorize for different services
On Thu, 3 Apr 2008, Alan DeKok wrote:
I have trouble remembering messages from 10 minutes ago. It's easier
that way.
There were messages 10 minutes ago? ;-)
...
- My configuration files are nearly stock, with the exception of the
necessary configuration to get the ldap module talking to the LDAP
server.
- This setup has been running like this now for a couple of days
without any trouble.
And yes, it really is that easy. ...
And quite frankly, darned amazing! All (?!? nearly all?) the third-party
documentation out there makes it *seem* difficult. If nothing else,
not trying to set the Auth-Type anywhere (and letting the server do the
Right Thing) results in a noticeable improvement in RADIUS performance
(at least in the case here, where our old configuration explicitly sets
Auth-Type to LDAP, causing an LDAP-bind for every authentication
request, and we're getting LOTS of authentication requests).
Had I persisted more at getting this right (rather than simply working)
a couple of years ago when I originally set it up, I likely would have
saved myself many headaches!
What I'm aiming to accomplish, however, is that the FreeRADIUS server
will authorize users for different services based on a slightly
different LDAP query. ...
You should be able to do this with multiple LDAP modules, or maybe by
dynamically editing the ldap query.
Dynamically editting the query hadn't occurred to me. I've been trying
to configure multiple instances of the LDAP module. Even now
considering dynamically editing the ldap query, I suspect that the
multiple module approach is likely simpler to configure and maintain.
You have to change the reference to ldap in sites-available/default.
to the instance name. e.g. ldap_wireless.
In the authorize stanza, then? So I replace
#
# The ldap module will set Auth-Type to LDAP if it has not
# already been set
ldap
with
#
# The ldap module will set Auth-Type to LDAP if it has not
# already been set
ldap_wireless
or
#
# The ldap module will set Auth-Type to LDAP if it has not
# already been set
ldap ldap_wireless
?
Can I then add an ldap_vpn as well, in the same place?
Is this where I should be using
Autz-Type wireless {
ldap_wireless
}
Autz-Type vpn {
ldap_vpn
}
...
?
I'm placing the ldap module-instance configuration in radiusd.conf,
and setting Autz-Type in users. Are these the correct places for
those items?
Is there specific documentation I should be re-reading to properly
understand this? I feel as though I sort-of understand the sequence,
from examining debug output, but I don't feel I really know (yet) how to
make the server do my bidding.
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
and maintaining this package. You're making other people's jobs easier! -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
Earlier, I wrote: For some reason, I seem unable to get this to produce a core file to try and track it down any further (limit coredumpsize unlimited as root hasn't helped). ... Sigh ... while reviewing the configuration for my now-in-production installation, I spotted the allow_core_dumps parameter. I will finish with what I'm doing now, then return to getting more information of when and where the CVS version is seg-faulting. If the problem is of my own creation, I'll just fix it. Otherwise I'll report back with any additional information I can provide. -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
On Tue, 1 Apr 2008, Alan DeKok wrote: Remember: the default configuration *works*. :) So you keep saying! ;-) Hrmmm... That one segfaults on the first authentication request it receives. Correction: it's an accounting request for a stop. Likely because of version numbers, etc. If you re-build install *one* module, it might not work. If you install everything from the same source tree, it should work. That's what I did, though (installed everything from the same source tree). As I just wrote, I'll get back to looking at that after I'm finished getting 2.0.3 doing everything I need (authorizing for multiple services). I'll probably find something I did wrong, perhaps during the pre-compilation configure run? -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems and Network analyst Concordia University Instructional Information TechnologyMontreal, Quebec, Canada -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
internally by the server core,
and doesn't do the magic required to recognize the {SSHA} in the
User-Password config item.
Right, that's rlm_pap's job.
Login incorrect: [j_doe/*SANITIZED*] (from client wireless-mcconnell
...hence login fails.
and my users complain. :-(
Much later in your email, you list the output of a radtest against
LDAP. Because that isn't EAP-TTLS, there's no tunnel and thus the
rlm_pap bug isn't triggered.
I think I'm still following ...
radeapclient against a user listed in the users file still performs the
ldap query for authorization (I actually don't want that; I'd like the
users file to over-ride the LDAP listing, if an entry is matched in the
users file),
In that case, you will need to configure the server appropriately - in older
versions of the server you'd do this:
authorize {
preprocess
files
Autz-Type LDAP {
ldap
}
}
Yes.
...and in users:
j_doe Cleartext-Password := foo
DEFAULT Calling-Station-Id == 0011.2233.4455, Auth-Type := Reject
DEFAULT Autz-Type := LDAP
Yes.
...or something like:
authorize {
preprocess
redundant {
files
ldap
}
}
I only learned about redundant this week. I expect that will be
useful to me for listing multiple LDAP servers (with parallel copies of
the data), but no, I don't have this.
...in 2.x versions of the server you might want to use unlang
I'll re-read that, but will worry about this matter only after I get the
authentication working as I intend.
In my opinion, radeapclient is not terribly useful.
I would recommend compiling eapol_test from the wpa_supplicant
package; it can do a full EAP TTLS/PAP request against a radius
server.
Thanks. I'll set that up for testing.
As has been pointed out in another email, you have set:
modules {
ldap {
...
password_radius_attribute = SSHA-Password
}
}
yes.
password_radius_attribute is not a valid config item for the LDAP
module; the ldap module will be ignoring it. You don't need it.
Ugh! See above for where I learned about that parameter in the first
place (doc/rlm_ldap in the freeradius-server-2.0.3 source tree). Here I
was under the impression that I was doing exactly as needed! :-(
Indeed the string password_radius_attribute shows up _only_ in
doc/rlm_ldap, and not in any source (or header) files. I should have
thought to check for that in the first place ...
To summarize, the main things I need to look at Monday are:
- invert the PW_PROXY_TO_REALM test in rlm_pap.c, unless it's declared
that the test is correct as it is.
- confure auto_header = yes for the ldap module.
- Consider adding a caching DNS resolver to the systems running RADIUS
servers.
- Test with an SSHA hash as the password in the users file, and
understand exactly what attribute it needs to be in. Make sure
that the ldap module is placing the users' passwords in that
attribute.
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
On Sat, 29 Mar 2008, Alan DeKok wrote:
ldap {
auto_header = yes
...
I will definitely give that a try on Monday morning. ...
I would very much prefer that the PAP module be used for the password
mangling, rather than rlm_ldap. The code in the PAP module does
more, and is more used than the similar code in rlm_ldap. I think
that functionality will be removed from rlm_ldap.
Ok, fair enough. What you're saying is if I've done everything else
correctly (and using a freeradius-server version that has the fixed
rlm_pap), I shouldn't need ldap's auto_header functionality.
[password_radius_attribute]
I've deleted that text from the documentation. The configuration item
hasn't been in rlm_ldap for a long time.
I should have checked the source before attempting to use the parameter.
I would have been able to see for myself that the parameter simply
doesn't exist.
You need to tell FreeRADIUS *how* you have encrypted the passwords.
If there's a {ssha} header on the password, then the PAP module should
figure it out.
The header is there, as {SSHA}. I imagine (I'm not trying to avoid
*checking* for myself; I can do so on Monday when I'm back at work ...)
that it isn't case-sensitive.
30 second delays are almost always DNS.
Understood.
Hrmmm... I have hostname_lookups = no ...
Yes. That configuration item controls IP address - hostname lookups
for printing. It has *no* effect on hostname - IP mapping, such as
looking up ldap servers by hostname.
Right, and I wouldn't have kidded myself that it had anything to do with
that.
Of course, if that's the problem (and if the server is performing that
lookup for every LDAP query, and in my current installation, every bind
to LDAP for authentication, it occurs to me that the DNS resolvers
just might be throttling their responses due to the sheer number of
queries they would be seeing from the same small number of systems), I
could work-around it just as easily by using IP addresses for the LDAP
server configurations, or simply list the LDAP servers in the system's
/etc/hosts file (assuming appropriate configuration of nsswitch).
That's getting a bit off-topic for freeradius-users, though. Still,
thank you again for bringing this up; I had completely overlooked
it as a possibility. And yes, I've quite well received your point:
run in debug mode and SEE why my current radiusd is taking so long to
respond to the authentication requests.
This might be an easy-enough fix that would at least buy me time to
return to getting 2.0.3 properly configured and running.
... The issue is that the rlm_ldap module is reading the
userPassword ldap field, and creating a User-Password attribute.
It could really be fixed.
By patching rlm_ldap, you mean, or by adjusting my configuration?
Patching rlm_ldap, probably. The userPassword should be mapped to
User-Password via ldap.attrmap, just like everything else.
If it's that simple, I definitely can go ahead and do that.
Ok, but what I'm stuck on is *why* the differences are there. I
don't doubt I've done something wrong, but I'm unable to figure out
what it is that I've done wrong.
It may be the bug in rlm_pap. Grab a current CVS snapshot, and see if
that works any better.
I will do that Monday and report back. Thank you.
Ok, and then I'll need to put the blob in a SSHA-Password attribute,
correct?
Yes. And it will likely work. But... the LDAP module is putting it
into the User-Password attribute. So you might want to test that, too.
Alright.
I only learned about redundant this week. ...
$ man unlang
You probably want redundant-load-balance. It's a bit of effort to
type, but it results in a pretty robust system.
I have read man unlang and will read it again. I agree that
redundant-load-balance is more likely to be what I want, and came to the
same conclusion when I did read man unlang (only yesterday). A
pretty robust system is definitely what I'm after, yes. :-)
- confure auto_header = yes for the ldap module.
I really don't think that's necessary. If you're not proxying, then
the PAP module *should* take care of fixing the password up.
Ok, will try without it first, and report back.
Also, test with a User-Password := {ssha} Check that the PAP
module fixes it, and turns it into a SSHA-Password attribute.
Right. Thanks very much. I think I'm well on my way to getting this
going, and even to fixing the original problem I was trying to solve in
the first place (performance of the RADIUS server during peak usage
hours).
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
On Sat, 29 Mar 2008, Arran Cudbard-Bell wrote:
If there's a {ssha} header on the password, then the PAP module should
figure it out.
But it doesn't appear to be... you have got the autoheader option set
in the PAP module?
pap {
auto_header = yes
}
Yes, that's configured.
*nothing* will work until you get the hash into the correct attribute
with the header stripped off.
Right. As already noted, radtest against a user entry in our LDAP data
*does* work. I just need to get this working inside the TTLS tunnel.
Fudging it by creating a static mapping userPassword - SSHA-Password
in ldap.attrmap won't work because the header will still be present in
the hash...
Ok, which suggests that my attempt to use password_radius_attribute
(if that parameter still existed) in the ldap configuration would have
still failed, because I was trying to set it to SSHA-Password there.
Alan's suggestion was to map it tp User-Password, though, which is where
rlm_pap *would* know how to deal with it.
Thanks, of course, for your continued interest ...
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
file), but then seems to stop short of setting up the TTLS tunnel
and performing any authentication:
radeapclient says:
+++ About to send encoded packet:
User-Name = j_doe
Cleartext-Password = *SANITIZED*
NAS-IP-Address = 192.168.198.20
NAS-Port-Type = Wireless-802.11
EAP-Code = Response
EAP-Id = 210
EAP-Type-Identity = j_doe
Message-Authenticator = 0x00
NAS-Port = 0
+++ EAP decoded packet:
Service-Type = Dialout-Framed-User
EAP-Message = 0x01d300061520
Message-Authenticator = 0x796172e3b17c8b07c0409d2a811f0996
State = 0x99802cfd9953395efbafe88eb97f8c71
EAP-Id = 211
EAP-Code = Request
EAP-Type-LEAP = 0x20
I don't want LEAP! Where did it get this from?
Radiusd says:
rlm_ldap: performing search in ou=people,dc=concordia,dc=ca, with filter
((cn=syl)(search filter trimmed for brevity))
rlm_ldap: Added User-Password = {SSHA}*SANITIZED*QDmffXBQkU42Wt9x*SANITIZED*==
in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user syl authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
rlm_pap: Found existing Auth-Type, not changing it.
++[pap] returns noop
rad_check_password: Found Auth-Type EAP
auth: type EAP
+- entering group authenticate
rlm_eap: EAP Identity
rlm_eap: processing type tls
rlm_eap_tls: Initiate
rlm_eap_tls: Start returned 1
rlm_eap: RT Modif EAP-Type = 21 EAP-LENGTH = 1
++[eap] returns handled
Service-Type = Dialout-Framed-User
EAP-Message = 0x01d300061520
Message-Authenticator = 0x
State = 0x99802cfd9953395efbafe88eb97f8c71
Finished request 2.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 2 ID 243 with timestamp +465
Ready to process requests.
I'm certainly prepared to be told that I'm doing it wrong, but in that
case, I'd sure like to know WHAT I'm doing wrong, because I believe
I've followed documented instructions completely, and haven't strayed
any further than necessary from the default configuration as shipped
with FreeRADIUS-2.0.3.
Can someone please tell me where I should be looking? As promised,
the unified context diff of my configuration against the default is
appended below my signature.
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
diff -ur raddb/clients.conf ../root-freeradius-2.0.3/etc/raddb/clients.conf
--- raddb/clients.conf 2008-02-13 04:41:14.0 -0500
+++ ../root-freeradius-2.0.3/etc/raddb/clients.conf 2008-03-28
11:11:49.0 -0500
@@ -227,3 +227,96 @@
# secret = testing123
#}
#}
+
+client hostname.concordia.ca {
+ secret = *SANITIZED*
+ shortname = LOCAL/LOCALTEST
+}
### more entries in the same format, for other RADIUS clients ###
diff -ur raddb/eap.conf ../root-freeradius-2.0.3/etc/raddb/eap.conf
--- raddb/eap.conf 2008-02-26 04:32:29.0 -0500
+++ ../root-freeradius-2.0.3/etc/raddb/eap.conf 2008-03-28 12:15:53.0
-0500
@@ -27,7 +27,7 @@
# then that EAP type takes precedence over the
# default type configured here.
#
- default_eap_type = md5
+ default_eap_type = ttls
# A list is maintained to correlate EAP-Response
# packets with EAP-Request packets. After a
@@ -145,7 +145,7 @@
cadir = ${confdir}/certs
private_key_password = whatever
- private_key_file = ${certdir}/server.pem
+ private_key_file =
/public/apache/ssl/netnames-1_private.pem
# If Private key Certificate are located in
# the same file, then private_key_file
@@ -157,7 +157,7 @@
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
- certificate_file = ${certdir}/server.pem
+ certificate_file = /public/apache/ssl/netnames-1.pem
# Trusted Root CA list
#
@@ -174,7 +174,7 @@
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
- CA_file = ${cadir}/ca.pem
Re: yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...
On Fri, 28 Mar 2008, Ivan Kalik wrote:
You have obviously ignored the warnings about storing User-Password
attribute:
No, I don't believe that I can be said to have ignored it at all.
In fact, I'm under the impresseion that I made very clear in my earlier
message that I'm not ignoring this warning. I may not be doing the right
thing to deal correctly with what causes it, but that's another matter
entirely, and why I am putting myself at the mercy of experts for help.
I wrote:
The text User-Password appears in exactly the following places in my
raddb directory (not counting comment lines):
./attrs.pre-proxy: User-Password =* ANY,
./sql/mysql/dialup.conf:
'%{%{User-Password}:-%{Chap-Password}}', \
./sql/postgresql/dialup.conf: VALUES ('%{User-Name}',
'%{%{User-Password}:-Chap-Password}', '%{reply:Packet-Type}', NOW())
These files are as shipped with FreeRADIUS-2.0.3. I'm trying to get
this done with minimal change to the default configuration, since it
appears that's what is expected. Which of the above needs to change?
(attrs.pre-proxy?)
... So server translates User-Password to Cleartext-Password and the
check fails since the password is encrypted.
Understood, yes.
Configure ldap section to use SSHA-Password as password attribute instead.
That's what I believed I HAD done with the following, from the diff of
my radiusd.conf file against the default radiusd.conf that ships with
2.0.3, orignally included after the signature in my first message:
@@ -820,7 +825,8 @@
# Novell may require TLS encrypted sessions before returning
# the user's password.
#
- # password_attribute = userPassword
+ password_attribute = userPassword
+password_radius_attribute = SSHA-Password
If the above is not the correct way to accomplish what I am trying to
do, I would be very grateful if someone would point me in the right
direction to find what is the correct way.
The radtest test against a user in the LDAP data succeeds. How do I get
from here to having successful authentication through TTLS against the
same LDAP data, without the above warning?
radtest j_doe '*SANITIZED*' localhost:1814 1 testing123
User-Name = j_doe
User-Password = *SANITIZED*
NAS-IP-Address = 192.168.7.47
NAS-Port = 1
Older versions of radtest would report receiving Access-Accept, while
this one silently exists. However, radiusd in this case says:
Ready to process requests.
User-Name = j_doe
User-Password = *SANITIZED*
NAS-IP-Address = 192.168.7.47
NAS-Port = 1
+- entering group authorize
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
rlm_realm: No '@' in User-Name = j_doe, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix] returns noop
rlm_eap: No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
++[files] returns noop
rlm_ldap: - authorize
rlm_ldap: performing user authorization for j_doe
expand: %{Stripped-User-Name} -
expand: %{User-Name} - j_doe
expand: ((cn=%{%{Stripped-User-Name}:-%{User-Name}})(search filter
trimmed for brevity)) - ((cn=j_doe)(search filter trimmed for brevity))
expand: ou=people,dc=concordia,dc=ca - ou=people,dc=concordia,dc=ca
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 localhost boris:389, authentication 0
rlm_ldap: bind as cn=iits_neg,ou=AdminRoles,dc=concordia,dc=ca/*SANITIZED* to
localhost boris:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=people,dc=concordia,dc=ca, with filter
((cn=j_doe)(search filter trimmed for brevity))
rlm_ldap: Added User-Password = {SSHA}*SANITIZED*QDmffXBQkU42Wt9x*SANITIZED*==
in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user j_doe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
rad_check_password: Found Auth-Type auth: type PAP
+- entering group PAP
rlm_pap: login attempt with password *SANITIZED*
rlm_pap: Using SSHA encryption.
rlm_pap: Normalizing SSHA1-Password from base64 encoding
rlm_pap: User authenticated successfully
++[pap] returns ok
Login OK: [j_doe/*SANITIZED*] (from client localhost port 1)
Finished request 0.
Going to the next request
Thanks for following up, and for any additional help ...
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
