Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com
On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote:
> Andrew:
> > One suggestion following a very quick scan of the code: I think it
> > would be worth bringing the warning about turning off TLS checks
> > into the manual page.
>
> Agreed. Done.
>
> > In particular, there is no reason for this
> > to be AD-specific and it should be easy to adapt it to authenticate
> > against any [collection of] remote LDAP servers.
>
> Actually, it may not be AD specific as is.
Are we any further forward to getting this rolled into contrib? Is there
more we need to do to make it fit better? The tarball has been sitting
there a while, it would seem.
Cheers,
Neil
--
SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
Registered Office:
Cain Road, Bracknell, Berks
RG12 1HN Registered No: 690597 England
12 years, 10 months
Re: (ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by hyc＠symas.com
imjustmatthew(a)gmail.com wrote:
> Full_Name: Matthew Roy
> Version: 2.4.9
> OS: Ubuntu
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.94.128.99)
>
>
> In the Administrater's Guide, Section 18.3.1.3
> (http://www.openldap.org/doc/admin24/replication.html) there is no mention of
> needing to explicitly load the "syncprov" module with a loadmodule directive. It
> is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously
> in 18.3.1 when setting up "plain" syncrepl between servers.
Modules are an optional part of the configuration. You're expected to know
that you need to use loadmodule if you configured module support.
>
> Simply adding it to the example server configuration so new users realize that
> this module may need to be loaded would be sufficient. Otherwise, we try the
> sample code and the testing server won't start and needs to be debugged. Sure
> it's not a big deal, but first experiences should be as positive as possible.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
"error in SSLv3 flush data" when connecting from network again!
by Lifeng Wang
Hi All,
After many googling, I find one thread in openldap mailing list year 2007, Feb to March about this issue, but no solution, and now it happened to me again. So I'm write to this mailing list to report this bug.
I'm running openldap 2.3.27 on CentOS 5.2 x86_64. I configured TLS on the server, and localhost successfully connected to 389 port with start_tls. However when I try to connect to this ldap server with start_tls from a Fedora 10 x86_64 client, it hangs.
As previous reported, if I launch slapd with -d2, remote client can connect to the server with TLS. by using -d1 on both server and client, server hangs at some where:
TLS trace: SSL_accept:error in SSLv3 write certificate request B
and client hangs at
TLS trace: SSL_accept:SSLv3 read certificate A
So, I rung -d2 on client, and find:
tls_read: want=179, got=179
...
tls_read: want=5, got=5
...
tls_read: want=14771, got=9952
...
So, the last seconds shows client expecting 14771 bytes of data, but server only send 9952 bytes, so client thinking server will send more, but server get error?
if I run same ldapsearch command from server (localhost), that line read as:
tls_read: want=14771, got=14771
Does this ring the bell?
Thanks
Noodle
12 years, 10 months
(ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by imjustmatthew＠gmail.com
Full_Name: Matthew Roy
Version: 2.4.9
OS: Ubuntu
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.94.128.99)
In the Administrater's Guide, Section 18.3.1.3
(http://www.openldap.org/doc/admin24/replication.html) there is no mention of
needing to explicitly load the "syncprov" module with a loadmodule directive. It
is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously
in 18.3.1 when setting up "plain" syncrepl between servers.
Simply adding it to the example server configuration so new users realize that
this module may need to be loaded would be sufficient. Otherwise, we try the
sample code and the testing server won't start and needs to be debugged. Sure
it's not a big deal, but first experiences should be as positive as possible.
12 years, 10 months
Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it
hyc(a)symas.com wrote:
> Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on
> attributes that were configured for sorting. I suppose a config option to
> check all attrs may be useful, but for now it seems unnecessary.
OK, I was working on a fix that always eliminated duplicates, but yours
is saving the effort when not strictly needed.
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
-----------------------------------
12 years, 10 months
Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com
hyc(a)symas.com wrote:
> ando(a)sys-net.it wrote:
>> mhardin(a)symas.com wrote:
>>> Full_Name: Matthew Hardin
>>> Version: 2.4.14
>>> OS: RHEL4 x86
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (74.44.226.116)
>>>
>>>
>>> Given an Active Directory group object containing the following two members:
>>>
>>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
>>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>>>
>>> and
>>>
>>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
>>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>>>
>>> (note the extra space between "Frank" and "Y" in the second member)
>>>
>>> Active Directory sees these as different entries and allows them to both be
>>> members of the same group. Back-LDAP and back-meta happily return both of these
>>> values.
>> I'd expect slapd-ldap to return two identical values, since value
>> prettification also eliminates multiple spaces in directoryString values.
>
> Right. It's strange that the value with two spaces was preserved.
Never mind, cn is DirectoryString and has no pretty function.
>
>>> When 'sortvals member' is turned on, the pcache overlay will cache this value
>>> but will not return it on subsequent searches because it sees these two values
>>> as duplicates. According to Howard Chu, this is because the equality matching
>>> rule for the 'member' attribute collapses multiple spaces into one before doing
>>> the comparison and so reports these two values as duplicates.
>>>
>>> Howard asked me to file this ITS as a means to solicit guidance from others as
>>> to the best way/place to fix this.
>> After value normalization, slapd-ldap I think should also check for
>> duplicates (possibly leaving this as an option), and discard them. In
>> fact, it is the proxy backend that injects broken data into the loop.
Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on
attributes that were configured for sorting. I suppose a config option to
check all attrs may be useful, but for now it seems unnecessary.
>> Of course, the best solution in your case would probably be to fix your
>> data... :)
>
> Agreed on all points...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com
ando(a)sys-net.it wrote:
> mhardin(a)symas.com wrote:
>> Full_Name: Matthew Hardin
>> Version: 2.4.14
>> OS: RHEL4 x86
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (74.44.226.116)
>>
>>
>> Given an Active Directory group object containing the following two members:
>>
>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>>
>> and
>>
>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>>
>> (note the extra space between "Frank" and "Y" in the second member)
>>
>> Active Directory sees these as different entries and allows them to both be
>> members of the same group. Back-LDAP and back-meta happily return both of these
>> values.
>
> I'd expect slapd-ldap to return two identical values, since value
> prettification also eliminates multiple spaces in directoryString values.
Right. It's strange that the value with two spaces was preserved.
>> When 'sortvals member' is turned on, the pcache overlay will cache this value
>> but will not return it on subsequent searches because it sees these two values
>> as duplicates. According to Howard Chu, this is because the equality matching
>> rule for the 'member' attribute collapses multiple spaces into one before doing
>> the comparison and so reports these two values as duplicates.
>>
>> Howard asked me to file this ITS as a means to solicit guidance from others as
>> to the best way/place to fix this.
>
> After value normalization, slapd-ldap I think should also check for
> duplicates (possibly leaving this as an option), and discard them. In
> fact, it is the proxy backend that injects broken data into the loop.
>
> Of course, the best solution in your case would probably be to fix your
> data... :)
Agreed on all points...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it
mhardin(a)symas.com wrote:
> Full_Name: Matthew Hardin
> Version: 2.4.14
> OS: RHEL4 x86
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.44.226.116)
>
>
> Given an Active Directory group object containing the following two members:
>
> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>
> and
>
> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
> Accounts,ou=Common,dc=ad,dc=foobar,dc=com
>
> (note the extra space between "Frank" and "Y" in the second member)
>
> Active Directory sees these as different entries and allows them to both be
> members of the same group. Back-LDAP and back-meta happily return both of these
> values.
I'd expect slapd-ldap to return two identical values, since value
prettification also eliminates multiple spaces in directoryString values.
> When 'sortvals member' is turned on, the pcache overlay will cache this value
> but will not return it on subsequent searches because it sees these two values
> as duplicates. According to Howard Chu, this is because the equality matching
> rule for the 'member' attribute collapses multiple spaces into one before doing
> the comparison and so reports these two values as duplicates.
>
> Howard asked me to file this ITS as a means to solicit guidance from others as
> to the best way/place to fix this.
After value normalization, slapd-ldap I think should also check for
duplicates (possibly leaving this as an option), and discard them. In
fact, it is the proxy backend that injects broken data into the loop.
Of course, the best solution in your case would probably be to fix your
data... :)
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
-----------------------------------
12 years, 10 months
(ITS#5977) pcache and broken Active Directory equality matching rules
by mhardin＠symas.com
Full_Name: Matthew Hardin
Version: 2.4.14
OS: RHEL4 x86
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.44.226.116)
Given an Active Directory group object containing the following two members:
member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
Accounts,ou=Common,dc=ad,dc=foobar,dc=com
and
member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User
Accounts,ou=Common,dc=ad,dc=foobar,dc=com
(note the extra space between "Frank" and "Y" in the second member)
Active Directory sees these as different entries and allows them to both be
members of the same group. Back-LDAP and back-meta happily return both of these
values.
When 'sortvals member' is turned on, the pcache overlay will cache this value
but will not return it on subsequent searches because it sees these two values
as duplicates. According to Howard Chu, this is because the equality matching
rule for the 'member' attribute collapses multiple spaces into one before doing
the comparison and so reports these two values as duplicates.
Howard asked me to file this ITS as a means to solicit guidance from others as
to the best way/place to fix this.
Comments?
-Matt
12 years, 10 months
Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no
ando(a)sys-net.it writes:
> Correct. However I'm not sure whether the man page or the code needs to
> be fixed. I'm open to suggestions. I'm inclined towards following the
> man page, as the use of -d implies one may not need the pid, and knows
> the args.
It _may_ mean that. But the existence of the pidfile also means one
need not save the pid after running slapd &. So I think it's best to
keep the existing behavior, in case someone depends on the pidfile.
--
Hallvard
12 years, 10 months
