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
