ldapi:// with path
HI! Testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9 I noticed that something's wrong with LDAPI URLs containing a URL-encoded path. This does not work: server = 'ldapi://%2Ftmp%2Fopenldap-socket' leads to: rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi:///tmp/openldap-socket failed: Can't contact LDAP server I'm not sure whether radiusd URL-decodes the path and passes "ldapi:///tmp/openldap-socket" to libldap or whether the decoding simply happens when writing the log line. It should *not* do URL-decoding because parsing the LDAP URL "ldapi:///tmp/openldap-socket" in libldap won't work since the first "/" after the "hostport" part is the next separator to the DN portion. Ciao, Michael.
On 29 Jun 2015, at 05:01, Michael Ströder <michael@stroeder.com> wrote:
HI!
Testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9 I noticed that something's wrong with LDAPI URLs containing a URL-encoded path.
This does not work:
server = 'ldapi://%2Ftmp%2Fopenldap-socket'
leads to:
rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi:///tmp/openldap-socket failed: Can't contact LDAP server
I'm not sure whether radiusd URL-decodes the path and passes "ldapi:///tmp/openldap-socket" to libldap or whether the decoding simply happens when writing the log line.
It should *not* do URL-decoding because parsing the LDAP URL "ldapi:///tmp/openldap-socket" in libldap won't work since the first "/" after the "hostport" part is the next separator to the DN portion.
It's actually ldap_url_parse doing more than what's claimed in the man page entry: ldap_url_parse() breaks down an LDAP URL passed in url into its component pieces. If successful, zero is returned, an LDAP URL description is allocated, filled in, and ludpp is set to point to it. If an error occurs, a non-zero URL error code is returned. In addition to breaking the components down, it also url unescapes them *sigh*. So the solution is to re-escape the host portion. I'll push a fix in a bit. -Arran 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 29 Jun 2015, at 05:01, Michael Ströder <michael@stroeder.com> wrote:
HI!
Testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9 I noticed that something's wrong with LDAPI URLs containing a URL-encoded path.
This does not work:
server = 'ldapi://%2Ftmp%2Fopenldap-socket'
leads to:
rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi:///tmp/openldap-socket failed: Can't contact LDAP server
I'm not sure whether radiusd URL-decodes the path and passes "ldapi:///tmp/openldap-socket" to libldap or whether the decoding simply happens when writing the log line.
It should *not* do URL-decoding because parsing the LDAP URL "ldapi:///tmp/openldap-socket" in libldap won't work since the first "/" after the "hostport" part is the next separator to the DN portion.
It's actually ldap_url_parse doing more than what's claimed in the man page entry:
ldap_url_parse() breaks down an LDAP URL passed in url into its component pieces. If successful, zero is returned, an LDAP URL description is allocated, filled in, and ludpp is set to point to it. If an error occurs, a non-zero URL error code is returned.
In addition to breaking the components down, it also url unescapes them *sigh*.
Yes, it has to for using the URI components later. That's what module ldapurl in python-ldap also does. Unparsing the components to a valid LDAP URL is more.
So the solution is to re-escape the host portion. I'll push a fix in a bit.
Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI. Ciao, Michael.
On 29 Jun 2015, at 09:48, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 05:01, Michael Ströder <michael@stroeder.com> wrote:
HI!
Testing git v3.1.x 36e1b02e926df5cd75d4d548694401535c607ca9 I noticed that something's wrong with LDAPI URLs containing a URL-encoded path.
This does not work:
server = 'ldapi://%2Ftmp%2Fopenldap-socket'
leads to:
rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi:///tmp/openldap-socket failed: Can't contact LDAP server
I'm not sure whether radiusd URL-decodes the path and passes "ldapi:///tmp/openldap-socket" to libldap or whether the decoding simply happens when writing the log line.
It should *not* do URL-decoding because parsing the LDAP URL "ldapi:///tmp/openldap-socket" in libldap won't work since the first "/" after the "hostport" part is the next separator to the DN portion.
It's actually ldap_url_parse doing more than what's claimed in the man page entry:
ldap_url_parse() breaks down an LDAP URL passed in url into its component pieces. If successful, zero is returned, an LDAP URL description is allocated, filled in, and ludpp is set to point to it. If an error occurs, a non-zero URL error code is returned.
In addition to breaking the components down, it also url unescapes them *sigh*.
Yes, it has to for using the URI components later.
It's a public function, for breaking a url into components, it should do what its man page entry says it should do. There's an internal version which accepts compatibility flags, if they need the components unescaped for internal use they could of used that. Breaking the URL into its components does not require unescaping. The component separators '/' and '?' are not escaped. See here: https://tools.ietf.org/html/rfc2255#section-3
That's what module ldapurl in python-ldap also does. Unparsing the components to a valid LDAP URL is more.
OK.
So the solution is to re-escape the host portion. I'll push a fix in a bit.
Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI.
base_dn, filter, scope and attributes need stripping. We don't support specifying them via the URL. I guess we could error out if any of those components were found -Arran 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 29 Jun 2015, at 09:48, Michael Ströder <michael@stroeder.com> wrote: Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI.
base_dn, filter, scope and attributes need stripping. We don't support specifying them via the URL.
I guess we could error out if any of those components were found
To me this seems to be the best solution for now. Ciao, Michael.
On Jun 29, 2015, at 11:22 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 09:48, Michael Ströder <michael@stroeder.com> wrote: Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI.
base_dn, filter, scope and attributes need stripping. We don't support specifying them via the URL.
I guess we could error out if any of those components were found
To me this seems to be the best solution for now.
OK, done. -Arran
Arran Cudbard-Bell wrote:
On Jun 29, 2015, at 11:22 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 09:48, Michael Ströder <michael@stroeder.com> wrote: Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI.
base_dn, filter, scope and attributes need stripping. We don't support specifying them via the URL.
I guess we could error out if any of those components were found
To me this seems to be the best solution for now.
OK, done.
Sorry, this needs some more work. Checked 0b81520cb825473a91d1ae21cc874e6220fec461: server = 'ldap://localhost:1390' now results in log message: rlm_ldap (ldap): Connecting to ldap://ldap://localhost:1390 ^^^^^^^^^^^ rlm_ldap (ldap): ldap_initialize failed: Bad parameter to an ldap routine server = 'ldapi://%2Ftmp%2Fopenldap-socket' now results in log message: Invalid server, must be in <server>[:<port>] format server = 'localhost:1390' works ok. Ciao, Michael.
On Jun 30, 2015, at 1:00 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 29, 2015, at 11:22 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 29 Jun 2015, at 09:48, Michael Ströder <michael@stroeder.com> wrote: Hmm, I'd prefer you to simply pass the configured original string to libldap and use result code of ldap_url_parse() just as proof that it's a valid LDAP URI.
base_dn, filter, scope and attributes need stripping. We don't support specifying them via the URL.
I guess we could error out if any of those components were found
To me this seems to be the best solution for now.
OK, done.
Sorry, this needs some more work.
Checked 0b81520cb825473a91d1ae21cc874e6220fec461:
server = 'ldap://localhost:1390' now results in log message:
rlm_ldap (ldap): Connecting to ldap://ldap://localhost:1390 ^^^^^^^^^^^ rlm_ldap (ldap): ldap_initialize failed: Bad parameter to an ldap routine
server = 'ldapi://%2Ftmp%2Fopenldap-socket'
now results in log message:
Invalid server, must be in <server>[:<port>] format
server = 'localhost:1390' works ok.
You didn't re-run configure... re-run configure. -Arran
On Jun 30, 2015, at 1:45 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
You didn't re-run configure... re-run configure.
I did.
But again: make distclean ; ./configure --prefix=/opt/freeradius && make
Odd, I don't see that. Can you post the ./configure output for the LDAP module. -Arran
Arran Cudbard-Bell wrote:
On Jun 30, 2015, at 1:45 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
You didn't re-run configure... re-run configure.
I did.
But again: make distclean ; ./configure --prefix=/opt/freeradius && make
Odd, I don't see that.
Did you run configure? Just kidding, SCNR. ;-)
Can you post the ./configure output for the LDAP module.
Find attached src/modules/rlm_ldap/config.log. Is that the file you wanted? Ciao, Michael.
On Jun 30, 2015, at 1:52 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 30, 2015, at 1:45 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
You didn't re-run configure... re-run configure.
I did.
But again: make distclean ; ./configure --prefix=/opt/freeradius && make
Odd, I don't see that.
Did you run configure? Just kidding, SCNR. ;-)
:P
Can you post the ./configure output for the LDAP module.
Find attached src/modules/rlm_ldap/config.log. Is that the file you wanted?
Got stripped. If you have the content-type I can white list it... But really just wanted the output to see what functions your libldap was providing. Output, or config.h from src/modules/rlm_ldap would work just as well. -Arran
Arran Cudbard-Bell wrote:
Got stripped. If you have the content-type I can white list it...
But really just wanted the output to see what functions your libldap was providing.
BTW: It's OpenLDAP 2.4.40. All lines starting with ac_cv_func_ldap: ac_cv_func_ldap_create_session_tracking_control=yes ac_cv_func_ldap_create_sort_control=yes ac_cv_func_ldap_create_sort_keylist=yes ac_cv_func_ldap_free_sort_keylist=yes ac_cv_func_ldap_initialize=yes ac_cv_func_ldap_is_ldap_url=yes ac_cv_func_ldap_sasl_interactive_bind=yes ac_cv_func_ldap_set_rebind_proc=yes ac_cv_func_ldap_start_tls_s=yes ac_cv_func_ldap_unbind_ext_s=yes ac_cv_func_ldap_url_desc2str=yes ac_cv_func_ldap_url_parse=yes Ciao, Michael.
On Jun 30, 2015, at 2:03 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
Got stripped. If you have the content-type I can white list it...
But really just wanted the output to see what functions your libldap was providing.
BTW: It's OpenLDAP 2.4.40.
All lines starting with ac_cv_func_ldap:
ac_cv_func_ldap_create_session_tracking_control=yes ac_cv_func_ldap_create_sort_control=yes ac_cv_func_ldap_create_sort_keylist=yes ac_cv_func_ldap_free_sort_keylist=yes ac_cv_func_ldap_initialize=yes ac_cv_func_ldap_is_ldap_url=yes ac_cv_func_ldap_sasl_interactive_bind=yes ac_cv_func_ldap_set_rebind_proc=yes ac_cv_func_ldap_start_tls_s=yes ac_cv_func_ldap_unbind_ext_s=yes ac_cv_func_ldap_url_desc2str=yes ac_cv_func_ldap_url_parse=yes
OK, should work now. -Arran
Michael Ströder wrote:
Arran Cudbard-Bell wrote:
OK, should work now.
These cases both work:
server = 'ldap://localhost:1390' server = 'localhost:1390'
This does not work: server = 'ldapi://%2Ftmp%2Fopenldap-socket'
=> "Failed recombining URL components"
And this fails too: server = 'ldapi://' rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi://:389 failed: Can't contact LDAP server ^^^^^ As said you should not do any recombination and pass the string as is to libldap. This would save you a lot of headache. Ciao, Michael. (author of python-ldap's module ldapurl)
On Jun 30, 2015, at 3:50 PM, Michael Ströder <michael@stroeder.com> wrote:
Michael Ströder wrote:
Arran Cudbard-Bell wrote:
OK, should work now.
These cases both work:
server = 'ldap://localhost:1390' server = 'localhost:1390'
This does not work: server = 'ldapi://%2Ftmp%2Fopenldap-socket'
=> "Failed recombining URL components"
And this fails too:
server = 'ldapi://'
rlm_ldap (ldap): Bind with uid=radiusd,ou=sys,dc=stroeder,dc=local to ldapi://:389 failed: Can't contact LDAP server ^^^^^
As said you should not do any recombination and pass the string as is to libldap. This would save you a lot of headache.
TBH LDAP URLs are the wrong thing to use to specify a server, but we have no choice, the the OpenLDAP guys don't provide an interface to specify the connection type for a handle. The string recombination is done because we need to set a port. If the user specifies: server = 'ldap://example.org' port = 1300 They would (and did) wonder why the server was still attempting to connect on port 389. So whilst in theory, in a perfect world, it would be nice to pass through the URLs unmolested, in this case we can't (except for ldapi://). Why not just get rid of port? ----------------------------- Because not all versions of libldap or LDAP libraries support LDAP urls, plus we need it for legacy compatibility. Why not just disallow URLs? --------------------------- We likely will for v3.1.x, because the current code is ridiculously complex for what is does. We'll then have a scheme configuration option to specify ldapi, ldapc, ldaps or ldap, which will make integrating with other LDAP implementations easier. If ldap_initialize is the only interface for specifying the scheme, then we'll construct a URL behind the scenes and pass that to it. -Arran rlm_ldap (ldap): Opening additional connection (0), 1 of 100 pending slots used rlm_ldap (ldap): Connecting to ldapi:// rlm_ldap (ldap): Bind with cn=admin,dc=foo,dc=com to ldapi:// failed: Can't contact LDAP server rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /usr/local/freeradius/etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap" rlm_ldap (ldap): Opening additional connection (0), 1 of 100 pending slots used rlm_ldap (ldap): Connecting to ldapi://%2Ftmp%2Fopenldap-socket rlm_ldap (ldap): Bind with cn=admin,dc=foo,dc=com to ldapi://%2Ftmp%2Fopenldap-socket failed: Can't contact LDAP server rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /usr/local/freeradius/etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap"
Arran Cudbard-Bell wrote:
If the user specifies:
server = 'ldap://example.org' port = 1300
They would (and did) wonder why the server was still attempting to connect on port 389.
Hmm, I'm inclined to just spit out an error message in this case clearly recommending to add the port number to the LDAP URL. Ciao, Michael.
On Jun 30, 2015, at 4:54 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
If the user specifies:
server = 'ldap://example.org' port = 1300
They would (and did) wonder why the server was still attempting to connect on port 389.
Hmm, I'm inclined to just spit out an error message in this case clearly recommending to add the port number to the LDAP URL.
Which we can't do in v3.0.x because it would break people's configurations. What are your arguments for URL support when specifying servers? -Arran
Arran Cudbard-Bell wrote:
On Jun 30, 2015, at 4:54 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
If the user specifies:
server = 'ldap://example.org' port = 1300
They would (and did) wonder why the server was still attempting to connect on port 389.
Hmm, I'm inclined to just spit out an error message in this case clearly recommending to add the port number to the LDAP URL.
Which we can't do in v3.0.x because it would break people's configurations.
It's quite a simple change which you could announce clearly.
What are your arguments for URL support when specifying servers?
First of all: It's required to work for LDAPI (which I use a lot together with SASL/EXTERNAL). LDAP URLs also have everything in one parameter. Example: ldaps://ldap.example.com:9999 tells you to talk TLS before LDAP to host ldap.example.com and port 9999 all in one line. In web2ldap I even use LDAP URL extensions so you can construct a bookmark for specifying to use StartTLS extended operation. Ciao, Michael.
Re-tested recent commit d55a4dfec89fac91140fb1ec68198c3deef7afa4: --------------------------- These tests were OK: server = 'ldapi://' server = 'ldapi://%2Ftmp%2Fopenldap-socket' server = 'ldaps://localhost:1390' server = 'ldap://localhost:1390' server = 'ldap://localhost' port = 1390 server = 'localhost:1390' server = 'localhost' port = 1390 --------------------------- What I found surprising: server = 'ldap://localhost:1390' port = 1391 results in ldap://localhost:1391 I'd argue that the port number in the LDAP URL should have precedence over an accidently uncommented port parameter. Anyway, thanks for working on it so quickly! Ciao, Michael.
Arran Cudbard-Bell wrote:
What I found surprising:
server = 'ldap://localhost:1390' port = 1391
results in ldap://localhost:1391
I'd argue that the port number in the LDAP URL should have precedence over an accidently uncommented port parameter.
Agreed, but not for that reason :)
Re-tested with 8655446068a7bbec8a6ecc148418926fea9fc2d0: server = 'ldap://localhost' port = 1390 now results in ldap://localhost:389 Ciao, Michael.
On 30 Jun 2015, at 19:12, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 30, 2015, at 5:55 PM, Michael Ströder <michael@stroeder.com> wrote:
Re-tested with 8655446068a7bbec8a6ecc148418926fea9fc2d0:
server = 'ldap://localhost' port = 1390
now results in ldap://localhost:389
I've pushed a fix.
You pushed (helpful) changes for the case where we don't have ldap_initialize. We know on OPs system he has ldap_initialize because the code is producing URLs, so it'll still be broken in the OPs case. This says when a port does not exist in the string, don't set it. http://www.openldap.org/devel//gitweb.cgi?p=openldap.git;a=blob;f=libraries/... Unless LDAP_PVT_URL_PARSE_DEF_PORT was passed in. So I have no idea why it's still messed up. I guess i'll run it under lldb and find exactly where libldap is setting the port. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 30 Jun 2015, at 22:43, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 30 Jun 2015, at 19:12, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 30, 2015, at 5:55 PM, Michael Ströder <michael@stroeder.com> wrote:
Re-tested with 8655446068a7bbec8a6ecc148418926fea9fc2d0:
server = 'ldap://localhost' port = 1390
now results in ldap://localhost:389
I've pushed a fix.
You pushed (helpful) changes for the case where we don't have ldap_initialize.
We know on OPs system he has ldap_initialize because the code is producing URLs, so it'll still be broken in the OPs case.
This says when a port does not exist in the string, don't set it.
http://www.openldap.org/devel//gitweb.cgi?p=openldap.git;a=blob;f=libraries/...
Unless LDAP_PVT_URL_PARSE_DEF_PORT was passed in.
So I have no idea why it's still messed up. I guess i'll run it under lldb and find exactly where libldap is setting the port.
1175 int 1176 ldap_url_parse( LDAP_CONST char *url_in, LDAPURLDesc **ludpp ) 1177 { 1178 return ldap_url_parse_ext( url_in, ludpp, LDAP_PVT_URL_PARSE_HISTORIC ); 1179 } 51 #define LDAP_PVT_URL_PARSE_HISTORIC (LDAP_PVT_URL_PARSE_NODEF_SCOPE | \ 52 LDAP_PVT_URL_PARSE_NOEMPTY_HOST | \ 53 LDAP_PVT_URL_PARSE_DEF_PORT) Well that explains it... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
1175 int 1176 ldap_url_parse( LDAP_CONST char *url_in, LDAPURLDesc **ludpp ) 1177 { 1178 return ldap_url_parse_ext( url_in, ludpp, LDAP_PVT_URL_PARSE_HISTORIC ); 1179 }
51 #define LDAP_PVT_URL_PARSE_HISTORIC (LDAP_PVT_URL_PARSE_NODEF_SCOPE | \ 52 LDAP_PVT_URL_PARSE_NOEMPTY_HOST | \ 53 LDAP_PVT_URL_PARSE_DEF_PORT)
Well that explains it...
OK, run through all OPs test cases, and they work, I think this is finally fixed *sigh* -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
1175 int 1176 ldap_url_parse( LDAP_CONST char *url_in, LDAPURLDesc **ludpp ) 1177 { 1178 return ldap_url_parse_ext( url_in, ludpp, LDAP_PVT_URL_PARSE_HISTORIC ); 1179 }
51 #define LDAP_PVT_URL_PARSE_HISTORIC (LDAP_PVT_URL_PARSE_NODEF_SCOPE | \ 52 LDAP_PVT_URL_PARSE_NOEMPTY_HOST | \ 53 LDAP_PVT_URL_PARSE_DEF_PORT)
Well that explains it...
OK, run through all OPs test cases, and they work, I think this is finally fixed
Assuming I haven't missed one of my test cases I can confirm it works now. Thanks again for your effort.
*sigh*
Yeah, sometimes fixing things feels like working byte-wise to the solution... Ciao, Michael.
On 1 Jul 2015, at 03:42, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
1175 int 1176 ldap_url_parse( LDAP_CONST char *url_in, LDAPURLDesc **ludpp ) 1177 { 1178 return ldap_url_parse_ext( url_in, ludpp, LDAP_PVT_URL_PARSE_HISTORIC ); 1179 }
51 #define LDAP_PVT_URL_PARSE_HISTORIC (LDAP_PVT_URL_PARSE_NODEF_SCOPE | \ 52 LDAP_PVT_URL_PARSE_NOEMPTY_HOST | \ 53 LDAP_PVT_URL_PARSE_DEF_PORT)
Well that explains it...
OK, run through all OPs test cases, and they work, I think this is finally fixed
Assuming I haven't missed one of my test cases I can confirm it works now. Thanks again for your effort.
*sigh*
Yeah, sometimes fixing things feels like working byte-wise to the solution...
Thanks for testing :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jun 30, 2015, at 5:19 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Jun 30, 2015, at 4:54 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
If the user specifies:
server = 'ldap://example.org' port = 1300
They would (and did) wonder why the server was still attempting to connect on port 389.
Hmm, I'm inclined to just spit out an error message in this case clearly recommending to add the port number to the LDAP URL.
Which we can't do in v3.0.x because it would break people's configurations.
It's quite a simple change which you could announce clearly.
Then all the package maintainers would refuse to update until the next major release of their OS because it'd be a breaking change.
What are your arguments for URL support when specifying servers?
First of all: It's required to work for LDAPI (which I use a lot together with SASL/EXTERNAL).
No it's not. As previously stated we could construct the URL with an ldapi:// prefix, and pass that to LDAP initialize.
LDAP URLs also have everything in one parameter.
Which makes parsing and modifying the configuration programatically, harder, and is inconsistent with everything else in the server. You don't use redis:// to specify a redis server, you don't use mysql:// to specify a mysql server.
Example:
ldaps://ldap.example.com:9999 tells you to talk TLS before LDAP to host ldap.example.com and port 9999 all in one line.
But being able to turn on SSL for individual hosts in a cluster is potentially useful. I guess that's the biggest advantage. I can't say i've ever come across an LDAP cluster that uses a mixture of encryption clear and tls connections though.
In web2ldap I even use LDAP URL extensions so you can construct a bookmark for specifying to use StartTLS extended operation.
Is the extension standard, or something you pull out and use as a hint to call ldap_start_tls (or Python equivalent)? -Arran
Arran Cudbard-Bell wrote:
On Jun 30, 2015, at 5:19 PM, Michael Ströder <michael@stroeder.com> wrote: It's quite a simple change which you could announce clearly.
Then all the package maintainers would refuse to update until the next major release of their OS because it'd be a breaking change.
The holy cow of package maintainers to call their distribution "stable". For whatever definition of "stable" that is...
First of all: It's required to work for LDAPI (which I use a lot together with SASL/EXTERNAL).
No it's not.
As previously stated we could construct the URL with an ldapi:// prefix, and pass that to LDAP initialize.
Hmm, of course you could even accept a path name for "server". But that makes distinguishing the different values even more complicated.
LDAP URLs also have everything in one parameter.
Which makes parsing and modifying the configuration programatically, harder, and is inconsistent with everything else in the server.
You don't use redis:// to specify a redis server, you don't use mysql:// to specify a mysql server.
Frankly I love URLs... ;-)
Example:
ldaps://ldap.example.com:9999 tells you to talk TLS before LDAP to host ldap.example.com and port 9999 all in one line.
But being able to turn on SSL for individual hosts in a cluster is potentially useful. I guess that's the biggest advantage.
I can't say i've ever come across an LDAP cluster that uses a mixture of encryption clear and tls connections though.
You could think of a local replica accessible via LDAPI and using a remote replica as fall-back.
In web2ldap I even use LDAP URL extensions so you can construct a bookmark for specifying to use StartTLS extended operation.
Is the extension standard, or something you pull out and use as a hint to call ldap_start_tls (or Python equivalent)?
The LDAP URL extensions are standard but this particular extension is not. I should write an I-D though. <off-topic> In python-ldap it's pretty easy to deal with LDAP URLs and custom extensions by just defining a mapping from a extension name to a class attribute: https://fossies.org/linux/web2ldap/pylib/ldaputil/extldapurl.py </off-topic> Ciao, Michael.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Michael Ströder