Question about authentication
Hello list, suppose I want to authenticate a device capable of using PEAP with EAP-MS-CHAP v2 or EAP-GTC and TTLS with EAP-MS-CHAP v2 or MS-CHAPv2 and I have user password stored in LDAP (linux) with the crypt scheme and freeradius server 2.1.9. Is there any mechanism to successfully authenticate the client? for example getting user password from ldap, and comparing with the one in the request packet (previously encrypted)? Thanks in advance. Matteo - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about authentication
matteo wrote: Hello list, suppose I want to authenticate a device capable of using PEAP with EAP-MS-CHAP v2 or EAP-GTC and TTLS with EAP-MS-CHAP v2 or MS-CHAPv2 and I have user password stored in LDAP (linux) with the crypt scheme and freeradius server 2.1.9. Is there any mechanism to successfully authenticate the client? No. It's impossible. http://deployingradius.com/documents/protocols/compatibility.html Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about authentication
John Baldwin wrote: I’m trying to configure freeradius on a Centos server to authenticate my logins on Cisco devices. I can see in the log file that my request is hitting the server. I’m advised to just add a username and password in the users file so I’ve done that, I’ve used the steve login and password of testing as used as an example in the file and as follows ... I’m running radiusd –x. The following is the contents of the log file. Please run radiusd -X as suggested in the FAQ, README, and daily on this list. Doing so would have helped you solve the problem. rlm_pap: login attempt with password CÃ?-Ã+Cý?Aà ?ü?RE The shared secret is wrong. Check it, or re-enter it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Question about authentication
Hello all I'm trying to configure freeradius on a Centos server to authenticate my logins on Cisco devices. I can see in the log file that my request is hitting the server. I'm advised to just add a username and password in the users file so I've done that, I've used the steve login and password of testing as used as an example in the file and as follows steve Cleartext-Password := testing All following lines are still commented out. I'm running radiusd -x. The following is the contents of the log file. Waking up in 0.9 seconds. rlm_pap: login attempt with password CÃ?-Ã+Cý?Aà ?ü?RE rlm_pap: Using clear text password testing rlm_pap: Passwords don't match Waking up in 3.9 seconds. Ready to process requests. Ready to process requests. Exiting normally. Listening on authentication address 192.168.72.100 port 1812 Listening on accounting address * port 1813 Listening on proxy address 192.168.72.100 port 1814 Ready to process requests. Waking up in 0.9 seconds. rlm_pap: login attempt with password CVæÃ??)yc8é?Ã?ir rlm_pap: Using clear text password testing rlm_pap: Passwords don't match Waking up in 3.9 seconds. Any assistance you can provide would be greatly appreciated. Many thanks John [cid:image001.png@01C97B03.22F83520]http://www.saxonfinancials.com/ John Baldwin Head of IT Saxon Financials Limited | Singapore 112 Robinson Road #06-04 Singapore 068902 Tel: (65) 6349 Fax: (65) 6349 0001 Did: (65) 6349 0006 Cell: (65) 9144 6382 j.bald...@saxonfinancials.commailto:j.bald...@saxonfinancials.com www.saxonfinancials.comhttp://www.saxonfinancials.com Click herehttp://www.saxonfinancials.com/disclaimer.htm for our email disclaimer. inline: image001.png- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
Phil Mayers wrote:
I am suggesting that in some sense (and obviously, it's only my opinion,
and as I say it's only doable to an extent with newer FR versions) the
following is better:
authenticate {
Auth-Type PAP {
krb5
}
}
That is, that the Auth-Type be set to reflect the algorithm in the
radius request, and not the backend processing that request.
OK... This makes sense, as long as all services using PAP need to use
the rlm_krb5 back end.
Now, in my case (perhaps I should have mentioned this before), I have
other services that use PAP, but not Kerberos (just Crypt-Password from
a local database). So this really is the 1 competing module for a
given Auth-Type: I'd declare two different PAP Auth-Types, then set
the appropriate one in the authorization module for each service.
IOW, this is pretty much just what I'm doing now, except that the
Auth-Type that invokes rlm_krb5 is explicitly declared in the
authenticate{} section, which is not the case for Kerberos in FR 1.0.5.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
George C. Kaplan wrote:
I don't think I understand your examples. A NAS is sending a User-Name
and User-Password, and somehow I have to tell radiusd, Use Kerberos to
authenticate these users. I don't see how I can do that except by
setting 'Auth-Type = Kerberos' *somewhere*.
I am suggesting that in some sense (and obviously, it's only my opinion,
and as I say it's only doable to an extent with newer FR versions) the
following is better:
authenticate {
Auth-Type PAP {
krb5
}
}
That is, that the Auth-Type be set to reflect the algorithm in the
radius request, and not the backend processing that request.
Out of interest, are you finding rlm_krb5 stable? Under high concurrency?
Yes, except (and it's a big except) for signals. I posted something
about this a little while ago: when radiusd gets a HUP or TERM signal,
it sometimes becomes unresponsive, using 98% CPU. A 'kill -9' is
Ah. I'll stick with LDAP to the AD controllers.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
On Friday 17 March 2006 19:21, George C. Kaplan wrote: Phil Mayers wrote: Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set Auth-Type based on the incoming requests e.g. the mschap modules sets Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the chap and eap modules. pap is a bit more complex and has changed in CVS head. Generally, you should not set Auth-Type in the users file. It's a sign you're doing something wrong. Perhaps if you told us what you're trying to do? I've been wondering about this, in relation to the rlm_perl module. We see Don't set Auth-Type in the users file all over the place, but with rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for authorization, I *have to* set the Auth-Type in the users file. This isn't really a problem (since it all works the way I want), but it seems inconsistent, especially considering that other modules can modify the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST made read-only? Because perl hashes are not ordered. -- Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
Boian Jordanov [EMAIL PROTECTED] wrote:
So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
Because perl hashes are not ordered.
The only requirement is that attributes of the same name be ordered.
This may change the way the module works (I haven't looked), but if
${RAD_REQUEST}{'attribute'} was an array of values rather than a
scalar, that should allow the hash to be writable.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
Boian Jordanov [EMAIL PROTECTED] wrote:
So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
Because perl hashes are not ordered.
The only requirement is that attributes of the same name be ordered.
This may change the way the module works (I haven't looked), but if
${RAD_REQUEST}{'attribute'} was an array of values rather than a
scalar, that should allow the hash to be writable.
That is how the module works for multi-valued attributes: $
{RAD_REQUEST}{'attribute'} is a ref to an array.
For single-valued attributes, it's just the attribute value. So
you'd have to be careful if you're adding values to an attribute that
starts out with a single value, but it sounds like it should work.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
On Saturday 18 March 2006 21:40, George C. Kaplan wrote:
On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
Boian Jordanov [EMAIL PROTECTED] wrote:
So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
Because perl hashes are not ordered.
The only requirement is that attributes of the same name be ordered.
This may change the way the module works (I haven't looked), but if
${RAD_REQUEST}{'attribute'} was an array of values rather than a
scalar, that should allow the hash to be writable.
That is how the module works for multi-valued attributes: $
{RAD_REQUEST}{'attribute'} is a ref to an array.
For single-valued attributes, it's just the attribute value. So
you'd have to be careful if you're adding values to an attribute that
starts out with a single value, but it sounds like it should work.
It will be easy to change RAD_XXX to become writable then.
--
Best Regards,
Boian Jordanov
SNE
Orbitel - Next Generation Telecom
tel. +359 2 4004 723
tel. +359 2 4004 002
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
On Mar 17, 2006, at 5:45 PM, Phil Mayers wrote: George C. Kaplan wrote: Or you're using an authentication method (Kerberos, in my case) that isn't one of the standard methods assocated with the authorization module. (As Alan points out, you have to know what you're doing to make this work). Hmm. PAP seems to be the big problem area in these situations. I have a notion the correct thing would be: [...] Right; you configure each authorization module to set the appropriate Auth-Type. Sort-of bad example. In theory, you should only ever need to set that if you have 1 competing module for a particular Auth-Type. My example did, your use case by the sounds of it does not. I don't think I understand your examples. A NAS is sending a User- Name and User-Password, and somehow I have to tell radiusd, Use Kerberos to authenticate these users. I don't see how I can do that except by setting 'Auth-Type = Kerberos' *somewhere*. Out of interest, are you finding rlm_krb5 stable? Under high concurrency? Yes, except (and it's a big except) for signals. I posted something about this a little while ago: when radiusd gets a HUP or TERM signal, it sometimes becomes unresponsive, using 98% CPU. A 'kill -9' is usually necessary to get it unstuck. I'm not sure, but I think it happens when a signal arrives just as rlm_krb5 is being called. If I don't signal the daemon, it hums along with no problems. -- George C. Kaplan[EMAIL PROTECTED] Communication Network Services510-643-0496 University of California at Berkeley - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
General question about authentication/authorization
Hi, 1.) in the users-file, I can only check for attributes provided by the request - correct? 2.) in the users-file, if an entry matches all check-attributes, I can specify an Auth/Autz-Type - correct? 3.) in the users-file, if I do not specify the Auth/Autz-Type the radius is taken the requested Type automatically - correct? 4.) Authentication is comparing a password - correct? 5.) Authorization is even if a password is correct, the user may not use/do something - correct? 6.) Authorization is done by providing appropriate reply-attributes - correct? Now the big question: If I have an user who is authenticate, meaning correct username + password whereas the password is stored in LDAP. I want to replay attributes according th some other information stored in LDAP - how can I do such a thing, like: IF ldap-attribute::xy == valid_1 THEN RETURN ldap-attribute::IP-good, ELSIF dap-attribute::xy == valid_2 THEN RETURN ldap-attribute::IP-better, ELSE RETURN ldap-attribute::IP-bad Thanks Florian -- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Martensstr. 1 91052 Erlangen Germany Tel.: +499131 8527813 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question about authentication/authorization
Florian Prester wrote: Hi, 1.) in the users-file, I can only check for attributes provided by the request - correct? I think so 2.) in the users-file, if an entry matches all check-attributes, I can specify an Auth/Autz-Type - correct? yes 3.) in the users-file, if I do not specify the Auth/Autz-Type the radius is taken the requested Type automatically - correct? Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set Auth-Type based on the incoming requests e.g. the mschap modules sets Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the chap and eap modules. pap is a bit more complex and has changed in CVS head. Generally, you should not set Auth-Type in the users file. It's a sign you're doing something wrong. Perhaps if you told us what you're trying to do? 4.) Authentication is comparing a password - correct? Not necessarily. If it's a PAP request, it's possible to check the plaintext password in the request by straight comparison, hashes comparison, or callout to another system (LDAP, PAM) Other authentication mechanisms may perform cryptographic operations on passwords at the server and challenges from the NAS to generate the servers idea of the correct response and compare it to the client-supplied response (chap, mschap). Others still may reply to the NAS with a server-generated challenge (EAP). 5.) Authorization is even if a password is correct, the user may not use/do something - correct? No. That's the common meaning. The authorize section in FreeRadius is something else. Please read doc/aaa.txt 6.) Authorization is done by providing appropriate reply-attributes - correct? If you mean user is OK, can/can't do something-type authorization, then yes some NASes can do that based on attributes in the radius reply. Now the big question: If I have an user who is authenticate, meaning correct username + password whereas the password is stored in LDAP. I want to replay attributes according th some other information stored in LDAP - how can I do such a thing, like: IF ldap-attribute::xy == valid_1 THEN RETURN ldap-attribute::IP-good, ELSIF dap-attribute::xy == valid_2 THEN RETURN ldap-attribute::IP-better, ELSE RETURN ldap-attribute::IP-bad I don't understand that I'm afraid. I think that's because your question is based on faulty assumptions about the meaning of FreeRadius authorize and authenticate sections. Please have a look at the docs. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question about authentication/authorization
Thank you for your answer, I try to specify my problem mor clearly. Phil Mayers wrote: Florian Prester wrote: Hi, 1.) in the users-file, I can only check for attributes provided by the request - correct? I think so ok 2.) in the users-file, if an entry matches all check-attributes, I can specify an Auth/Autz-Type - correct? yes ok 3.) in the users-file, if I do not specify the Auth/Autz-Type the radius is taken the requested Type automatically - correct? Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set Auth-Type based on the incoming requests e.g. the mschap modules sets Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the chap and eap modules. pap is a bit more complex and has changed in CVS head. Generally, you should not set Auth-Type in the users file. It's a sign you're doing something wrong. Perhaps if you told us what you're trying to do? ok 4.) Authentication is comparing a password - correct? Not necessarily. If it's a PAP request, it's possible to check the plaintext password in the request by straight comparison, hashes comparison, or callout to another system (LDAP, PAM) Other authentication mechanisms may perform cryptographic operations on passwords at the server and challenges from the NAS to generate the servers idea of the correct response and compare it to the client-supplied response (chap, mschap). Others still may reply to the NAS with a server-generated challenge (EAP). ok 5.) Authorization is even if a password is correct, the user may not use/do something - correct? No. That's the common meaning. The authorize section in FreeRadius is something else. Please read doc/aaa.txt so, AFAIK authorization is retreiving user-information from a source? 6.) Authorization is done by providing appropriate reply-attributes - correct? If you mean user is OK, can/can't do something-type authorization, then yes some NASes can do that based on attributes in the radius reply. Now the big question: If I have an user who is authenticate, meaning correct username + password whereas the password is stored in LDAP. I want to replay attributes according th some other information stored in LDAP - how can I do such a thing, like: IF ldap-attribute::xy == valid_1 THEN RETURN ldap-attribute::IP-good, ELSIF dap-attribute::xy == valid_2 THEN RETURN ldap-attribute::IP-better, ELSE RETURN ldap-attribute::IP-bad I don't understand that I'm afraid. I think that's because your question is based on faulty assumptions about the meaning of FreeRadius authorize and authenticate sections. Please have a look at the docs. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ok, lets assume a user can authenticate because he/she supplys a valid username/password e.g. using PAP. Now the user is authenticated. But I want to allow access to something not only if the user is authenticated, but also if a given attribute is present in the users ldap enty. How can I do that? Thanks Florian -- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Martensstr. 1 91052 Erlangen Germany Tel.: +499131 8527813 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question about authentication/authorization
Florian Prester wrote:
Now the big question:
If I have an user who is authenticate, meaning correct username +
password whereas the password is stored in LDAP.
I want to replay attributes according th some other information
stored in LDAP - how can I do such a thing, like:
IF ldap-attribute::xy == valid_1 THEN RETURN ldap-attribute::IP-good,
ELSIF dap-attribute::xy == valid_2 THEN RETURN
ldap-attribute::IP-better,
ELSE RETURN ldap-attribute::IP-bad
ok, lets assume a user can authenticate because he/she supplys a valid
username/password e.g. using PAP. Now the user is authenticated.
But I want to allow access to something not only if the user is
authenticated, but also if a given attribute is present in the users
ldap enty.
How can I do that?
We faced a similar problem recently. The issue is that the rlm_ldap
module is designed to work in the same way as the 'users' file: compare
incoming request attributes to check attributes from LDAP, and
authorize the user if they match.
If you control the LDAP schema, then you can do what you want by simply
adding the reply attributes to each user's LDAP profile. Users with 'xy
== valid_1' get 'IP-good', users with 'xy == valid_2' get 'IP-better',
and so on.
If you *don't* control the LDAP schema (as in our case), you'll have to
something else. We combined LDAP with rlm_perl, something like this:
- Define site-local RADIUS attributes in the dictionary, and map them as
check items to the LDAP attributes of interest in 'ldap.attrmap'.
- Define an Autz-Type using both LDAP and rlm_perl, in 'radiusd.conf':
authorize {
...
Autz-Type our-autz {
ldap {
notfound = reject
}
perl {
notfound = reject
}
}
...
}
- Configure rlm_perl to call a perl script to compare the retrieved LDAP
attributes according to your policy and add the appropriate reply
attributes.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_perl question (was Re: General question about authentication/authorization)
Phil Mayers wrote: Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set Auth-Type based on the incoming requests e.g. the mschap modules sets Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the chap and eap modules. pap is a bit more complex and has changed in CVS head. Generally, you should not set Auth-Type in the users file. It's a sign you're doing something wrong. Perhaps if you told us what you're trying to do? I've been wondering about this, in relation to the rlm_perl module. We see Don't set Auth-Type in the users file all over the place, but with rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for authorization, I *have to* set the Auth-Type in the users file. This isn't really a problem (since it all works the way I want), but it seems inconsistent, especially considering that other modules can modify the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST made read-only? -- George C. Kaplan[EMAIL PROTECTED] Communication Network Services510-643-0496 University of California at Berkeley - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question about authentication/authorization
Alan DeKok wrote: 5.) Authorization is even if a password is correct, the user may not use/do something - correct? Yes. Strictly speaking, during the authorisation section of the FR config, you haven't determined the password is correct yet. You don't need me to tell you this of course - the reason I mention it is that I was under the impression the OP was thinking in terms of the more common definition where the flow is authen-authz-acct. Of course in Radius (and thus FR) the order of authz and authn is not that important since the authen algorithm (the only commonly important input to authz aside from OK/NO) is known at request time (except in EAP I guess). - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
George C. Kaplan [EMAIL PROTECTED] wrote: I've been wondering about this, in relation to the rlm_perl module. We see Don't set Auth-Type in the users file all over the place, but with rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for authorization, I *have to* set the Auth-Type in the users file. It's not don't set Auth-Type in the users file, it's don't set it ANYWHERE. Almost all instances of people forcibly setting it are wrong. There *are* a few places where setting it is OK, but those are rare, and require carefully analyzing what you're doing. This isn't really a problem (since it all works the way I want), but it seems inconsistent, especially considering that other modules can modify the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST made read-only? No idea. They should be writable. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question about authentication/authorization
Florian Prester wrote:
so, AFAIK authorization is retreiving user-information from a source?
Yes, however see Alan's reply - his yes and my no are not as
contradictory as they might seem (it's purely semantics). See below.
ok, lets assume a user can authenticate because he/she supplys a valid
username/password e.g. using PAP. Now the user is authenticated.
But I want to allow access to something not only if the user is
authenticated, but also if a given attribute is present in the users
ldap enty.
How can I do that?
Well, if the user is REJECTed, regardless of what is put in the reply
packet[1], as long as the NAS is sane then they won't get access to
anything, so it should not matter if you put the attributes in but then
reject them.
For example. Say you are using LDAP, and your NAS gives admin privs.
based on the Class attribute in the Radius reply (unlikely, but it's a
simple example):
dn: cn=username,dc=domain,dc=com
cn: username
radiusClass: Administrator
userPassword: APassWord
...and:
authorize {
preprocess
ldap
}
authenticate {
Auth-Type LDAP {
ldap
}
}
post-auth {
ippool
somelogging
Auth-Type REJECT {
somerejectlogging
}
}
The flow is:
1. request comes in, User-Name==username
2. authorize run
i. preprocess run
ii. ldap run
* LDAP search done - entry found
* Ldap-UserDn is set to entry DN
* Class==Administrator is set
* Auth-Type==LDAP is set
3. authenticate run, Auth-Type LDAP subsection ONLY,
* ldap module run - does LDAP simple bind to Ldap-UserDn with
User-Password
* if password OK - Accept
* if password NO - Reject
4. post-auth run
* if Accept - run main body
* ippool run
* somelogging run
* else if Reject - run Auth-Type REJECT subsection ONLY
* somerejectlogging run
So if the user gives the wrong password, the Class attribute may[1] be
added to the reply, but they'll still get a REJECT so does it matter? If
they give the right password, they'll be accepted AND given the admin privs.
The only time it matters whether auth succeeds or rejects is when the
attribute you're returning is a dynamic resource which you absolutely do
not want to allocate for failed requests e.g. an IP assignment. If
that's the case, then you'd need to do something in the post-auth
section where you can differentiate between auth success and failure.
The only modules that implement post-auth handlers useful for such
dynamic allocation purposes are exec, files, ippool, perl and policy.
But I'm guessing it's a static thing and you can go with simple LDAP
attributes, especially given that...
[1] In recent versions of FreeRadius (1.1.0 and up?) the server will
automatically strip everything from a REJECT except EAP-Message,
Message-Authenticator and Reply-Message (and Proxy-State). This is
specified by the RFCs anyway. So in recent versions of the server, the
Class attribute wouldn't even go to the NAS, so it truly doesn't matter
if you add it then fail it. That's a recent change though.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
George C. Kaplan wrote:
Phil Mayers wrote:
Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
Auth-Type based on the incoming requests e.g. the mschap modules sets
Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the
chap and eap modules. pap is a bit more complex and has changed in
CVS head.
Generally, you should not set Auth-Type in the users file. It's a sign
you're doing something wrong. Perhaps if you told us what you're trying
to do?
I've been wondering about this, in relation to the rlm_perl module. We
see Don't set Auth-Type in the users file all over the place, but with
rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
authorization, I *have to* set the Auth-Type in the users file.
You shouldn't really ever have to set it AT ALL, EVER, though some of
the fixes that make that a doable proposition are only in newer (CVS?)
versions of FR - e.g. the reworking of the PAP module, optional setting
of the Auth-Type on the ldap module, {algo} detection in the
User-Password field, and so forth.
As far as I can tell, there are really 2 classes of FreeRadius module:
1. Authentication algorithm modules - these do two things:
* in authorize, examine the request for attributes indicating the
request is using the algorithm they implement. If present, set Auth-Type
to AUTHALGO.
* in authenticate, get run by Auth-Type AUTHALGO conditionals,
and execute the auth algorithm using the request data and any other data
(e.g. check items added by other modules)
2. Authorization modules that add data to config items (and other
things as well, but mainly that)
There is a special case of the first which hand off algorithms to
external sources - for example, the ldap and pam authenticate handler
really implements PAP, but by doing something different (and it's
further complicated by the fact that ldap is ALSO an authorization
module AND it's authenticate function is dependent on configure items it
adds at authorize time - specifically Ldap-UserDN)
The only case I can see where you need to Auth-Type is when you have a
need for 1 copy of an authentication algorithm with different
parameters e.g. for different services. This can typically be handled
more cleanly IMHO with Autz-Type. So, for example:
modules {
# shared modules - no state, irrelevant which service they answer
chap {
authtype = CHAP
}
# service 1 modules
mschap mschap1 {
# we'll to MS-CHAP internally
authtype = MS-CHAP1
}
files files1 {
userfile = ${confdir}/users1
}
# service 2 modules
mschap mschap2 {
# we'll call out to ntlm_auth DOMAIN1
ntlm_auth = /opt/samba_DOMAIN1/bin/ntlm_auth --args
authtype = MS-CHAP2
}
files files2 {
userfile = ${confdir}/users2
}
# service 3 modules
mschap mschap3 {
# 2nd install of samba e.g. no interdomain trust between domains
# so join both!
ntlm_auth = /opt/othersamba/bin/ntlm_auth --args
authtype = MS-CHAP3
}
files files3 {
userfile = ${confdir}/users3
}
}
authorize {
preprocess
files
Autz-Type SERVICE1 {
files1
mschap1
chap
}
Autz-Type SERVICE2 {
files2
mschap2
chap
}
Autz-Type SERVICE3 {
files3
mschap3
chap
}
}
authenticate {
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP1 {
mschap1
}
Auth-Type MS-CHAP2 {
mschap2
}
Auth-Type MS-CHAP3 {
mschap3
}
}
/etc/raddb/users:
DEFAULT Huntgroup-Name==service1, Autz-Type := SERVICE1
DEFAULT Huntgroup-Name==service2, Autz-Type := SERVICE2
DEFAULT Huntgroup-Name==service3, Autz-Type := SERVICE3
This isn't really a problem (since it all works the way I want), but it
seems inconsistent, especially considering that other modules can modify
the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
I can't say specifically in that case. It does seem odd. But that still
doesn't make setting Auth-Type any cleaner ;o)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
Phil Mayers wrote:
George C. Kaplan wrote:
I've been wondering about this, in relation to the rlm_perl module. We
see Don't set Auth-Type in the users file all over the place, but with
rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
authorization, I *have to* set the Auth-Type in the users file.
You shouldn't really ever have to set it AT ALL, EVER, though some of
the fixes that make that a doable proposition are only in newer (CVS?)
versions of FR - e.g. the reworking of the PAP module, optional setting
of the Auth-Type on the ldap module, {algo} detection in the
User-Password field, and so forth.
[...]
The only case I can see where you need to Auth-Type is when you have a
need for 1 copy of an authentication algorithm with different
parameters e.g. for different services.
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing to make
this work).
This can typically be handled
more cleanly IMHO with Autz-Type. So, for example:
modules {
# shared modules - no state, irrelevant which service they answer
chap {
authtype = CHAP
}
# service 1 modules
mschap mschap1 {
# we'll to MS-CHAP internally
authtype = MS-CHAP1
}
Right; you configure each authorization module to set the appropriate
Auth-Type.
In my case, I'm using a combination of LDAP and perl for authorization
(see my reply to Florian Prester earlier) and Kerberos for
authentication. There's no place in the LDAP module config to set
Auth-Type (although maybe that'll change soon, as you note), and I
couldn't do it in the perl module (in the config or the script) either.
This isn't really a problem (since it all works the way I want), but it
seems inconsistent, especially considering that other modules can modify
the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
I can't say specifically in that case. It does seem odd. But that still
doesn't make setting Auth-Type any cleaner ;o)
Well, if you're using rlm_perl for authorization, you're already doing
something out of the ordinary, so you really need to know what you're
doing in the first place. It seems better to set the Auth-Type there
than in the users file, where the more mundane parts of the RADIUS
config live.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl question (was Re: General question about authentication/authorization)
George C. Kaplan wrote:
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing to make
this work).
Hmm. PAP seems to be the big problem area in these situations. I have a
notion the correct thing would be:
authorize {
preprocess
chap
mshcap
eap
files
# final auth type
pap
}
authenticate {
Auth-Type PAP {
# how to auth PAP requests
AMODULE # default unix
BMODULE # default pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
# why does eap not live inside an Auth-Type?
Auth-Type EAP {
eap
}
}
...which would approximate the current defaults. What would be really
neat for cleanness would be Autz-Type subsections inside authenticate, e.g.:
authenticate {
Autz-Type SERVICE1 {
Auth-Type PAP {
pam
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap-DOMAIN1
}
}
Autz-Type SERVICE2 {
Auth-Type PAP {
ldap2
}
}
}
Problem is that's not terribly backwards-compatible.
Right; you configure each authorization module to set the appropriate
Auth-Type.
Sort-of bad example. In theory, you should only ever need to set that if
you have 1 competing module for a particular Auth-Type. My example did,
your use case by the sounds of it does not.
Out of interest, are you finding rlm_krb5 stable? Under high concurrency?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Question about Authentication flow.
I'm trying to understand how to send dynamic replies based on user. If I authenticate via LDAP or some other mechanism, I can authorize via the sql tables? Is that right? -Bob - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about Authentication flow.
Robert Myers [EMAIL PROTECTED] wrote: If I authenticate via LDAP or some other mechanism, I can authorize via the sql tables? Yes. All of the modules are completely independent of each other. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about Authentication flow.
So let me ask you this, this allows me to set specific replies for each user. How would I go about setting replies for groups of users, when I don't know the specific usernames? Like if I'd want to assign a specific reply based on an LDAP group? -Bob Alan DeKok wrote: Robert Myers [EMAIL PROTECTED] wrote: If I authenticate via LDAP or some other mechanism, I can authorize via the sql tables? Yes. All of the modules are completely independent of each other. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about Authentication flow.
Robert Myers [EMAIL PROTECTED] wrote: How would I go about setting replies for groups of users, when I don't know the specific usernames? Like if I'd want to assign a specific reply based on an LDAP group? You would read the documentation for the LDAP module, and see how to use LDAP groups. The server *does* come with documentation, and many examples. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Question about Authentication flow.
The documentation is how I found out what questions to ask. :) Thanks for the point in the right direction. -Bob Alan DeKok wrote: Robert Myers [EMAIL PROTECTED] wrote: How would I go about setting replies for groups of users, when I don't know the specific usernames? Like if I'd want to assign a specific reply based on an LDAP group? You would read the documentation for the LDAP module, and see how to use LDAP groups. The server *does* come with documentation, and many examples. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
