FR 3.0.7 RADIUS Client Schema error
Hi, in the schema file the entry for require message authenticator is listed as olcAttributeTypes: ( 1.3.6.1.4.1.11344.1.100.2.6 NAME 'radiusClientRequireMa' SINGLE-VALUE DESC 'Require Message Authenticator' EQUALITY booleanMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.7' ) thus one has to enter TRUE or FALSE in LDAP - everything else (I tried it with true, Yes, yes, YES and 1) throws an LDAP error. But now, with TRUE FR won't start anymore. Below is the debug log .... Thu Apr 30 16:34:04 2015 : Debug: client radiusClientIdentifier=127.0.0.1,ou=RADIUS,ou=Services,dc=example,dc=com { Thu Apr 30 16:34:04 2015 : Debug: ipaddr = 127.0.0.1 Thu Apr 30 16:34:04 2015 : Debug: require_message_authenticator = no Thu Apr 30 16:34:04 2015 : Debug: secret = "testing123" Thu Apr 30 16:34:04 2015 : Debug: nas_type = "other" Thu Apr 30 16:34:04 2015 : Debug: limit { Thu Apr 30 16:34:04 2015 : Debug: max_connections = 16 Thu Apr 30 16:34:04 2015 : Debug: lifetime = 0 Thu Apr 30 16:34:04 2015 : Debug: idle_timeout = 30 Thu Apr 30 16:34:04 2015 : Debug: } Thu Apr 30 16:34:04 2015 : Debug: } Thu Apr 30 16:34:04 2015 : Debug: Adding client 127.0.0.1/32 (127.0.0.1) to prefix tree 32 Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap (ldap): Client "radiusClientIdentifier=127.0.0.1,ou=RADIUS,ou=Services,dc=example,dc=com" added Thu Apr 30 16:34:04 2015 : Debug: client radiusClientIdentifier=192.168.0.20,ou=RADIUS,ou=Services,dc=example,dc=com { Thu Apr 30 16:34:04 2015 : Debug: ipaddr = 192.168.0.20 Thu Apr 30 16:34:04 2015 : Error: unknown[0]: Invalid value "TRUE" for boolean variable require_message_authenticator Thu Apr 30 16:34:04 2015 : Debug: } Thu Apr 30 16:34:04 2015 : Error: unknown[0]: Error parsing client section Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap (ldap): Released connection (4) Thu Apr 30 16:34:04 2015 : Error: /etc/freeradius/mods-enabled/ldap[1]: Error loading clients Thu Apr 30 16:34:04 2015 : Error: /etc/freeradius/mods-enabled/ldap[1]: Instantiation failed for module "ldap" Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap (ldap): Removing connection pool Thu Apr 30 16:34:04 2015 : Info: rlm_ldap (ldap): Closing connection (4) Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap: Closing libldap handle 0x26578c0 Thu Apr 30 16:34:04 2015 : Info: rlm_ldap (ldap): Closing connection (3) Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap: Closing libldap handle 0x2656d40 Thu Apr 30 16:34:04 2015 : Info: rlm_ldap (ldap): Closing connection (2) Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap: Closing libldap handle 0x26460a0 Thu Apr 30 16:34:04 2015 : Info: rlm_ldap (ldap): Closing connection (1) Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap: Closing libldap handle 0x26454b0 Thu Apr 30 16:34:04 2015 : Info: rlm_ldap (ldap): Closing connection (0) Thu Apr 30 16:34:04 2015 : Debug: rlm_ldap: Closing libldap handle 0x26278e0 I know FR wants yes / no but those are not boolean so I guess the schema is not correct - or do you plan to update FR to accept TRUE / FALSE instead of yes / no? Thanks
On Apr 30, 2015, at 10:43 AM, Ben Humpert <ben@an3k.de> wrote:
in the schema file the entry for require message authenticator is listed as
olcAttributeTypes: ( 1.3.6.1.4.1.11344.1.100.2.6 NAME 'radiusClientRequireMa' SINGLE-VALUE DESC 'Require Message Authenticator' EQUALITY booleanMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.7' )
thus one has to enter TRUE or FALSE in LDAP - everything else (I tried it with true, Yes, yes, YES and 1) throws an LDAP error. But now, with TRUE FR won't start anymore. Below is the debug log
I've pushed a fix to v3.0.x. It will now allow true / false for booleans. Alan DeKok.
Alan DeKok wrote:
On Apr 30, 2015, at 10:43 AM, Ben Humpert <ben@an3k.de> wrote:
in the schema file the entry for require message authenticator is listed as
olcAttributeTypes: ( 1.3.6.1.4.1.11344.1.100.2.6 NAME 'radiusClientRequireMa' SINGLE-VALUE DESC 'Require Message Authenticator' EQUALITY booleanMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.7' )
thus one has to enter TRUE or FALSE in LDAP - everything else (I tried it with true, Yes, yes, YES and 1) throws an LDAP error. But now, with TRUE FR won't start anymore. Below is the debug log
I've pushed a fix to v3.0.x. It will now allow true / false for booleans. ^^^^^^^^^^^^ Just in case: Please note that LDAP syntax Boolean requires upper-case TRUE / FALSE.
I saw LDAP client and server implementations which do not care about that leading to interop problems. Ciao, Michael.
On 30 Apr 2015, at 13:14, Michael Ströder <michael@stroeder.com> wrote:
Alan DeKok wrote:
On Apr 30, 2015, at 10:43 AM, Ben Humpert <ben@an3k.de> wrote:
in the schema file the entry for require message authenticator is listed as
olcAttributeTypes: ( 1.3.6.1.4.1.11344.1.100.2.6 NAME 'radiusClientRequireMa' SINGLE-VALUE DESC 'Require Message Authenticator' EQUALITY booleanMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.7' )
thus one has to enter TRUE or FALSE in LDAP - everything else (I tried it with true, Yes, yes, YES and 1) throws an LDAP error. But now, with TRUE FR won't start anymore. Below is the debug log
I've pushed a fix to v3.0.x. It will now allow true / false for booleans. ^^^^^^^^^^^^ Just in case: Please note that LDAP syntax Boolean requires upper-case TRUE / FALSE.
I saw LDAP client and server implementations which do not care about that leading to interop problems.
The comparison will be case insensitive Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
On 30 Apr 2015, at 13:14, Michael Ströder <michael@stroeder.com> wrote:
Alan DeKok wrote:
On Apr 30, 2015, at 10:43 AM, Ben Humpert <ben@an3k.de> wrote:
in the schema file the entry for require message authenticator is listed as
olcAttributeTypes: ( 1.3.6.1.4.1.11344.1.100.2.6 NAME 'radiusClientRequireMa' SINGLE-VALUE DESC 'Require Message Authenticator' EQUALITY booleanMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.7' )
thus one has to enter TRUE or FALSE in LDAP - everything else (I tried it with true, Yes, yes, YES and 1) throws an LDAP error. But now, with TRUE FR won't start anymore. Below is the debug log
I've pushed a fix to v3.0.x. It will now allow true / false for booleans. ^^^^^^^^^^^^ Just in case: Please note that LDAP syntax Boolean requires upper-case TRUE / FALSE.
I saw LDAP client and server implementations which do not care about that leading to interop problems.
The comparison will be case insensitive
Ok. But maybe you will also generate LDAP filters based on a variable. Bear in mind this would have to be upper-case. Otherwise strict LDAP servers (e.g. OpenLDAP) will render the assertion value to invalid. Ciao, Michael.
On Apr 30, 2015, at 1:51 PM, Michael Ströder <michael@stroeder.com> wrote:
But maybe you will also generate LDAP filters based on a variable. Bear in mind this would have to be upper-case. Otherwise strict LDAP servers (e.g. OpenLDAP) will render the assertion value to invalid.
Booleans are only used when parsing the configuration files. They are NOT used in RADIUS packets, or as attributes in the rest of the server. Alan DeKok.
Just tried to set tRue ... OpenLDAP throws an error. Only TRUE or FALSE is accepted. 2015-04-30 19:59 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On Apr 30, 2015, at 1:51 PM, Michael Ströder <michael@stroeder.com> wrote:
But maybe you will also generate LDAP filters based on a variable. Bear in mind this would have to be upper-case. Otherwise strict LDAP servers (e.g. OpenLDAP) will render the assertion value to invalid.
Booleans are only used when parsing the configuration files. They are NOT used in RADIUS packets, or as attributes in the rest of the server.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 30 Apr 2015, at 17:03, Ben Humpert <ben@an3k.de> wrote:
Just tried to set tRue ... OpenLDAP throws an error. Only TRUE or FALSE is accepted.
Ok... but this is useful outside of LDAP. You can now set any boolean CONF_PAIR in the server to true/false in addition to on/off or yes/no. You can use the most appropriate state description for the context. In regards to using boolean values in LDAP filters, you can't, you're limited to strings as there are no boolean attributes in the server. Even if we did support bools, it would be up to the user to convert the value into something LDAP would accept. Making the server perform different type->string conversions based on where the attribute is being used, would be a complete PITA, and isn't worth considering as the use cases are so small. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Apr 30, 2015, at 5:03 PM, Ben Humpert <ben@an3k.de> wrote:
Just tried to set tRue ... OpenLDAP throws an error. Only TRUE or FALSE is accepted.
I fail to see how that's in any way relevant. I said: 1) The server doesn't care if it's TRUE, true, or TrUe. 2) Booleans are only used when parsing the configuration files. And this was in response to your question about FreeRADIUS reading "TRUE" from OpenLDAP for booleans. FreeRADIUS can now read "TRUE" from OpenLDAP for booleans. FreeRADIUS can also read "true" from the config files. What's the problem? If you're going to put something in OpenLDAP that OpenLDAP doesn't understand... well... don't do that. There's no reason to point out here that OpenLDAP requires "TRUE". It's entirely irrelevant to FreeRADIUS. Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Ben Humpert -
Michael Ströder