Hi guys, I'm sure these are questions that have been asked a thousand times, but can't for the life of me find the answers I'm looking for. My first problem is this: I want to store reply attributes for my users in a MySQL database, however I want them to authenticate against an LDAP server. No problem, I sort of have this working. Except the reply attributes get sent even on an Access-Reject packet. This seems undesirable to me. My second problem is this: The LDAP server isn't necessarily in the same building as the radius server. I want users to be able to fall back on locally stored passwords in the MySQL database should the LDAP server be down for some reason. I'd thought that setting Fall-Through=yes and having a DEFAULT Auth-Type = local would have done this, but no dice. Any suggestions? Regards, Justin
I'm sure these are questions that have been asked a thousand times, but can't for the life of me find the answers I'm looking for.
My first problem is this: I want to store reply attributes for my users in a MySQL database, however I want them to authenticate against an LDAP server. No problem, I sort of have this working. > Except the reply attributes get sent even on an Access-Reject packet. This seems undesirable to me.
Have you done something to attribute filter in Post-Auth-Type REJECT?
My second problem is this: The LDAP server isn't necessarily in the same building as the radius server. I want users to be able to fall back on locally stored passwords in the MySQL database should > the LDAP server be down for some reason. I'd thought that setting Fall-Through=yes and having a DEFAULT Auth-Type = local would have done this, but no dice. Any suggestions?
man unlang - redundant. Ivan Kalik Kalik Informatika ISP
Justin Steward wrote:
My first problem is this: I want to store reply attributes for my users in a MySQL database, however I want them to authenticate against an LDAP server. No problem, I sort of have this working. Except the reply attributes get sent even on an Access-Reject packet. This seems undesirable to me.
You can filter them out... In any case, it doesn't cause too many issues in practice.
My second problem is this: The LDAP server isn't necessarily in the same building as the radius server. I want users to be able to fall back on locally stored passwords in the MySQL database should the LDAP server be down for some reason. I'd thought that setting Fall-Through=yes and having a DEFAULT Auth-Type = local would have done this, but no dice. Any suggestions?
$ man unlang ... ldap if (fail) { sql } ... Don't use the "users" file for complex policies. It doesn't work for anything complicated. Alan DeKok.
On Thu, Apr 9, 2009 at 10:27 PM, Alan DeKok <aland@deployingradius.com>wrote:
$ man unlang
... ldap if (fail) { sql } ...
Hi Alan, Thanks for the reply. Since SQL modules can't go in authenticate, this would have to be in authorize, yes? How then, would I get the reply attributes out of the SQL database? Or am I misunderstanding something? I currently have sql in authorize, the users have Auth-Type = LDAP, and ldap is in the authenticate section. This is authenticating users against LDAP, and getting the reply attributes from the SQL database. Thanks, Justin
Justin Steward wrote:
Thanks for the reply. Since SQL modules can't go in authenticate, this would have to be in authorize, yes? How then, would I get the reply attributes out of the SQL database? Or am I misunderstanding something?
Maybe you could describe exactly what you want to do.
I currently have sql in authorize, the users have Auth-Type = LDAP, and ldap is in the authenticate section. This is authenticating users against LDAP, and getting the reply attributes from the SQL database.
LDAP is not an authentication protocol. I suggest using LDAP servers as a database, if possible. Alan DeKok.
On Fri, Apr 10, 2009 at 7:32 PM, Alan DeKok <aland@deployingradius.com>wrote:
Justin Steward wrote:
Thanks for the reply. Since SQL modules can't go in authenticate, this would have to be in authorize, yes? How then, would I get the reply attributes out of the SQL database? Or am I misunderstanding something?
Maybe you could describe exactly what you want to do.
I want to return some radius reply attributes from an SQL database, check the user's password against an openLDAP server (maybe a Windows Server running AD at some point in the future), and if possible fall back against a password stored in a MySQL database. (Though this password may not always be entirely up to date, so it's only for if the user either doesn't exist in the directory or the LDAP server is temporarily unavailable) ~Justin
Justin Steward wrote:
I want to return some radius reply attributes from an SQL database, check the user's password against an openLDAP server
As I said... LDAP isn't an authentication protocol.
(maybe a Windows Server running AD at some point in the future), and if possible fall back against a password stored in a MySQL database. (Though this password may not always be entirely up to date, so it's only for if the user either doesn't exist in the directory or the LDAP server is temporarily unavailable)
Why not let FreeRADIUS do authentication, as I suggested? Have the LDAP module pull the password from LDAP. Then, do MySQL. authorize { ... ldap if (notfound | fail) { sql } ... } That does *exactly* what you suggested above. But the last time I suggested that solution, you said you *also* wanted to get reply attributes from MySQL... apparently, even for the users that were found in LDAP. So which is it? Alan DeKok.
On Fri, Apr 10, 2009 at 11:51 PM, Alan DeKok <aland@deployingradius.com>wrote:
Justin Steward wrote:
I want to return some radius reply attributes from an SQL database, check the user's password against an openLDAP server
As I said... LDAP isn't an authentication protocol.
(maybe a Windows Server running AD at some point in the future), and if possible fall back against a password stored in a MySQL database. (Though this password may not always be entirely up to date, so it's only for if the user either doesn't exist in the directory or the LDAP server is temporarily unavailable)
Why not let FreeRADIUS do authentication, as I suggested? Have the LDAP module pull the password from LDAP. Then, do MySQL.
authorize { ... ldap if (notfound | fail) { sql } ... }
That does *exactly* what you suggested above. But the last time I suggested that solution, you said you *also* wanted to get reply attributes from MySQL... apparently, even for the users that were found in LDAP.
So which is it?
My apologies, I tend to let things slip when I send emails late at night. Yes, I need to also send reply attributes from a MySQL database. The reason for this is that the LDAP server is somewhat out of my control. I can't store values for attributes there. Again, apologies for being unclear. You've mentioned a few times that LDAP is not meant for authentication, however the default config that ships with FreeRADIUS has LDAP in the authentication section. Could you clear that up a little for me please? (or point me to somewhere it's been cleared up before?) ~Justin
You've mentioned a few times that LDAP is not meant for authentication, however the default config that ships with FreeRADIUS has LDAP in the authentication section. Could you clear that up a little for me please? (or point me to somewhere it's been cleared up before?)
Don't force Auth-Type Ldap. But you will have to use two sql instances - one to store reply info and one to store backup passwords. You can't store passwords in sql (used for reply attributes) and ldap as well. authorize { ... sql_reply ldap if (notfound | fail) { sql_bkp_pass } ... } Ivan Kalik Kalik Informatika ISP
Don't force Auth-Type Ldap.
But you will have to use two sql instances - one to store reply info and one to store backup passwords. You can't store passwords in sql (used for reply attributes) and ldap as well. authorize { ... sql_reply ldap if (notfound | fail) { sql_bkp_pass } ... }
Ah, thank you very much. I think I understand now. Will experiment with that when I get back to work on Tuesday. Many thanks, Justin Steward
On Mon, Apr 13, 2009 at 4:48 AM, Ivan Kalik <tnt@kalik.net> wrote:
You've mentioned a few times that LDAP is not meant for authentication, however the default config that ships with FreeRADIUS has LDAP in the authentication section. Could you clear that up a little for me please? (or point me to somewhere it's been cleared up before?)
Don't force Auth-Type Ldap.
But you will have to use two sql instances - one to store reply info and one to store backup passwords. You can't store passwords in sql (used for reply attributes) and ldap as well. authorize { ... sql_reply ldap if (notfound | fail) { sql_bkp_pass } ... }
Works perfectly. Exactly what I was after. Thanks Ivan. Regards, Justin
Hello List, I am attempting to address some issues I have had it setting up proxy accounting using the robust-proxy-accounting example. Just a short background. I used radrelay for years for this very purpose. During a maintenance period or other outage, FreeRADIUS (1.x) would spool all of the accounting data to a single detail file. Once the remote accounting server was accessible, radrelay would then "grab" the file and send all of the data to the accounting server. On occasion, we could have days worth of accounting data that would have to be relayed, but it all seemed to work properly. In FreeRADIUS 2.x, the radrelay functions have been built into radiusd. However, I seem to be having problems with data loss. Everything works fine when the remote accounting server is up. However, when it goes down, here is what I am seeing. 1) Remote accounting server is shutdown (as a test). 2) Radiusd begins to spool accounting data to the defined detail file (i.e. detail-20090409). 3) Radiusd starts to read the detail file (i.e. the "detail.work" is created). 4) Here is where is gets confusing. It almost seems like radiusd goes into some sort of loop. After a short period (less than a minute), all of the files are deleted from the "listen" directory and radiusd goes into a hyper polling mode (see the bottom of the attached debug file). This is very different from the normal polling mode which occurs at appoximatly 1 second intervals. All this does not seem to crash the server, however, the accounting data does appear to be lost which is my greatest concern in this e-mail. If anyone sees any problems with my configuration or needs any further information, please let me know. I am currently using FreeRADIUS 2.1.4. Thanks, Jim L.
JDL wrote:
In FreeRADIUS 2.x, the radrelay functions have been built into radiusd.
That's the intention.
However, I seem to be having problems with data loss. Everything works fine when the remote accounting server is up. However, when it goes down, here is what I am seeing. ... 4) Here is where is gets confusing. It almost seems like radiusd goes into some sort of loop. After a short period (less than a minute), all of the files are deleted from the "listen" directory and radiusd goes into a hyper polling mode (see the bottom of the attached debug file). This is very different from the normal polling mode which occurs at appoximatly 1 second intervals.
There have been other reports of the same thing. Unfortunately, I've been unable to reproduce this locally. That makes it difficult to find the issue, and to fix it.
All this does not seem to crash the server, however, the accounting data does appear to be lost which is my greatest concern in this e-mail.
If anyone sees any problems with my configuration or needs any further information, please let me know. I am currently using FreeRADIUS 2.1.4.
I'll do some more tests before I release the next version of the server. Alan DeKok.
participants (5)
-
Alan DeKok -
Ivan Kalik -
JDL -
Justin Steward -
Justin Steward