openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: Most of system définitions may also be centralized without any used of Active Directory. Redundance notions are nevertheless necessary, also inside Linux-land ... ;-) Used of SRV rr is a good reponse, (in particular in case of large Intranet with many remote sites -islands in pacific- and poor communication ressources - satellite) but require to be performed in all client applications : nssldap, samba, ldap client tools for rsync/mail/DNS/proxy/supervision definitions, ... or openldap.

1 0

Re: (ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > This can be solved along with ITS#5792 relatively easily from within > entry_schema_check(), provided the structuralObjectClass attribute is not > indexed. Otherwise, things get a little bit more complicated. Fixed in HEAD, including the (unlikely) case structuralObjectClass is indexed. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.100.26) Submitted by: ando When the structural objectClass of an entry is modified, the corresponding structuralObjectClass attr is not modified accordingly. While addressing ITS#5792, I found out that the only other case that allows modification of the structural objectClass of an object, from "glue" to any other class using the manageDSAit control, results in an entry with the objectClass attribute set to the modified values, while the structuralObjectClass attribute remains "glue". This can be solved along with ITS#5792 relatively easily from within entry_schema_check(), provided the structuralObjectClass attribute is not indexed. Otherwise, things get a little bit more complicated. p.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by h.b.furuseth＠usit.uio.no 04 Feb '09

04 Feb '09

I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > Philippe.eychart(a)informatique.gov.pf wrote: > >> The "tool_conn_setup" function (in common.c) autorise the Url synthaxe >> "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server >> to request (not yet according the rfc 2782 - I've made dnssrv.c patch to >> implement priorities and I try to implement weight before submit this work). So, >> the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via >> "ldap_dn2domain" and "ldap_domain2hostlist" functions). > > This was done to allow testing client-side the DNS SRV feature. > >> Unfortunately, ldap_initialize() doesn't use these functions (but only >> ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages >> (like SAMBA) doesn't enjoy this capability : "passdb backend = >> ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition >> "_ldap._tcp.my.domain. IN SRV ..." >> >> Is there any reason for that ? Can we envisage to increase this possibility ? > > None that I'm aware of. Feel free to move that code from tools to > libldap. Patches are welcome, as usual. But please put a note into the accompanying man-page with a strong recommendation not to use it without further security mechs. I wouldn't configure Samba like this. (Similar problems like DNS lookups in Kerberos implementations for realm- and KDC-discovery.) I've implemented something like this in web2ldap but the SRV mech causes an user interaction on the UI. So the user has a vague chance to determine whether he's tricked to another DSA by DNS spoofing. Ciao, Michael.

1 0

Re: (ITS#5920) segfault in sockbuf.c
by hyc＠symas.com 04 Feb '09

04 Feb '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 01/30/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I link postfix against OpenLDAP libraries for its ldap lookups. With my > previous CVS checkout of RE24 (12/9/2008) there were no problems with this. > However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap > binary always segfaults: > This is likely related to the recent TLS changes in RE24. Yes, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Philippe.eychart(a)informatique.gov.pf wrote: > The "tool_conn_setup" function (in common.c) autorise the Url synthaxe > "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server > to request (not yet according the rfc 2782 - I've made dnssrv.c patch to > implement priorities and I try to implement weight before submit this work). So, > the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via > "ldap_dn2domain" and "ldap_domain2hostlist" functions). This was done to allow testing client-side the DNS SRV feature. > Unfortunately, ldap_initialize() doesn't use these functions (but only > ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages > (like SAMBA) doesn't enjoy this capability : "passdb backend = > ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition > "_ldap._tcp.my.domain. IN SRV ..." > > Is there any reason for that ? Can we envisage to increase this possibility ? None that I'm aware of. Feel free to move that code from tools to libldap. Patches are welcome, as usual. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5920) segfault in sockbuf.c
by quanah＠zimbra.com 04 Feb '09

04 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 01/30/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I link postfix against OpenLDAP libraries for its ldap lookups. With my previous CVS checkout of RE24 (12/9/2008) there were no problems with this. However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap binary always segfaults: Core was generated by `proxymap -t unix -u'. Program terminated with signal 11, Segmentation fault. [New process 19154] #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 168 sockbuf.c: No such file or directory. in sockbuf.c (gdb) bt #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 #1 0xb7e21eaf in ldap_pvt_tls_inplace (sb=0x807bfc0) at tls2.c:456 #2 0xb7e21f2c in ldap_tls_inplace (ld=0x807ce18) at tls2.c:475 #3 0xb7e22e84 in ldap_start_tls_s (ld=0x807ce18, serverctrls=0x0, clientctrls=0x0) at tls2.c:922 #4 0x080514aa in dict_ldap_connect (dict_ldap=0x807ca08) at dict_ldap.c:711 #5 0x0805257e in dict_ldap_lookup (dict=0x807ca08, name=0x807cbc8 "*") at dict_ldap.c:1123 #6 0x0804b590 in proxymap_service (client_stream=0x80799a8, unused_service=0xbf8cbf6d "proxymap", argv=0xbf8c9f24) at proxymap.c:354 #7 0x0804c5d2 in multi_server_execute (unused_event=1, context=0x80799a8 "") at multi_server.c:311 #8 0x0805b08d in event_loop (delay=-1) at events.c:1079 #9 0x0804bee0 in multi_server_main (argc=4, argv=0xbf8c9f14, service=0x804b1b0 <proxymap_service>) at multi_server.c:841 #10 0x0804add4 in main (argc=4, argv=0xbf8c9f14) at proxymap.c:651 (gdb) print *sb $2 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 0}, sb_iod = 0x0, sb_fd = -1, sb_max_incoming = 0, sb_trans_needs_read = 0, sb_trans_needs_write = 0} This is likely related to the recent TLS changes in RE24.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs