Hi all! I am using freeradius 2.1.10 (from backports) on a Debian Lenny server to authenticate wireless users using EAP and normal users (from Ascend NAS and ASA5510) with CHAP and PAP and so on. My backend is a LDAP directory (OpenLDAP). So far, everything is fine and working great. My question is more about fine tuning some aspects and some understanding issues with the way rlm_ldap adds (or doesn't add) attributes to the query/reply. I need to explain a bit about my environment: I have two LDAP attributes, which control the state of the account of a user: a) gifb-Status ("1" means enabled) b) gifb-NetzAccStatus ("1" again means enabled) - gifb-status gets set to "0" if the password expires or the account gets disabled because of other reasons. - gifb-NetzAccStatus gets set to "0" if the networking account has to be disabled If any of the two attributes is != 1, then the user has to be rejected. To achieve this, until recently I had a filter like the following for the ldap module: filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(objectclass=gifb-NetzAccount)((gifb-status=1)(gifb-NetzAccStatus=1))" This worked OK, ie. the user was rejected if his account was disabled, because he wasn't even found by the ldap module. But this also resulted in somewhat ugly log entries: Sun Oct 3 20:38:18 2010 : Auth: Login incorrect ( [ldap] User not found): [XXXX123] (from client alb13 port 5 cli 00236CDEADBF via TLS tunnel) Sun Oct 3 20:38:18 2010 : Auth: Login incorrect: [XXXX123] (from client alb13 port 5 cli 00236CDEADBF) So, using unlang I created the following, adjusting my filter first ... filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(objectclass=gifb-NetzAccount))" ... adding to the dictionary ... ATTRIBUTE GIFB-NetzAccStatus 3000 integer ATTRIBUTE GIFB-Status 3001 integer and then in the inner-tunnel: ,----[sites-enabled/inner-tunnel | ldap | | if ( !notfound ) { | update request { | GIFB-NetzAccStatus := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-NetzAccStatus?sub?uid=%u}" | GIFB-Status := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-Status?sub?uid=%u}" | } | if ( GIFB-NetzAccStatus != 1 ) { | update reply { | Reply-Message = "User denied by GIFB-NetzAccStatus" | } | reject | } | if ( GIFB-Status != 1 ) { | update reply { | Reply-Message = "User denied by GIFB-Status" | } | reject | } | } `---- This also works great, I get meaningful log-entries and everything is OK. Now, for my rather simple question: Why can't I just add the following to ldap.attrmap and have the ldap module add those two attributes automagically. Why do I have to use two separate ldap_xlat queries: checkItem GIFB-NetzAccStatus GIFB-NetzAccStatus checkItem GIFB-Status GIFB-Status I also tried this with "replyItem" instead of checkItem and also tried adding ":=" as the operator, but without the separate ldap_xlat queries both RADIUS-Attributes are not available after the normal ldap module ran. It seems I am missing some crucial part of information here or just lack the understanding of this part of Freeradius. Please enlighten me. Grüße, Sven. -- Sig lost. Core dumped.
Sven Hartge wrote: ...
| update request { | GIFB-NetzAccStatus := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-NetzAccStatus?sub?uid=%u}" | GIFB-Status := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-Status?sub?uid=%u}" ... Now, for my rather simple question:
Why can't I just add the following to ldap.attrmap and have the ldap module add those two attributes automagically. Why do I have to use two separate ldap_xlat queries:
checkItem GIFB-NetzAccStatus GIFB-NetzAccStatus checkItem GIFB-Status GIFB-Status
That doesn't seem to be consistent. "update request" versus "checkItem" ?
I also tried this with "replyItem" instead of checkItem and also tried adding ":=" as the operator, but without the separate ldap_xlat queries both RADIUS-Attributes are not available after the normal ldap module ran.
It seems I am missing some crucial part of information here or just lack the understanding of this part of Freeradius.
They attributes *are* added, to the list that you specified. If you want to refer to them in a particular list, see "man unlang". Referring to them a "GIFB-NetzAccStatus" means referring to that attribute in the *request*, not the *control* list, and not the *reply* list. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Sven Hartge wrote: ...
| update request { | GIFB-NetzAccStatus := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-NetzAccStatus?sub?uid=%u}" | GIFB-Status := "%{ldap:ldap:///dc=fh-giessen-friedberg,dc=de?GIFB-Status?sub?uid=%u}" ... Now, for my rather simple question:
Why can't I just add the following to ldap.attrmap and have the ldap module add those two attributes automagically. Why do I have to use two separate ldap_xlat queries:
checkItem GIFB-NetzAccStatus GIFB-NetzAccStatus checkItem GIFB-Status GIFB-Status
That doesn't seem to be consistent. "update request" versus "checkItem" ?
Correct. This was my configuration _before_ I used the "update request" method to get this information. As I said: this was just a misunderstanding of the involved mechanisms on my side.
I also tried this with "replyItem" instead of checkItem and also tried adding ":=" as the operator, but without the separate ldap_xlat queries both RADIUS-Attributes are not available after the normal ldap module ran.
It seems I am missing some crucial part of information here or just lack the understanding of this part of Freeradius.
They attributes *are* added, to the list that you specified. If you want to refer to them in a particular list, see "man unlang". Referring to them a "GIFB-NetzAccStatus" means referring to that attribute in the *request*, not the *control* list, and not the *reply* list.
Ah! I need to use "%{control:GIFB-NetzAccStatus}". Thank you, this was just the little nudge, I needed. Just out of curiosity: is there an easy way to see the whole contents of all lists while debugging? This would have saved me this question, as I could have easily spottet my data in the output. Grüße, S° -- Sig lost. Core dumped.
Alan DeKok <aland@deployingradius.com> wrote:
Sven Hartge wrote:
Just out of curiosity: is there an easy way to see the whole contents of all lists while debugging?
Not really. It's a *lot* of data.
Yeah, I thought so. Another thought: Are those lists fully available to the perl module? Maybe then I could just dump the %hashes to disk to examine them.
It's possible to patch the server to do this. If you do it, send us the patch. :)
Nah, my C-fu is just too bad to do this ;) I will have to live with the situation as is. Grüße, Sven. -- Sig lost. Core dumped.
participants (2)
-
Alan DeKok -
Sven Hartge