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
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.
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
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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
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.
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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
"George C. Kaplan" <gckaplan@ack.berkeley.edu> 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.
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)
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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
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?
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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
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.
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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
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
Boian Jordanov <bjordanov@orbitel.bg> 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.
On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
Boian Jordanov <bjordanov@orbitel.bg> 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 gckaplan@ack.berkeley.edu Communication & Network Services 510-643-0496 University of California at Berkeley
On Saturday 18 March 2006 21:40, George C. Kaplan wrote:
On Mar 18, 2006, at 7:13 AM, Alan DeKok wrote:
Boian Jordanov <bjordanov@orbitel.bg> 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
Florian Prester <Florian.Prester@rrze.uni-erlangen.de> wrote:
1.) in the users-file, I can only check for attributes provided by the request - correct?
Yes.
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. The type may be set from another module.
4.) Authentication is comparing a password - correct?
No. Authentication is validating credentials. e.g. an EAP-TLS client certificate. No password is required.
5.) Authorization is even if a password is correct, the user may not use/do something - correct?
Yes.
6.) Authorization is done by providing appropriate reply-attributes - correct?
Sort of. Since there are multiple machines involved, there are multiple kinds of authorization. The server may decide you're not authorized to use that NAS, and reject you. Or, it may decide you're authorized, but you're only authorized to do certain things. So it returns reply attributes that tell the NAS to apply authorization rules. The NAS may then decide it doesn't like the servers response, and stil reject you.
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
Hmm... the first thing that comes to mind is the Perl module. Alan DeKok.
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).
participants (5)
-
Alan DeKok -
Boian Jordanov -
Florian Prester -
George C. Kaplan -
Phil Mayers