Configuration trouble with fail-over
Hello list. I've recently upgraded my freeradius servers from 1.1.7 to 2.0.0, and I've been hit badly by the change in the handling of LDAP-UserDn attribute, as detailed in http://www.nabble.com/Re%3A-LDAP-Groups-and-EAP-p14886209.html I think this ought to be documented in rlm_ldap documentation (as well as minor other changes, such as the new tls subsection). I also tried to clean up my configuration a little bit. I think a found a bug in the handling of set_auth_type directive. From what I understood, this directive governs the setting of the Auth-Type attribute to 'LDAP' during the authorisation phase. However, whatever its value, it's automatically disabled when launching radius at startup: Tue Apr 29 14:07:17 2008 : Debug: rlm_ldap: Over-riding set_auth_type, as we're not listed in the "authenticate" section. Here is my autenticate section, using two ldap modules in fail-over: authenticate { Auth-Type LDAP { redundant { ldap1 ldap2 handled } } } If I drop failover, everything work as expected. Should I report this as a bug ? So far, the only workaround I found is to force the Auth-Type attribute in the user file: DEFAULT ldap1-LDAP-Group == admins, Auth-Type := LDAP, Huntgroup-Name == AdminNet Service-Type = Login, Cisco-AVPair = "shell:priv-lvl=15" DEFAULT ldap2-LDAP-Group == admins, Auth-Type := LDAP, Huntgroup-Name == AdminNet Service-Type = Login, Cisco-AVPair = "shell:priv-lvl=15" But I can't make my mind if it is a good solution or not. According to the comment in default configuration file: "In general, you SHOULD NOT set the Auth-Type attribute". According to Alan answer in http://www.nabble.com/Re%3A-Force-Auth-Type-p15069162.html "The LDAP module setting Auth-Type to LDAP is a bit of a hack." Which one should I believe ? -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62
Guillaume Rousse wrote:
I've recently upgraded my freeradius servers from 1.1.7 to 2.0.0,
2.0.3 has been out for a while...
and
I've been hit badly by the change in the handling of LDAP-UserDn attribute, as detailed in http://www.nabble.com/Re%3A-LDAP-Groups-and-EAP-p14886209.html
This was fixed in CVS head, in what will be 2.0.4.
I think this ought to be documented in rlm_ldap documentation (as well as minor other changes, such as the new tls subsection).
The new tls sub-section isn't required. The old-style configuration *should* work.
I also tried to clean up my configuration a little bit. I think a found a bug in the handling of set_auth_type directive. From what I understood, this directive governs the setting of the Auth-Type attribute to 'LDAP' during the authorisation phase. However, whatever its value, it's automatically disabled when launching radius at startup:
Tue Apr 29 14:07:17 2008 : Debug: rlm_ldap: Over-riding set_auth_type, as we're not listed in the "authenticate" section.
Yes... the LDAP module is now aware that you may have *multiple* copies of the LDAP module running.
Here is my autenticate section, using two ldap modules in fail-over: authenticate { Auth-Type LDAP { redundant { ldap1 ldap2
ldap1 != "LDAP".
handled } } }
If I drop failover, everything work as expected. Should I report this as a bug ?
No.
So far, the only workaround I found is to force the Auth-Type attribute in the user file:
Yes. The old behavior was wrong.
But I can't make my mind if it is a good solution or not. According to the comment in default configuration file: "In general, you SHOULD NOT set the Auth-Type attribute".
In general. In some cases, it works. In this case, the knowledge that you want to do LDAP authentication is buried inside of a "redundant" section.
According to Alan answer in http://www.nabble.com/Re%3A-Force-Auth-Type-p15069162.html "The LDAP module setting Auth-Type to LDAP is a bit of a hack."
Yes. If you use the LDAP server as a *database*, then there's no need to set Auth-Type. The FreeRADIUS just figures it out. The only reasons to use Auth-Type = LDAP is when you're using LDAP as an *authentication* server, not as a database.
Which one should I believe ?
All of them. There are generalizations, which are usually true. In addition, there are specific corner cases where the generalizations aren't true. Alan deKok.
Alan DeKok a écrit :
I think this ought to be documented in rlm_ldap documentation (as well as minor other changes, such as the new tls subsection).
The new tls sub-section isn't required. The old-style configuration *should* work. It does. But clarification between what's old and what's new syntax doesn't harm.
I also tried to clean up my configuration a little bit. I think a found a bug in the handling of set_auth_type directive. From what I understood, this directive governs the setting of the Auth-Type attribute to 'LDAP' during the authorisation phase. However, whatever its value, it's automatically disabled when launching radius at startup:
Tue Apr 29 14:07:17 2008 : Debug: rlm_ldap: Over-riding set_auth_type, as we're not listed in the "authenticate" section.
Yes... the LDAP module is now aware that you may have *multiple* copies of the LDAP module running. I guess you mean 'not aware'
Here is my autenticate section, using two ldap modules in fail-over: authenticate { Auth-Type LDAP { redundant { ldap1 ldap2
ldap1 != "LDAP". Right, but that seems to be only a syntax difference, refering to a named instance of the LDAP module. One would expect the code to be more robust, or at least the problem documented somewhere.
[..]
Which one should I believe ?
All of them. There are generalizations, which are usually true. In addition, there are specific corner cases where the generalizations aren't true. I need the second solution (ldap as an autentication server), so I need to have Auth-Type set.
If I understand correctly, there no way to help the rlm_module understand I'm using it for autentication, as I use a complex synta, so I have to set it up explicitely, right ? In this case, I think this deserve some explanation in the rlm_ldap documentation, such as: "Warning, if the LDAP module is not directly referenced to in authentication section, such as a failover configuration using named aliases, this setting will be disabled". -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62
Guillaume Rousse wrote:
It does. But clarification between what's old and what's new syntax doesn't harm.
The new syntax is documented, and is preferred. If you try the old one (undocumented and deprecated), it works. What needs clarification?
Right, but that seems to be only a syntax difference, refering to a named instance of the LDAP module. One would expect the code to be more robust, or at least the problem documented somewhere.
It is very difficult to determine what is *supposed* to happen inside of an authentication section. if you have suggestions for how to make that determination, I'm interested. And the problem is documented: the debug log prints out a warning message, as you saw.
If I understand correctly, there no way to help the rlm_module understand I'm using it for autentication, as I use a complex synta, so I have to set it up explicitely, right ?
Yes.
In this case, I think this deserve some explanation in the rlm_ldap documentation, such as: "Warning, if the LDAP module is not directly referenced to in authentication section, such as a failover configuration using named aliases, this setting will be disabled".
The same problem applies to other modules, so it needs to be documented in one place. Alan DeKok.
Alan DeKok a écrit :
Guillaume Rousse wrote:
It does. But clarification between what's old and what's new syntax doesn't harm.
The new syntax is documented, and is preferred. If you try the old one (undocumented and deprecated), it works. What needs clarification? It is not documented in the rlm_ldap file shipped in top-level directory (at least for release 2.0.0). The fact that there is a huge redundancy between this file and comments in default configuration files doesn't help maintaining a reference documentation.
Right, but that seems to be only a syntax difference, refering to a named instance of the LDAP module. One would expect the code to be more robust, or at least the problem documented somewhere.
It is very difficult to determine what is *supposed* to happen inside of an authentication section. if you have suggestions for how to make that determination, I'm interested. No, especially as I got no clue about freeradius internals.
And the problem is documented: the debug log prints out a warning message, as you saw.
If I understand correctly, there no way to help the rlm_module understand I'm using it for autentication, as I use a complex synta, so I have to set it up explicitely, right ?
Yes.
In this case, I think this deserve some explanation in the rlm_ldap documentation, such as: "Warning, if the LDAP module is not directly referenced to in authentication section, such as a failover configuration using named aliases, this setting will be disabled".
The same problem applies to other modules, so it needs to be documented in one place. Indeed. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62
Guillaume Rousse wrote:
It is not documented in the rlm_ldap file shipped in top-level directory (at least for release 2.0.0). The fact that there is a huge redundancy between this file and comments in default configuration files doesn't help maintaining a reference documentation.
The configuration files are up-to-date. Other documentation files may not be. As always, we welcome patches to help fix code or documentation.
... if you have suggestions for how to make that determination, I'm interested. No, especially as I got no clue about freeradius internals.
There's no need to understand the internals. All you need to do is understand the configuration, and to come up with some simple logic for the "right" thing to do. The problem is a common one in computer science: write a program that "understands" what another program is doing. This problem is generally known to be impossible. Alan DeKok.
Alan DeKok a écrit :
Guillaume Rousse wrote:
It is not documented in the rlm_ldap file shipped in top-level directory (at least for release 2.0.0). The fact that there is a huge redundancy between this file and comments in default configuration files doesn't help maintaining a reference documentation.
The configuration files are up-to-date. Other documentation files may not be.
As always, we welcome patches to help fix code or documentation. Here is a trivial one.
... if you have suggestions for how to make that determination, I'm interested. No, especially as I got no clue about freeradius internals.
There's no need to understand the internals. All you need to do is understand the configuration, and to come up with some simple logic for the "right" thing to do. What's wrong with just looking recursively for the name under which the module has been instanciated in the authorization section, without interpreting fail-over behaviour at all ?
The problem is a common one in computer science: write a program that "understands" what another program is doing. This problem is generally known to be impossible. Here the communication occurs between the main program, and one of its module, the relationship is a bit tighter. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62
diff -Naur freeradius-server-2.0.3/doc/rlm_ldap freeradius-server-2.0.3-drop-redundant-documentation/doc/rlm_ldap --- freeradius-server-2.0.3/doc/rlm_ldap 2008-02-14 08:03:42.000000000 +0100 +++ freeradius-server-2.0.3-drop-redundant-documentation/doc/rlm_ldap 2008-04-30 11:23:20.000000000 +0200 @@ -26,236 +26,7 @@ 3. CONFIGURATION -Add following subsection to the modules{} section of radiusd.conf to control -the rlm_ldap module: - - modules { ... - - ldap { - -# server: LDAP server hostname/ip address -# -# Optionaly could contain space separated list of host[:port], but -# redundancy/resiliency is better acheived configuring multiple rlm_ldap -# module instances and invocing them in redundand/failover -# configuration in authorize/authenticate sections -# -# You can also pass an ldap url like ldap://localhost -# That way you can also specify alternative ldap schemas like -# ldaps:// or ldapi:// -# The port directive will be ignored in that case -# -# default: settings for your system, as set in etc/openldap/ldap.conf -# - server = localhost - -# port: LDAP server port -# -# If LDAP server port is set to 636 (ldaps), SSL connection is enforced. -# This feature is useful for LDAP servers which support SSL, but don't -# do TLS negotiation (like Novell eDirectory). -# -# default: 389 (ldap) -# - port = 636 - -# net_timeout: # of seconds to wait for response of the server (network -# failures) default: 10 -# - net_timeout = 1 - -# timeout: # seconds to wait for LDAP query to finish default: 20 -# - timeout = 2 - -# timelimit: # of seconds server has to process the query (server-side -# time limit) default: 20 -# - timelimit = 5 - -# ldap_debug: debug flag for LDAP SDK (see OpenLDAP documentation) -# default: 0x0000 (no debugging messages) -# Example:(LDAP_DEBUG_FILTER+LDAP_DEBUG_CONNS) - ldap_debug = 0x0028 - -# identity: DN under which LDAP searches are done password: pasword -# which authenticate this DN default: anonymous bind, no password -# required NOTE: searches are done now over unencrypted connection! -# -# identity = "cn=admin,o=My Org,c=UA" password = mypass - - -# ldap_connections_number: The number of ldap connections that the -# module will keep open to use in requests. Usually it will not need to -# be larger than 5-10 connections default: 5 - - ldap_connections_number = 5 - -# basedn = <Base of LDAP searches> -# - basedn = "o=My Org,c=UA" - -# filter: LDAP search filter, to locate user object using name supplied -# by client during Radius authentication -# -# default: filter = "(uid=%u)" - -# base_filter: The LDAP search filter used for base scope searches, like -# when searching for the default or regular profiles -# -# deafault: base_filter = "(objectclass=radiusprofile)" - - filter = "(uid=%u)" - -# start_tls: When set to "yes" the StartTLS extended operation is used to -# start TLS transport encryption. - start_tls = no - -# tls_mode: When set to "yes" OR the server port is 636 we try to connect with TLS -# Start TLS should be prefered, tls_mode is provided only for ldap servers -# like Active Directory which do not support it. -# default: no - - tls_mode = no - -# tls_cacertfile: A PEM-encoded file that contains the CA Certificates that -# you trust - tls_cacertfile = /path/to/cacert.pem - -# tls_cacertdir: Path the a directory of CA Certificates that you trust, the -# directory must be in "hash format" (see openssl verify) - tls_cacertdir = /path/to/ca/dir/ - -# tls_certfile: The PEM Encoded certificate file that we should present to -# clients connecting - tls_certfile = /path/to/radius.crt - -# tls_keyfile: The PEM Encoded private key that we should use to encrypt the -# session - tls_keyfile = /path/to/radius.key - -# tls_randfile: A file containing random data to seed the OpenSSL PRNG. Not -# needed if your OpenSSL is already properly random. - tls_randfile = /path/to/rnd - -# tls_require_cert: Certificate Verification requirements. Can be "never" -# (don't even bother trying), "allow" (try, but don't fail if the cerificate -# can't be verified), or "demand" (fail if the certificate doesn't verify.) -# The default is "allow" - tls_require_cert = "allow" - -# default_profile: DN of a LDAP object, which contains default RADIUS -# attributes. default: NULL - use only user specific attributes or -# attributes, supplied by other modules. -# - default_profile = "cn=RadProfile,o=My Org,c=UA" - -# profile_attribute: user object attribute, which contains DN of -# radiusProfile object for this user. default: NULL - use only user -# specific attributes or attributes, supplied by other modules. -# -# profile_attribute = "radiusProfileDn" - -# access_attr_used_for_allow: Define if the access attribute (described -# below) will be used to allow access (meaning if it exists then user -# remote access will be allowed) or to deny access. default: yes - used -# to allow access - -# access_attr: if attribute is specified, module checks for its -# existance in user object. If access_attr_used_for_allow is set to -# yes: If it exists the user is allowed to get remote access. If it -# exists and is set to FALSE the user is denied remote access. If it -# does not exist user is denied remote access by default if -# access_attr_used_for_allow is set to no: If it exists the user is -# denied remote access. If it does not exist user is allowed remote -# access. -# -# default: NULL - don't check for the attribute - - access_attr = "dialupAccess" - -# password_header: If the user password is available we add it to the -# check items (to assist in CHAP ie) striping any headers first. -# NOTE: The password_header directive is NOT case insensitive -# default: NULL -# -# password_header = "{clear}" - -# password_attribute: Define the attribute which contains the user -# password. -# While integrating FreeRADIUS with Novell eDirectory, set -# 'password_attribute = nspmpassword' in order to use the universal -# password of the eDirectory users for RADIUS authentication. This will -# work only if FreeRADIUS is configured to build with --with-edir option. -# -# default: NULL - don't add password -# -# password_attribute = "userPassword" - -# password_radius_attribute: Defined the RADIUS attribute where the extracted -# user password will be stored to. Can be used to set it to NT-Password or any -# other similar attribute instead of the default -# -# default: User-Password -# -# password_radius_attribute = "NT-Password" - -# edir_account_policy_check: Specifies if the module has to enforce -# Novell eDirectory account policy check and intruder detection for -# RADIUS users. This will work only if FreeRADIUS is configured to build -# with --with-edir option. -# -# default: yes - eDirectory account policy check enabled -# -# edir_account_policy_check = no - -# groupname_attribute: The attribute containing group name in the LDAP -# server. It is used to search group by name. -# -# default: cn - Search filter is "(cn=%GroupName)" -# -# groupname_attribute = "cn" - -# compare_check_items: Specifies if the module will do a comparison on -# the check items extracted from the ldap with the corresponding items -# present in the incoming request. -# -# default: no - don't do any comparisons -# -# compare_check_items = yes - -# do_xlat: Specifies if the module will do an xlat on the radius attributes -# extracted from the ldap database. Also the attribute operators will be -# honored. If the directive is set to 'no' then we will fall back to the -# pairadd() function which will just add the attributes at the end of the -# corresponding attribute list (check or reply items). This can be used to -# fall back to 0.8.1 behaviour without changing the ldap data or to gain a -# little performance if the ldap data is rather simple (no special operators) -# -# default: yes - do an xlat and honor operators -# -# do_xlat = yes - - -# groupmembership_filter: The filter to search for group membership of a -# particular user after we have found the DN for the group. -# -# default: (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) -# -# groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" - - -# groupmembership_attribute: The attribute in the user entry that states -# the group the user belongs to. The attribute can either contain the -# group name or the group DN. If it contains the group DN -# groupmembership_attribute will also be used to find the group's name. -# The attribute will be used after a search based on the -# groupname_attribute and groupmembership_filter has failed. default: -# NULL - don't search for a group based on attributes in the user entry. -# -# groupmembership_attribute = "radiusGroupName" - - } } +See the default configuration file for up-to-date directives and explanations. NOTE: As LDAP is case insensitive, you should probably also set "lower_user = yes" and "lower_time = before" in main section of radiusd.conf, to get limits
Guillaume Rousse wrote:
What's wrong with just looking recursively for the name under which the module has been instanciated in the authorization section, without interpreting fail-over behaviour at all ?
Because it may be listed under multiple Auth-Type sections. This is something that people do, and is valid.
The problem is a common one in computer science: write a program that "understands" what another program is doing. This problem is generally known to be impossible. Here the communication occurs between the main program, and one of its module, the relationship is a bit tighter.
The problem is interpreting the meaning of the configuration in an "authenticate" section, including sections, sub-sections, "unlang", and redundant sections. Then, automatically making the server do the "right thing" in the authorize section, based on it's interpretation of the "authenticate" section. This is hard. Alan DeKok.
participants (2)
-
Alan DeKok -
Guillaume Rousse