Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2,
> for what it matters, and db-4.6.21, for what it matters), and it works
> fine if you explicitly ask for hasSubordinates, while this specific attr
> is not returned if you request '+'. The fact hasSubordinates does not
> appear means that the appropriate backend operational attrs hook was not
> called, or its value was ignored.
Since hasSubordinates is a generated attribute, it would be filtered out on
the consumer anyway. There's no reason to ever include it in replication traffic.
> After a quick check, I figured out that bdb_hasSubordinates is passed a
> copy of the original entry, thus without bdb information, and
> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry
> instead of putting operational attrs in rs_operational_attrs in SlapReply.
>
> p.
>
>> Full_Name: Matt Hardin
>> Version: 2.4.22
>> OS: Red Hat AS 4
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (74.38.117.141)
>>
>>
>> In test043 the test database defines a root entry of dc=example,dc=com.
>> For this
>> entry, the results of the ldapsearch do not include the hasSubordinates
>> attribute at all, in spite of the fact that the entry does have
>> subordinates.
>> Test043 passes, due to the fact that this attribute is missing from the
>> root
>> entry in both the provider and the consumer.
>>
>> Other entries with subordinates do include this attribute and its value is
>> correct in all the cases I examined.
>>
>> Here is the snippet from tests/testrun/server1.flt:
>>
>> dn: dc=example,dc=com
>> dc: example
>> objectClass: organization
>> objectClass: domainRelatedObject
>> objectClass: dcObject
>> l: Anytown, Michigan
>> st: Michigan
>> o: Example, Inc.
>> o: EX
>> o: Ex.
>> description: The Example, Inc. at Anytown
>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
>> telephoneNumber: +1 313 555 1817
>> associatedDomain: example.com
>> structuralObjectClass: organization
>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2
>> creatorsName: cn=Manager,dc=example,dc=com
>> createTimestamp: 20100512194705Z
>> entryCSN: 20100512194705.076849Z#000000#000#000000
>> modifiersName: cn=Manager,dc=example,dc=com
>> modifyTimestamp: 20100512194705Z
>> contextCSN: 20100512194748.621773Z#000000#000#000000
>> entryDN: dc=example,dc=com
>> subschemaSubentry: cn=Subschema
>>
>> The version of BDB in use here is 4.8.30, although I note this happens
>> with
>> earlier releases of BDB as well.
>>
>> Also of interest is the fact that this test fails on some platforms (e.g.
>> Windows), because the provider slapd correctly reports
>> hasSubordinates=TRUE,
>> while the consumer omits the attribute entirely, in spite of the fact that
>> subordinate entries do exist on the consumer.
>>
>> -Matt
>>
>>
>>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it
I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2,
for what it matters, and db-4.6.21, for what it matters), and it works
fine if you explicitly ask for hasSubordinates, while this specific attr
is not returned if you request '+'. The fact hasSubordinates does not
appear means that the appropriate backend operational attrs hook was not
called, or its value was ignored.
After a quick check, I figured out that bdb_hasSubordinates is passed a
copy of the original entry, thus without bdb information, and
bdb_hasSubordinates bails out. Apparently, syncprov copies the entry
instead of putting operational attrs in rs_operational_attrs in SlapReply.
p.
> Full_Name: Matt Hardin
> Version: 2.4.22
> OS: Red Hat AS 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.38.117.141)
>
>
> In test043 the test database defines a root entry of dc=example,dc=com.
> For this
> entry, the results of the ldapsearch do not include the hasSubordinates
> attribute at all, in spite of the fact that the entry does have
> subordinates.
> Test043 passes, due to the fact that this attribute is missing from the
> root
> entry in both the provider and the consumer.
>
> Other entries with subordinates do include this attribute and its value is
> correct in all the cases I examined.
>
> Here is the snippet from tests/testrun/server1.flt:
>
> dn: dc=example,dc=com
> dc: example
> objectClass: organization
> objectClass: domainRelatedObject
> objectClass: dcObject
> l: Anytown, Michigan
> st: Michigan
> o: Example, Inc.
> o: EX
> o: Ex.
> description: The Example, Inc. at Anytown
> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
> telephoneNumber: +1 313 555 1817
> associatedDomain: example.com
> structuralObjectClass: organization
> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2
> creatorsName: cn=Manager,dc=example,dc=com
> createTimestamp: 20100512194705Z
> entryCSN: 20100512194705.076849Z#000000#000#000000
> modifiersName: cn=Manager,dc=example,dc=com
> modifyTimestamp: 20100512194705Z
> contextCSN: 20100512194748.621773Z#000000#000#000000
> entryDN: dc=example,dc=com
> subschemaSubentry: cn=Subschema
>
> The version of BDB in use here is 4.8.30, although I note this happens
> with
> earlier releases of BDB as well.
>
> Also of interest is the fact that this test fails on some platforms (e.g.
> Windows), because the provider slapd correctly reports
> hasSubordinates=TRUE,
> while the consumer omits the attribute entirely, in spite of the fact that
> subordinate entries do exist on the consumer.
>
> -Matt
>
>
>
13 years, 4 months
openldap test-058 error
by tibor benke
Hi,
I try to compile openLDAP 2.4.21 with this flags:
ldap:~# ./configure --enable-bdb --enable-hdb --enable-dnssrv --enable-ldap
--enable-ppolicy --disable-nbd
The configuration works perfectly (make depend too), but i get 3 erros
messages by test-058.
ERROR: Second site1 backend not replicated to central master
ERROR: Second site1 backend not replicated to central search
What could cause this? Does anyone know?
Any suggestions or help will be appreciated
platform: Debian Lenny
13 years, 4 months
Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> While I agree that slapo-ppolicy is the better solution in the long run I
>>> see no reason why to not set both attributes at the server's side to
>>> make older LDAP clients happy.
>>
>> This is not a realistic use case. smbk5pwd was written starting in 2004;
>> pam_ldap started supporting LDAP password policy long before then.
>
> Yes, pam_ldap supports enforcing the password policy probably by correcty
> handling the response controls. Grepping through the source of recent versions
> it seems to me it does not read attribute pwdChangedTime nor does nss_ldap.
Because clients don't need to read the value. Since password modification is
all managed on the server, it's an irrelevant detail on the client.
>> Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far
>> worse problems to worry about.
>
> AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when
> someone or something invokes a call like this
>
> getent shadow michael
Nobody does that. Normal users don't even have read permission to do that.
> 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is
> Integer with seconds since epoch. In theory nss_ldap could convert it. But
> AFAICs it doesn't. Also if an older client would search for
> (shadowLastChange<=<value>) this wouldn't work either.
You've just proven the point why shadowLastChange is problematic. The encoded
value is in *minutes* since the epoch. All of the shadow values were poorly
defined to begin with (talking about /etc/shadow, not just RFC2307),
inconsistent with common Unix practice, and most people don't understand them
anyway. They have no role in an LDAP-enabled environment, all they do is
perpetuate confusion.
>> This ITS will be closed.
>
> Well, you're the OpenLDAP boss and free to refuse anything you want. But
> personally I don't understand your strong objections.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com
Howard Chu wrote:
> Michael Ströder wrote:
>> While I agree that slapo-ppolicy is the better solution in the long run I
>> see no reason why to not set both attributes at the server's side to
>> make older LDAP clients happy.
>
> This is not a realistic use case. smbk5pwd was written starting in 2004;
> pam_ldap started supporting LDAP password policy long before then.
Yes, pam_ldap supports enforcing the password policy probably by correcty
handling the response controls. Grepping through the source of recent versions
it seems to me it does not read attribute pwdChangedTime nor does nss_ldap.
> Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far
> worse problems to worry about.
AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when
someone or something invokes a call like this
getent shadow michael
'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is
Integer with seconds since epoch. In theory nss_ldap could convert it. But
AFAICs it doesn't. Also if an older client would search for
(shadowLastChange<=<value>) this wouldn't work either.
> This ITS will be closed.
Well, you're the OpenLDAP boss and free to refuse anything you want. But
personally I don't understand your strong objections.
Ciao, Michael.
13 years, 4 months
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9D91E1E8CB10AE4177453556
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Yes, I'll have to do some work to set that up -- I'll get back to you.
Frank
On 5/13/10 8:44 PM, masarati(a)aero.polimi.it wrote:
> I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn'=
t
> reproduce the issue. Can you provide the configuration and an example
> LDIF that triggers the issue? I simply ran test043, restart both serve=
rs,
> and perform a modification similar to yours, and it went through with n=
o
> problems.
>
> p.
>
> =20
>> Full_Name: Francis Swasey
>> Version: 2.4.22
>> OS: Red Hat Enterprise Linux 5 update 5 64-bit
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (132.198.107.64)
>>
>>
>> Platform: Red Hat Enterprise Linux 5, update 5, 64-bit
>> OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl.
>>
>> The following modify ldif successfully applies to the master:
>>
>> dn: uid=3Dfcswasey,ou=3DPeople,dc=3Duvm,dc=3Dedu
>> changetype: modify
>> replace: sn
>> sn: Swasey
>> -
>> replace: sn
>> sn: Swasey
>> -
>>
>> In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn"
>> attribute is presented twice. In OpenLDAP 2.4 -- it works, but the
>> delta-syncrepl replica pukes on it with this error:
>>
>> syncrepl_message_to_op: rid=3D100 mods check (sn: value #0 provided mo=
re
>> than once)
>>
>>
>>
>> =20
> =20
--=20
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
--------------enig9D91E1E8CB10AE4177453556
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJL7YngAAoJEK5S4SsZ5NvSXhMP/24kilppZcRb+NHqXnP1yqaP
3Y4U/6UJ4E6/oVOccr2trGXzCk4LDPyRvGrlY9SouX5Rf8Y7FsddoE0aiTN3mU+L
xd4iTsExl7lTTuPZ55BvLBgCQWIkwppArXR/u8OasNTtIcgdDPKVkjbCsGY6xcji
ISefkXix5jNgqOe6dQl/DTfJtsAQepCC18t2AvFh727udKu592e5lawlvc3EBH9C
ZB+8Pn7iKbVsUX9htwD3PQY+v52SAgmANoPvbTIeH7HQiclqLBi5qgWW9EbOt43Y
716+FCB55M5W5SKSiFncj45UVAv7z+E1qVuduzcFDuX0LrnC1BMjL/9SbIN2IQX6
ATMrsR1DgxIlBFrKuEAyyQ3IdWMlEtNZQsKj1p+z3YXAJT6C2u8RC3slyL11vMAH
OvkOLwj56Nlib70Zezuevh/5R+KnzEipVrGosIbsZSmTUx32MR4ByRy8DMi8uNkt
JEGSULErsfQEiCr1UsFnwO7d06bf+m0NvcvxTJYvWPBXOjMkTQja1cKnxdEtgoP5
Qg9MZKia3PqO6lQUHgIkRfcqutbuJ+IIuQJ8/oijD3zc198fuUurtiIis/2mjRQv
1Jd/sa52A4z3YFqQ4GyEJokzxFa3xwF4pIoO8NEf1nE1kvUid2gBfqpIfn+SlwBQ
nEKtuFX8bXBV0y2Ze3tv
=7Ac3
-----END PGP SIGNATURE-----
--------------enig9D91E1E8CB10AE4177453556--
13 years, 4 months
Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> michael(a)stroeder.com wrote:
>>> michael(a)stroeder.com wrote:
>>>> I'd rather argue that for
>>>> Samba 3 'sambaPwdLastSet' should be set.
>>>
>>> Uumpf! This is already set. Sorry for the noise.
>>>
>>>> 'shadowLastChange' is rather a POSIX account attribute which from my
>>>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope
>>>> could be
>>>> extended...
>>>
>>> But still it's the question whether we want to have this functionality
>>> for
>>> various password-related attribute all in on overlay or whether there
>>> should
>>> be distinct overlays for each account type (posixAccount/shadowAccount,
>>> sambaSAMAccount, Kerberos user).
>>
>> shadowAccount is deprecated. LDAP ppolicy already provides a
>> pwdChangedTime attribute.
>
> While I agree that slapo-ppolicy is the better solution in the long run I see
> no reason why to not set both attributes at the server's side to make older
> LDAP clients happy.
This is not a realistic use case. smbk5pwd was written starting in 2004;
pam_ldap started supporting LDAP password policy long before then. Anyone
running LDAP clients (pam_ldap, nss_ldap) older than that has far worse
problems to worry about.
>> Ultimately both Kerberos and Samba will just be using LDAP ppolicy.
>
> Yes. But there is indeed a real need for a solution in the meantime...
Yes, in the meantime both Heimdal and Samba use the smbPwdLastSet attribute
which is already taken care of.
This ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 4 months
Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com
Howard Chu wrote:
> michael(a)stroeder.com wrote:
>> michael(a)stroeder.com wrote:
>>> I'd rather argue that for
>>> Samba 3 'sambaPwdLastSet' should be set.
>>
>> Uumpf! This is already set. Sorry for the noise.
>>
>>> 'shadowLastChange' is rather a POSIX account attribute which from my
>>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope
>>> could be
>>> extended...
>>
>> But still it's the question whether we want to have this functionality
>> for
>> various password-related attribute all in on overlay or whether there
>> should
>> be distinct overlays for each account type (posixAccount/shadowAccount,
>> sambaSAMAccount, Kerberos user).
>
> shadowAccount is deprecated. LDAP ppolicy already provides a
> pwdChangedTime attribute.
While I agree that slapo-ppolicy is the better solution in the long run I see
no reason why to not set both attributes at the server's side to make older
LDAP clients happy.
> Ultimately both Kerberos and Samba will just be using LDAP ppolicy.
Yes. But there is indeed a real need for a solution in the meantime...
Ciao, Michael.
13 years, 4 months
