Andrew thanks for the quick reply.
Looks like you don't have the LDAP information setup correctly. FreeRADIUS can't login to LDAP with the settings (un)specified.
rlm_ldap: (re)connection attempt failed rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns fail for request 0 modcall: leaving group authorize (returns fail) for request 0
Yep, knew that, but expected to continue with the text auth since the user existed in that file.
LDAP returns fail, which is weighted heavier than the both the "noop" returned by mschap and the "ok" returned by files. Because LDAP returns "fail," the entire request returns "fail." You can specify different weighted settings for noop, fail, etc, but the obvious answer is to fix your LDAP settings and then try again. How do you go about setting the weighting. I want to be able to use text, ldap and mysql so that we have various fall back options with a failure of the external databases (ldap and mysql).
Once you can login to the LDAP, if the user does not exist in there then LDAP should return "noop" for the request. If you want a user to exist in both the LDAP and the users file with different passwords, that requires a bit of tweaking but I've got it working if you need to see
Would like to see how you did it.
Hope this helps!
Andrew
Gerry Dalton, Network System Support Consolidated Communications Cell: 214 532-1905
How do you go about setting the weighting. I want to be able to use text, ldap and mysql so that we have various fall back options with a failure of the external databases (ldap and mysql).
I'm pulling this straight from the "configurable_failover.gz" file from the documentation: ---------------cut----------------- Rewriting results for single modules ------------------------------------ Normally, when a module fails, the entire section ("authorize", "accounting", etc.) stops being processed. In some cases, we may want to permit "soft failures". That is, we may want to tell the server that it is "ok" for a module to fail, and that the failure should not be treated as a fatal error. In this case, the module is treated as a "section", rather than just as a single line in "radiusd.conf". The configuration entries for that section are taken from the "configurable fail-over" code, and not from the configuration information for that module. For example, the "detail" module normally returns "fail" if it is unable to write its information to the "detail" file. As a test, we can configure the server so that it continues processing the request, even if the "detail" module fails. The following example shows how: #-- # Handle accounting packets accounting { detail { fail = 1 } redundant { sql1 sql2 handled } } #-- The "fail = 1" entry tells the server to remember the "fail" code, with priority "1". The normal configuration is "fail = return", which means "if the detail module fails, stop processing the accounting section". ---------------cut----------------- So by setting fail equal to a value (1-99999) you override the default "fail = return."
Once you can login to the LDAP, if the user does not exist in there then LDAP should return "noop" for the request. If you want a user to exist in both the LDAP and the users file with different passwords, that requires a bit of tweaking but I've got it working if you need to see
Would like to see how you did it.
Here's how I have ldap/unix redundant group setup: Auth-Type LDAP { ldap { reject = 3 fail = 3 } unix } If the user exists in the LDAP (module ldap returns ok for the request), then the Auth-Type is set to LDAP by default (assuming you have things setup correctly). If the password provided by the user does not match the one in the LDAP, then instead of flat out rejecting the user and stopping processing, I assign an arbitrary value of 3 to the reject codes (I do the same with fail, although looking back I don't know if there's any real reason to do so). Now rather than returning reject (or fail) for the entire request, the section calls the unix module to attempt to authorize via /etc/passwd. You could just as simply have it check the users file (module "files") or a number of other methods. Does that make things any more clear?
After sending the second email, I realized that while you're having problems with the Authorization section, I gave solutions applicable to the Authentication section. I don't know if you can set certain fail and reject codes in the Autz section. The real answer to your first question was that as long as you setup the LDAP information correctly, you'll no longer have the Autz section failing on you. The rest of the information I gave should be useful in the Auth section though. Sorry for the confusion.
participants (2)
-
Andrew Browning -
Gerry Dalton