[FreeRADIUS-Statistics-Type to list home agent server and general question about status server]
Hello, Here's two questions about radius statistics (status server) 1. By looking at the freeradius-snmp.pl from sky networks, I notice something : - It uses FreeRADIUS-Statistics-Type = 63, and I haven't found documentation about it in status virtual server. By the way, it allows to list radius client ip without knowing them by incrementing the Client Number, which is great. echo Message-Authenticator = 0xd9380c451e4bf78659144474b673b931, FreeRADIUS-Statistics-Type = 63, FreeRADIUS-Stats-Client-Number = 4 | radclient 127.0.0.1:18120 status adminsecret Then is there a FreeRADIUS-Statistics-Type number to do the same for home server IP (not the 131 one) ? # All packets for a home server IP / port # FreeRADIUS-Statistics-Type = 131 # FreeRADIUS-Stats-Server-IP-Address = 192.168.1.2 # FreeRADIUS-Stats-Server-Port = 1812 2. Another question about specific query for specific client IP www1# echo Message-Authenticator = 0xd9380c451e4bf78659144474b673b931, FreeRADIUS-Statistics-Type = 35, FreeRADIUS-Stats-Client-IP-Address = X, FreeRADIUS-Stats-Server-IP-Address = Y, FreeRADIUS-Stats-Server-Port = 1812 | radclient 127.0.0.1:18120 status adminsecret Received response ID 169, code 2, length = 464 FreeRADIUS-Total-Access-Requests = 398 FreeRADIUS-Total-Access-Accepts = 6322 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 6322 FreeRADIUS-Total-Auth-Duplicate-Requests = 0 FreeRADIUS-Total-Auth-Malformed-Requests = 0 FreeRADIUS-Total-Auth-Invalid-Requests = 0 FreeRADIUS-Total-Auth-Dropped-Requests = 0 FreeRADIUS-Total-Auth-Unknown-Types = 0 FreeRADIUS-Total-Accounting-Requests = 12 FreeRADIUS-Total-Accounting-Responses = 24 FreeRADIUS-Total-Acct-Duplicate-Requests = 0 FreeRADIUS-Total-Acct-Malformed-Requests = 0 FreeRADIUS-Total-Acct-Invalid-Requests = 0 FreeRADIUS-Total-Acct-Dropped-Requests = 0 FreeRADIUS-Total-Acct-Unknown-Types = 0 FreeRADIUS-Stats-Client-IP-Address = X FreeRADIUS-Stats-Server-IP-Address = Y FreeRADIUS-Stats-Server-Port = 1812 FreeRADIUS-Total-Access-Requests = 4 FreeRADIUS-Total-Access-Accepts = 4 FreeRADIUS-Total-Access-Rejects = 0 FreeRADIUS-Total-Access-Challenges = 0 FreeRADIUS-Total-Auth-Responses = 4 FreeRADIUS-Total-Auth-Duplicate-Requests = 0 FreeRADIUS-Total-Auth-Malformed-Requests = 0 FreeRADIUS-Total-Auth-Invalid-Requests = 0 FreeRADIUS-Total-Auth-Dropped-Requests = 0 FreeRADIUS-Total-Auth-Unknown-Types = 0 FreeRADIUS-Total-Accounting-Requests = 7 FreeRADIUS-Total-Accounting-Responses = 7 FreeRADIUS-Total-Acct-Duplicate-Requests = 0 FreeRADIUS-Total-Acct-Malformed-Requests = 0 FreeRADIUS-Total-Acct-Invalid-Requests = 0 FreeRADIUS-Total-Acct-Dropped-Requests = 0 FreeRADIUS-Total-Acct-Unknown-Types = 0 Why does it gives first global statistics, and then the statistics we want (eg stat for client) ? Couldn't we have just the one we've done the query for ? Thanx Thomas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [FreeRADIUS-Statistics-Type to list home agent server and general question about status server]
Thomas Fagart wrote: Hello, Here's two questions about radius statistics (status server) 1. By looking at the freeradius-snmp.pl from sky networks, I notice something : - It uses FreeRADIUS-Statistics-Type = 63, and I haven't found documentation about it in status virtual server. The flags are a bit mask. See share/dictionary.freeradius. By the way, it allows to list radius client ip without knowing them by incrementing the Client Number, which is great. Yup. Then is there a FreeRADIUS-Statistics-Type number to do the same for home server IP (not the 131 one) ? Nope. 2. Another question about specific query for specific client IP ... Why does it gives first global statistics, and then the statistics we want (eg stat for client) ? Couldn't we have just the one we've done the query for ? Sure. Send a patch. See also radmin. It will print out more detailed statistics, including lists of home servers. 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)
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
general question
I know, that every single of the requirements described below is possible with freeradius. The question is, whether all fits together in a single authentication process: - do an 802.1x authentication using certificates - extract the username (here: a machine name in the form host/26tef001.tde002.mydomain.net) from the certificate and query AD, whether the associated account is valid proceed, if okay, else reject user. -if valid, take that username host/... and ask a mysql database which vlan that client shall get assigned and assign the vlan. Thanks Norbert Wegener - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General Question..
FreeRadius users mailing list freeradius-users@lists.freeradius.org on August 17, 2005 at 15:47 -0800 wrote: Can we use Radius/LDAP to do this. What I was hope we can do is as follow: everyone will get one user-id/password But for every service we will create a boolean attribute. All services, dialup/wireless/vpn/etc will use one radius server for both Auth(authenticate/authorize). The question is can FreeRadius(or any radius) be configured to as the LDAP for the correct service attribute and give access both base on the user-id/password and what the value of the services? Sort of. The best bet is to use the LDAP posixgroup objectclass -- then you can force certain radius clients to require a specific group membership. Let me know when you get closer to implementation and I can help you with some config files. -kb -- Kris Benson, CCP, I.S.P. Technical Analyst, District Projects School District #57 (Prince George) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
General Question..
Hello, I am new to Radius and Free Radius, so forgave me if this question has been asked or it is crazy.We are in process of change all our authentication and authorization.At the moment every "service" has it's own user-id/password database. Thus authentication/authorization per service is simple. want to deny access to a given user, disable his/her password or that service.As you can imagine this has a big overhead and users have to remember many user-id/password per.Can we use Radius/LDAP to do this.What I was hope we can do is as follow:everyone will get one user-id/password But for every service we will create a boolean attribute. All services, dialup/wireless/vpn/etc will use one radius server for both Auth(authenticate/authorize).The question is can FreeRadius(or any radius) be configured to as the LDAP for the correct service attribute and give access both base on the user-id/password and what the value of the services?Thank you all for your help. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: General Question..
So just set Auth-Type for the user to Reject. We do this for suspended (non paying users) until they pay up. No changing password this way. Brent From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Behzad Barzideh Sent: Wednesday, August 17, 2005 4:47 PM To: freeradius-users@lists.freeradius.org Subject: General Question.. Hello, I am new to Radius and Free Radius, so forgave me if this question has been asked or it is crazy. We are in process of change all our authentication and authorization. At the moment every service has it's own user-id/password database. Thus authentication/authorization per service is simple. want to deny access to a given user, disable his/her password or that service. As you can imagine this has a big overhead and users have to remember many user-id/password per. Can we use Radius/LDAP to do this. What I was hope we can do is as follow: everyone will get one user-id/password But for every service we will create a boolean attribute. All services, dialup/wireless/vpn/etc will use one radius server for both Auth(authenticate/authorize). The question is can FreeRadius(or any radius) be configured to as the LDAP for the correct service attribute and give access both base on the user-id/password and what the value of the services? Thank you all for your help. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question on Radius/802.1x
Thank you all for your help. Andrea -- Andrea G. Forte On Thu, 18 Nov 2004, Joe Matuscak wrote: On Thu, 18 Nov 2004, Andrea G. Forte wrote: The assumption made here is that the authenticator is the AP. I believe things would be much easier and still safe if one authenticator would control a group of APs and not just be one itself. This group of APs could be a subnet or a smaller group, but at least within this group the handoff would be much faster. The authenticator would act in the same way except that it would do the job for a group of APs and not for just one. Thats pretty much what Wireless Domain Services (WDS) on the Cisco Aironet APs does. One of the APs does the direct communication to the radius server and then caches that for its client APs. Take a look at: http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_configuration_example09186a00801c951f.shtml Joe Matuscak Rohrer Corporation 717 Seville Road Wadsworth, Ohio 44281 (330)335-1541 [EMAIL PROTECTED] - 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: General question on Radius/802.1x
The supplicant needs to authenticate anytime it wishes to get L2 access. It is an extention of the Authenticate Associate MAC processes. Why the authentication is done every single time L2 handoff occurs? Usually for 802.11b, I can cover a building floor with about two or three APs and for 802.11a each AP covers even a smaller area. This means that I will have to authenticate even if I move from one room to another (exageration!). This to me sounds like an uneccesary overhead. There is a fundamental authentication/security problem you are glossing over: How does the AP you roam to know who you are? How does one AP know you authenticated against another? How does the new AP know the session key you were using with the prior one? If it doesn't how to make a new one? How does that AP trust the other AP? How does it know you are really the same station? and not some hacker spoofing the same MAC address? Answer those questions throughly and you will be on the way to solving the roaming problem. The assumption made here is that the authenticator is the AP. I believe things would be much easier and still safe if one authenticator would control a group of APs and not just be one itself. This group of APs could be a subnet or a smaller group, but at least within this group the handoff would be much faster. The authenticator would act in the same way except that it would do the job for a group of APs and not for just one. If this would be done than all the questions above would have their answers. What is your opinion? Andrea - 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: General question on Radius/802.1x
The assumption made here is that the authenticator is the AP. I believe things would be much easier and still safe if one authenticator would control a group of APs and not just be one itself. This group of APs could be a subnet or a smaller group, but at least within this group the handoff would be much faster. The authenticator would act in the same way except that it would do the job for a group of APs and not for just one. If this would be done than all the questions above would have their answers. What is your opinion? This is how some of the switched wireless systems work. However, if you roam from an AP on one switch to an AP on another switch, you still have the same issue. It reduces the volume of traffic but doesn't make it disappear altogether. You can also reduce the amount of reauthentication traffic if your supplicant, authenticator and authentication server all support Session Resumption. This works on the premise that at the point where the Session-Timeout times out, if the supplicant and the authenticator both know the master key, then there's no need to trouble the authentication server. Normally, there is a time and/or number of reauthentications limit on this process before a complete reauthentication has to take place. Regards, Guy Andrea - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question on Radius/802.1x
On Thu, 18 Nov 2004, Andrea G. Forte wrote: The assumption made here is that the authenticator is the AP. I believe things would be much easier and still safe if one authenticator would control a group of APs and not just be one itself. This group of APs could be a subnet or a smaller group, but at least within this group the handoff would be much faster. The authenticator would act in the same way except that it would do the job for a group of APs and not for just one. Thats pretty much what Wireless Domain Services (WDS) on the Cisco Aironet APs does. One of the APs does the direct communication to the radius server and then caches that for its client APs. Take a look at: http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_configuration_example09186a00801c951f.shtml Joe Matuscak Rohrer Corporation 717 Seville Road Wadsworth, Ohio 44281 (330)335-1541 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question on Radius/802.1x
On 11/17/2004 11:01 AM, Andrea G. Forte wrote: Hi all, I am new to WPA/802.11i and I have a few doubts. I hope you can help me. What is not clear to me is how often a supplicant needs to authenticate to the server...is it everytime the supplicant performs a L2 handoff? The supplicant needs to authenticate anytime it wishes to get L2 access. It is an extention of the Authenticate Associate MAC processes. It seems like if the supplicant does not authenticate it does not get an IP address, so I would think that authentication would happen only when the supplicant performs L3 and not L2 handoff. Am I right? No. 802.1x authentication is L2 access, and has nothing to do with IP addressing. If a station moves to another AP, it must become authenticated (somehow) at that AP. Either by another AAA exchange, or a back-end protocol between AP's and maybe a AAA server (See 802.11f) or a central controller (see CAPWAP). Making authentication work quickly across handoffs is a current working effort in several groups. Obviously, IP topology becomes a configuration issue, but not an authentication problem, per se. Another doubt I have is: if I am a malicious user and set a static IP address and know the key, am I able to use the network or am I blocked somehow by the authenticator? How does the authenticator know if it has to block my ports or not when I connect to the AP? Your port is blocked (by your MAC address and MAC state) at the AP until you pass authentication. IP has nothing to do with it. I'm not sure what the key you know, but session keys are derived dynamically from the master key. In fact you must know your key, as it's not exchanged over the network. It could be your account password, or a machine certificate. What's different from WEP is the master key is unique per user, and the derived session key is unique for every authentication instance. Your help is very much appreciated. Thank you. Andrea Forte Good luck, Dave. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: General question on Radius/802.1x
On 11/17/2004 11:01 AM, Andrea G. Forte wrote: Hi all, I am new to WPA/802.11i and I have a few doubts. I hope you can help me. What is not clear to me is how often a supplicant needs to authenticate to the server...is it everytime the supplicant performs a L2 handoff? The supplicant needs to authenticate anytime it wishes to get L2 access. It is an extention of the Authenticate Associate MAC processes. Why the authentication is done every single time L2 handoff occurs? Usually for 802.11b, I can cover a building floor with about two or three APs and for 802.11a each AP covers even a smaller area. This means that I will have to authenticate even if I move from one room to another (exageration!). This to me sounds like an uneccesary overhead. Another doubt I have is: if I am a malicious user and set a static IP address and know the key, am I able to use the network or am I blocked somehow by the authenticator? How does the authenticator know if it has to block my ports or not when I connect to the AP? Your port is blocked (by your MAC address and MAC state) at the AP until you pass authentication. IP has nothing to do with it. I'm not sure what the key you know, but session keys are derived dynamically from the master key. In fact you must know your key, as it's not exchanged over the network. It could be your account password, or a machine certificate. What's different from WEP is the master key is unique per user, and the derived session key is unique for every authentication instance. How is my port blocked? Also, if I return to an AP I previously authenticated with, does this AP have some sort of allowed MAC list without having me to start the whole authentication process over (i.e. with exchange of certificates, etc.) for a second time? Good luck, Dave. Thank you Dave for your precious help. Andrea - 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: General question on Radius/802.1x
On 11/18/2004 12:20 AM, Andrea G. Forte wrote: On 11/17/2004 11:01 AM, Andrea G. Forte wrote: Hi all, I am new to WPA/802.11i and I have a few doubts. I hope you can help me. What is not clear to me is how often a supplicant needs to authenticate to the server...is it everytime the supplicant performs a L2 handoff? The supplicant needs to authenticate anytime it wishes to get L2 access. It is an extention of the Authenticate Associate MAC processes. Why the authentication is done every single time L2 handoff occurs? Usually for 802.11b, I can cover a building floor with about two or three APs and for 802.11a each AP covers even a smaller area. This means that I will have to authenticate even if I move from one room to another (exageration!). This to me sounds like an uneccesary overhead. There is a fundamental authentication/security problem you are glossing over: How does the AP you roam to know who you are? How does one AP know you authenticated against another? How does the new AP know the session key you were using with the prior one? If it doesn't how to make a new one? How does that AP trust the other AP? How does it know you are really the same station? and not some hacker spoofing the same MAC address? Answer those questions throughly and you will be on the way to solving the roaming problem. Another doubt I have is: if I am a malicious user and set a static IP address and know the key, am I able to use the network or am I blocked somehow by the authenticator? How does the authenticator know if it has to block my ports or not when I connect to the AP? Your port is blocked (by your MAC address and MAC state) at the AP until you pass authentication. IP has nothing to do with it. I'm not sure what the key you know, but session keys are derived dynamically from the master key. In fact you must know your key, as it's not exchanged over the network. It could be your account password, or a machine certificate. What's different from WEP is the master key is unique per user, and the derived session key is unique for every authentication instance. How is my port blocked? Until you pass authentication, only EAPOL data frames will be processed, all other data frames will be discarded. This is what 802.11i and 802.1x standards describe. It's part of the operation of an AP that adheres to those standards. Also, if I return to an AP I previously authenticated with, does this AP have some sort of allowed MAC list without having me to start the whole authentication process over (i.e. with exchange of certificates, etc.) for a second time? It might. There is a Re-Associate control frame that can be used. However, there is still the problem of proving you are whom you say you are. I've forgotten how much of that process is settled. Dave. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP/TLS general question
Hi everbody! I have a freeradius eap/tls working setup and now my sake is having different routing for different users-classes. By example, I need that a student of my campus isn't able to access subnets accessible by professors. I need to differentiate policies by the content of certificates provided by users. Is it possible? Another question: If the above isn't possible only with eap/tls, I can use a ldap database, which is alredy present. My question is, can I authenticate with eap/tls and ONLY IF this returns ok, authenticate next with ldap? Thanks a lot! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
