Re: (ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠zimbra.com
--On Thursday, June 09, 2011 10:19 PM +0000 quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: NA
> OS: NA
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.45.108)
>
>
> The admin guide refers to "Start TLS" in multiple locations instead of
> "StartTLS", which leads to confusion among end users, and makes searching
> for the startTLS pieces a pain. I will fix shortly.
>
I will mark this as invalid, as this is how it is described in all the RFCs
as well (Start TLS).
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 9 months
Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com
mark.cave-ayland(a)siriusit.co.uk wrote:
> Full_Name: Mark Cave-Ayland
> Version: 2.4.23
> OS: Linux/Debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (81.187.123.11)
>
>
> Hi all,
>
> We have an issue on one of our production systems whereby openldap is not
> enforcing the ACLs on a back-perl subordinate database.
Keep in mind, this is back-perl's documented behavior.
>>>
ACCESS CONTROL
The perl backend does not honor any of the access control semantics
described in slapd.access(5); all access control is delegated to the
underlying PERL scripting. Only read (=r) access to the entry pseudo-
attribute and to the other attribute values of the entries returned by
the search operation is honored, which is performed by the frontend.
<<<
Treating this as an enhancement request.
> In this particular system, the membership of certain groups stored within LDAP
> is determined by some customised logic in a Perl module which dynamically
> generates LDAP objects with posixGroup/groupOfNames entries conditionally based
> upon the values of existing LDAP attributes within the tree. However, since
> these internal LDAP attribute lookups can be quite slow, we wish to hide them
> from all but a small minority of bind DNs. Unfortunately what we are finding is
> that the back-perl module is not respecting the ACLs in slapd.conf.
>
> The following files can be used to reproduce this issue with openldap 2.4.23:
>
> http://pastebin.siriusit.co.uk/perlacl/slapd.conf
> http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif
> http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm
>
> The password for both the "cn=admin,dc=my-domain,dc=com" and the
> "cn=restricted,dc=my-domain,dc=com" DNs is secret.
>
> The ACLs in the above slapd.conf look like this:
>
> access to dn.subtree="ou=perl,dc=my-domain,dc=com"
> by dn="cn=admin,dc=my-domain,dc=com" read
> by dn="cn=restricted,dc=my-domain,dc=com" none
>
> access to dn.subtree="ou=hidden,dc=my-domain,dc=com"
> by dn="cn=admin,dc=my-domain,dc=com" read
> by dn="cn=restricted,dc=my-domain,dc=com" none
>
> access to *
> by dn="cn=admin,dc=my-domain,dc=com" write
> by dn="cn=restricted,dc=my-domain,dc=com" read
> by * auth
>
> Using these ACLs, I would expect that cn=admin should be able to read the whole
> directory, whereas cn=restricted should not be able to see either the
> "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com"
> DN subtree.
>
> However, performing an LDAP search binding as cn=restricted gives the following
> output:
>
> build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D
> 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW
> Enter LDAP Password:
> dn: dc=my-domain,dc=com
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o:: bXlkb21haW4uY29tIA==
> dc: my-domain
>
> dn: ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: real
>
> dn: ou=realtest1,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest1
>
> dn: ou=realtest2,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest2
>
> dn: ou=realtest3,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest3
>
> dn: ou=realtest4,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest4
>
> dn: ou=realtest5,ou=real,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: realtest5
>
> dn: cn=restricted,dc=my-domain,dc=com
> objectClass: simpleSecurityObject
> objectClass: organizationalRole
> cn: restricted
> description: restricted user
> userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9
>
> dn: cn=admin,dc=my-domain,dc=com
> objectClass: simpleSecurityObject
> objectClass: organizationalRole
> cn:: YWRtaW4g
> description: admin user
> userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9
>
> dn: ou=perltest5,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest5
>
> dn: ou=perltest4,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest4
>
> dn: ou=perltest3,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest3
>
> dn: ou=perltest2,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest2
>
> dn: ou=perltest1,ou=perl,dc=my-domain,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: perltest1
>
>
> In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden
> from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree
> is not.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com
Andrew Findlay wrote:
> On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote:
>
>>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema
>>> fragments for pwdPolicySubentry and pwdAccountLockedTime.
>>
>> That's how they were defined in the IETF Draft. The schema fragments
>> in the manpage were copied directly from the spec. The fact that the
>> current implementation deviates from the spec is just out of
>> necessity to make things work at all in our present code base.
>
> Certainly the use of pwdPolicySubentry differs from the
> intention of the draft (which I believe was intending to use
> real X.500-style subentries).
>
> The case of pwdAccountLockedTime is arguable.
> draft-behera-ldap-password-policy-xx.txt says:
>
> This attribute holds the time that the user's account was locked. A
> locked account means that the password may no longer be used to
> authenticate. A 000001010000Z value means that the account has been
> locked permanently, and that only a password administrator can unlock
> the account.
>
> Unfortunately it says nothing about *how* a password
> administrator should do that when the attribute is marked
> NO-USER-MODIFICATION. I would argue that this is a
> deficiency in the draft, and that the current OpenLDAP
> behaviour is more useful.
>
>> Things will not always work this way...
>
> Indeed, but I would prefer the manpages to reflect the
> reality of the current release!
I note that in ppolicy.c we have:
{ "( 1.3.6.1.4.1.42.2.27.8.1.17 "
"NAME ( 'pwdAccountLockedTime' ) "
"DESC 'The time an user account was locked' "
"EQUALITY generalizedTimeMatch "
"ORDERING generalizedTimeOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 "
"SINGLE-VALUE "
#if 0
/* Not until Relax control is released */
"NO-USER-MODIFICATION "
#endif
"USAGE directoryOperation )",
We have in fact released support for the Relax control, so it's probably time
to unifdef these bits and go back to the documented behavior.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: [PATCH] More for ITS#6872
by hyc＠symas.com
cmikk(a)qwest.net wrote:
> [Note: The previous patch did not fix the problem when
> the consumer's access was restricted to the replicated
> subtree. This patch fixes that.]
Both applied to git master, thanks.
>
> Perform the internal FIND_CSN search based at the backend's suffix with the
> privileges of the backend's root DN.
> ---
> servers/slapd/overlays/syncprov.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c
> index 0c148f9..a058e19 100644
> --- a/servers/slapd/overlays/syncprov.c
> +++ b/servers/slapd/overlays/syncprov.c
> @@ -661,6 +661,8 @@ again:
> if ( BER_BVISEMPTY(&cf.f_av_value )) {
> cf.f_av_value = *csn;
> }
> + fop.o_dn = op->o_bd->be_rootdn;
> + fop.o_ndn = op->o_bd->be_rootndn;
> fop.o_req_dn = op->o_bd->be_suffix[0];
> fop.o_req_ndn = op->o_bd->be_nsuffix[0];
> /* Look for exact match the first time */
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
Re: (ITS#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com
hyc(a)symas.com wrote:
> bcolston(a)xtec.com wrote:
>> Full_Name: Barry Colston
>> Version: 2.4.23
>> OS: Fedora 10
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (209.255.208.200)
>
> I'm looking at your test case now. One thing to note, serverIDs must all be
> non-zero in a multi-master configuration. serverID == 0 is only valid in
> single-master replication.
>
>> When a "Refresh Present" phase is performed at a multi-master consumer, objects
>> that were deleted at the provider
>> while the consumer was down are not deleted from the multi-master consumer (if
>> the provider is brought down and back up after the consumer is down). This
>> problem can be duplicated as follows:
>> 1. Start provider
>> 2. Start consumer, which is configured as a multi-master server
>> 3. Add 10 records to the provider and wait until the records are replicated to
>> the multi-master consumer
>> 4. Stop the consumer
>> 5. Delete 3 of the records that were added to the provider
>> 6. Stop the provider
>> 7. Start the provider
>> 8. Start the consumer
>> 9. After giving the consumer time to perform the refresh present phase, the 3
>> records that were deleted at the provider while the consumer was down
>> are still present on the consumer and were not deleted during the refresh
>> present phase
>>
>> Note: the consumer database must have a contextCSN attribute value present for
>> itself (e.g., there should be 2 contextCSN attribute values
>> present in the consumer database, one for the provider (in my configuration,
>> this is serverID 000), and one value for the consumer
>> (in my configuration, this is serverID 001). An example of the contextCSN
>> values follows:
I see. This configuration is not supported. "Multi-Master" requires the
servers to be full peers. In your configuration, you have a dedicated
provider, it never pulls changes from the consumer, while your consumer is
pulling from the provider and accepting local changes. Since the consumer has
changes that the provider doesn't know about, the sync protocol is broken. The
consumer cannot conclusively state that all entries the provider doesn't know
about must be deleted, since some of those entries may have legitimately been
created on the consumer, so it cannot execute the delete-nonpresent step.
Closing this ITS.
>> dn: dc=authentx
>> objectClass: top
>> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f
>> contextCSN: 20101012154030.379053Z#000000#000#000000
>> contextCSN: 20101012141508.956053Z#000000#001#000000
>>
>> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches).
>>
>> Consumer log file from -d sync logging option:
>> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $
>> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd
>> slapd starting
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
>> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
>> do_syncrep2: rid=001
>> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000
>> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000
>> slap_graduate_commit_csn: removing 0x1841b18
>> 20101012180219.072053Z#000000#000#000000
>> daemon: shutdown requested and initiated.
>> slapd shutdown: waiting for 1 operations/tasks to finish
>> slapd stopped.
>>
>> Provider slapd.conf file:
>> #
>> include /usr/local/etc/openldap/schema/core.schema
>> include /usr/local/etc/openldap/schema/cosine.schema
>> include /usr/local/etc/openldap/schema/inetorgperson.schema
>> include /usr/local/etc/openldap/schema/nis.schema
>>
>> include /usr/local/etc/openldap/schema/authentx.schema
>>
>> pidfile /usr/local/var/slapd.sync1.pid
>> argsfile /usr/local/var/slapd.sync1.args
>>
>> allow bind_v2
>>
>> threads 32
>>
>> #loglevel 416
>> password-hash {SSHA}
>>
>> serverID 000
>>
>> database bdb
>> suffix "dc=authentx"
>> rootdn "cn=xroot,dc=authentx"
>> rootpw SECRET
>> directory /authentx/db/ldap/authentx-sync1
>>
>> overlay syncprov
>> syncprov-checkpoint 100 15
>> syncprov-sessionlog 150000
>>
>> # checkpoint<kbytes> <min>
>> checkpoint 128 20
>>
>> #index for the objectclass
>> index objectClass eq,pres
>> index cid,eid,pid eq,pres
>> index gcoid eq,pres
>> index sysid,certid eq,pres
>> index imageid,bioid eq,pres
>> index addrid,emplid eq,pres
>> index acid,apid,aeid eq,pres
>> index acpid,agpid eq,pres
>> index deviceid eq,pres
>> index qid eq,pres
>> index scid eq,pres
>> index docid eq,pres
>> index procid eq,pres
>> index prochandlerid eq,pres
>> index ounit eq,pres
>> index credentials eq,pres
>> index entities eq,pres
>> index permissions eq,pres
>> index region eq,pres
>> index aliasedObjectName eq,pres
>> index proctype eq,pres
>> index procname eq,pres
>> index status eq,pres
>> index upi,ediident eq,pres
>> index xsync eq,pres
>> index role,xrole eq,pres
>> index eroid eq,pres
>> index esfunction eq,pres
>> index nippsector eq,pres
>> index ercog,ercoop eq,pres
>> index eropron eq,pres
>> index xsyncid eq,pres
>> index stockid eq,pres
>> index stocktypecode eq,pres
>> index lotserialin eq,pres
>> index lotserialout eq,pres
>> index entryCSN,entryUUID eq
>> index incl eq,pres
>>
>> cachesize 10000
>> dncachesize 20000
>> idlcachesize 1000
>>
>> sizelimit 500000
>> timelimit 36000
>> include /usr/local/etc/openldap/acl.authentx
>>
>> database monitor
>>
>> Consumer slapd.conf file:
>> #
>> include /usr/local/etc/openldap/schema/core.schema
>> include /usr/local/etc/openldap/schema/cosine.schema
>> include /usr/local/etc/openldap/schema/inetorgperson.schema
>> include /usr/local/etc/openldap/schema/nis.schema
>>
>> include /usr/local/etc/openldap/schema/authentx.schema
>>
>> pidfile /usr/local/var/slapd.sync2.pid
>> argsfile /usr/local/var/slapd.sync2.args
>>
>> allow bind_v2
>>
>> threads 32
>>
>> #loglevel 416
>> password-hash {SSHA}
>>
>> serverID 001
>>
>> database bdb
>> suffix "dc=authentx"
>> rootdn "cn=xroot,dc=authentx"
>> rootpw SECRET
>> directory /authentx/db/ldap/authentx-sync2
>>
>> overlay syncprov
>> syncprov-checkpoint 100 15
>> syncprov-sessionlog 5000
>>
>> # SLAVE server replication section
>> syncrepl rid=001
>> provider=ldap://localhost:3891
>> type=refreshAndPersist
>> retry="30 60 60 +"
>> searchbase="dc=authentx"
>> scope=sub
>> schemachecking=off
>> bindmethod=simple
>> binddn="cn=xroot,dc=authentx"
>> credentials="SECRET"
>>
>> mirrormode on
>>
>> # checkpoint<kbytes> <min>
>> checkpoint 128 20
>>
>> #index for the objectclass
>> index objectClass eq,pres
>> index cid,eid,pid eq,pres
>> index gcoid eq,pres
>> index sysid,certid eq,pres
>> index imageid,bioid eq,pres
>> index addrid,emplid eq,pres
>> index acid,apid,aeid eq,pres
>> index acpid,agpid eq,pres
>> index deviceid eq,pres
>> index qid eq,pres
>> index scid eq,pres
>> index docid eq,pres
>> index procid eq,pres
>> index prochandlerid eq,pres
>> index ounit eq,pres
>> index credentials eq,pres
>> index entities eq,pres
>> index permissions eq,pres
>> index region eq,pres
>> index aliasedObjectName eq,pres
>> index proctype eq,pres
>> index procname eq,pres
>> index status eq,pres
>> index upi,ediident eq,pres
>> index xsync eq,pres
>> index role,xrole eq,pres
>> index eroid eq,pres
>> index esfunction eq,pres
>> index nippsector eq,pres
>> index ercog,ercoop eq,pres
>> index eropron eq,pres
>> index xsyncid eq,pres
>> index stockid eq,pres
>> index stocktypecode eq,pres
>> index lotserialin eq,pres
>> index lotserialout eq,pres
>> index entryCSN,entryUUID eq
>> index incl eq,pres
>>
>> cachesize 10000
>> dncachesize 20000
>> idlcachesize 1000
>>
>> sizelimit 100000
>> timelimit 36000
>> # the authentx database access control directives
>> include /usr/local/etc/openldap/acl.authentx
>>
>> database monitor
>>
>>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 9 months
