Re: force_check_config - how to use?
According to Alan DeKok <aland@deployingradius.com> on Wed, 01/19/11 at 13:57:
I *think* it's something you can add to a module configuration to force it to instantiate itself. Normally, when "radiusd -C" is used, the SQL module is skipped, because checking the config doesn't mean opening 50 sockets to the SQL server. Adding "force_check_config=yes" will make modules like SQL instantiate themselves, including opening 50 sockets to the SQL server.
Thanks. I came across this while trying to debug a gnarly situation with the mschap module. The configs in modules/mschap include at the end: #ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" This was changed by an adminstrator to --username=%{mschap:User-Name:-None} except that the leading left brace ("{") was omitted... :-( The output of radiusd -XC concluded that "Configuration appears to be OK." when in fact mschap authentications could never recover the User-Name when ntlm_auth was given --username=%mschap:User-Name:-None} to deal with... My question: is there any way to parse and check the "value" of the ntlm_auth variable in the modules/mschap file for valid syntax? Inside cf_item_parse() in src/main/conffile.c there is a PW_TYPE_STRING_PTR case of the switch statement. In this case there is the following comment: /* * Expand variables which haven't already been * expanded automagically when the configuration * file was read. */ It doesn't seem that this ntlm_auth variable was expanded when the config file was read. After this comment is an if statement "if (value == dflt)" which, if true, results in a call to cf_expand_variables() passing the above ntlm_auth string value as "value". It appears to me that this if statement will never be true, since the default value for ntlm_auth is NULL, so any string value (right hand side of ntlm_auth variable) will not be NULL, nor will the pointers match. And if they did, what is the purpose of expanding a variable which is NULL? The net result is that the human error (see typo above) was not discovered while configuration checking with -XC which gave a false positive indication. Very confusing... Regards, web... -- William Bulley Email: web@umich.edu 72 characters width template ----------------------------------------->|
William Bulley wrote:
Thanks. I came across this while trying to debug a gnarly situation with the mschap module. The configs in modules/mschap include at the end:
#ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
This was changed by an adminstrator to --username=%{mschap:User-Name:-None} except that the leading left brace ("{") was omitted... :-(
That's a run-time expansion. Checking the config won't help.
The output of radiusd -XC concluded that "Configuration appears to be OK." when in fact mschap authentications could never recover the User-Name when ntlm_auth was given --username=%mschap:User-Name:-None} to deal with...
Exactly.
My question: is there any way to parse and check the "value" of the ntlm_auth variable in the modules/mschap file for valid syntax?
No. It can only be checked by running the server.
It doesn't seem that this ntlm_auth variable was expanded when the config file was read.
It's not. It's expanded at *run time*, when the server receives a packet.
After this comment is an if statement "if (value == dflt)" which, if true,
You're lost in the weeds. Don't bother reading the source, it won't help.
... The net result is that the human error (see typo above) was not discovered while configuration checking with -XC which gave a false positive indication. Very confusing...
No. "-XC" succeeding means that the configuration is *superficially* OK. It's not a substitute for doing functional tests. The ntlm_auth line is expanded at run time, using data taken from the packet. That is the *only* time that the server can discover an error. It can't discover the error when it loads the configuration, because the server core doesn't know which strings should be expanded, and what data should be put in the expansion. Alan DeKok.
Hello Aland, I am having one question regarding UTF-8 handling of RADIUS server. As Per our talk you told me that whatever the module which required to use mulilingual characters that is required to do UTF-8 encoding decoding stuff.. But my doubt lies here, When RADIUS server recieves request containing the username of multilingual characters then without decoding UTF-8, how can RADIUS server compare it with the stored username's password inside the its own file named *"/usr/local/etc/raddb/users"* ?
Don't CC me on messages to the list. I *do* read the list, and getting multiple messages means I'm more likely to delete them all. And start your own thread, it makes tracking questions and answers much easier. karnik jain wrote:
I am having one question regarding UTF-8 handling of RADIUS server. As Per our talk you told me that whatever the module which required to use mulilingual characters that is required to do UTF-8 encoding decoding stuff..
I don't think I said that.
But my doubt lies here,
When RADIUS server recieves request containing the username of multilingual characters then without decoding UTF-8, how can RADIUS server compare it with the stored username's password inside the its own file named *"/usr/local/etc/raddb/users"* ?
The RFCs require that the User-Name (and all other printable strings) within RADIUS are UTF-8. Alan DeKok.
You mean to say that, /usr/local/etc/raddb/users file has to be stored in UTF-8 encoded format, right? then and then RADIUS server can compare UTF-8 with another UTF-8 encoded stuff? On Thu, Jan 20, 2011 at 3:51 PM, Alan DeKok <aland@deployingradius.com>wrote:
Don't CC me on messages to the list. I *do* read the list, and getting multiple messages means I'm more likely to delete them all.
And start your own thread, it makes tracking questions and answers much easier.
karnik jain wrote:
I am having one question regarding UTF-8 handling of RADIUS server. As Per our talk you told me that whatever the module which required to use mulilingual characters that is required to do UTF-8 encoding decoding stuff..
I don't think I said that.
But my doubt lies here,
When RADIUS server recieves request containing the username of multilingual characters then without decoding UTF-8, how can RADIUS server compare it with the stored username's password inside the its own file named *"/usr/local/etc/raddb/users"* ?
The RFCs require that the User-Name (and all other printable strings) within RADIUS are UTF-8.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
karnik jain -
William Bulley