Should I expect something like this to do the right thing? ldap-localhost { server = "127.0.0.1" basedn = switch "%{Huntgroup-Name}" { case dsl { "ou=dsl,ou=radius,dc=viptalk,dc=net" } case { "ou=accounts,ou=viptalk,ou=net" } } } etc.... Basically, I want to set certain ldap variables based on the Huntgroup- Name. Without defining a bunch of different ldap servers, that is. Thanks.
Chris wrote:
Should I expect something like this to do the right thing?
No. The configuration for modules cannot use unlang. "unlang" is used *only* for processing packets.
Basically, I want to set certain ldap variables based on the Huntgroup-Name. Without defining a bunch of different ldap servers, that is.
The basedn is dynamically expanded. You can do something like: modules { ldap { basedn = "%{Tmp-String-1}" } } and then use "unlang" (or anything else) to set the value of TMP-String-1 to whatever DN you want. Alan DeKok.
Any other dynamic expansions? server = ? filter = ? On Apr 24, 2008, at 12:17 AM, Alan DeKok wrote:
Chris wrote:
Should I expect something like this to do the right thing?
No. The configuration for modules cannot use unlang. "unlang" is used *only* for processing packets.
Basically, I want to set certain ldap variables based on the Huntgroup-Name. Without defining a bunch of different ldap servers, that is.
The basedn is dynamically expanded. You can do something like:
modules { ldap { basedn = "%{Tmp-String-1}"
} }
and then use "unlang" (or anything else) to set the value of TMP-String-1 to whatever DN you want.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 24, 2008, at 12:17 AM, Alan DeKok wrote:
The basedn is dynamically expanded. You can do something like:
modules { ldap { basedn = "%{Tmp-String-1}"
} }
and then use "unlang" (or anything else) to set the value of TMP-String-1 to whatever DN you want.
And what would the unlang syntax be for setting the value of an arbitrarily-named variable like that? Nothing I've tried is working. Keep getting: /usr/local/etc/raddb/sites-enabled/default[49]: Unknown action 'ou=accounts,dc=viptalk,dc=net'.
Chris wrote:
And what would the unlang syntax be for setting the value of an arbitrarily-named variable like that?
$ man unlang It's not an "arbitrarily named variable", it's defined in the private FreeRADIUS dictionary. It's a string attribute, just like anything else.
Nothing I've tried is working. Keep getting:
/usr/local/etc/raddb/sites-enabled/default[49]: Unknown action 'ou=accounts,dc=viptalk,dc=net'.
Since you didn't post what you were trying to do, all I can say is you're doing it wrong. I hate guessing games. Is it so difficult to give an example of what you tried to do? And even the example is unnecessary. The documentation explains how to assign values to attributes, and gives examples of doing it. Copy the examples, and change the attribute name and value. Alan DeKok.
On Apr 24, 2008, at 1:41 AM, Alan DeKok wrote:
Chris wrote:
And what would the unlang syntax be for setting the value of an arbitrarily-named variable like that?
$ man unlang
I have. Several times. Maybe I'm just an idiot.
It's not an "arbitrarily named variable", it's defined in the private FreeRADIUS dictionary. It's a string attribute, just like anything else.
I've since learned this. Thanks.
I hate guessing games. Is it so difficult to give an example of what you tried to do?
Sorry, mate. Currently, I'm here: authorize { switch "%{Huntgroup-Name}" { case dialup { update control { Tmp-String-1 := "ou=accounts,dc=viptalk,dc=net" } ldap-localhost } } } modules { ldap-localhost { basedn = "%{Tmp-String-1}" } } And getting: expand: %{Tmp-String-1} -> rlm_ldap: unable to create basedn. And trying this: ldap-localhost { basedn = "%{control:Tmp-String-1}" } gets me closer, but I have quoting issues: expand: %{control:Tmp-String-1} -> ou\3daccounts\2cdc\3dviptalk\2cdc \3dnet I couldn't get anything to set the variable until I used an update section. "man unlang" seemed to indicate control was the place to put it.
And even the example is unnecessary. The documentation explains how to assign values to attributes, and gives examples of doing it. Copy the examples, and change the attribute name and value.
I'm doing exactly as you're suggesting and coming up empty. When you say "documentation" I presume you mean the sample config files. Lots of examples for setting variables in the users file. Not so many for unlang.
Chris wrote:
gets me closer, but I have quoting issues:
expand: %{control:Tmp-String-1} -> ou\3daccounts\2cdc\3dviptalk\2cdc\3dnet
Hmm... OK, to fix that you'll have to update the LDAP module. Or, ensure that the *dynamic* portions of the basedn don't contain '='.
I couldn't get anything to set the variable until I used an update section.
Which is what the documentation says. "update sections updates an attribute list". Nothing else says that. Alan DeKok.
On Apr 24, 2008, at 4:21 AM, Alan DeKok wrote:
Chris wrote:
gets me closer, but I have quoting issues:
expand: %{control:Tmp-String-1} -> ou\3daccounts\2cdc\3dviptalk\2cdc \3dnet
Hmm... OK, to fix that you'll have to update the LDAP module. Or, ensure that the *dynamic* portions of the basedn don't contain '='.
Or any of these, for that matter: ",+\"\\<>;*=()" I guess the trick is fixing it (breaking it?) so this works without opening up any vectors for injection attacks. Would it be safe to exclude the "control" list from being escaped like this? It seems that only attributes in the the request and proxy-request lists would be the real problems. I am pretty sure I can accomplish this by limiting the dynamic portions of basedn and filter as suggested. Thanks.
I couldn't get anything to set the variable until I used an update section.
Which is what the documentation says. "update sections updates an attribute list". Nothing else says that.
Would it have been so difficult to say "man unlang see update" instead of just "man unlang"? You spent more time complaining about the way I asked the question than it would have taken to answer it. ;) Thanks again.
Chris wrote:
I guess the trick is fixing it (breaking it?) so this works without opening up any vectors for injection attacks. Would it be safe to exclude the "control" list from being escaped like this? It seems that only attributes in the the request and proxy-request lists would be the real problems.
Yes and no. The best way is via a "tainted" flag, like Perl. But that involves a lot more work.
Would it have been so difficult to say "man unlang see update" instead of just "man unlang"? You spent more time complaining about the way I asked the question than it would have taken to answer it. ;)
Exactly. I wish to emphasize *thinking* and *reading*. Answering questions by cutting & pasting portions of the documentation is a disservice to everyone. It has it's appeal, but it's wrong. Alan DeKok.
On Apr 24, 2008, at 11:57 AM, Alan DeKok wrote:
Chris wrote:
I guess the trick is fixing it (breaking it?) so this works without opening up any vectors for injection attacks. Would it be safe to exclude the "control" list from being escaped like this? It seems that only attributes in the the request and proxy-request lists would be the real problems.
Yes and no. The best way is via a "tainted" flag, like Perl. But that involves a lot more work.
Certainly better from my perspective to work within the current capabilities. I've pared what would have been about six different ldap modules per redundant server down to two, so I'm happy. I *could* probably get it down to one but I don't think the extra complexity to do so would outweigh the gains.
Would it have been so difficult to say "man unlang see update" instead of just "man unlang"? You spent more time complaining about the way I asked the question than it would have taken to answer it. ;)
Exactly.
I wish to emphasize *thinking* and *reading*. Answering questions by cutting & pasting portions of the documentation is a disservice to everyone. It has it's appeal, but it's wrong.
Hardly suggesting a cut-and-paste, but okay. Thanks again for the help.
participants (2)
-
Alan DeKok -
Chris