Hi all, I recently set up a new freeradius installation for VPN authentication. This is my first foray into using the LDAP module and, while I am successfully authenticating, I want to make sure that my config is both correct and streamlined. I am seeing a few failed authentications due to loss of LDAP connections, so I'm also trying to identify where that problem exists. The radius server is currently very low use, handling only a few requests an hour. This may increase later on, but I don't see it having to handle more than a few requests per minute. However, I would like to make sure those requests are handled efficiently and quickly. The current radius ldap config looks like this : modules { ldap { server = "ldap.example.com" port = 636 identity = "cn=manager,o=MyOrg" password = MySuperSecretPassword basedn = "o=MyOrg" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "memberOf" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 groupname_attribute = cn groupmembership_filter = "(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))" groupmembership_attribute = memberOf net_timeout = 1 timeout = 8 timelimit = 3 } } In our users file, we have the following : DEFAULT Auth-Type := Reject Fall-Through = 1 DEFAULT Ldap-Group == "cn=vpn,ou=groups,o=myorg", Auth-Type := Accept Fall-Through = 1 DEFAULT Ldap-Group == "cn=admin,ou=groups,o=myorg" Class = ADMIN, Fall-Through = 1 DEFAULT Ldap-Group == "cn=user,ou=groups,o=myorg" Class = USER, Fall-Through = 1 Essentially, we want to assign a user to a specific class based on what group they are in, with some groups superseding others. Our LDAP entries have multiple memberOf attributes that list the groups a user is in, as well as groups that list the members. I was able to get this to work, but it appears that every group is scanned to find the user rather than merely using the memberOf attribute in the main LDAP record. Is there a way to trigger on that rather than scanning the groups? Note: The dictionary mapping file (ldap.attrs) is the default one, I have made no changes. With respect to the users file, I believe I can remove the Fall-Through parameter there for all but the vpn LDAP group. That would cut down, somewhat, on the group scanning. In the main radius config, can I remove all of the unused modules? I don't believe we're using PAP/CHAP/MS-CHAP at all, nor are we using the unix passwd file or EAP. Those can all be commented out to save time/resources, correct? And finally, can someone give me a few hints on how to identify the cause of the "LDAP connection lost" messages we see? They seem to be intermittent and I am unable to find a cause for them. The network is stable and there is no loss of connectivity at the lower layers. I believe radius is sending keepalives, correct, so a loss of connectivity could indicate keepalives being lost? Any help is appreciated! Thanks! If there's any additional information I can provide that would help, please let me know. -- --------------------------- Jason Frisvold xenophage0@gmail.com --------------------------- "I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams
Jason Frisvold wrote:
I recently set up a new freeradius installation for VPN authentication. This is my first foray into using the LDAP module and, while I am successfully authenticating, I want to make sure that my config is both correct and streamlined. I am seeing a few failed authentications due to loss of LDAP connections, so I'm also trying to identify where that problem exists.
Likely because the LDAP connections time out, and are closed.
The radius server is currently very low use, handling only a few requests an hour. This may increase later on, but I don't see it having to handle more than a few requests per minute. However, I would like to make sure those requests are handled efficiently and quickly.
Yes... that little traffic will result in LDAP connection timeouts.
In our users file, we have the following :
DEFAULT Auth-Type := Reject Fall-Through = 1
Huh? Why?
DEFAULT Ldap-Group == "cn=vpn,ou=groups,o=myorg", Auth-Type := Accept Fall-Through = 1
Do you really want to accept these users without checking their passwords? That's a *very* bad idea.
I was able to get this to work, but it appears that every group is scanned to find the user rather than merely using the memberOf attribute in the main LDAP record. Is there a way to trigger on that rather than scanning the groups?
The group membership configurations should ensure that it's using the memberOf attribute.
In the main radius config, can I remove all of the unused modules? I don't believe we're using PAP/CHAP/MS-CHAP at all, nor are we using the unix passwd file or EAP. Those can all be commented out to save time/resources, correct?
Why are you not checking passwords? That's a bad idea... If you don't use a module, you can delete all references to it. It will make some *minor* difference in performance. But if you're getting a few requests a minute, that difference will be miniscule. Alan DeKok.
On Mar 17, 2009, at 5:37 AM, Alan DeKok wrote:
Likely because the LDAP connections time out, and are closed.
Yes... that little traffic will result in LDAP connection timeouts.
Hrm... Ok, I can accept that. Is there a way to force a keepalive or something?
In our users file, we have the following :
DEFAULT Auth-Type := Reject Fall-Through = 1
Huh? Why?
I *thought* this was required, but apparently not?
Do you really want to accept these users without checking their passwords? That's a *very* bad idea.
I agree. What am I missing? I thought the user passwords were checked by the ldap module via the authentication section. Is that not correct?
The group membership configurations should ensure that it's using the memberOf attribute.
Can you give me an example please? I'm not sure I understand...
Why are you not checking passwords? That's a bad idea...
I thought I was... Do I need more than this? authenticate { Auth-Type LDAP { ldap } }
If you don't use a module, you can delete all references to it. It will make some *minor* difference in performance. But if you're getting a few requests a minute, that difference will be miniscule.
It's more of a "don't use it if you don't need it" philosophy, really.. Cleans up debug output too, when I'm trying to figure out what's going on ..
Alan DeKok.
Thanks for the help! -- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com http://blog.godshell.com
Do you really want to accept these users without checking their passwords? That's a *very* bad idea.
I agree. What am I missing? I thought the user passwords were checked by the ldap module via the authentication section. Is that not correct?
Remove those entries in users file. They are bypassing password checking. If you want to accept only some ldap groups use unlang. Something like: if(Ldap-Group == something || Ldap-Group == something_else) { ok } else { update control { Auth-Type := Reject } }
The group membership configurations should ensure that it's using the memberOf attribute.
Can you give me an example please? I'm not sure I understand...
Example is the default group membership query in raddb/modules/ldap.
Why are you not checking passwords? That's a bad idea...
I thought I was... Do I need more than this?
authenticate { Auth-Type LDAP { ldap } }
Yes. Auth-Type LDAP needs to be set. If you force Auth-Type Accept in users file this will never be used. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net wrote:
Remove those entries in users file. They are bypassing password checking. If you want to accept only some ldap groups use unlang. Something like:
if(Ldap-Group == something || Ldap-Group == something_else) { ok } else { update control { Auth-Type := Reject } }
Yeah.. that may be a problem. Does freeradius 1.1.3 support unlang? This is a RHEL 5.3 install... I'm not aware of a trustable source for 2.x RPMs ...
Example is the default group membership query in raddb/modules/ldap.
I *think* that's what I have already.
Yes. Auth-Type LDAP needs to be set. If you force Auth-Type Accept in users file this will never be used.
Hrm... ok, understood.. So I need to figure out how to require the vpn group and reject if it isn't there...
Ivan Kalik Kalik Informatika ISP
-- --------------------------- Jason Frisvold xenophage0@gmail.com --------------------------- "I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams
Remove those entries in users file. They are bypassing password checking. If you want to accept only some ldap groups use unlang. Something like:
if(Ldap-Group == something || Ldap-Group == something_else) { ok } else { update control { Auth-Type := Reject } }
Yeah.. that may be a problem. Does freeradius 1.1.3 support unlang? This is a RHEL 5.3 install... I'm not aware of a trustable source for 2.x RPMs ...
1.1.3 doesn't support unlang. You need 2.x. http://wiki.freeradius.org/Red_Hat_FAQ Ivan Kalik Kalik Informatika ISP
Jason Frisvold wrote:
DEFAULT Auth-Type := Reject Fall-Through = 1
Huh? Why?
I *thought* this was required, but apparently not?
No. the server will automatically reject anyone who isn't authenticated. As a hint, the default config does *not* have that entry. So adding it is likely "unusual".
Do you really want to accept these users without checking their passwords? That's a *very* bad idea.
I agree. What am I missing? I thought the user passwords were checked by the ldap module via the authentication section. Is that not correct?
Yes, they can be. But you're telling the server to *not* check passwords. "Just accept the users... they're fine".
The group membership configurations should ensure that it's using the memberOf attribute.
Can you give me an example please? I'm not sure I understand...
See raddb/modules/ldap. Group checking is documented in the comments there.
Why are you not checking passwords? That's a bad idea...
I thought I was... Do I need more than this?
You need to use the *default* configuration files. Start with them. Configure LDAP, and un-comment the references to "ldap" from the various places in raddb/*. It should then work. Alan DeKok.
Alan DeKok wrote:
No. the server will automatically reject anyone who isn't authenticated.
As a hint, the default config does *not* have that entry. So adding it is likely "unusual".
You are, of course, correct... :) I believe we resolved this now, however. I removed the default reject and updated the ldap groups with this : DEFAULT Ldap-Group != "cn=vpn,ou=groups,o=myorg", Auth-Type := Reject DEFAULT Ldap-Group == "cn=admin,ou=groups,o=myorg" Class = ADMIN, DEFAULT Ldap-Group == "cn=user,ou=groups,o=myorg" Class = USER,
Yes, they can be. But you're telling the server to *not* check passwords. "Just accept the users... they're fine".
I understand this now... What I have now appears to be working properly. We tested all cases (with/without vpn group, good/bad password)
See raddb/modules/ldap. Group checking is documented in the comments there.
Will do. Thanks a ton for the help...
Alan DeKok.
-- --------------------------- Jason Frisvold xenophage0@gmail.com --------------------------- "I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams
participants (3)
-
Alan DeKok -
Jason Frisvold -
tnt＠kalik.net