Sync replication halted

2015-11-25 Thread espeake

We are run a 3 node MMR with Openldap 2.4.39 on Ubuntu 14.04 (trusty)
Everything runs great with an occasional hiccup like this.  I see the
following in the logs that appear to be searches on the RID numbers that
are used for config replicationL


Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: syncprov_matchops: skipping
relayed sid 003
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: syncprov_matchops: skipping
original sid 001
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: syncprov_matchops: skipping
relayed sid 003
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: syncprov_matchops: skipping
original sid 001

Imeadiately after this all changes show csn_too_old errors:


Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20151125103121.701210Z#00#001#00
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004 CSN too old,
ignoring 20151125103121.701210Z#00#001#00
(uid=JRIVAS21,ou=Users,dc=oreillyauto,dc=com)
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20151125103121.705110Z#00#001#00
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004 CSN too old,
ignoring 20151125103121.705110Z#00#001#00
(uid=JRIVAS21,ou=Users,dc=oreillyauto,dc=com)
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20151125103121.713760Z#00#001#00
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004 CSN too old,
ignoring 20151125103121.713760Z#00#001#00
(uid=ACERVANT4,ou=Users,dc=oreillyauto,dc=com)
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20151125103121.718018Z#00#001#00
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004 CSN too old,
ignoring 20151125103121.718018Z#00#001#00
(uid=ACERVANT4,ou=Users,dc=oreillyauto,dc=com)
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004
cookie=rid=004,sid=001,csn=20151125103121.726847Z#00#001#00
Nov 25 04:31:22 tn-ldap-a-2 slapd[5931]: do_syncrep2: rid=004 CSN too old,
ignoring 20151125103121.726847Z#00#001#00
(uid=KCOOPER10,ou=Users,dc=oreillyauto,dc=com)

This happened on one node.  The third node had the same replication error
for a few miliseconds and then recovered.

I am attaching the database config file as well.

Thank you,
Eric Speake
Senior Systems Administrator
Information Systems
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975


(See attached file: olcDatabase={1}mdb.ldif)This communication and any 
attachments are confidential, protected by Communications Privacy Act 18 USCS § 
2510, solely for the use of the intended recipient, and may contain legally 
privileged material. If you are not the intended recipient, please return or 
destroy it immediately. Thank you.


olcDatabase={1}mdb.ldif
Description: Binary data


Re: Syncrepl issue with one node (SOLVED_

2015-06-14 Thread espeake

-"openldap-technical" openldap-technical-boun...@openldap.org wrote: -

To: openldap-technical@openldap.orgFrom: Abdelhamid Meddeb 
Sent by: "openldap-technical" 
Date: 06/13/2015 12:58AMSubject: Re: Syncrepl issue with one node
Hi,
In the same situation I've solved the issue by dropping data in the 
server 1, and retrieve them from the other servers:Server 1:
1. Stop2. Drop data in db (keep the DB_CONFIG file)3. Start it
Hope this helps.Cheers.Le 11/06/2015 15:59, espe...@oreillyauto.com a écrit :
 From:Quanah Gibson-Mount qua...@zimbra.com
 To:espe...@oreillyauto.com, openldap-technical@openldap.org
 Date:06/10/2015 04:09 PM Subject:Re: Syncrepl issue with one node
 b) Not enough information provided here to go on. Are all server IDs
 unique? Are all syncrepl clauses unique per DB? Personally I've never
 found ntpd particularly good at keeping clocks in sync. I've generally
 resorted to running ntpdate frequently out of cron, particularly for VMs.
 --Quanah -- Quanah Gibson-Mount
 Platform Architect Zimbra, Inc. 
 Zimbra :: the leader in open source messaging and collaboration
 All of the nodes have unique ID's: olcServerID: 1 ldap://tn-ldap-a-1.mydomain.com
 olcServerID: 2 ldap://tn-ldap-a-2.mydomain.com olcServerID: 3 ldap://tn-ldap-a-3.mydomain.com
 Each database has it's one Syncrepl clause 001, 002, 003 rids sync
 configuraiton changes, and 004,005,  006 sync the user data.
 All configuration changes replicate with no issue. Data changed on servers
 23 replicate between each other, but server 1 gives the CSN too old error.
 If I change user data on node 1 it replicates to nodes 2  3 with no
 issues. I stopped the ntp service on the offending node and ran ntpdate-debian. I
 still get the CSN too old errors in the logs. Is there a setting in the syncrepl that I can use to expand out the window
 for a CSN "age"? Below is the configuration I have for user data.
 olcSyncrepl: {0}rid=004 provider=ldap://tn-ldap-a-1.mtdomain.com
 binddn="uid=admin,dc=mydomain,dc=com" bindmethod=simple credentials=secret
 searchbase="dc=mydomain,dc=com" type=refreshAndPersist retry="5 5 5 +"
 timeout=1 Thank you, Eric This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
-- *Abdelhamid Meddeb*
http://www.meddeb.net

After being able to fox the timing the issue I noticed that I was still getting the CSN too old error. Upon further review of the logs this would be expected behavior I believe. With 3 nodes in MMR the node that the change is happening on sends out the notice of the change. The other servers pick this change up and apply it. Then when node 2 advertises it has a change from node 3 to node 1, node 1 responds that with the CSN too old to let that node know that it already has the change. At least I hope that is what it's doing. Right now all modified records are being replicated to all of the nodes.

Thank you,
Eric

This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.




Re: Syncrepl issue with one node

2015-06-11 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   06/10/2015 04:09 PM
Subject:Re: Syncrepl issue with one node



--On Tuesday, June 09, 2015 8:50 AM -0500 espe...@oreillyauto.com wrote:


 We are running openLDAP 2.4.39 in an MMR replication on Ubuntu 14.04.  I
 have one node that is not wanting to sync with other nodes giving the
 following error:

 Jun  9 06:51:35 tn-ldap-a-1 slapd[3138]: do_syncrep2: rid=005 CSN too
old,
 ignoring 20150609115135.153480Z#00#003#00

 As you can see the CSN shows the exact same time the time that is being
 logged. We are in the U.S. Central timezone.  I have checked our ntp
 service on my three nodes.  All three are pointed to the same ntp and are
 in sync.  Would be possible that one node might still be just a few
 miliseconds too fast and the csn timestamp would appear wrong?  Is there
a
 logging level I can set for that specific issue?  I am currently logging
 the sync records.  I can go to debug in needed.

a) Please don't resend your emails to the list.  The first one got through
fine, which you could easily verify by looking at the list archives.

b) Not enough information provided here to go on.  Are all server IDs
unique?  Are all syncrepl clauses unique per DB?  Personally I've never
found ntpd particularly good at keeping clocks in sync.  I've generally
resorted to running ntpdate frequently out of cron, particularly for VMs.

--Quanah




--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

All of the nodes have unique ID's:

olcServerID: 1 ldap://tn-ldap-a-1.mydomain.com
olcServerID: 2 ldap://tn-ldap-a-2.mydomain.com
olcServerID: 3 ldap://tn-ldap-a-3.mydomain.com

Each database has it's one Syncrepl clause 001, 002, 003 rids sync
configuraiton changes, and 004,005,  006 sync the user data.

All configuration changes replicate with no issue.  Data changed on servers
23 replicate between each other, but server 1 gives the CSN too old error.
If I change user data on node 1 it replicates to nodes 2  3 with no
issues.

I stopped the ntp service on the offending node and ran ntpdate-debian.  I
still get the CSN too old errors in the logs.

Is there a setting in the syncrepl that I can use to expand out the window
for a CSN age?  Below is the configuration I have for user data.

olcSyncrepl: {0}rid=004 provider=ldap://tn-ldap-a-1.mtdomain.com
binddn=uid=admin,dc=mydomain,dc=com bindmethod=simple credentials=secret
searchbase=dc=mydomain,dc=com type=refreshAndPersist retry=5 5 5 +
timeout=1

Thank you,
Eric

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Syncrepl issue with one node

2015-06-10 Thread espeake



From:   espe...@oreillyauto.com
To: openldap-technical@openldap.org
Date:   06/09/2015 07:51 AM
Subject:Syncrepl issue with one node
Sent by:openldap-technical openldap-technical-boun...@openldap.org




We are running openLDAP 2.4.39 in an MMR replication on Ubuntu 14.04.  I
have one node that is not wanting to sync with other nodes giving the
following error:

Jun  9 06:51:35 tn-ldap-a-1 slapd[3138]: do_syncrep2: rid=006 CSN too old,
ignoring 20150609115135.153480Z#00#003#00

As you can see the CSN shows the exact same time the time that is being
logged. We are in the U.S. Central timezone.  I have checked our ntp
service on my three nodes.  All three are pointed to the same ntp and are
in sync.  Would be possible that one node might still be just a few
miliseconds too fast and the csn timestamp would appear wrong?  Is there a
logging level I can set for that specific issue?  I am currently logging
the sync records.  I can go to debug in needed.

Thank you,
Eric Speake
Senior Systems Administrator
Information Systems
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.

This is an example from my config for the syncrepl that is giving me the
error.  I have even build another server and added it to my group and that
server has the CSN too old errors.  I have only two servers that are
actually sync'ing at this time.

olcSyncrepl: {2}rid=006 provider=ldap://tn-ldap-a-3.mydomain.com
binddn=credentials bindmethod=simple credentials=Password
searchbase=dc=mydomain,dc=com type=refreshAndPersist retry=5 5 5 +
timeout=1
Thanks,
Eric

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Syncrepl issue with one node

2015-06-09 Thread espeake

We are running openLDAP 2.4.39 in an MMR replication on Ubuntu 14.04.  I
have one node that is not wanting to sync with other nodes giving the
following error:

Jun  9 06:51:35 tn-ldap-a-1 slapd[3138]: do_syncrep2: rid=005 CSN too old,
ignoring 20150609115135.153480Z#00#003#00

As you can see the CSN shows the exact same time the time that is being
logged. We are in the U.S. Central timezone.  I have checked our ntp
service on my three nodes.  All three are pointed to the same ntp and are
in sync.  Would be possible that one node might still be just a few
miliseconds too fast and the csn timestamp would appear wrong?  Is there a
logging level I can set for that specific issue?  I am currently logging
the sync records.  I can go to debug in needed.

Thank you,
Eric Speake
Senior Systems Administrator
Information Systems
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Adding and attribute and editing a matchingRuleUse in the subschema

2014-07-11 Thread espeake




From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   07/10/2014 03:59 PM
Subject:Re: Adding and attribute and editing a matchingRuleUse in the
subschema



--On Thursday, July 10, 2014 8:10 AM -0500 espe...@oreillyauto.com wrote:

 Any ideas for me on this?

pwdFailureTime is hard coded into ppolicy.c.  You would need to change it
there, and recompile.

--Quanah

--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 4B2F96004A2.AD8F7


Here is what I find in the ppolicy.c file in my source code used to build
my package.

static AttributeDescription *ad_pwdChangedTime, *ad_pwdAccountLockedTime,
*ad_pwdFailureTime, *ad_pwdHistory, *ad_pwdGraceUseTime,
*ad_pwdReset,
*ad_pwdPolicySubentry;


 ad_pwdAccountLockedTime },
{   ( 1.3.6.1.4.1.42.2.27.8.1.19 
NAME ( 'pwdFailureTime' ) 
DESC 'The timestamps of the last consecutive
authentication failures' 
EQUALITY generalizedTimeMatch 
ORDERING generalizedTimeOrderingMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
NO-USER-MODIFICATION USAGE directoryOperation ),

 if (attr_find(e-e_attrs, ad_pwdFailureTime )) {
mods = (Modifications *) ch_calloc( sizeof
( Modifications ), 1 );
mods-sml_op = LDAP_MOD_DELETE;
mods-sml_desc = ad_pwdFailureTime;
mods-sml_flags = SLAP_MOD_INTERNAL;
mods-sml_next = NULL;
modtail-sml_next = mods;
modtail = mods;
}

There are a couple of pieces of logic that write the value to
pwdFailureTime.  This matches what is on my current ldap server that works
with version 2.4.31.  Did I miss a configure option when I built the
package?

Thanks

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Adding and attribute and editing a matchingRuleUse in the subschema

2014-07-11 Thread espeake

 (417) 862-2674  Ext. 1975



From:   Howard Chu h...@symas.com
To: espe...@oreillyauto.com, Quanah Gibson-Mount
qua...@zimbra.com
Cc: openldap-technical@openldap.org
Date:   07/11/2014 11:07 AM
Subject:Re: Adding and attribute and editing a matchingRuleUse in the
subschema



espe...@oreillyauto.com wrote:
 This matches what is on my current ldap server that works
 with version 2.4.31.  Did I miss a configure option when I built the
 package?

Did you post your configure options, or are we supposed to just make random

guesses? My guess: yes, you missed something.

 Thanks

 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts
   (417) 862-2674  Ext. 1975

 This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.




--
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 58FDE600663.A6363

Here are the configure options.  Would the highlighted entry be the issue?
Not sure why I have it that way.  I have never used that syntax in my
builds.

--prefix=/usr \
--libexecdir='${prefix}/lib' \
--sysconfdir=/etc \
--localstatedir=/var \
--mandir='${prefix}/share/man' \
--enable-debug \
--enable-dynamic \
--enable-syslog \
--enable-proctitle \
--enable-ipv6 \
--enable-local \
--enable-slapd \
--enable-dynacl \
--enable-aci \
--enable-cleartext \
--enable-crypt \
--disable-lmpasswd \
--enable-spasswd \
--enable-modules \
--enable-rewrite \
--enable-rlookups \
--enable-slapi \
--enable-slp \
--enable-wrappers \
--enable-backends \
--disable-perl \
--disable-sql \
--disable-bdb \
--disable-ndb \
--enable-overlays=mod \
--with-subdir=ldap \
--with-cyrus-sasl \
--with-threads \
--with-gssapi \
--with-tls=openssl
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts


This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Adding and attribute and editing a matchingRuleUse in the subschema

2014-07-10 Thread espeake
Any ideas for me on this?

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975



From:   espe...@oreillyauto.com
To: openldap-technical@openldap.org
Date:   07/08/2014 09:55 AM
Subject:Adding and attribute and editing a matchingRuleUse in the
subschema
Sent by:openldap-technical-boun...@openldap.org




On our current server running 2.4.31 we have an operational attribute in
the schema labeled pwdFailureTime.  I have done:

slapcat -n 0 -l /tmp/my_config.ldif on our production server.  I have
also used an LDAP browser to export the schema.

When I do a a slapadd -F /etc/your/config/goes/here/ -n 0
-l /tmp/my_config.ldif  I do get the config loaded.  I have confirmed
that I am loading all of the same modules on both servers and that the
config files match.  What I don't have is the pwdFailureTime attribute
which I need since it is in the data file as well, making it so I cannot
import my data either.  This is what the attribute looks like in the
subschema:

attributeTypes: ( 1.3.6.1.4.1.42.2.27.8.1.19 NAME 'pwdFailureTime' DESC
'The timestamps of the last consecutive authentication failures' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 NO-USER-MODIFICATION USAGE
directoryOperation )

Here is the matchingRuleUse:

matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES
( createTimesta
 mp $ modifyTimestamp $ pwdChangedTime $ pwdAccountLockedTime $
pwdFailureTime $
  pwdGraceUseTime $ birthDate $ hireDate $ statusDate $ openDate ) )

From other posts that I have read I cannot edit the subschema directly and
that makes sense since that would be the fastest way to kill a server.  I
have tried doing an ldap modify to dn: cn={4}ppolicy,cn=schema,cn=config
and I get a syntax error in trying to number the attribute.

The new version is 2.4.39 running on ubuntu 12.04 with 3.13 kernel.


Thanks
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 5A63E6004D3.AE6DC




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Adding and attribute and editing a matchingRuleUse in the subschema

2014-07-08 Thread espeake

On our current server running 2.4.31 we have an operational attribute in
the schema labeled pwdFailureTime.  I have done:

slapcat -n 0 -l /tmp/my_config.ldif on our production server.  I have
also used an LDAP browser to export the schema.

When I do a a slapadd -F /etc/your/config/goes/here/ -n 0
-l /tmp/my_config.ldif  I do get the config loaded.  I have confirmed
that I am loading all of the same modules on both servers and that the
config files match.  What I don't have is the pwdFailureTime attribute
which I need since it is in the data file as well, making it so I cannot
import my data either.  This is what the attribute looks like in the
subschema:

attributeTypes: ( 1.3.6.1.4.1.42.2.27.8.1.19 NAME 'pwdFailureTime' DESC
'The timestamps of the last consecutive authentication failures' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 NO-USER-MODIFICATION USAGE
directoryOperation )

Here is the matchingRuleUse:

matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES
( createTimesta
 mp $ modifyTimestamp $ pwdChangedTime $ pwdAccountLockedTime $
pwdFailureTime $
  pwdGraceUseTime $ birthDate $ hireDate $ statusDate $ openDate ) )

From other posts that I have read I cannot edit the subschema directly and
that makes sense since that would be the fastest way to kill a server.  I
have tried doing an ldap modify to dn: cn={4}ppolicy,cn=schema,cn=config
and I get a syntax error in trying to number the attribute.

The new version is 2.4.39 running on ubuntu 12.04 with 3.13 kernel.


Thanks
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Not adding attributes

2014-03-26 Thread espeake

I have just started getting this error in the past 10 days.  There has not
been any configuration changes that we can find.  In googleing this error I
am not finding anything that matches it.  If I create an ldif file to add
these for the user, that works fine.

Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17:
memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com add
locationEntry=ou=Store4351,ou=Locations,dc=oreillyauto,dc=com failed
err=32
Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19:
memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com add
oreillyGroup=cn=Store Non-Management,ou=Groups,dc=oreillyauto,dc=com
failed err=32
Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21:
memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com add
oreillyGroup=cn=Store,ou=Groups,dc=oreillyauto,dc=com failed err=32


What I do wonder about though in my olcDatabase={1}hdb folder I have two
memberOf overlays.

This is the first one.

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 a078db21
dn: olcOverlay={0}memberof
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: oreillyGroup
structuralObjectClass: olcMemberOf
creatorsName: cn=config
entryUUID: 91cea156-9e13-1032-84c3-0151b658a842
createTimestamp: 20130820183919Z
entryCSN: 20130820183919.833799Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20130820183919Z

This is the second one.

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 fe8a4925
dn: olcOverlay={1}memberof
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: oreillyOrgUnit
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: locationEntry
structuralObjectClass: olcMemberOf
creatorsName: cn=config
entryUUID: 91ceb650-9e13-1032-84c4-0151b658a842
createTimestamp: 20130820183919Z
entryCSN: 20130820183919.834337Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20130820183919Z

I have am looking through the application to see if something could have
changed in the way it is presenting the data.  I haven't found anything
yet.  Am I correct in that an error 32 means that it couldn't find the uid
to add the group to?

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Not adding attributes

2014-03-26 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   03/26/2014 10:23 AM
Subject:Re: Not adding attributes



--On Wednesday, March 26, 2014 10:26 AM -0500 espe...@oreillyauto.com
wrote:


 I have just started getting this error in the past 10 days.  There has
not
 been any configuration changes that we can find.  In googleing this error
 I am not finding anything that matches it.  If I create an ldif file to
 add these for the user, that works fine.

 Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17:
 memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com
 add locationEntry=ou=Store4351,ou=Locations,dc=oreillyauto,dc=com
failed
 err=32
 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19:
 memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com
 add oreillyGroup=cn=Store
Non-Management,ou=Groups,dc=oreillyauto,dc=com
 failed err=32
 Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21:
 memberof_value_modify DN=uid=dsmith174,ou=users,dc=oreillyauto,dc=com
 add oreillyGroup=cn=Store,ou=Groups,dc=oreillyauto,dc=com failed err=32

err=32 means no such object. I.e., the object it is attempting to modify
does not exist on this server at the time the modification is being
attempted.  Perhaps you are using MMR, and it was added to a different
master first and this one hasn't got the entry yet?

--Quanah

That is what I was thinking the error meant.  I will have to double check
the code and make sure that it is not directly calling to a server.  I have
the connection properties on our batch server pointed to just one specific
node.

Thanks again,
Eric Speake

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: A10FE60142B.AE6D8




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Question on replication files.

2014-03-18 Thread espeake
Yes all of our servers are sync'd very tightly.  In going through all of
our user data and diff'ing it out.  I see in most instances the information
is current on two of three servers when there is a discrepancy.  So I have
correct data on the servers and back to my original question, is there a
way to make the nodes go through compare and update the data?  How can I
force a manual sync between the nodes?

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   03/17/2014 10:40 PM
Subject:Re: Question on replication files.
Sent by:openldap-technical-boun...@openldap.org





--On March 17, 2014 at 10:02:33 PM -0500 espe...@oreillyauto.com wrote:

 The date on the CSN is tomorrow's date.  This was taken from the log
 shortly before 10 PM CST.

 do_syncrep2: rid=005 CSN too old, ignoring
 20140318025932.803264Z#00#002#00

 So how can the CSN be too old?

Well, since the CSN is based off timezone Z
(
http://www.timeanddate.com/library/abbreviations/timezones/military/z.html
)
that should give you some idea.  I imagine you can figure it out from
there.  I also assume you keep your systems clocks tightly sync'd, as that
is a documented requirement for syncreplication.

--Quanah


--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 0A81160141D.AC6CA




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Fw: Salted hashes

2014-03-18 Thread espeake
Thanks Marc.  That's what I was getting out of it as well but I wanted to
check to be sure.


Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975



From:   Marc Haber mh+openldap-techni...@zugschlus.de
To: openldap-technical@openldap.org
Date:   03/18/2014 10:12 AM
Subject:Re: Fw: Salted hashes
Sent by:openldap-technical-boun...@openldap.org



On Tue, Mar 18, 2014 at 09:49:36AM -0500, espe...@oreillyauto.com wrote:
 I have been doing some reading on the salted hash and I know that I never
 setup a salt for servers.  We are doing some documentation for our
security
 people and the question came up about the salt and if it differs for each
 user, or if the same salt is used?

The basic idea of a salted hash is that the salt is different for
every user so that a rainbow table of hashes is only useful for a
single password.

Usually, the salt is randomized when a hash is generated.

Greetings
Marc

--
-

Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 9899260142D.AEEF2




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Question on replication files.

2014-03-17 Thread espeake






--On Friday, March 14, 2014 2:07 PM +0100 Marc Haber
mh+openldap-techni...@zugschlus.de wrote:

 On Thu, Mar 13, 2014 at 11:03:22AM -0700, Quanah Gibson-Mount wrote:
 Known issue with 2.4.31.  Solution is to upgrade and stop using the
 crap shipped by Debian.

 Please watch your language: it was the OpenLDAP project that released
 this crap a while ago.

Debian makes very specific decisions to:

a) Not update what they ship to address known issues (The debian openldap
package list is littered with bug reports with pointers to the upstream
ITSes)

b) Link to a TLS implementation that is known to be utterly flawed
(https://symas.com/software-design-and-trustworthiness/)

So don't try and lecture me about the decisions made by Debian.  What they
ship is crap, and what they ship could be fixed to not be crap.  End of
story.

--Quanah


--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 08B276014D5.A01BA

The date on the CSN is tomorrow's date.  This was taken from the log
shortly before 10 PM CST.

do_syncrep2: rid=005 CSN too old, ignoring
20140318025932.803264Z#00#002#00

So how can the CSN be too old?

Thanks,
Eric


This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Question on replication files.

2014-03-14 Thread espeake
I'm sure this bug is already fixed in newer version from other
conversations I have had.  We are limited while waiting for hardware
upgrades.  Things like upgrading the kernerl has to wait.

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975



From:   Ulrich Windl ulrich.wi...@rz.uni-regensburg.de
To: openldap-technical-boun...@openldap.org,
espe...@oreillyauto.com, Quanah Gibson-Mount
qua...@zimbra.com
Cc: openldap-technical@openldap.org
Date:   03/14/2014 03:27 AM
Subject:Antw: Re: Question on replication files.



 Quanah Gibson-Mount qua...@zimbra.com schrieb am 13.03.2014 um 19:03
in
Nachricht 34E9E18C6D0A7C6D92162635@[192.168.1.46]:
 --On Thursday, March 13, 2014 1:56 PM -0500 espe...@oreillyauto.com
wrote:

 Version 2.4.31-1+nmu2

 Plain syncrepl.

 As I said I hope to be upgrading to the latest version in the next
couple
 of months.  Right now I need to get through this problem the best I can.

 Known issue with 2.4.31.  Solution is to upgrade and stop using the crap
 shipped by Debian.  The LTB project now has a deb repository for their
 builds, I'd advise investigating switching to using it.

One could also file a bug report for Debian, I guess.


 --Quanah


 --

 Quanah Gibson-Mount
 Architect - Server
 Zimbra, Inc.
 
 Zimbra ::  the leader in open source messaging and collaboration




--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 1450C601424.A5E8C




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Question on replication files.

2014-03-14 Thread espeake






--On Thursday, March 13, 2014 1:56 PM -0500 espe...@oreillyauto.com wrote:

 Version 2.4.31-1+nmu2

 Plain syncrepl.

 As I said I hope to be upgrading to the latest version in the next couple
 of months.  Right now I need to get through this problem the best I can.

Known issue with 2.4.31.  Solution is to upgrade and stop using the crap
shipped by Debian.  The LTB project now has a deb repository for their
builds, I'd advise investigating switching to using it.

--Quanah

Back to one of my original questions.  In looking at the diff of the data I
can see where the CSN and timestamps are different where the issue occurs.
Is there a way to have the nodes scan for the differences and update the
files to the latest record?


Thanks,
Eric
--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: C084960141C.AEC8C




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Question on replication files.

2014-03-13 Thread espeake

We are having an issue with some users not replicating to all of servers.
I have MMR setup with three nodes and there are a few times that a user is
has an attribute changed, i.e. supervisor, and the change is replicated to
one server and not to another.  So the information is correct on 2 of 3
servers.  My question is this after running a very long diff against two
ldif's created by slapcat of the replication database.  Shouldn't the
replication databases be the same?  The issues do happen with every change
and every user, just a few times.

I am n ot on the latest version and I cannot upgrade to the latest version
with a better kernel until our staff upgrades our VM server due to
migration issues with the kernel I would like have.  We are on ubuntu 12.04
and if we can get the VM server updated soon we will start testing 14.04
when it is released.

Any suggestions on a good way to test besides the obvious of turning on
logging for sync which I have done in out test environment for now.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Question on replication files.

2014-03-13 Thread espeake
Version 2.4.31-1+nmu2

Plain syncrepl.

As I said I hope to be upgrading to the latest version in the next couple
of months.  Right now I need to get through this problem the best I can.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   03/13/2014 12:40 PM
Subject:Re: Question on replication files.
Sent by:openldap-technical-boun...@openldap.org



--On Thursday, March 13, 2014 1:19 PM -0500 espe...@oreillyauto.com wrote:

 I am n ot on the latest version and I cannot upgrade to the latest
version
 with a better kernel until our staff upgrades our VM server due to
 migration issues with the kernel I would like have.  We are on ubuntu
 12.04 and if we can get the VM server updated soon we will start testing
 14.04 when it is released.

What version are you on?  Are you using plain syncrepl or delta-syncrepl
for MMR?

--Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 08343601410.AD0DD




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Question on replication files.

2014-03-13 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical-boun...@openldap.org,
openldap-technical@openldap.org
Date:   03/13/2014 01:16 PM
Subject:Re: Question on replication files.
Sent by:openldap-technical-boun...@openldap.org



--On Thursday, March 13, 2014 1:56 PM -0500 espe...@oreillyauto.com wrote:

 Version 2.4.31-1+nmu2

 Plain syncrepl.

 As I said I hope to be upgrading to the latest version in the next couple
 of months.  Right now I need to get through this problem the best I can.

Known issue with 2.4.31.  Solution is to upgrade and stop using the crap
shipped by Debian.  The LTB project now has a deb repository for their
builds, I'd advise investigating switching to using it.

--Quanah

We are working towards an upgrade with a couple of questions.  We have two
very write intensive applications that run at night touch 60,000+ records.
Is MMR the best way with a large number of rights like this?  or would a
master-slave configuration work better.

Also, is there a tool or a way to make the nodes go back and check for
records that might need to updated still?  I am going to diff the the
databases, is there a way to force the servers to check again on records
that might not be changed to compare the CSN's?

Thanks so much,
Eric


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: C084960141C.AEC8C




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Recovering from a Single-Node downtime in a Multi-Master Setup

2013-12-10 Thread espeake
Do the slapcat on ldap2 and then delete the db files on ldap1 and then run
the slapadd.  you will not get duplicates because all of the CSN's will be
the same.  This is what I have done my migrations to the most recent
versions and doing my own builds.  Works great that way.


Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Marco Nett n...@billiger-mietwagen.de
To: Quanah Gibson-Mount qua...@zimbra.com
Cc: openldap-technical@openldap.org
openldap-technical@openldap.org
Date:   12/10/2013 11:00 AM
Subject:Re: Recovering from a Single-Node downtime in a Multi-Master
Setup
Sent by:openldap-technical-boun...@openldap.org



I'm running openldap 2.4.28.
If i just slapcat ldap2 and slapadd that to ldap1, won't i end up with
duplicates on ldap1?

is this the best way to do this?


2013/12/8 Quanah Gibson-Mount qua...@zimbra.com


  On Dec 7, 2013, at 2:48 AM, Marco Nett n...@billiger-mietwagen.de
  wrote:

Quick question:

State 1:
- I have two OpenLDAP slapd servers (ldap1 and ldap2) configured as
Multi-master.
- The both have the exact same data between the mirrored
directories.
- If I create a new directory entry on one server, it immediately
gets mirrored to the second server.
- I'm happy.

State 2:
- One LDAP-Master (ldap1) is down because of whatever.
- Changes to the directory are made on the LDAP-Master which is
still up (ldap2).
- Changes are not mirrored to ldap1 because it's down.
- I'm a little worried but still happy.

State 3:
- ldap1 is back up and running, but it's directory is not up to
date.
- The changes made to ldap2 in state 2 are not on ldap1 and aren't
getting replicated automatically.
- Mirroring again works fine, but ldap1 still doens't know about
changes made in state 2.
- I'm confused because I can't seem to find any information on how
to recover from this.

I couldn't just delete the directory on ldap1 and import the one
from ldap2 because the importing would also be mirrored to ldap2.
right?
how would i go about recoverying from a downtime in a multi-master
setup?

  What is the exact version of openldap are you running?

  To recover, you could slapcat ldap2 and slapadd that to ldap1 so the db's
  and csn's are sync'd up.

  --Quanah

-- This message has been scanned for viruses and dangerous content, and is
believed to be clean. Message id: 9BEF7600D85.A1785

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38

2013-12-06 Thread espeake
Phillip,

I have done the exact same thing.  And you can control where data is at
through your configuration files.  As far as the other directories that
change, you definitely want to use folders other than what the distro
version uses.  That way you do not overwrite files that other systems may
need.  Make sure you have a good backup of your config  and your data.  I
did remove the existing version before I installed the current version.

This is also a good time to look at tuning your setup as far as your your
replication if you are doing that.  There are some great people on this
list that were very helpful in getting me going, especially since I am (as
I considor myself) a noob to openldap.

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Philip Colmer philip.col...@linaro.org
To: openldap-technical@openldap.org
Date:   12/06/2013 05:41 AM
Subject:Upgrading from Ubuntu-packaged 2.4.28 to self-built 2.4.38
Sent by:openldap-technical-boun...@openldap.org



Our current implementation of OpenLDAP is Ubuntu 12.04 running version
2.4.28 which has been installed as a package.

To upgrade to 2.4.38, it looks like I need to remove that package and
then install my own built binaries.

Has anyone gone through this process before and got any tips/notes to
share? I'm particularly thinking that there will be some path changes
to contend with. For example, my main HDB database seems to be in
/var/lib/ldap but the migration steps suggest that everything is in
/usr/local/var/openldap-data/.

Clearly I can work through this but if someone has already done it and
can share lessons learnt, that would be much appreciated.

Philip


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 0B814601340.ACC54




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Unknown db in slapd.conf

2013-10-03 Thread espeake
Yes I must have hit something when I typing and pasting.  Here is the
latest.

524c6c74 line 66 (database  mdb)
Unrecognized database type (mdb)
524c6c74 /usr/local/etc/openldap/slapd.conf: line 66: database failed
init (mdb)
slaptest: bad configuration file!


Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Dieter Klünter die...@dkluenter.de
To: openldap-technical@openldap.org
Date:   10/03/2013 03:41 AM
Subject:Re: Unknown db in slapd.conf
Sent by:openldap-technical-boun...@openldap.org



Am Wed, 2 Oct 2013 13:41:07 -0500
schrieb espe...@oreillyauto.com:


 I have a brand new Ubuntu-12.04 server with a brand new build of
 openldap 2.4.36 on it and I am try to set it up for MMR with mdb.  I
 get the following error when I try slapadd my config.

 524c62f1 line 61 (databse   mdb)
   ^^
is this a typo?

-Dieter

--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95N
10°08'02,42E


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: F1E5F600855.A0207




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Unknown db in slapd.conf

2013-10-03 Thread espeake



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: Dieter Klünter die...@dkluenter.de,
openldap-technical-boun...@openldap.org,
openldap-technical@openldap.org
Date:   10/03/2013 08:37 AM
Subject:Re: Unknown db in slapd.conf



Hi,

On Thu, 3 Oct 2013, espe...@oreillyauto.com wrote:

 Yes I must have hit something when I typing and pasting.  Here is the
 latest.

 524c6c74 line 66 (database  mdb)
 Unrecognized database type (mdb)
 524c6c74 /usr/local/etc/openldap/slapd.conf: line 66: database failed
 init (mdb)
 slaptest: bad configuration file!

it would help slightly if you could be bothered in pasting your entire
configuration file (without secrets) pastebin or something similar.

Greetings
Christian

Here is the slapd.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
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/oreilly.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
include /usr/local/etc/openldap/schema/dyngroup.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org

pidfile /usr/local/var/run/slapd.pid
argsfile/usr/local/var/run/slapd.args

threads 8


loglevel256

# Load dynamic backend modules:
 modulepath /usr/local/libexec/openldap/
 moduleload back_mdb.la
 moduleload back_ldap.la
 moduleload back_hdb.la

# Sample security restrictions
#   Require integrity protection (prevent hijacking)
#   Require 112-bit (3DES or better) encryption for updates
#   Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

include /usr/local/etc/openldap/acl.conf

# Sample access control policy:
#   Root DSE: allow anyone to read it
#   Subschema (sub)entry DSE: allow anyone to read it
#   Other DSEs:
#   Allow self write access
#   Allow authenticated users read access
#   Allow anonymous users to authenticate
#   Directives needed to implement policy:
# access to dn.base= by * read
# access to dn.base=cn=Subschema by * read
# access to *
#   by self write
#   by users read
#   by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., access to * by * read)
#
# rootdn can always read and write EVERYTHING!


###
# MDB database definitions
###

databasemdb
suffix  dc=oreillyauto,dc=com
securityssf=0
rootdn  uid=admin,dc=oreillyauto,dc=com
rootpw  password
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory   /var/lib/ldap
# Indices to maintain
index
objectClass,uid,position,employeeNumber,counterNumber,oreillyGroup,locationEntry,uniqueMember,ou,cn,businessCategory,locationNumber,functionListing,manager
 pres,eq
index   title,givenName,sn,nickName pres,eq,sub

lastmod on

checkpoint  512 30

#overlay accesslog
logdb   cn=log
logops  all
logold  (objectclass=oreillyOrgPerson)
logpurge7+00:00 2+00:00
logsuccess  TRUE


backend mdb

Thanks,
Eric



 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Dieter Klünter die...@dkluenter.de
 To:openldap-technical@openldap.org
 Date:  10/03/2013 03:41 AM
 Subject:   Re: Unknown db in slapd.conf
 Sent by:   openldap-technical-boun...@openldap.org



 Am Wed, 2 Oct 2013 13:41:07 -0500
 schrieb espe...@oreillyauto.com:


 I have a brand new Ubuntu-12.04 server with a brand new build of
 openldap 2.4.36 on it and I am try to set it up for MMR with mdb.  I
 get the following error when I try slapadd my config.

 524c62f1 line 61 (databse   mdb)
   ^^
 is this a typo?

 -Dieter

 --
 Dieter Klünter | Systemberatung
 http://dkluenter.de
 GPG Key ID:DA147B05
 53°37'09,95N
 10°08'02,42E


 --
 This message has been scanned for viruses and dangerous content,
 and is believed to be clean.
  Message id: F1E5F600855.A0207




 This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please 

Re: Unknown db in slapd.conf

2013-10-03 Thread espeake
Thank you for the help.  Howard is was the spaces and I removed the
back_hdb since it is now old.

Thank you again,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Howard Chu h...@symas.com
To: Christian Kratzer c...@cksoft.de, espe...@oreillyauto.com
Cc: Dieter Klünter die...@dkluenter.de,
openldap-technical-boun...@openldap.org,
openldap-technical@openldap.org
Date:   10/03/2013 10:32 AM
Subject:Re: Unknown db in slapd.conf



Christian Kratzer wrote:
 Hi,

 snipp/
 moduleload back_mdb.la
 moduleload back_ldap.la
 moduleload back_hdb.la

 on my centos system your config started once I changed above to

moduleload back_mdb

In his actual paste, all of his moduleload statements have a leading space,
so
they are simply continuations of the preceding comment line. I.e., they
never
actually got processed.

--
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 8D5FE60097D.A74BD




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Log level will not change.

2013-10-03 Thread espeake
Christian this worked.  The weird thing is that it encrypted it in base64.
My access lists did the same thing.  Really strange.

Thanks again.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   10/03/2013 04:21 PM
Subject:Re: Log level will not change.
Sent by:openldap-technical-boun...@openldap.org



Hi,

On Thu, 3 Oct 2013, Christian Kratzer wrote:
snipp/
 try following:

 dn: cn=config
 changetype: modify
 replace: olcLogLevel
 olcLogLevel: 0

I also like to use symbolic names so I keep following file floating around:

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: Conns
olcLogLevel: Stats
olcLogLevel: Stats2
olcLogLevel: Sync
#olcLogLevel: filter
#olcLogLevel: config
#olcLogLevel: ACL
#olcLogLevel: parse

you should be able to use just following to clear logging:

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: none

Greetings
Christian




--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 25DE8600D5E.A5163




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Log level will not change.

2013-10-03 Thread espeake
 Howard,

This is actually a format that I have use on other ldif's and they work.  I
did follow you advice on the slapd.conf and got pas the errors and hit
another snag to discover that after following instructions on createing a
build and installing with no errors that openLdap still wsa showing as
installed.  So I have started going back over those instructions from the
install file as well as the 2.4 admin documentation that is out of date.
The slapd.conf man pages on the server don't even list mdb as an attribute
for the database.  So reading documentation that has not been updated isn't
always that helpful.

This is my first go at openLDAP and I am sorry that I might waste some of
your time, but the last book that written on this software that I can find
was written 7 years when some of the now deprecated features were just in
the planning stages.

Thank you for our help.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Howard Chu h...@symas.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   10/03/2013 05:14 PM
Subject:Re: Log level will not change.
Sent by:openldap-technical-boun...@openldap.org



espe...@oreillyauto.com wrote:

 Here is the contents of configlog.ldif

You seem to have continual difficulty understanding that whitespace is
significant. Please read the ldif(5) manpage more carefully. Judging from
your
other lengthy email thread, you also need to read slapd.conf(5) more
carefully.

 dn: cn=config
 changetype: modify

 delete: olcLogLEvel
 -
 add: olcLogLevel
 olcLogLevel: 0

 I run the following commend:

 ldapmodify -Wx -D uid=admin,dc=oreillyauto,dc=com -H
 ldap://tntest-ldap-1.oreillyauto.com -c -f /tmp/configlog.ldif

 the output shows:

 Enter LDAP Password:
 modifying entry cn=config

 Except the loglevel cn=config does not change.  The modifyTimeStamp and
 entryCSN change to match the server.  I have a 3 node MMR cluster on
 2.4.31.  I am working on  a build to go to 2.4.36, but in the mean time I
 need to get this working.

 Thanks,
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts

 This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.




--
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: ABCAD600DE6.A2076




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Unknown db in slapd.conf

2013-10-02 Thread espeake

I have a brand new Ubuntu-12.04 server with a brand new build of openldap
2.4.36 on it and I am try to set it up for MMR with mdb.  I get the
following error when I try slapadd my config.

524c62f1 line 61 (databse   mdb)
524c62f1 /usr/local/etc/openldap/slapd.conf: line 61: database failed
init (mdb)!

Now when I look at man slapd.conf and these are the database types that are
shown for use.  There is nothing there showing mdb, but I know that it is a
viable selection.

 database databasetype
  Mark the beginning of a new database instance definition.
databasetype  should  be  one  of  bdb,  config, dnssrv, hdb, ldap, ldif,
meta, monitor, null, passwd, perl, relay, shell, or sql, depending on which
backend will serve the database.

in my slapd.conf file I have the following setup (just partially listing
here):

# Load dynamic backend modules:
 modulepath /usr/local/libexec/openldap
 moduleload back_mdb.la
 moduleload back_ldap.la


databasemdb

I have checked and double cheked to be sure
that /usr/local/libexec/openldap/back_mdb.la exists.

What simple thing am I missing?

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Synchronous or asynchronous replication

2013-09-27 Thread espeake

We have a 3 node N-Way Multi master set running 2.4.31.  I have been
looking and trying to find a way to have asynchronous replication because
synchronous replication is not required and we believe is actually slowing
us down.  I read in one article that by default n-way multi-master was
doing asynchronous replication.  But then another article kind of mucked
that up.  I ran through all of my db files with db_stat to get the internal
pages and page size to be sure that my DB_Config was set with a large
enough paging space and from my calculations it has more than enough.  Not
enough to cache the entire db, but enough.

So how can I be sure that we are using asynchronous replication with the
n-way mulri master configuration.

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Synchronous or asynchronous replication

2013-09-27 Thread espeake




From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   09/27/2013 03:49 PM
Subject:Re: Synchronous or asynchronous replication
Sent by:openldap-technical-boun...@openldap.org



--On Friday, September 27, 2013 2:46 PM -0500 espe...@oreillyauto.com
wrote:


 We have a 3 node N-Way Multi master set running 2.4.31.  I have been
 looking and trying to find a way to have asynchronous replication because
 synchronous replication is not required and we believe is actually
slowing
 us down.  I read in one article that by default n-way multi-master was
 doing asynchronous replication.  But then another article kind of mucked
 that up.  I ran through all of my db files with db_stat to get the
 internal pages and page size to be sure that my DB_Config was set with a
 large enough paging space and from my calculations it has more than
 enough.  Not enough to cache the entire db, but enough.

 So how can I be sure that we are using asynchronous replication with the
 n-way mulri master configuration.

What you should do is use delta-syncrepl based MMR with OpenLDAP 2.4.36.
Delta-syncrepl based MMR only replicates the exact changes that occurred,
rather than the entries, vastly reducing the amount of data being
transferred between nodes.  I would also recommend switching to back-mdb
with OpenLDAP 2.4.36, as it handles writes at *least* 50 times faster than
back-hdb/back-bdb.

I've already told you *multiple* times that there are known bugs with the
MMR code in 2.4.31, and you will end up having data issues, yet you
continue to ignore this.  Why, is beyond me.  Stop wasting your time and
everyone else's by insisting to run out of date code with known bugs.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC

Zimbra ::  the leader in open source messaging and collaboration

If I could get 2.4.35 or 2.4.36 to build a debian package as required by
our company I would use a newer version.  Every time I run the build it
errors out in the config.  So I have tried.  I can't do just a build I have
to be able to create the package for our puppet implementation.

Is there an update 2.4 admin doc out there that shows how to do this in a
dynamic setup instead of the slapd.conf.  Our MMR is working great with the
exception of one app that rebuilds groups and keeps them up to date.  this
application going against a single 2.4.21 version finished in an hour and
after 8 hours it is not completing.  Other than the replication, everything
is pretty much the same as far as cacheing and other DB tuning settings.

Sorry that I am wasting your time.
Eric
--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 0001A600A4C.AD92D




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Synchronous or asynchronous replication

2013-09-27 Thread espeake
 That is what I have done so far was a fresh install and not part of a distro. And I have everything working with the exception of this one application. And it appears that tuning the DB should be what fixes it. According to the documentation from the openldap site I should need about 150 MB for the cache setting in my DB_config. It was already set at 512MB The is a setting dealing with the number of records that can be open at onetime ad it is set to 5. I thoguht about moving that to 10 and the other one, I have to appologize I am at home right and don't have all of the information in front of me, to 30 or three times the open records as recommended in the admin guide.I just need to be pointed to a little more information on tuning the DB.Eric-openldap-technical-boun...@openldap.org wrote: -To: espe...@oreillyauto.comFrom: Quanah Gibson-Mount Sent by: openldap-technical-boun...@openldap.orgDate: 09/27/2013 04:32PMCc: openldap-technical@openldap.orgSubject: Re: Synchronous or asynchronous replication--On Friday, September 27, 2013 4:09 PM -0500 espe...@oreillyauto.com wrote: If I could get 2.4.35 or 2.4.36 to build a debian package as required by our company I would use a newer version. Every time I run the build it errors out in the config. So I have tried. I can't do just a build I have to be able to create the package for our puppet implementation.If you are having problems with Debian's dpkg system, then I would advise contacting the debian folks etc about how to properly build dpkg's. That certainly is not an OpenLDAP specific issue. I would note that Debian's default packages for OpenLDAP have a lot of problems (like linking to GnuTLS instead of OpenSSL among other things).So if you are just trying to "upgrade" what Debian already ships, that is a bad starting point. I would advise creating your own fresh .deb's that install into your own location, so as not to conflict with the system libraries.--Quanah--Quanah Gibson-MountLead EngineerZimbra Software, LLCZimbra :: the leader in open source messaging and collaboration--This message has been scanned for viruses and dangerous content, and is believed to be clean.Message id: 2EE00600D64.ADDD4This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.


Re: Other system use port 636 connect LDAP Server Error

2013-09-26 Thread espeake




From:   Tian Zhiying tianzy1...@thundersoft.com
To: openldap-technical openldap-technical@openldap.org
Cc: tianzy1225 tianzy1...@thundersoft.com
Date:   09/26/2013 03:38 AM
Subject:Other system use port 636 connect LDAP Server Error
Sent by:openldap-technical-boun...@openldap.org



 Hi

 In ldap server(localhost) , I execute  the below command , it ok.
 # ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D
 cn=interface,dc=mydomain,dc=com -H ldaps://192.168.1.10 -W

 But in other linux system is not ok, below is the error info:
 # ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D
 cn=interface,dc=mydomain,dc=com -H ldaps://192.168.1.10 -W
 ldap_bind: Can't contact LDAP server (-1)
 additional info: error:14090086:SSL
 routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

 LDAP Server is Centos 5.8 64 OS, iptables serverice is closed state. What
 is the cause?

 You have any Suggestions?  Thanks.


 Tian Zhiying
 -- This message has been scanned for viruses and dangerous content, and is
 believed to be clean. Message id: 6C4D96009F0.A06A1
 Is there a firewall between the two systems  That port could be blocked.
 Try doing a telnet to that IP on port 636.

 telenet 192.168.1.10 636

 Eric

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Fw: Access being denied.

2013-09-24 Thread espeake


Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
- Forwarded by Eric Speake/OReilly on 09/24/2013 06:31 AM -

From:   Eric Speake/OReilly
To: Jason Brandt jbra...@fsmail.bradley.edu
Cc: openlda-techni...@openldap.org
Date:   09/24/2013 06:16 AM
Subject:Re: Access being denied.






From:   Jason Brandt jbra...@fsmail.bradley.edu
To: espe...@oreillyauto.com
Cc: openldap-technical@OpenLDAP.org
openldap-technical@openldap.org
Date:   09/23/2013 03:26 PM
Subject:Re: Access being denied.



I hope this doesn't confuse you too much... First off... Your admin account
will be dn=cn=admin,dc=oreillyauto,dc=com, if you are talking about the
default admin account.  You also want manage instead of write.  I would
also recommend securing your admin account with access lists, only allowing
access from specific manager IP addresses.  In order to restrict the
cn=admin account as I do below, you have to set the userPassword attribute
for the admin account, and blank the olcRootPW.

set admin password:
dn: cn=admin,dc=bradley,dc=edu
changeType: modify
add: userPassword
userPassword: {SSHA}passwordhash

blank old olcRootPW

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcRootPW

This allows use of the normal authentication process and will look at your
access lists.  Otherwise, it will always bypass access lists and use the
olcRootPW to authenticate.


Here's how I handle access restrictions, which I would suggest you
evaluate.  This is a positive security model as well (meaning the default
action is deny), which I highly recommend (ie no one can access any field,
unless it's specifically defined).  The downside to the positive security
model is that it's less flexible, you have to whitelist any new attributes
you wish users to access, but it provides you with the best security.
Another note in this, is that my user accounts are all shadowAccounts, and
setting shadowInactive to 1 disables the account. (handled by the 3rd
section with password fields).


Here is my access list in a template form:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
# limit access to directory manager to local host only and specific manager
ip's
olcAccess: to dn.base=cn=admin,dc=,dc=
  by peername.ip=127.0.0.1 auth
  by sockurl=ldapi:/// auth
  by peername.ip=manager IP auth
  by users none
  by anonymous none
#Allow admin users full access to all attrs
#Allow OpenLDAP2 Sync User read access to all
#Everyone else, continue
olcAccess: to *
  by peername.ip=172.16.0.0%255.255.0.0 dn=uid=adminuser,dc=,dc= manage
  by peername.ip=secondary ldap server ip
dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
  by peername.ip=third ldap server ip
dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
  by * break
#Handle password fields, for all possible entities.  No further processing
for these attributes
olcAccess: to attrs=userPassword,shadowLastChange filter=
((objectClass=shadowAccount)(!(shadowInactive=1)))
  by self =w
  by sockurl=ldapi:/// auth
  by peername.ip=172.16.0.0%255.255.0.0 auth
  by peername.ip=127.0.0.1 group.exact=cn=localadmingroup,dc=,dc= manage
  by group.exact=cn=admingroup,dc=,dc= write
  by * none
#Specific processing for an Account
#Everyone else, continue
olcAccess: to attrs=attr1,attr2
  by dn=uid=account1,ou=Service_Logins,dc=,dc= read
  by * break
#Specific processing for a Group
#Everyone else, continue
olcAccess: to attrs=attr3,attr4
  by group.exact=cn=group1,out=Group,dc=,dc= manage
  by * break
#Handle SELF writable fields
#Everyone else, continue
olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs
  by self write
  by * break
#Handle more restrictive fields
#Stop processing on match
olcAccess: to attrs=audio,attr5,attr6,attr7
  filter=((matchTrue=1)(objectClass=Person))
  by * none
#Handle Anonymous Allowed fields
#Stop Processing on Match
olcAccess: to attrs=attr8,attr9,attr10
  by * read
#Handle User Allowed Fields
#Stop Processing on Match
olcAccess: to dn.subtree=dc=,dc= attrs=audio
  by users read
#Hide additional superuser accounts in directory
olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins))
  by * none
#Allow access to specific objectclasses
olcAccess: to filter=(|
(objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit))
  by * read
#Allow access to directory entries.  Required to query directory when using
default deny policy
olcAccess: to dn.subtree=dc=,dc=
  attrs=entry,objectClass
  by * read
#Default Deny
olcAccess: to *
  by * none


Jason,

Thanks for the layout and I will take this to my bosses.  I might have to
group the servers because we have several servers that access the out LDAP
servers and by IP address would be a little cumbersome to manage.  We use
somewhere in the range of 140 different applications on our internal
network and accessed by our stores across the country.  so we use 

Re: Access being denied.

2013-09-24 Thread espeake



From:   Jason Brandt jbra...@fsmail.bradley.edu
To: espe...@oreillyauto.com
Cc: openldap-technical@OpenLDAP.org
openldap-technical@openldap.org
Date:   09/23/2013 03:26 PM
Subject:Re: Access being denied.



I hope this doesn't confuse you too much... First off... Your admin account
will be dn=cn=admin,dc=oreillyauto,dc=com, if you are talking about the
default admin account.  You also want manage instead of write.  I would
also recommend securing your admin account with access lists, only allowing
access from specific manager IP addresses.  In order to restrict the
cn=admin account as I do below, you have to set the userPassword attribute
for the admin account, and blank the olcRootPW.

set admin password:
dn: cn=admin,dc=bradley,dc=edu
changeType: modify
add: userPassword
userPassword: {SSHA}passwordhash

blank old olcRootPW

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcRootPW

This allows use of the normal authentication process and will look at your
access lists.  Otherwise, it will always bypass access lists and use the
olcRootPW to authenticate.


Here's how I handle access restrictions, which I would suggest you
evaluate.  This is a positive security model as well (meaning the default
action is deny), which I highly recommend (ie no one can access any field,
unless it's specifically defined).  The downside to the positive security
model is that it's less flexible, you have to whitelist any new attributes
you wish users to access, but it provides you with the best security.
Another note in this, is that my user accounts are all shadowAccounts, and
setting shadowInactive to 1 disables the account. (handled by the 3rd
section with password fields).


Here is my access list in a template form:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
# limit access to directory manager to local host only and specific manager
ip's
olcAccess: to dn.base=cn=admin,dc=,dc=
  by peername.ip=127.0.0.1 auth
  by sockurl=ldapi:/// auth
  by peername.ip=manager IP auth
  by users none
  by anonymous none
#Allow admin users full access to all attrs
#Allow OpenLDAP2 Sync User read access to all
#Everyone else, continue
olcAccess: to *
  by peername.ip=172.16.0.0%255.255.0.0 dn=uid=adminuser,dc=,dc= manage
  by peername.ip=secondary ldap server ip
dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
  by peername.ip=third ldap server ip
dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
  by * break
#Handle password fields, for all possible entities.  No further processing
for these attributes
olcAccess: to attrs=userPassword,shadowLastChange filter=
((objectClass=shadowAccount)(!(shadowInactive=1)))
  by self =w
  by sockurl=ldapi:/// auth
  by peername.ip=172.16.0.0%255.255.0.0 auth
  by peername.ip=127.0.0.1 group.exact=cn=localadmingroup,dc=,dc= manage
  by group.exact=cn=admingroup,dc=,dc= write
  by * none
#Specific processing for an Account
#Everyone else, continue
olcAccess: to attrs=attr1,attr2
  by dn=uid=account1,ou=Service_Logins,dc=,dc= read
  by * break
#Specific processing for a Group
#Everyone else, continue
olcAccess: to attrs=attr3,attr4
  by group.exact=cn=group1,out=Group,dc=,dc= manage
  by * break
#Handle SELF writable fields
#Everyone else, continue
olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs
  by self write
  by * break
#Handle more restrictive fields
#Stop processing on match
olcAccess: to attrs=audio,attr5,attr6,attr7
  filter=((matchTrue=1)(objectClass=Person))
  by * none
#Handle Anonymous Allowed fields
#Stop Processing on Match
olcAccess: to attrs=attr8,attr9,attr10
  by * read
#Handle User Allowed Fields
#Stop Processing on Match
olcAccess: to dn.subtree=dc=,dc= attrs=audio
  by users read
#Hide additional superuser accounts in directory
olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins))
  by * none
#Allow access to specific objectclasses
olcAccess: to filter=(|
(objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit))
  by * read
#Allow access to directory entries.  Required to query directory when using
default deny policy
olcAccess: to dn.subtree=dc=,dc=
  attrs=entry,objectClass
  by * read
#Default Deny
olcAccess: to *
  by * none




On Mon, Sep 23, 2013 at 12:08 PM, espe...@oreillyauto.com wrote:

  I know this has to be super simple in what I am missing.  My ldapadmin
  account cannot write to the database due to insufficient privileges..
  This
  is the ACL part of the ldif file. Version 2.4.31 and this is from
  olcDatabase={1}hdb.ldif

  olcAccess: {0}to attrs=userPassword by
  dn=uid=admin,dc=oreillyauto,dc=com
  wr
   ite by anonymous auth by self write by * none
  olcAccess: {1}to dn.subtree= by * read
  olcAccess: {2}to * by dn=uid=admin,dc=oreillyauto,dc=com write by
  dn=uid=ld
   apadmin,ou=System,dc=oreillyauto,dc=com write by * read

  olcAccess: {2} for ldap admin actually be
  

Re: Access being denied.

2013-09-24 Thread espeake




From:   Jason Brandt jbra...@fsmail.bradley.edu
To: espe...@oreillyauto.com
Cc: openldap-technical@OpenLDAP.org
openldap-technical@openldap.org
Date:   09/24/2013 09:37 AM
Subject:Re: Access being denied.



Are you using the default admin account?

As far as the replication, I have not tried replicating.  I only have 2
ldap servers running currently (a primary and a slave), so I just manually
apply the ACL's to both servers when there is a change.

I'm not sure why your config changes are not being pushed in.  Have you
gone detailed with debugging mode, etc, to see if any errors are being
logged?  It seems to me that this is the source of most of your problems.
I would try and track down the cause of that issue first.


On Tue, Sep 24, 2013 at 9:18 AM, espe...@oreillyauto.com wrote:



  From:   Jason Brandt jbra...@fsmail.bradley.edu
  To:     espe...@oreillyauto.com
  Cc:     openldap-technical@OpenLDAP.org
              openldap-technical@openldap.org
  Date:   09/23/2013 03:26 PM
  Subject:        Re: Access being denied.



  I hope this doesn't confuse you too much... First off... Your admin
  account
  will be dn=cn=admin,dc=oreillyauto,dc=com, if you are talking about the
  default admin account.  You also want manage instead of write.  I would
  also recommend securing your admin account with access lists, only
  allowing
  access from specific manager IP addresses.  In order to restrict the
  cn=admin account as I do below, you have to set the userPassword
  attribute
  for the admin account, and blank the olcRootPW.

  set admin password:
  dn: cn=admin,dc=bradley,dc=edu
  changeType: modify
  add: userPassword
  userPassword: {SSHA}passwordhash

  blank old olcRootPW

  dn: olcDatabase={1}hdb,cn=config
  changetype: modify
  delete: olcRootPW

  This allows use of the normal authentication process and will look at
  your
  access lists.  Otherwise, it will always bypass access lists and use the
  olcRootPW to authenticate.


  Here's how I handle access restrictions, which I would suggest you
  evaluate.  This is a positive security model as well (meaning the default
  action is deny), which I highly recommend (ie no one can access any
  field,
  unless it's specifically defined).  The downside to the positive security
  model is that it's less flexible, you have to whitelist any new
  attributes
  you wish users to access, but it provides you with the best security.
  Another note in this, is that my user accounts are all shadowAccounts,
  and
  setting shadowInactive to 1 disables the account. (handled by the 3rd
  section with password fields).


  Here is my access list in a template form:

  dn: olcDatabase={1}hdb,cn=config
  changetype: modify
  replace: olcAccess
  # limit access to directory manager to local host only and specific
  manager
  ip's
  olcAccess: to dn.base=cn=admin,dc=,dc=
    by peername.ip=127.0.0.1 auth
    by sockurl=ldapi:/// auth
    by peername.ip=manager IP auth
    by users none
    by anonymous none
  #Allow admin users full access to all attrs
  #Allow OpenLDAP2 Sync User read access to all
  #Everyone else, continue
  olcAccess: to *
    by peername.ip=172.16.0.0%255.255.0.0 dn=uid=adminuser,dc=,dc= manage
    by peername.ip=secondary ldap server ip
  dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
    by peername.ip=third ldap server ip
  dn=uid=syncuser,ou=Service_Logins,dc=,dc= read
    by * break
  #Handle password fields, for all possible entities.  No further
  processing
  for these attributes
  olcAccess: to attrs=userPassword,shadowLastChange filter=
  ((objectClass=shadowAccount)(!(shadowInactive=1)))
    by self =w
    by sockurl=ldapi:/// auth
    by peername.ip=172.16.0.0%255.255.0.0 auth
    by peername.ip=127.0.0.1 group.exact=cn=localadmingroup,dc=,dc=
  manage
    by group.exact=cn=admingroup,dc=,dc= write
    by * none
  #Specific processing for an Account
  #Everyone else, continue
  olcAccess: to attrs=attr1,attr2
    by dn=uid=account1,ou=Service_Logins,dc=,dc= read
    by * break
  #Specific processing for a Group
  #Everyone else, continue
  olcAccess: to attrs=attr3,attr4
    by group.exact=cn=group1,out=Group,dc=,dc= manage
    by * break
  #Handle SELF writable fields
  #Everyone else, continue
  olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs
    by self write
    by * break
  #Handle more restrictive fields
  #Stop processing on match
  olcAccess: to attrs=audio,attr5,attr6,attr7
    filter=((matchTrue=1)(objectClass=Person))
    by * none
  #Handle Anonymous Allowed fields
  #Stop Processing on Match
  olcAccess: to attrs=attr8,attr9,attr10
    by * read
  #Handle User Allowed Fields
  #Stop Processing on Match
  olcAccess: to dn.subtree=dc=,dc= attrs=audio
    by users read
  #Hide additional superuser accounts in directory
  olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins))
    by * none
  #Allow access to specific objectclasses
  olcAccess: to filter=(|
  

Wrong certificate being presented

2013-09-23 Thread espeake

The authentication works on the single server we have which is running an
older version of openLDAP (2.4.21).  In my packet captures it appears that
the older version of openLDAP is presenting the certificate we want it to
present.  The new version (2.4.31), although it has the same cert installed
in the same place it is presenting an older self signed cert that has been
removed.  The new servers have been rebooted since this change so where
could this possibly be cached at?

This is from my slapcat of the new servers.

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzPolicy: any
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 1 ldap://tntest-ldap-3.example.com
olcServerID: 2 ldap://tntest-ldap-1.example.com
olcServerID: 3 ldap://tntest-ldap-2.example.com
olcThreads: 8
olcTLSCACertificateFile: /etc/ldap/gd_bundle.crt
olcTLSCertificateFile: /etc/ldap/wildcard.example.com.crt
olcTLSCertificateKeyFile: /etc/ldap/wildcard.example.com.key
olcToolThreads: 1
structuralObjectClass: olcGlobal
creatorsName: cn=config
entryUUID: 91cc0ae0-9e13-1032-84b5-0151b658a842
createTimestamp: 20130820183919Z
olcLogLevel: config acl stats conns
olcTLSCipherSuite: NORMAL
olcTLSCRLCheck: none
olcTLSVerifyClient: never
entryCSN: 20130923150907.574575Z#00#001#00
modifiersName: uid=admin,dc=oreillyauto,dc=com
modifyTimestamp: 20130923150907Z
contextCSN: 20130923150907.574575Z#00#001#00
contextCSN: 20130923150843.855673Z#00#002#00
contextCSN: 20130919185322.242639Z#00#003#00

I tried doing an ldapmodify and delete the olcTLSCipherSuite and
olcTLSCRLCheck that I added and they will not disappear.
Thanks
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Access being denied.

2013-09-23 Thread espeake

I know this has to be super simple in what I am missing.  My ldapadmin
account cannot write to the database due to insufficient privileges..  This
is the ACL part of the ldif file. Version 2.4.31 and this is from
olcDatabase={1}hdb.ldif

olcAccess: {0}to attrs=userPassword by dn=uid=admin,dc=oreillyauto,dc=com
wr
 ite by anonymous auth by self write by * none
olcAccess: {1}to dn.subtree= by * read
olcAccess: {2}to * by dn=uid=admin,dc=oreillyauto,dc=com write by
dn=uid=ld
 apadmin,ou=System,dc=oreillyauto,dc=com write by * read

olcAccess: {2} for ldap admin actually be
'dn.base=uid=ldapadmin,ou-System, dc=domain,dc=com write'?

Thanks
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



{resolved}Re: Wrong certificate being presented

2013-09-23 Thread espeake



From:   espe...@oreillyauto.com
To: openldap-technical@openldap.org
Date:   09/23/2013 10:27 AM
Subject:Wrong certificate being presented
Sent by:openldap-technical-boun...@openldap.org




The authentication works on the single server we have which is running an
older version of openLDAP (2.4.21).  In my packet captures it appears that
the older version of openLDAP is presenting the certificate we want it to
present.  The new version (2.4.31), although it has the same cert installed
in the same place it is presenting an older self signed cert that has been
removed.  The new servers have been rebooted since this change so where
could this possibly be cached at?

This is from my slapcat of the new servers.

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzPolicy: any
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 1 ldap://tntest-ldap-3.example.com
olcServerID: 2 ldap://tntest-ldap-1.example.com
olcServerID: 3 ldap://tntest-ldap-2.example.com
olcThreads: 8
olcTLSCACertificateFile: /etc/ldap/gd_bundle.crt
olcTLSCertificateFile: /etc/ldap/wildcard.example.com.crt
olcTLSCertificateKeyFile: /etc/ldap/wildcard.example.com.key
olcToolThreads: 1
structuralObjectClass: olcGlobal
creatorsName: cn=config
entryUUID: 91cc0ae0-9e13-1032-84b5-0151b658a842
createTimestamp: 20130820183919Z
olcLogLevel: config acl stats conns
olcTLSCipherSuite: NORMAL
olcTLSCRLCheck: none
olcTLSVerifyClient: never
entryCSN: 20130923150907.574575Z#00#001#00
modifiersName: uid=admin,dc=oreillyauto,dc=com
modifyTimestamp: 20130923150907Z
contextCSN: 20130923150907.574575Z#00#001#00
contextCSN: 20130923150843.855673Z#00#002#00
contextCSN: 20130919185322.242639Z#00#003#00

I tried doing an ldapmodify and delete the olcTLSCipherSuite and
olcTLSCRLCheck that I added and they will not disappear.
Thanks
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

The old certificates had been renamed adding .orig to the end.  I deleted
those and now the certificates are being presented properly.

Thank you,
Eric

This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 9E11060097D.AE15A




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



TLS negation failure

2013-09-19 Thread espeake

We have a client server that is failing on the ssl handshake using TLS.
The following is from the server log when the client is trying to connect.

Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
IP=172.17.1.10:55469 (IP=0.0.0.0:389)
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
err=0 text=
Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
negotiation failure)

On the client when I run the following:

openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389

I get this on the client

CONNECTED(0003)
139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 226 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

If I do the same command on port 636 I can see the certificate.  All of our
applications that use ldap are all set for TLS.  Even if I force them to
port 636 they fail.

Any ideas to look at are appreciated.

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: TLS negation failure

2013-09-19 Thread espeake



From:   Aaron Richton rich...@nbcs.rutgers.edu
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   09/19/2013 10:13 AM
Subject:Re: TLS negation failure



On Thu, 19 Sep 2013, espe...@oreillyauto.com wrote:

 We have a client server that is failing on the ssl handshake using TLS.
 The following is from the server log when the client is trying to
connect.

 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
 IP=172.17.1.10:55469 (IP=0.0.0.0:389)
 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
 oid=1.3.6.1.4.1.1466.20037
 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
 err=0 text=
 Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
 negotiation failure)

The above information is from a connection when a server is running an
application that is trying to access the LDAP server.  And this is what the
logging is doing on the server.  I tried to change the logging level to
debug but my changes aren't going through.  I tried deleting the
olcLogLevel and and then adding it back and tried a replace with no luck.

I also tried adding olcTLSCACertificatePath but none of my ldapmodifies
seem to be working.  I am on version 2.4.31 with a 3 node n-way multimaster
setup.


Try something like
https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw
if you'd like. Or OpenLDAP Software such as ldapsearch(1).

The above allowed me to connect and the connection was closed as soon as it
opened.

Thanks,
Eric




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Fw: SyncRepl Chaining

2013-09-06 Thread espeake
Old, Please disregard.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   espe...@oreillyauto.com
To: openldap-technical@openldap.org
Date:   09/06/2013 06:35 AM
Subject:Fw: SyncRepl Chaining
Sent by:openldap-technical-boun...@openldap.org




Bumping.


Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
- Forwarded by Eric Speake/OReilly on 08/20/2013 07:39 AM -

From:Eric Speake/OReilly
To:  openldap-technical@openldap.org
Date:08/19/2013 09:46 AM
Subject: SyncRepl Chaining


I believe we are very close to our goal of a master/slave syncrepl
configuration.  I have a master that through refreshAndPersist instantly
updates the slave servers.  The issue I am having is is passing on updates
to the master server for writing the updated information.  This is the
error message I get.

ldap_modify: Strong(er) authentication required (8)

I have set up chainingin bother the {-1}frontend database and the {1}hdb
database.  My understanding of what I read in man slapd-conf is that any
attributes used in the {-1}frontend makes these global and I should not
need that setup anywhere else unless I need to override the settings fro an
individual DB.  TLS with openSSL is setup through the compiling of the
openldap.

I am attaching the slapcat from my master.  Any and all help is
appreciated.

(See attached file: config-20130819-master.ldif)

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto PartsThis communication and any attachments are confidential,
protected by Communications Privacy Act 18 USCS § 2510, solely for the use
of the intended recipient, and may contain legally privileged material. If
you are not the intended recipient, please return or destroy it
immediately. Thank you.

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: D8807600DE9.A7366


[attachment config-20130819-master.ldif deleted by Eric Speake/OReilly]

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: SyncRepl Chaining

2013-09-06 Thread espeake




From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Date:   09/06/2013 10:42 AM
Subject:Re: SyncRepl Chaining



--On Friday, September 06, 2013 10:39 AM -0500 espe...@oreillyauto.com
wrote:

 root@tntest-ldap-3:~# ldapwhoami -d -1 -Wx -D
 uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com

Debug output from ldapwhoami is useless

 ldap_bind: Invalid credentials (49)

This error can indicate any of a number of things:

a) Wrong password
b) Acls block the ability to auth to the password
c) The DN specified doesn't exist

What you would need to provide is the debug output from *slapd* to see
which of a, b, or c was the problem.

--Quanah

--

Here is the olcAcces from the slapcat on the database.  Rule {0} should
what it is using but becaus eof it not authenticating rule {2} is being
applied instead.

Here is the slapd debug.

Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: conn=1015 op=0 BIND
dn=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com method=128
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = bdb_entry_get: found entry:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = bdb_entry_get: found entry:
cn=passwordadminpolicy,ou=policies,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: result not
in cache (userPassword)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: auth access
to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com userPassword
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = acl_get: [1] attr
userPassword
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = acl_mask: access to entry
uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com, attr userPassword
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = acl_mask: to value by ,
(=0)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = check a_dn_pat:
uid=syncrepl,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = check a_dn_pat:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = check a_dn_pat:
uid=ldapadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = check a_dn_pat:
uid=newuseradmin,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = check a_dn_pat:
uid=passwordadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = acl_mask: no more who
clauses, returning =0 (stop)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = slap_access_allowed: auth
access denied by =0
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: no more
rules
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = bdb_entry_get: found entry:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25  slapd[20347]: last message repeated 3 times
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: PRESENT
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com objectClass
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = root access granted
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access granted by manage(=mwrscxd)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter 6
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: PRESENT
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com objectClass
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = root access granted
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access granted by manage(=mwrscxd)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter 6
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = bdb_entry_get: found entry:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = bdb_entry_get: found entry:
cn=passwordadminpolicy,ou=policies,dc=oreillyauto,dc=com
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com entry
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = root access granted
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access granted by manage(=mwrscxd)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: EQUALITY
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com objectClass
requested
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = root access granted
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access granted by manage(=mwrscxd)
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = test_filter 5
Sep  6 11:01:25 tntest-ldap-1 slapd[20347]: = access_allowed: search
access to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com entry
requested
Sep 

Re: SyncRepl Chaining

2013-09-06 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   09/06/2013 11:45 AM
Subject:Re: SyncRepl Chaining



--On Friday, September 06, 2013 11:35 AM -0500 espe...@oreillyauto.com
wrote:

 Here is the olcAcces from the slapcat on the database.  Rule {0} should
 what it is using but becaus eof it not authenticating rule {2} is being
 applied instead.

Did you mean to paste your rules in here and forget? ;)

--Quanah

Yep.  had a hungry child calling me while I was trying to get this out.

olcAccess: {0}to *
by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com
by group/groupOfUniqueNames/uniqueMember=cn=System
Administrators,ou=Groups,dc=oreillyauto,dc=com write
by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=oreillyauto,dc=com write
olcAccess: {2}to attrs=userPassword
by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 write
by anonymous read
olcAccess: {3}to attrs=uid
by anonymous read
by users read
olcAccess: {4}to attrs=ou,employeeNumber
by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com
by dn.subtree=ou=Users,dc=oreillyauto,dc=com none
by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com
by dnattr=owner write
by dnattr=uniqueMember read
by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com
by self read
by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 read
by * none
olcAccess: {8}to *
by self read
by users read

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 5D29E600DE9.AF853




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: SyncRepl Chaining

2013-09-06 Thread espeake




From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   09/06/2013 11:56 AM
Subject:Re: SyncRepl Chaining



--On Friday, September 06, 2013 11:52 AM -0500 espe...@oreillyauto.com
wrote:




 From:  Quanah Gibson-Mount qua...@zimbra.com
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  09/06/2013 11:45 AM
 Subject:   Re: SyncRepl Chaining



 --On Friday, September 06, 2013 11:35 AM -0500 espe...@oreillyauto.com
 wrote:

 Here is the olcAcces from the slapcat on the database.  Rule {0} should
 what it is using but becaus eof it not authenticating rule {2} is being
 applied instead.

 Did you mean to paste your rules in here and forget? ;)

 --Quanah

 Yep.  had a hungry child calling me while I was trying to get this out.

 olcAccess: {0}to *
 by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write

As you have no break clause, this is the only ACL that ever applies.  Since

there is no anonymous read access to userPassword, it is impossible to
authenticate as any user.  Thus your inability to authenticate any user is
entirely caused by your broken ACLs.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration
Here is the ldif I created and used with ldapmodify

dn: olcDatabase={1}hdb,cn=config
changetype: modify

delete: olcAccess

add: olcAccess
olcAccess: {0}to *
by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write
break
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com
by group/groupOfUniqueNames/uniqueMember=cn=System
Administrators,ou=Groups,dc=oreillyauto,dc=com write
by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=oreillyauto,dc=com write
olcAccess: {2}to attrs=userPassword
by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 write
by anonymous read
olcAccess: {3}to attrs=uid
by anonymous read
by users read
olcAccess: {4}to attrs=ou,employeeNumber
by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com
by dn.subtree=ou=Users,dc=oreillyauto,dc=com none
by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com
by dnattr=owner write
by dnattr=uniqueMember read
by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com
by self read
by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 read
by * none
olcAccess: {8}to *
by self read
by users read

I confirmed the changes by looking at the LDIF that the changes were made.
Even though it's not supposed to be needed, I restarted the slapd service.
TO me it looks like it is reading the break and moving to rule {2} but
still no love or authentication.

Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: conn=1019 op=0 BIND
dn=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com method=128
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = bdb_entry_get: found entry:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = bdb_entry_get: found entry:
cn=passwordadminpolicy,ou=policies,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = access_allowed: result not
in cache (userPassword)
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = access_allowed: auth access
to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com userPassword
requested
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = acl_get: [1] attr
userPassword
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = acl_mask: access to entry
uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com, attr userPassword
requested
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = acl_mask: to value by ,
(=0)
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = check a_dn_pat:
uid=syncrepl,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = check a_dn_pat:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = check a_dn_pat:
uid=ldapadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = check a_dn_pat:
uid=newuseradmin,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 slapd[22140]: = check a_dn_pat:
uid=passwordadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 12:12:46 tntest-ldap-1 

Re: SyncRepl Chaining

2013-09-06 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   09/06/2013 12:29 PM
Subject:Re: SyncRepl Chaining



--On Friday, September 06, 2013 12:21 PM -0500 espe...@oreillyauto.com
wrote:


 add: olcAccess
 olcAccess: {0}to *
 by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write
 break

This should be by * break not break

You have no ACL granting access to the pseudo-attribute entry.

I personally have as my last ACL:

olcAccess: {10}to attrs=entry  by dn.children=cn=admins,cn=zimbra write
by *
  read

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Here is the access list from a new slapcat, this is for olcDatabase={1}hdb


olcAccess: {0}to *   by
dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com
  read   by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write   by
dn.base
 =uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write   by
dn.base=uid=p
 asswordAdmin,ou=System,dc=oreillyauto,dc=com write   by * break
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com   by
group/groupOfUniqueNa
 mes/uniqueMember=cn=System
Administrators,ou=Groups,dc=oreillyauto,dc=com w
 rite   by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=o
 reillyauto,dc=com write
olcAccess: {2}to attrs=userPassword   by
group/groupOfUniqueNames/uniqueMember
 =cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com write   by anonymous
read
olcAccess: {3}to attrs=uid   by anonymous read   by users read
olcAccess: {4}to attrs=ou,employeeNumber   by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com   by
dn.subtree=
 ou=Users,dc=oreillyauto,dc=com none   by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com   by
dnattr=own
 er write   by dnattr=uniqueMember read   by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com   by self
read
 by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreill
 yauto,dc=com read   by * none
olcAccess: {8}to *   by self read   by users read
olcAccess: {9} to attrs=entry by dn.children=cn=admins write by * read

and here is the debug.

Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: conn=2777 op=0 BIND
dn=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com method=128
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = bdb_entry_get: found entry:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = bdb_entry_get: found entry:
cn=passwordadminpolicy,ou=policies,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = access_allowed: result not
in cache (userPassword)
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = access_allowed: auth access
to uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com userPassword
requested
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_get: [1] attr
userPassword
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: access to entry
uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com, attr userPassword
requested
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: to value by ,
(=0)
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat:
uid=syncrepl,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat:
uid=readonlyuser,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat:
uid=ldapadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat:
uid=newuseradmin,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat:
uid=passwordadmin,ou=system,dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = check a_dn_pat: *
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: [6] applying +0
(break)
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: [6] mask: =0
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = dn: [2]
dc=oreillyauto,dc=com
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_get: [2] matched
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_get: [2] attr
userPassword
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: access to entry
uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com, attr userPassword
requested
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: to value by ,
(=0)
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = acl_mask: no more who
clauses, returning =0 (stop)
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = slap_access_allowed: auth
access denied by =0
Sep  6 13:28:29 tntest-ldap-1 slapd[22892]: = access_allowed: no more

{resolved}Re: SyncRepl Chaining

2013-09-06 Thread espeake




From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   09/06/2013 02:14 PM
Subject:Re: SyncRepl Chaining



--On Friday, September 06, 2013 1:46 PM -0500 espe...@oreillyauto.com
wrote:




 From:  Quanah Gibson-Mount qua...@zimbra.com
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  09/06/2013 12:29 PM
 Subject:   Re: SyncRepl Chaining



 --On Friday, September 06, 2013 12:21 PM -0500 espe...@oreillyauto.com
 wrote:


 add: olcAccess
 olcAccess: {0}to *
 by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
 by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write
 break

 This should be by * break not break

 You have no ACL granting access to the pseudo-attribute entry.

 I personally have as my last ACL:

 olcAccess: {10}to attrs=entry  by dn.children=cn=admins,cn=zimbra write
 by *
   read

 --Quanah

 --

 Quanah Gibson-Mount
 Lead Engineer
 Zimbra, Inc
 
 Zimbra ::  the leader in open source messaging and collaboration

 Here is the access list from a new slapcat, this is for olcDatabase=
{1}hdb


 olcAccess: {0}to *   by
 dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com
   read   by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com
 read  by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
 by dn.base
  =uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write   by
 dn.base=uid=p
  asswordAdmin,ou=System,dc=oreillyauto,dc=com write   by * break
 olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com   by
 group/groupOfUniqueNa
  mes/uniqueMember=cn=System
 Administrators,ou=Groups,dc=oreillyauto,dc=com w
  rite   by group/groupOfUniqueNames/uniqueMember=cn=LDAP
 Admin,ou=Groups,dc=o
  reillyauto,dc=com write
 olcAccess: {2}to attrs=userPassword   by
 group/groupOfUniqueNames/uniqueMember
  =cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com write   by anonymous
 read
 olcAccess: {3}to attrs=uid   by anonymous read   by users read
 olcAccess: {4}to attrs=ou,employeeNumber   by users read
 olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com   by
 dn.subtree=
  ou=Users,dc=oreillyauto,dc=com none   by users read
 olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com   by
 dnattr=own
  er write   by dnattr=uniqueMember read   by * none
 olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com   by self
 read
  by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreill
  yauto,dc=com read   by * none
 olcAccess: {8}to *   by self read   by users read
 olcAccess: {9} to attrs=entry by dn.children=cn=admins write by * read

Your acls are still clearly a mess.

olcAccess{1} blocks access to most of the tree for everything but two
identities.

I would also note that ACL 9 is clearly never going to be evaluated because

ACL{8} covers everything, and has no break clause.

I would also note that ACL2 is a significant security risk, as it grants
read access on the user password attribute to anonymous, instead of AUTH
access.

I would note that ACLs 5, 6, and 7 will never be evaluated because of ACL
{1}

I would note that ACLS 3, 4, and 8 likely do not do anything, given ACL{1},

since the majority of the tree is closed to them.  You probably want a by *

break on ACL{1} as well.

I would note that the general way in which you've structured your ACLs
makes them difficult to evaluate and maintain.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

This was definately an issue with the ACL's  I took down to three for
testing and I will work on any areas our team deems to be a security issue.

Thank you for all of your help.

Eric



This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Object not found

2013-09-03 Thread espeake




From:   espe...@oreillyauto.com
To: Quanah Gibson-Mount qua...@zimbra.com
Cc: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de,
openldap-technical@openldap.org
Date:   08/29/2013 06:39 PM
Subject:Re: Antw: Re: Object not found
Sent by:openldap-technical-boun...@openldap.org




To: espe...@oreillyauto.com
From: Quanah Gibson-Mount qua...@zimbra.com
Date: 08/29/2013 05:55PM
Cc: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de,
openldap-technical@openldap.org
Subject: Re: Antw: Re: Object not found

--On Thursday, August 29, 2013 2:30 PM -0500 espe...@oreillyauto.com wrote:

 Quanah,

 I have retyped the password a couple of times to be sure I didn't
 fat-finger the password.   I have a 3 node n-way multimaster cluster that
 working with replication on all changes with no issues other than the
 authentication.  I changed the password for the user on one server and
 checked the other two making sure the password hash replicated to the
 other servers and it did with no problems.  I tried the ldapsearch with
 two system users that will be used against the ldap server with the same
 result for both.  The only user that will authenticate is the DB rootDN
 user.  And of course that password is stored in the config.

 Any ideas on what I can check on next.  I tried changing the logging to
-1
 to get everything, but I just wasn't seeing anything that looked helpful.

So, as someone else noted, if your previous OpenLDAP version used a {crypt}

type hash, the newer build of OpenLDAP may not support {crypt} type
passwords.  So, my suggestion was you modify the password of the user who
can't bind.  You can do this using the rootdn and the ldappasswd utility.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


Sorry that I was unclear.  I have changed the password and I still the
invalid credentials error.

Thanks,
Eric
--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 879D0600DEB.AF5BB

I came across something might explain what is causing the authentication
issue.  In looking at the readOnlyUser that is not authenticating on my new
server running openladap 2.4.31 and my old server running openldap 2.4.21
is the password hash.  When decode the provided password hash the old
server returns that the the password was generated with a standard hash and
on the new server it is a salted hash.  I have looked through ppolicy from
my slapcat.ldif file and I don't see anything there dealing with password
storage. I am trying to figure out how I can toggle the salt hash off to do
further testing.

Thanks,
Eric


This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.
This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.
-- This message has been scanned for viruses and dangerous content, and is
believed to be clean. Message id: D3D8E600DEA.A3662

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Object not found

2013-08-30 Thread espeake
I used and LDAP browser to change the password. It encrypted the password and I matched the stored password on all three servers to be sure they matched.Eric-Quanah Gibson-Mount qua...@zimbra.com wrote: -To: espe...@oreillyauto.comFrom: Quanah Gibson-Mount qua...@zimbra.comDate: 08/29/2013 06:16PMCc: openldap-technical@openldap.org, Ulrich Windl ulrich.wi...@rz.uni-regensburg.deSubject: Re: Antw: Re: Object not found--On Thursday, August 29, 2013 6:11 PM -0500 espe...@oreillyauto.com wrote: Sorry that I was unclear. I have changed the password and I still the invalid credentials error.Changed it how?--Quanah--Quanah Gibson-MountLead EngineerZimbra, IncZimbra :: the leader in open source messaging and collaboration--This message has been scanned for viruses and dangerous content, and is believed to be clean.Message id: CA19D600DEA.AEC14This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.


Re: Antw: Re: Object not found

2013-08-30 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de,
openldap-technical@openldap.org
Date:   08/29/2013 06:25 PM
Subject:Re: Antw: Re: Object not found
Sent by:openldap-technical-boun...@openldap.org



--On Thursday, August 29, 2013 2:30 PM -0500 espe...@oreillyauto.com wrote:

 Quanah,

 I have retyped the password a couple of times to be sure I didn't
 fat-finger the password.   I have a 3 node n-way multimaster cluster that
 working with replication on all changes with no issues other than the
 authentication.  I changed the password for the user on one server and
 checked the other two making sure the password hash replicated to the
 other servers and it did with no problems.  I tried the ldapsearch with
 two system users that will be used against the ldap server with the same
 result for both.  The only user that will authenticate is the DB rootDN
 user.  And of course that password is stored in the config.

 Any ideas on what I can check on next.  I tried changing the logging to
-1
 to get everything, but I just wasn't seeing anything that looked helpful.

So, as someone else noted, if your previous OpenLDAP version used a {crypt}

type hash, the newer build of OpenLDAP may not support {crypt} type
passwords.  So, my suggestion was you modify the password of the user who
can't bind.  You can do this using the rootdn and the ldappasswd utility.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Quanah,

I tried this morning to change the password:

ldappasswd -s password -Wx -D uid=admin,dc=domain,dc=com
uid=readOnlyUser,ou=system,dc=domain,dc=com

I confirmed that the hashed password changed.  I still get invalid
credentials.  I am betting that there is some little simple thing that is
holding this up.

Thanks,
Eric
--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 4651C600DEA.A3E58




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Object not found

2013-08-30 Thread espeake



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org,
openldap-technical-boun...@openldap.org, Ulrich Windl
ulrich.wi...@rz.uni-regensburg.de
Date:   08/30/2013 12:37 PM
Subject:Re: Antw: Re: Object not found



--On Friday, August 30, 2013 10:55 AM -0500 espe...@oreillyauto.com wrote:

 Quanah,

 I tried this morning to change the password:

 ldappasswd -s password -Wx -D uid=admin,dc=domain,dc=com
 uid=readOnlyUser,ou=system,dc=domain,dc=com

 I confirmed that the hashed password changed.  I still get invalid
 credentials.  I am betting that there is some little simple thing that is
 holding this up.

Ok, so error (49) means one of two things:

a) Password is incorrect
b) No such object

No such object means either the entry you are attempting to bind as does
not exist in the LDAP DB, or ACLs prevent reading it, so it appears not to
exist.

My guess is this ACL is blocking access to the entry:

olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
dn.subtree=ou=Users,dc=oreillyauto,dc=com none by users read

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration
Wouldn't the following control grant the access first since it is the first
in the list.

olcAccess: {0}to *
by dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read
by dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write
by dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write

I think it may be in how the password is presented.  When I do a ldapsearch
for the readOnlyUser, the account is found.  I decode the password that is
presented and the password in the encrypted {SSHA} matches what I see in my
ldap browser.  I am going to have my developers do some further testing
against this ldap instance.
--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 63BD3600DF4.A1731




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Object not found

2013-08-29 Thread espeake

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Ulrich Windl ulrich.wi...@rz.uni-regensburg.de
To: espe...@oreillyauto.com
Date:   08/29/2013 01:46 AM
Subject:Antw: Re: Object not found



Eric,

following you progress on LDAP, why don't you use a working simple starting
configuration and then try simple steps towards getting where you want to
be at
the end? Only proceed if the current configuration works as intended; if
not
either undo or fix it.

Something like:
olcAccess: {0}to * by dn.base=uid=syncrepl,ou=system,dc=whatever read by
group/organizationalRole/roleOccupant.exact=cn=LDAP-Manager,dc=whatever
write
by * break
olcAccess: {1}to attrs=userPassword by self write by * auth
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to attrs=userPKCS12 by self read by * none
olcAccess: {4}to * by * read

You can leave out rule  {0}, because that's some local extension used here
(use a group for Managers).

Also I can recommend turning on auth logging for your tests. In
LDIF-format:
dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: ACL
-

I also recommend doing frequent database dumps per slapcat, so you can
revert
to a working configuration once you messed up things. However when using
replication, be aware that restoring one node to an older configuration,
the
older node may be overwritten if the other nodes still have a newer
configuration.

To all: Is there an option to slapadd to make any entries actually added
being
new (i.e. ignoring CSNs and modification timestamps in the LDIF)?

Regards,
Ulrich

 espe...@oreillyauto.com schrieb am 29.08.2013 um 05:25 in Nachricht
OF5EFEDB5F.26657526-ON86257BD6.001209FD-86257BD6.0012CADD@LocalDomain:
 Okay so I have the access list figured out and everything looks good
except
 now the credentials for my user aren't working.  I get an error 49
(invalid
 credentials)  I have reentered the password for the user.  There is one
 other user that will not autenticate.  Both of thes users are in the ou
 System.  The base admin account can login and get the informatio.  Here
is
 the new access list.

 olcAccess: {0}to * by
 dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read by
 dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read by
 dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write by
 dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write by
 dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write by *
 break
 olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
 group/groupOfUniqueNames/uniqueMember=cn=System
 Administrators,ou=Groups,dc=oreillyauto,dc=com write
 by group/groupOfUniqueNames/uniqueMember=cn=LDAP
 Admin,ou=Groups,dc=oreillyauto,dc=com write by * none break
 olcAccess: {2}to attrs=userPassword by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillya

 uto,dc=com
  write by anonymous auth by self write
 olcAccess: {3}to attrs=uid by anonymous read by users read
 olcAccess: {4}to attrs=ou,employeeNumber by users read
 olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
 dn.subtree=ou=Users,dc=oreillyauto,dc=com none by users read
 olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com by
 dnattr=owner write by dnattr=uniqueMember read by * none
 olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com by self read
 by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillya

 uto,dc=com
  read by * none
 olcAccess: {8}to * by self read by users read

 The two users that I need to work are:
  readOnlyUser
 dn=uid=readOnlyUser,ou=System,dc=oreilly,dc=com
  and
 ldapadmin  dn=uid=ldapadmin,
ou=System,dc=oreulllyauto,dc=com

 Here is the search and result:

 root@tntest-ldap-3:/var/lib/ldap# ldapsearch  -Wx -D
 uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com -b
 dc=oreillyauto,dc=com -H ldap://ldap-server.oreillyauto.com
uid=espeake
 uid dsplayName employeeNumber
 Enter LDAP Password:
 ldap_bind: Invalid credentials (49)

 any and all ideas are welcomed.
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Quanah Gibson-Mount qua...@zimbra.com
 To:espe...@oreillyauto.com, openldap-technical@openldap.org
 Date:  08/28/2013 11:35 AM
 Subject:   Re: Object not found
 Sent by:   openldap-technical-boun...@openldap.org



 --On Wednesday, August 28, 2013 8:12 AM -0500 espe...@oreillyauto.com
 wrote:


 I have a user name readonly that we use in our applications to get
uid's.
 THis has worked in the past with our old LDAP solution.  We have moved
to
 2.4.31 on Ubuntu 12.04 with a n-way Multi master setup.

 The slap cat for this database looks like this.

 dn: olcDatabase={1}hdb,cn=config
 objectClass: olcDatabaseConfig
 objectClass: olcHdbConfig
 olcDatabase: {1}hdb
 olcDbDirectory: /var/lib/ldap
 olcSuffix: dc=oreillyauto,dc=com
 olcAccess: {0}to attrs=userPassword by anonymous

RE: ldapadd ldap_bind: Invalid credentials (49)

2013-08-29 Thread espeake



From:   juergen.spren...@swisscom.com
To: cpe...@luthresearch.com, openldap-technical@openldap.org
Date:   08/29/2013 09:48 AM
Subject:RE: ldapadd ldap_bind: Invalid credentials (49)
Sent by:openldap-technical-boun...@openldap.org



--On Thursday, August 29, 2013 12:35 AM + Clint Petty
cpe...@luthresearch.com wrote:


 After upgrading from OpenLDAP 2.4.23 to 2.4.36, I can no longer add a
 user:



# ldapadd -x -D cn=Manager,dc=luthresearch,dc=net -w secret -f #
/etc/openldap/adduser.ldif

Check Your config for RootPW and whether the hash algorithm used is still
supported by
Your build of OpenLDAP.

Had a similar problem on an old server because --enable-crypt was not set
when
building OpenLDAP 2.4.36.

You can check that by using slappasswd to create a String like the one used
in Your config:

# /usr/local/sbin/slappasswd -s secret -h '{crypt}'
Password generation failed for scheme {crypt}: scheme not recognized

--Jürgen Sprenger

I tried this on two servers and got two different results.  Does this mean
that I have different hashes?  That might be part of the wrong credentials
I am getting.

Thanks,
Eric
--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: EA925600DEA.A40A9




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Antw: Re: Object not found

2013-08-29 Thread espeake



From:   espe...@oreillyauto.com
To: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de
Cc: openldap-technical@openldap.org
Date:   08/29/2013 10:29 AM
Subject:Re: Antw: Re: Object not found
Sent by:openldap-technical-boun...@openldap.org




Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:Ulrich Windl ulrich.wi...@rz.uni-regensburg.de
To:  espe...@oreillyauto.com
Date:08/29/2013 01:46 AM
Subject: Antw: Re: Object not found



Eric,

following you progress on LDAP, why don't you use a working simple starting
configuration and then try simple steps towards getting where you want to
be at
the end? Only proceed if the current configuration works as intended; if
not
either undo or fix it.

Something like:
olcAccess: {0}to * by dn.base=uid=syncrepl,ou=system,dc=whatever read by
group/organizationalRole/roleOccupant.exact=cn=LDAP-Manager,dc=whatever
write
by * break
olcAccess: {1}to attrs=userPassword by self write by * auth
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to attrs=userPKCS12 by self read by * none
olcAccess: {4}to * by * read

You can leave out rule  {0}, because that's some local extension used here
(use a group for Managers).

Also I can recommend turning on auth logging for your tests. In
LDIF-format:
dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: ACL
-

I also recommend doing frequent database dumps per slapcat, so you can
revert
to a working configuration once you messed up things. However when using
replication, be aware that restoring one node to an older configuration,
the
older node may be overwritten if the other nodes still have a newer
configuration.

To all: Is there an option to slapadd to make any entries actually added
being
new (i.e. ignoring CSNs and modification timestamps in the LDIF)?

Regards,
Ulrich

 espe...@oreillyauto.com schrieb am 29.08.2013 um 05:25 in Nachricht
OF5EFEDB5F.26657526-ON86257BD6.001209FD-86257BD6.0012CADD@LocalDomain:
 Okay so I have the access list figured out and everything looks good
except
 now the credentials for my user aren't working.  I get an error 49
(invalid
 credentials)  I have reentered the password for the user.  There is one
 other user that will not autenticate.  Both of thes users are in the ou
 System.  The base admin account can login and get the informatio.  Here
is
 the new access list.

 olcAccess: {0}to * by
 dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read by
 dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read by
 dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write by
 dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write by
 dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write by *
 break
 olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
 group/groupOfUniqueNames/uniqueMember=cn=System
 Administrators,ou=Groups,dc=oreillyauto,dc=com write
 by group/groupOfUniqueNames/uniqueMember=cn=LDAP
 Admin,ou=Groups,dc=oreillyauto,dc=com write by * none break
 olcAccess: {2}to attrs=userPassword by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillya


 uto,dc=com
  write by anonymous auth by self write
 olcAccess: {3}to attrs=uid by anonymous read by users read
 olcAccess: {4}to attrs=ou,employeeNumber by users read
 olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
 dn.subtree=ou=Users,dc=oreillyauto,dc=com none by users read
 olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com by
 dnattr=owner write by dnattr=uniqueMember read by * none
 olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com by self read
 by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillya


 uto,dc=com
  read by * none
 olcAccess: {8}to * by self read by users read

 The two users that I need to work are:
  readOnlyUser
 dn=uid=readOnlyUser,ou=System,dc=oreilly,dc=com
  and
 ldapadmin
  dn=uid=ldapadmin,
ou=System,dc=oreulllyauto,dc=com

 Here is the search and result:

 root@tntest-ldap-3:/var/lib/ldap# ldapsearch  -Wx -D
 uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com -b
 dc=oreillyauto,dc=com -H ldap://ldap-server.oreillyauto.com
uid=espeake
 uid dsplayName employeeNumber
 Enter LDAP Password:
 ldap_bind: Invalid credentials (49)

 any and all ideas are welcomed.
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:   Quanah Gibson-Mount qua...@zimbra.com
 To: espe...@oreillyauto.com,
openldap-technical@openldap.org
 Date:   08/28/2013 11:35 AM
 Subject:Re: Object not found
 Sent by:
 openldap-technical-boun...@openldap.org



 --On Wednesday, August 28, 2013 8:12 AM -0500 espe...@oreillyauto.com
 wrote:


 I have a user name readonly that we use in our applications to get
uid's.
 THis has worked in the past with our old LDAP solution.  We have

Re: Antw: Re: Object not found

2013-08-29 Thread espeake
To: espe...@oreillyauto.comFrom: Quanah Gibson-Mount qua...@zimbra.comDate: 08/29/2013 05:55PMCc: Ulrich Windl ulrich.wi...@rz.uni-regensburg.de, openldap-technical@openldap.orgSubject: Re: Antw: Re: Object not found--On Thursday, August 29, 2013 2:30 PM -0500 espe...@oreillyauto.com wrote: Quanah, I have retyped the password a couple of times to be sure I didn't fat-finger the password.  I have a 3 node n-way multimaster cluster that working with replication on all changes with no issues other than the authentication. I changed the password for the user on one server and checked the other two making sure the password hash replicated to the other servers and it did with no problems. I tried the ldapsearch with two system users that will be used against the ldap server with the same result for both. The only user that will authenticate is the DB rootDN user. And of course that password is stored in the config. Any ideas on what I can check on next. I tried changing the logging to -1 to get everything, but I just wasn't seeing anything that looked helpful.So, as someone else noted, if your previous OpenLDAP version used a {crypt} type hash, the newer build of OpenLDAP may not support {crypt} type passwords. So, my suggestion was you modify the password of the user who can't bind. You can do this using the rootdn and the ldappasswd utility.--Quanah--Quanah Gibson-MountLead EngineerZimbra, IncZimbra :: the leader in open source messaging and collaborationSorry that I was unclear. I have changed the password and I still the invalid credentials error.Thanks,Eric--This message has been scanned for viruses and dangerous content, and is believed to be clean.Message id: 879D0600DEB.AF5BBThis communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.


Object not found

2013-08-28 Thread espeake

I have a user name readonly that we use in our applications to get uid's.
THis has worked in the past with our old LDAP solution.  We have moved to
2.4.31 on Ubuntu 12.04 with a n-way Multi master setup.

The slap cat for this database looks like this.

dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=oreillyauto,dc=com
olcAccess: {0}to attrs=userPassword by anonymous auth by * none
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
group/groupOfUniqueName
 s/uniqueMember=cn=System Administrators,ou=Groups,dc=oreillyauto,dc=com
wri
 te by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=oreil
 lyauto,dc=com write by * none break
olcAccess: {2}to attrs=userPassword by
group/groupOfUniqueNames/uniqueMember=
 cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com write by anonymous auth
by s
 elf write
olcAccess: {3}to attrs=uid by anonymous read by users read
olcAccess: {4}to attrs=ou,employeeNumber by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
dn.subtree=o
 u=Users,dc=oreillyauto,dc=com none by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com by
dnattr=owner
  write by dnattr=uniqueMember read by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com by self read
by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillya
 uto,dc=com read by * none
olcAccess: {8}to * by self read by users read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcLimits: {0}dn.exact=uid=syncrepl,ou=System,dc=oreillyauto,dc=com
time.sof
 t=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {1}dn.exact=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com
time.so
 ft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {2}dn.exact=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com
time
 .soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: uid=admin,dc=oreillyauto,dc=com
olcRootPW:: c2VjcmV0
olcSyncUseSubentry: FALSE
olcDbCacheSize: 5
olcDbCheckpoint: 512 30
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 15
olcDbIndex: objectClass eq
olcDbIndex: cn eq
olcDbIndex: uid eq
olcDbIndex: oreillyGroup eq
olcDbIndex: locationEntry eq
olcDbIndex: counterNumber eq
olcDbIndex: businessCategory eq
olcDbIndex: locationNumber eq
olcDbIndex: position eq
olcDbIndex: title eq,subany
olcDbIndex: givenName eq,subany
olcDbIndex: functionListing eq
olcDbIndex: manager eq
olcDbIndex: sn eq,subany
olcDbIndex: nickName eq,subany
olcDbIndex: employeeNumber eq
olcDbIndex: ou eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: supervisor eq
olcDbIndex: status eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcHdbConfig
entryUUID: 91ce693e-9e13-1032-84c2-0151b658a842
createTimestamp: 20130820183919Z
creatorsName: cn=config
olcMirrorMode: TRUE
olcSyncrepl: {0}rid=004 provider=ldap://tntest-ldap-3.oreillyauto.com b
 inddn=uid=admin,dc=oreillyauto,dc=com bindmethod=simple
credentials=password
 searchbase=dc=oreillyauto,dc=com type=refreshAndPersist retry=5 5 5 +
tim
 eout=1
olcSyncrepl: {1}rid=005 provider=ldap://tntest-ldap-1.oreillyauto.com
binddn=
 uid=admin,dc=oreillyauto,dc=com bindmethod=simple credentials=password
searchb
 ase=dc=oreillyauto,dc=com type=refreshAndPersist retry=5 5 5 +
timeout=1
olcSyncrepl: {2}rid=006 provider=ldap://tntest-ldap-2.oreillyauto.com
binddn=
 uid=admin,dc=oreillyauto,dc=com bindmethod=simple credentials=password
searchb
 ase=dc=oreillyauto,dc=com type=refreshAndPersist retry=5 5 5 +
timeout=1
entryCSN: 20130821193620.549061Z#00#002#00
modifiersName: uid=admin,dc=oreillyauto,dc=com
modifyTimestamp: 20130821193620Z

And the ldap logs show this:

Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND
dn=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com method=128
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 BIND
dn=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com mech=SIMPLE ssf=0
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=0 RESULT tag=97
err=0 text=
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SRCH
base=uid=espeake,ou=Users,dc=oreillyauto,dc=com scope=0 deref=3
filter=(objectClass=*)
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=1 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 op=2 UNBIND
Aug 28 07:56:48 tntest-ldap-1 slapd[3067]: conn=27464 fd=40 closed

We had one issue with this server not running a rebuild last night due to a
certificate error of the cacert not being found and we are addressing the
through the following article:

http://www.mikepilat.com/blog/2011/05/adding-a-certificate-authority-to-the-java-runtime/

Searching as the ldapadmin user I find the user

Re: Object not found

2013-08-28 Thread espeake
Okay so I have the access list figured out and everything looks good except
now the credentials for my user aren't working.  I get an error 49 (invalid
credentials)  I have reentered the password for the user.  There is one
other user that will not autenticate.  Both of thes users are in the ou
System.  The base admin account can login and get the informatio.  Here is
the new access list.

olcAccess: {0}to * by
dn.base=uid=syncrepl,ou=System,dc=oreillyauto,dc=com read by
dn.base=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com read by
dn.base=uid=ldapAdmin,ou=System,dc=oreillyauto,dc=com write by
dn.base=uid=newUserAdmin,ou=System,dc=oreillyauto,dc=com write by
dn.base=uid=passwordAdmin,ou=System,dc=oreillyauto,dc=com write by *
break
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
group/groupOfUniqueNames/uniqueMember=cn=System
Administrators,ou=Groups,dc=oreillyauto,dc=com write
by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=oreillyauto,dc=com write by * none break
olcAccess: {2}to attrs=userPassword by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 write by anonymous auth by self write
olcAccess: {3}to attrs=uid by anonymous read by users read
olcAccess: {4}to attrs=ou,employeeNumber by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
dn.subtree=ou=Users,dc=oreillyauto,dc=com none by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com by
dnattr=owner write by dnattr=uniqueMember read by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com by self read
by
group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com
 read by * none
olcAccess: {8}to * by self read by users read

The two users that I need to work are:
 readOnlyUser
dn=uid=readOnlyUser,ou=System,dc=oreilly,dc=com
 and
ldapadmin   dn=uid=ldapadmin, 
ou=System,dc=oreulllyauto,dc=com

Here is the search and result:

root@tntest-ldap-3:/var/lib/ldap# ldapsearch  -Wx -D
uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com -b
dc=oreillyauto,dc=com -H ldap://ldap-server.oreillyauto.com uid=espeake
uid dsplayName employeeNumber
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

any and all ideas are welcomed.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   08/28/2013 11:35 AM
Subject:Re: Object not found
Sent by:openldap-technical-boun...@openldap.org



--On Wednesday, August 28, 2013 8:12 AM -0500 espe...@oreillyauto.com
wrote:


 I have a user name readonly that we use in our applications to get uid's.
 THis has worked in the past with our old LDAP solution.  We have moved to
 2.4.31 on Ubuntu 12.04 with a n-way Multi master setup.

 The slap cat for this database looks like this.

 dn: olcDatabase={1}hdb,cn=config
 objectClass: olcDatabaseConfig
 objectClass: olcHdbConfig
 olcDatabase: {1}hdb
 olcDbDirectory: /var/lib/ldap
 olcSuffix: dc=oreillyauto,dc=com
 olcAccess: {0}to attrs=userPassword by anonymous auth by * none
 olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
 group/groupOfUniqueName
  s/uniqueMember=cn=System
Administrators,ou=Groups,dc=oreillyauto,dc=com
 wri
  te by group/groupOfUniqueNames/uniqueMember=cn=LDAP
 Admin,ou=Groups,dc=oreil
  lyauto,dc=com write by * none break
 olcAccess: {2}to attrs=userPassword by
 group/groupOfUniqueNames/uniqueMember=
  cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com write by anonymous auth
 by s
  elf write

Hi,

You need to spend some time reading the manual pages and admin guide on
access rules for slapd.

It is immediately obvious that rule {2) will never evaluate because of rule

{0}.  Those shouldn't even be separate rule lines, they should be a single
rule.  I haven't looked further because that was so blatant, I'm guessing
you have any number of other issues in your access lines.

--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 898DB600A44.A073B




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Schema Replication and data replication.

2013-08-12 Thread espeake
I will try this in deb build app.  I tried making changes in this and it
did not like the build.  We do not use sql but we do use hdb and the other
options you have listed there.

I'll let you know what happens.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   08/12/2013 11:58 AM
Subject:Re: Schema Replication and data replication.



--On Monday, August 12, 2013 10:56 AM -0500 espe...@oreillyauto.com wrote:

 I understand what your are pointing in the location of the where the
 modules are being loaded.  The only modules that I find on the system
like
 back_hdb are found at usr/lib/ldap.  I have done a find on the entire
 system and find no other module files.  The date on all of the files is
 June 20th @14:36.  Including the mappings/links.

 I did not change any defaults and performed just the most basic of builds
 of the deb package.  I'm not sure where to put it to at this point.

Well, I have no idea what options you used to configure.  But if you don't
build modules, then there won't be any to install.  The fact that your
slapd is still reporting 2.4.28 would also indicate you've not yet actually

installed your build anywhere.

For example, I have:

--enable-dynamic \
--enable-slapd \
--enable-modules \
--enable-backends=mod \
--disable-shell \
--disable-sql \
--disable-bdb \
--disable-ndb \
--enable-overlays=mod \


--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 392C5600A4C.ACD4E




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Schema Replication and data replication.

2013-08-12 Thread espeake
Christian,

Thanks for the reply.  It doesn't do well without the options configured.
The issue I am dealing with right now is formatting the rules file be able
to modify the ./configure command.  trying to google the error messages I
get so I can get the formatting correct in the file.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: Quanah Gibson-Mount qua...@zimbra.com,
openldap-technical@openldap.org
Date:   08/12/2013 02:18 PM
Subject:Re: Schema Replication and data replication.



Hi,

On Mon, 12 Aug 2013, espe...@oreillyauto.com wrote:

 I understand what your are pointing in the location of the where the
 modules are being loaded.  The only modules that I find on the system
like
 back_hdb are found at usr/lib/ldap.  I have done a find on the entire
 system and find no other module files.  The date on all of the files is
 June 20th @14:36.  Including the mappings/links.

 I did not change any defaults and performed just the most basic of builds
 of the deb package.  I'm not sure where to put it to at this point.

it's quite possible that you built a statically linked slapd completely
without modules. You need something like '--enable-mdb=mod' in your
configure args for every feature you want as a module.

I use following in my centos rpm spec file:

 %configure --with-threads=posix --enable-local
--with-tls=openssl --prefix=%{_prefix}   \
 --includedir=%{_includedir} \
 --libexecdir=%{_libdir} \
 --enable-dynamic\
 --enable-syslog \
 --enable-proctitle  \
 --enable-ipv6   \
 --enable-local  \
 --enable-slapd  \
 --enable-dynacl \
 --enable-aci\
 --enable-cleartext  \
 --enable-crypt  \
 --enable-lmpasswd   \
 --enable-spasswd\
 --enable-modules\
 --enable-rewrite\
 --enable-rlookups   \
 --enable-wrappers   \
 --enable-cleartext  \
 --enable-crypt  \
 --enable-lmpasswd   \
 --enable-spasswd\
 --disable-bdb   \
 --enable-hdb=mod\
 --enable-ldap=mod   \
 --enable-mdb=mod\
 --enable-monitor=mod\
 --enable-overlays=mod   \
 --enable-accesslog=mod  \
 --enable-auditlog=mod   \
 --enable-memberof=mod   \
 --enable-ppolicy=mod\
 --enable-syncprov=mod   \
 --enable-translucent=mod
 make depend

It really depends on what debian package you took as a starting point.

I am not sure how openldap would react if you built it completely
without dynamic modules.

Greetings
Christian


 Thanks
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Quanah Gibson-Mount qua...@zimbra.com
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  08/09/2013 05:55 PM
 Subject:   Re: Schema Replication and data replication.





 --On August 9, 2013 12:55:17 PM -0500 espe...@oreillyauto.com wrote:

 So I have installed openldap 2.4.35 and it shows in the dpkg -l list.
 From the master that is running I ran:

 slapcat -n0 -F /etc/ldap/slapd.d
 -l /mnt/downloads/ldap/config-20130809-3.ldif

 on my server that I have ran the update on  and the server that I have
 not
 run the update on I run the following command:

 slapadd -n0 -F /etc/openldap/slapd.d
 -l /mnt/downloads/ldap/config-20130809-3.ldif

 On both servers I get the following error:

  str2entry: invalid value for attributeType objectClass #0 (syntax
 1.3.6.1.4.1.1466.115.121.1.38)

 You've left out some of the error message.  I'm also 

Re: Schema Replication and data replication.

2013-08-12 Thread espeake
I am building my package from fresh source code from openldap.org.
Changing OS is not going to be an option here.  Once I get the formatting
of the rules file straight I think everything should work.  Right now it
fails due to the format of the rules file.  An I think I found the issue.
Crossing my fingers for this next shot at the build.
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org, Quanah Gibson-Mount
qua...@zimbra.com
Date:   08/12/2013 02:32 PM
Subject:Re: Schema Replication and data replication.



Hi Eric,

On Mon, 12 Aug 2013, espe...@oreillyauto.com wrote:
 Christian,

 Thanks for the reply.  It doesn't do well without the options configured.
 The issue I am dealing with right now is formatting the rules file be
able
 to modify the ./configure command.  trying to google the error messages I
 get so I can get the formatting correct in the file.

as  I told you previously, considering that you need to get several things
right it might be a good idea to start fresh and build from source.

1. setup a fresh vm in a virtualisation setup of your choice
2. check that there is no openldap server package installed
3. build from source to keep it simple

Alternatively change to an OS for which there are prepackages current
openldap packages available.

Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: DBDF36009F0.A2920




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Schema Replication and data replication.

2013-08-09 Thread espeake
So I have installed openldap 2.4.35 and it shows in the dpkg -l list.  From
the master that is running I ran:

slapcat -n0 -F /etc/ldap/slapd.d
-l /mnt/downloads/ldap/config-20130809-3.ldif

on my server that I have ran the update on  and the server that I have not
run the update on I run the following command:

slapadd -n0 -F /etc/openldap/slapd.d
-l /mnt/downloads/ldap/config-20130809-3.ldif

On both servers I get the following error:

 str2entry: invalid value for attributeType objectClass #0 (syntax
1.3.6.1.4.1.1466.115.121.1.38)

Here that section of the ldif file created by the slapcat command:

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}ppolicy
olcModuleLoad: {2}memberof
olcModuleLoad: {3}dynlist
olcModuleLoad: {4}syncprov
olcModuleLoad: {5}refint
olcModuleLoad: {6}accesslog
structuralObjectClass: olcModuleList
entryUUID: 35b6151c-93c2-1032-9c9a-711c013d2dcb
creatorsName: cn=config
createTimestamp: 20130807153144Z
entryCSN: 20130807153144.459666Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20130807153144Z

Am I just missing something simple?
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   08/09/2013 11:11 AM
Subject:Re: Schema Replication and data replication.
Sent by:openldap-technical-boun...@openldap.org





--On August 9, 2013 9:07:06 AM -0500 espe...@oreillyauto.com wrote:

 So I have been able to build a package for ubuntu.  A few questions.

 I have yet to find where to set the default install directory when I
 run ./configure.  The default is /etc/openldap and I would like to change
 it to /etc/ldap which is the current install directory.

 I was able to install the package but the version still shows version
 2.4.28.  Do I need to reboot the server?

Hi,

First, you do not want to physically replace the distro provided OpenLDAP.
You want your build to install somewhere else, so that you don't overwrite
the distribution libldap, etc.  If you do that, you may have a number of
issues with other software programs that were linked to them.

Second, the best course would be to simply slapcat your existing config,
and re-import it to a location specific to you, so that OS updates/upgrades

don't potentially wipe out your configuration.

I.e., you should isolate your production instance from the OS.

Additionally, I would note the -F option to slapd, etc.  See the related
manual pages.

Hope this helps!

--Quanah


--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 98FA5600A42.AF8AA




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: Schema Replication and data replication

2013-08-08 Thread espeake
Christian,

Here is the ldif I created:

dn: olcDatabase={0}config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
olcServerID: 2 ldap://tntest-ldap-1.oreillyauto.com
olcServerID: 3 ldap://tntest-ldap-2.oreillyauto.com

Here is the error I get.

ldapmodify: wrong attributeType at line 4, entry olcDatabase={0}config

Should I be identifying the server elsewhere as well.  or maybe using.

dn: olcDatabase={0}config
changetype: modify
add: olcServerID: 1

and then run the other modify script.

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   08/08/2013 07:42 AM
Subject:Re: Schema Replication and data replication



Hi,

On Thu, 8 Aug 2013, espe...@oreillyauto.com wrote:

 Christian,

 The olcServerID goes in the cn=config file correct?  I will do a
ldapmodify to change this.

yes. use the following:

dn: olcDatabase={0}config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
olcServerID: 2 ldap://tntest-ldap-master-2.oreillyauto.com

 The consumer config is what was on there and that's why I asked the
question about wiping it out and then using slapcat to put it back in.

slapcat NEVER shows the checksums and protecting comments that you only see
when you go looking at the files under slapd.d

   # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
   # CRC32 3411e7fc

Once you have the correct configuration on one server dump it with slapcat
-n0 and import it to the second server using slapadd -n0.

Be sure to wipe ALL of the contents in the slapd.d directory before
importing with slapadd.

ps: please keep the mailinglist on the Cc: so what we learn from this is
for the greater good.

Greetings
Christian


 Thanks,
 Eric



 -openldap-technical-boun...@openldap.org wrote: -To:
espe...@oreillyauto.com
 From: Christian Kratzer
 Sent by: openldap-technical-boun...@openldap.org
 Date: 08/08/2013 06:58AM
 Cc: openldap-technical@openldap.org
 Subject: Re: Schema Replication and data replication

 Hi,

 On Wed, 7 Aug 2013, espe...@oreillyauto.com wrote:

 
  So we are cooking with warm oil and I wan to the cooking with hot
oil
 
  I have been able to get upgraded 2.4.28 on open ldap.  Having issue
with
  getting a good build of 2.4.35.  But that isn't the problem.  Below is
the
  log on my log from one of my consumers after starting the slapd
service.
 
 snipp
 
  Here is where is stops.
 
  Here in the ldif file from my master:
 
  # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
  # CRC32 3411e7fc

 use slapcat -n0 instead of copying manually the files from the slapd.d
directory.

  dn: olcDatabase={0}config
  objectClass: olcDatabaseConfig
  olcDatabase: {0}config
  olcUpdateRef: ldap://tntest-ldap-master-1.oreillyauto.com
  olcsyncrepl: rid=002
provider=ldap://tntest-ldap-master-1.oreillyauto.com
  type=refreshAndPersist retry=10 + searchbase=cn=config
  bindmethod=simple binddn=uid=admin,dc=oreillyauto,dc=com
  credentials=password
  olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com write by
  dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com write by * none
  olcRootDN: cn=admin,cn=config
  olcRootPW:: c2VjcmV0
  structuralObjectClass: olcDatabaseConfig
  entryUUID: 35b75e72-93c2-1032-9ca4-711c013d2dcb
  creatorsName: cn=config
  createTimestamp: 20130807153144Z
  entryCSN: 20130807153144.468097Z#00#000#00
  modifiersName: cn=config
  modifyTimestamp: 20130807153144Z
 
  Here is the ldif from my consumer:
 
  dn: olcDatabase={0}config
  objectClass: olcDatabaseConfig
  olcDatabase: {0}config
  olcRootDN: cn=admin,cn=config
  olcRootPW: secret
  structuralObjectClass: olcDatabaseConfig
  olcsyncrepl: {0}rid=002
  provider=ldap://tntest-ldap-master-1.oreillyauto.com type=refreshOnly
  retry=5 + searchbase=cn=config bindmethod=simple
  binddn=cn=admin,cn=config credentials=password schemachecking=on
  olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com write by
  dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com write by * none
  entryUUID: f074ba7c-09ed-1030-952b-0bb60fbd91a8
  creatorsName: cn=config
  createTimestamp: 20110503162710Z
  entryCSN: 20110503162710.319234Z#00#000#00
  modifiersName: cn=config
  ModifyTimestamp: 20110503162710Z
 

 both your entryCSN have #000# for the serverID. Even though it seems you
 have somehow modified the configuration.

 Your replication cannot work when you have not configured a serverID.

 You need at least the following in your configs.

    olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
    olcServerID: 2 ldap://tntest-ldap-master-2.oreillyauto.com

 Also why does the ModifyTimestamp: attribute from your second server
start with a capital 'M'.

 Are you still somehow manually poking at the files in slapd.d ?

 Please use slapcat / slapadd with the -n0 option to export 

Re: Schema Replication and data replication

2013-08-08 Thread espeake
That works.  I must have just been typing something wrong in that 4th line.
Now to get the other servers setup.

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   08/08/2013 10:35 AM
Subject:Re: Schema Replication and data replication
Sent by:openldap-technical-boun...@openldap.org



Hi,

On Thu, 8 Aug 2013, espe...@oreillyauto.com wrote:

 Christian,

 Here is the ldif I created:

 dn: olcDatabase={0}config
 changetype: modify
 replace: olcServerID
 olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
 olcServerID: 2 ldap://tntest-ldap-1.oreillyauto.com
 olcServerID: 3 ldap://tntest-ldap-2.oreillyauto.com


sorry. followig should do it:

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
olcServerID: 2 ldap://tntest-ldap-1.oreillyauto.com
olcServerID: 3 ldap://tntest-ldap-2.oreillyauto.com


 Here is the error I get.

 ldapmodify: wrong attributeType at line 4, entry olcDatabase={0}config

 Should I be identifying the server elsewhere as well.  or maybe using.

 dn: olcDatabase={0}config
 changetype: modify
 add: olcServerID: 1

your hostname should match one of the urls provided in olcServerId or you
should provide the specific servers url directly via the -h option to
slapd.

On linux this is often set by the init scripts that
parse /etc/sysconfig/ldap

Greetings
Christian

 and then run the other modify script.

 Thank you,
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Christian Kratzer ck-li...@cksoft.de
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  08/08/2013 07:42 AM
 Subject:   Re: Schema Replication and data replication



 Hi,

 On Thu, 8 Aug 2013, espe...@oreillyauto.com wrote:

 Christian,

 The olcServerID goes in the cn=config file correct?  I will do a
 ldapmodify to change this.

 yes. use the following:

 dn: olcDatabase={0}config
 changetype: modify
 replace: olcServerID
 olcServerID: 1 ldap://tntest-ldap-master-1.oreillyauto.com
 olcServerID: 2 ldap://tntest-ldap-master-2.oreillyauto.com

 The consumer config is what was on there and that's why I asked the
 question about wiping it out and then using slapcat to put it back in.

 slapcat NEVER shows the checksums and protecting comments that you only
see
 when you go looking at the files under slapd.d

   # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
   # CRC32 3411e7fc

 Once you have the correct configuration on one server dump it with
slapcat
 -n0 and import it to the second server using slapadd -n0.

 Be sure to wipe ALL of the contents in the slapd.d directory before
 importing with slapadd.

 ps: please keep the mailinglist on the Cc: so what we learn from this is
 for the greater good.

 Greetings
 Christian


 Thanks,
 Eric



 -openldap-technical-boun...@openldap.org wrote: -To:
 espe...@oreillyauto.com
 From: Christian Kratzer
 Sent by: openldap-technical-boun...@openldap.org
 Date: 08/08/2013 06:58AM
 Cc: openldap-technical@openldap.org
 Subject: Re: Schema Replication and data replication

 Hi,

 On Wed, 7 Aug 2013, espe...@oreillyauto.com wrote:


 So we are cooking with warm oil and I wan to the cooking with hot
 oil

 I have been able to get upgraded 2.4.28 on open ldap.  Having issue
 with
 getting a good build of 2.4.35.  But that isn't the problem.  Below is
 the
 log on my log from one of my consumers after starting the slapd
 service.

 snipp

 Here is where is stops.

 Here in the ldif file from my master:

 # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
 # CRC32 3411e7fc

 use slapcat -n0 instead of copying manually the files from the slapd.d
 directory.

 dn: olcDatabase={0}config
 objectClass: olcDatabaseConfig
 olcDatabase: {0}config
 olcUpdateRef: ldap://tntest-ldap-master-1.oreillyauto.com
 olcsyncrepl: rid=002
 provider=ldap://tntest-ldap-master-1.oreillyauto.com
 type=refreshAndPersist retry=10 + searchbase=cn=config
 bindmethod=simple binddn=uid=admin,dc=oreillyauto,dc=com
 credentials=password
 olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com write by
 dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com write by * none
 olcRootDN: cn=admin,cn=config
 olcRootPW:: c2VjcmV0
 structuralObjectClass: olcDatabaseConfig
 entryUUID: 35b75e72-93c2-1032-9ca4-711c013d2dcb
 creatorsName: cn=config
 createTimestamp: 20130807153144Z
 entryCSN: 20130807153144.468097Z#00#000#00
 modifiersName: cn=config
 modifyTimestamp: 20130807153144Z

 Here is the ldif from my consumer:

 dn: olcDatabase={0}config
 objectClass: olcDatabaseConfig
 olcDatabase: {0}config
 olcRootDN: cn=admin,cn=config
 olcRootPW: secret
 structuralObjectClass: olcDatabaseConfig
 olcsyncrepl: {0}rid=002
 provider=ldap://tntest-ldap-master-1.oreillyauto.com type=refreshOnly
 retry=5 + 

Re: Schema Replication and data replication.

2013-08-08 Thread espeake
Actually I did request help from the list in the building of a deb file
since source and rpm files are the only things available.  I even went
through the setup instructions to get the updates done that I needed.  I
even tried converting an rpm with alien with no luck.  Right now I am
trying to figure out how I can slapcat the config and then when I slapadd
it to another server as advised I get errors about invalid values for
attribute types from a working server.  the error is stating that the
olcModuleList value is invalid from this part of the created ldif from the
slapcat.

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}ppolicy
olcModuleLoad: {2}memberof
olcModuleLoad: {3}dynlist
olcModuleLoad: {4}syncprov
olcModuleLoad: {5}refint
olcModuleLoad: {6}accesslog
structuralObjectClass: olcModuleList

5203c44d str2entry: invalid value for attributeType objectClass #0 (syntax
1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=78)

The other error I get is this.

slapadd: dn=olcDatabase={-1}frontend,cn=config (line=353): (64) value of
single-valued naming attribute 'olcDatabase' conflicts with value present
in entry

dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcSizeLimit: 500
structuralObjectClass: olcDatabaseConfig

I don't want to sound ungrateful for the help and education on software
that I am a new user, but there are a few people offering assistance here
that pretty well speak down to everyone that asks for and with a disgusted
tone.  We are doing this in a test environment at this point and everything
that I have read says that we are on a version that accomplish what we are
trying to do.

Thank you again,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date:   08/08/2013 11:16 AM
Subject:Re: Schema Replication and data replication.
Sent by:openldap-technical-boun...@openldap.org





--On August 7, 2013 9:50:30 PM -0500 espe...@oreillyauto.com wrote:


 So we are cooking with warm oil and I wan to the cooking with hot oil

 I have been able to get upgraded 2.4.28 on open ldap.  Having issue with
 getting a good build of 2.4.35.  But that isn't the problem.  Below is
the
 log on my log from one of my consumers after starting the slapd service.

You seem to fail to understand that if you really want MMR and schema
replication, then upgrading to 2.4.35 is not optional, it is required.
Again, I will point you at the changes log:

http://www.openldap.org/software/release/changes.html

In addition, if you were having problems getting 2.4.35 to compile, it
would have been wisest to ask for assistance from the list.  At this point,

it sounds most like you need the help of some professional services, such
as Symas (http://www.symas.com).  If you are running such a mission
critical service, having a support team behind you would have resolved this

for you weeks ago.

Regards,
Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 7DDE0600A53.A3CE6




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: N-Way Master replication no contextcsn

2013-08-05 Thread espeake
Christian,

I did find a way to make the slapadd work by removing all of the files from
the slapd.d directory and then doing aa slapadd.  I run into the following
error and I have not been able to get passed it and the errors caused by
this one,  in processing this from the ldif I get an error.

The first line is line 19 of the file.

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}ppolicy.la
olcModuleLoad: {2}memberof.la
olcModuleLoad: {3}dynlist.la
olcModuleLoad: {4}syncprov.la
olcModuleLoad: {5}refint.la
olcModuleLoad: {6}accesslog.la
structuralObjectClass: olcModuleList

51fff80d str2entry: invalid value for attributeType objectClass #0 (syntax
1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=19)

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   08/02/2013 03:01 PM
Subject:Re: N-Way Master replication no contextcsn
Sent by:openldap-technical-boun...@openldap.org



Hi,

On Fri, 2 Aug 2013, espe...@oreillyauto.com wrote:

 Okay so I down loaded  tar and followed these instructions.

 http://www.openldap.org/software/release/install.html

 It says that everything was okay and I received no errors.  I restarted
the
 slapd service and it still shows that it is the old version.

 I guess I'm still missing something.

you obviously have at least one old version left on your system.

Ideally you shoud first remove all traces of your previous ldap
installation by removing respective rpms, deps or other packags.

You could also use find to search for slapd binaries and libraries on the
system but If you are not too experienced you can easily shoot yourself in
the foot by removing libaries in use by the rest of you system.

Best guess is propably to start with a clean installation perhaps in a VM
compile there.

Greetings
Christian




 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Christian Kratzer c...@cksoft.de
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org,
openldap-technical-boun...@openldap.org
 Date:  08/02/2013 10:09 AM
 Subject:   Re: N-Way Master replication no contextcsn



 Hi,

 On Fri, 2 Aug 2013, espe...@oreillyauto.com wrote:

 As a noob upgrading appears to easier said than done.  I am running on
 Ubuntu 10.04 on my master and I have tried to create packages from the
 code
 I downloaded from the web site and the install just doesn't work.  So I
 found an RPM and and converted it via alien to a deb file and used dpkg
 to
 try and install and even with --force it erred out trying to overwrite
 the
 slapd.d folder.  Is there and easy way to build the package as a deb
file
 so I can install it and also add it to my repo for the other servers.

 you could try just fetching the official tarball and building and
 installing from that.

 also take a backup of you config and your data with:

 slapcat -n0 -l  config.ldif
 slapcat -l data.ldif

 Greetings
 Christian



 Thanks,
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Christian Kratzer ck-li...@cksoft.de
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  07/29/2013 10:44 AM
 Subject:   Re: N-Way Master replication no 
 contextcsn
 Sent by:   
 openldap-technical-boun...@openldap.org



 Hi,

 On Fri, 26 Jul 2013, espe...@oreillyauto.com wrote:


 Trying a different method of replication to suit or need and I set up
 two
 test servers for n-way master mirroring servers.  Both servers have the
 same configuration being fed to them through puppet.  In the logs I can
 see
 them bind and check cookies but I get CSN too old, ignoring
 20110608165005.984980Z#00#000#00 (olcOverlay=
 {4}syncprov,olcDatabase={1}hdb,cn=config)  THen the last slapd entry in
 the
 log is rid=002
 cookie=rid=002,sid=002,csn=20110915141524.047299Z#00#000#00 and
 then nothing else happens.  If I make a change to user it never syncs
to
 the other server.

 At this point I don't know what to look at or what you might want to
 look
 at to help diagnose the problem.  I followed the documentation in the
 admin
 guide to set this up.

 Any and all help is appreciated.

 1. You are using an ancient openldap version 2.4.28 compiled by your
 distribution.  Please start by updating to a current 2.4.35 build from
 sources.

 2. You say both servers have the same configuration through puppet ? I
 see
 you are using cn=config. How are you distributing this configuration.
You
 should not write any files to slapd.d via puppet or 

Re: N-Way Master replication no contextcsn

2013-08-02 Thread espeake
As a noob upgrading appears to easier said than done.  I am running on
Ubuntu 10.04 on my master and I have tried to create packages from the code
I downloaded from the web site and the install just doesn't work.  So I
found an RPM and and converted it via alien to a deb file and used dpkg to
try and install and even with --force it erred out trying to overwrite the
slapd.d folder.  Is there and easy way to build the package as a deb file
so I can install it and also add it to my repo for the other servers.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   07/29/2013 10:44 AM
Subject:Re: N-Way Master replication no contextcsn
Sent by:openldap-technical-boun...@openldap.org



Hi,

On Fri, 26 Jul 2013, espe...@oreillyauto.com wrote:


 Trying a different method of replication to suit or need and I set up two
 test servers for n-way master mirroring servers.  Both servers have the
 same configuration being fed to them through puppet.  In the logs I can
see
 them bind and check cookies but I get CSN too old, ignoring
 20110608165005.984980Z#00#000#00 (olcOverlay=
 {4}syncprov,olcDatabase={1}hdb,cn=config)  THen the last slapd entry in
the
 log is rid=002
 cookie=rid=002,sid=002,csn=20110915141524.047299Z#00#000#00 and
 then nothing else happens.  If I make a change to user it never syncs to
 the other server.

 At this point I don't know what to look at or what you might want to look
 at to help diagnose the problem.  I followed the documentation in the
admin
 guide to set this up.

 Any and all help is appreciated.

1. You are using an ancient openldap version 2.4.28 compiled by your
distribution.  Please start by updating to a current 2.4.35 build from
sources.

2. You say both servers have the same configuration through puppet ? I see
you are using cn=config. How are you distributing this configuration. You
should not write any files to slapd.d via puppet or other means.  Use
slapcat/slapadd -n0 to export and import configurations.

Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 07A406006FB.AF9AA




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: N-Way Master replication no contextcsn

2013-08-02 Thread espeake
Okay so I down loaded  tar and followed these instructions.

http://www.openldap.org/software/release/install.html

It says that everything was okay and I received no errors.  I restarted the
slapd service and it still shows that it is the old version.

I guess I'm still missing something.

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer c...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org,
openldap-technical-boun...@openldap.org
Date:   08/02/2013 10:09 AM
Subject:Re: N-Way Master replication no contextcsn



Hi,

On Fri, 2 Aug 2013, espe...@oreillyauto.com wrote:

 As a noob upgrading appears to easier said than done.  I am running on
 Ubuntu 10.04 on my master and I have tried to create packages from the
code
 I downloaded from the web site and the install just doesn't work.  So I
 found an RPM and and converted it via alien to a deb file and used dpkg
to
 try and install and even with --force it erred out trying to overwrite
the
 slapd.d folder.  Is there and easy way to build the package as a deb file
 so I can install it and also add it to my repo for the other servers.

you could try just fetching the official tarball and building and
installing from that.

also take a backup of you config and your data with:

 slapcat -n0 -l  config.ldif
 slapcat -l data.ldif

Greetings
Christian



 Thanks,
 Eric Speake
 Web Systems Administrator
 O'Reilly Auto Parts



 From:  Christian Kratzer ck-li...@cksoft.de
 To:espe...@oreillyauto.com
 Cc:openldap-technical@openldap.org
 Date:  07/29/2013 10:44 AM
 Subject:   Re: N-Way Master replication no contextcsn
 Sent by:   openldap-technical-boun...@openldap.org



 Hi,

 On Fri, 26 Jul 2013, espe...@oreillyauto.com wrote:


 Trying a different method of replication to suit or need and I set up
two
 test servers for n-way master mirroring servers.  Both servers have the
 same configuration being fed to them through puppet.  In the logs I can
 see
 them bind and check cookies but I get CSN too old, ignoring
 20110608165005.984980Z#00#000#00 (olcOverlay=
 {4}syncprov,olcDatabase={1}hdb,cn=config)  THen the last slapd entry in
 the
 log is rid=002
 cookie=rid=002,sid=002,csn=20110915141524.047299Z#00#000#00 and
 then nothing else happens.  If I make a change to user it never syncs to
 the other server.

 At this point I don't know what to look at or what you might want to
look
 at to help diagnose the problem.  I followed the documentation in the
 admin
 guide to set this up.

 Any and all help is appreciated.

 1. You are using an ancient openldap version 2.4.28 compiled by your
 distribution.  Please start by updating to a current 2.4.35 build from
 sources.

 2. You say both servers have the same configuration through puppet ? I
see
 you are using cn=config. How are you distributing this configuration. You
 should not write any files to slapd.d via puppet or other means.  Use
 slapcat/slapadd -n0 to export and import configurations.

 Greetings
 Christian

 --
 Christian Kratzer  CK Software GmbH
 Email:   c...@cksoft.de  Wildberger Weg 24/2
 Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
 Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
 Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian
Kratzer


 --
 This message has been scanned for viruses and dangerous content,
 and is believed to be clean.
  Message id: 07A406006FB.AF9AA




 This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS ? 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you are
not the intended recipient, please return or destroy it immediately. Thank
you.


--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: C01E4600DDE.A423A




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Error 32 object not found.

2013-08-01 Thread espeake

Here is the error message I get when I and trying to replicate my
databases.

Aug  1 11:05:41 tntest-ldap-2 slapd[4871]: do_syncrep2: rid=002
LDAP_RES_SEARCH_RESULT
Aug  1 11:05:41 tntest-ldap-2 slapd[4871]: do_syncrepl: rid=002 rc -2
retrying

Here is the ldif from the master.

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW: secret
olcSyncrepl: rid=002 provider=ldap://tntest-ldap-master-1.oreillyauto.com
type=refreshAndPersist retry=5 + searchbase=cn=config bindmethod=simple
binddn=uid=admin,dc=oreillyauto,dc=com credentials=secret
olcUpdateRef: ldap://tntest-ldap-master-1.oreillyauto.com
olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com read by
dn=uid=ldapAdmin,ou=system,dc=oreillyauto,dc=com read by * none
structuralObjectClass: olcDatabaseConfig
entryUUID: f074ba7c-09ed-1030-952b-0bb60fbd91a8
creatorsName: cn=config
createTimestamp: 20110503162710Z
entryCSN: 20110503162710.319234Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20110503162710Z

Here is the ldif from the consumer.

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
olcRootPW: secret
structuralObjectClass: olcDatabaseConfig
olcUpdateRef: ldap://tntest-ldap-master-1.oreillyauto.co
olcsyncrepl: rid=002 provider=ldap://tntest-ldap-master-1.oreillyauto.com
type=refreshAndPersist retry=10 + searchbase=cn=config
bindmethod=simple binddn=uid=admin,dc=oreillyauto,dc=com
credentials=secret
olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com write by
dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com write by * none
entryUUID: f074ba7c-09ed-1030-952b-0bb60fbd91a8
creatorsName: cn=config
createTimestamp: 20110503162710Z
entryCSN: 20110503162710.319234Z#00#000#00
modifiersName: cn=config
ModifyTimestamp: 20110503162710Z

Getting cloaser I think.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



DR scenerio

2013-07-31 Thread espeake

Okay here is what we are wanting to do and I need to know if it is possible
with openLDAP.  We have a main production ldap server v. 2.4.28 running on
Ubuntu 10.04  We are adding two servers that will handle authenication and
refer writes to the main provider server.  What I would like to to setup
another provider in our DR site and have it pull replication from the main
LDAP server once a day, maybe twice.  Then in turn that server would be the
provider for two consumers at the DR site that would handle auth requests
and refer write to the provider at the DR site.  But the no changes at the
DR site would be written back to the main production provider.  I don't
want someone testing something in the DR to be written back to production.

In a nut shell I want to have two systems that look the same and the
information for the second system would come from a sync with the first
system, but the second system would not be able to write back to the main
system.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Re: N-Way Master replication no contextcsn

2013-07-29 Thread espeake
Thanks we are using 2.4.28 on ubuntu 12.04.

cn=config.ldif:

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
olcServerID: 1 ldap://tntest-ldap-1.oreillyauto.com
olcServerID: 2 ldap://tntest-ldap-2.oreillyauto.com
structuralObjectClass: olcGlobal
entryUUID: f074a7c6-09ed-1030-9529-0bb60fbd91a8
creatorsName: cn=config
createTimestamp: 20110503162710Z
olcSecurity: simple_bind=0
olcSecurity: ssf=0
olcSecurity: tls=0
olcLocalSSF: 0
olcTLSCACertificateFile: /etc/ldap/wildcard.oreillyauto.com.crt
olcTLSCertificateFile: /etc/ldap/wildcard.oreillyauto.com.crt
olcTLSCertificateKeyFile: /etc/ldap/wildcard.oreillyauto.com.key
olcIdleTimeout: 30
olcLogFIle: /var/log/slapd/ldapsync
olcLogLevel: 16384
entryCSN: 20110616153436.707254Z#00#000#00
modifiersName: cn=admin,cn=config
modifyTimestamp: 20110616153436Z

olcDatabase{0}config.ldif

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW: secret
structuralObjectClass: olcDatabaseConfig
olcsyncrepl: {0}rid=001 provider=ldap://tntest-ldap-1.oreillyauto.com
uri=ldap://tntest-ldap-1.oreillyauto.com; type=refreshAndPersist retry=5
+ searchbase=cn=config bindmethod=simple binddn=cn=admin,cn=config
credentials=password
olcsyncrepl: {1}rid=002 provider=ldap://tntest-ldap-2.oreillyauto.com
uri=ldap://tntest-ldap-2.oreillyauto.com; type=refreshAndPersist retry=5
+ searchbase=cn=config bindmethod=simple binddn=cn=admin,cn=config
credentials=password
olcMirrorMode: TRUE
olcAccess: to * by dn=uid=admin,dc=oreillyauto,dc=com write by
dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com write by * none
entryUUID: f074ba7c-09ed-1030-952b-0bb60fbd91a8
creatorsName: cn=config
createTimestamp: 20110503162710Z
entryCSN: 20110503162710.319234Z#00#000#00
modifiersName: cn=config
ModifyTimestamp: 20110503162710Z

olcDatabase{1}hdb.ldif

olcDbIndex: uid eq
olcDbIndex: oreillyGroup eq
olcDbIndex: locationEntry eq
olcDbIndex: counterNumber eq
olcDbIndex: businessCategory eq
olcDbIndex: locationNumber eq
olcDbIndex: position eq
olcDbIndex: title eq,subany
olcDbIndex: givenName eq,subany
olcDbIndex: functionListing eq
olcDbIndex: manager eq
olcDbIndex: sn eq,subany
olcDbIndex: nickName eq,subany
olcDbIndex: employeeNumber eq
olcDbIndex: ou eq
olcDbIndex: entryUUID eq
olcDbIndex: supervisor eq
olcDbIndex: entryCSN eq
olcSyncRepl: {0}rid=004 provider=ldap://tntest-ldap-1.oreillyauto.com
uri=ldap://tntest-ldap-1.oreillyauto.com; bindmethod=simple
binddn=uid=admin,dc=oreillyauto,dc=com
credentials=passwordsearchbase=dc=oreillyauto,dc=com
logbase=cn=accesslog type refreshAndPersist retry=50 +
olcSyncRepl: {1}rid=005 provider=ldap://tntest-ldap-2.oreillyauto.com
uri=ldap://tntest-ldap-2.oreillyauto.com; bindmethod=simple
binddn=uid=admin,dc=oreillyauto,dc=com
credentials=passwordsearchbase=dc=oreillyauto,dc=com
logbase=cn=accesslog type refreshAndPersist retry=50 +
olcMirrorMode: TRUE
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcHdbConfig
entryUUID: 5d3c8434-0acd-1030-95eb-4165b688bcbf
creatorsName: cn=config
createTimestamp: 20110504190630Z
olcLimits: {0}dn.exact=uid=admin,ou=System,dc=oreillyauto,dc=com time.so
 ft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {1}dn.exact=uid=readOnlyUser,ou=System,dc=oreillyauto,dc=com
time
 .soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymous auth by dn=uid=admin,dc=oreillyauto,dc=com write by
dn=uid=ldapadmin,ou-system,dc=oreillyauto,dc=com read by * none
olcAccess: {1}to dn.subtree=dc=oreillyauto,dc=com by
group/groupOfUniqueName
 s/uniqueMember=cn=System Administrators,ou=Groups,dc=oreillyauto,dc=com
wri
 te by group/groupOfUniqueNames/uniqueMember=cn=LDAP
Admin,ou=Groups,dc=oreil
 lyauto,dc=com write by * none break
olcAccess: {2}to attrs=userPassword by
group/groupOfUniqueNames/uniqueMember=
 cn=Authenticate,ou=Groups,dc=oreillyauto,dc=com write by anonymous auth
by s
 elf write
olcAccess: {3}to attrs=uid by anonymous read by users read
olcAccess: {4}to attrs=ou,employeeNumber by users read
olcAccess: {5}to dn.subtree=ou=System,dc=oreillyauto,dc=com by
dn.subtree=o
 u=Users,dc=oreillyauto,dc=com none by users read
olcAccess: {6}to dn.children=ou=Groups,dc=oreillyauto,dc=com by
dnattr=owner
  write by dnattr=uniqueMember read by * none
olcAccess: {7}to dn.children=ou=Users,dc=oreillyauto,dc=com by self read
by

group/groupOfUniqueNames/uniqueMember=cn=Authenticate,ou=Groups,dc=oreillyau
 to,dc=com read by * none
olcAccess: {8}to * by self read by users read
entryCSN: 20110915141524.047299Z#00#000#00
modifiersName: cn=admin,cn=config
modifyTimestamp: 20110915141524Z

olcDatabase{-1}frontend.ldif

dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig

Re: N-Way Master replication no contextcsn

2013-07-29 Thread espeake
The file structure is stored in module definitions and they are then
applied to the server in their proper place via the puppet agent.  The ldap
servers are running and I can write to individual servers.  I an just
having issues with the replication.  The one thing I see is the node
identifier in the CSN, the second to last set of numbers, are all zeros.
The CSN looks like a date actually  Should I take that out of the puppet
file and when I do will it regenerate the CSN ?  Also, is the modify
timestamp some that would be regenerated if I removed them..  The configs I
provided are actually from the puppet server.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts



From:   Christian Kratzer ck-li...@cksoft.de
To: espe...@oreillyauto.com
Cc: openldap-technical@openldap.org
Date:   07/29/2013 10:44 AM
Subject:Re: N-Way Master replication no contextcsn
Sent by:openldap-technical-boun...@openldap.org



Hi,

On Fri, 26 Jul 2013, espe...@oreillyauto.com wrote:


 Trying a different method of replication to suit or need and I set up two
 test servers for n-way master mirroring servers.  Both servers have the
 same configuration being fed to them through puppet.  In the logs I can
see
 them bind and check cookies but I get CSN too old, ignoring
 20110608165005.984980Z#00#000#00 (olcOverlay=
 {4}syncprov,olcDatabase={1}hdb,cn=config)  THen the last slapd entry in
the
 log is rid=002
 cookie=rid=002,sid=002,csn=20110915141524.047299Z#00#000#00 and
 then nothing else happens.  If I make a change to user it never syncs to
 the other server.

 At this point I don't know what to look at or what you might want to look
 at to help diagnose the problem.  I followed the documentation in the
admin
 guide to set this up.

 Any and all help is appreciated.

1. You are using an ancient openldap version 2.4.28 compiled by your
distribution.  Please start by updating to a current 2.4.35 build from
sources.

2. You say both servers have the same configuration through puppet ? I see
you are using cn=config. How are you distributing this configuration. You
should not write any files to slapd.d via puppet or other means.  Use
slapcat/slapadd -n0 to export and import configurations.

Greetings
Christian

--
Christian Kratzer  CK Software GmbH
Email:   c...@cksoft.de  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0  D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9  HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer


--
This message has been scanned for viruses and dangerous content,
and is believed to be clean.
  Message id: 07A406006FB.AF9AA




This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



N-Way Master replication no contextcsn

2013-07-26 Thread espeake

Trying a different method of replication to suit or need and I set up two
test servers for n-way master mirroring servers.  Both servers have the
same configuration being fed to them through puppet.  In the logs I can see
them bind and check cookies but I get CSN too old, ignoring
20110608165005.984980Z#00#000#00 (olcOverlay=
{4}syncprov,olcDatabase={1}hdb,cn=config)  THen the last slapd entry in the
log is rid=002
cookie=rid=002,sid=002,csn=20110915141524.047299Z#00#000#00 and
then nothing else happens.  If I make a change to user it never syncs to
the other server.

At this point I don't know what to look at or what you might want to look
at to help diagnose the problem.  I followed the documentation in the admin
guide to set this up.

Any and all help is appreciated.

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Replicating schema

2013-07-25 Thread espeake

Okay so I am very new to openLDAP and we are running v 2.4.28 on ubuntu
12.04.  In trying to set up a mirror with two servers  that will grow to 3
soon.  THis is what I get in the log about syncing the schema:

Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 fd=16 ACCEPT from IP=
172.17.3.148:39672 (IP=0.0.0.0:389)
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=0 BIND
dn=uid=admin,dc=example,dc=com method=128
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=0 BIND
dn=uid=admin,dc=example,dc=com mech=SIMPLE ssf=0
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=0 RESULT tag=97
err=0 text=
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=1 SRCH
base=cn=config scope=2 deref=0 filter=(objectClass=*)
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=1 SRCH attr=* +
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: findbase failed! 32
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=1 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 op=2 UNBIND
Jul 25 13:26:42 tntest-ldap-1 slapd[27954]: conn=1004 fd=16 closed

From what I can tell it is binding with the simple methad establishes the
search base looking at all of the object classes. but then it says it can't
find the data base.  Here is the ldif file from olcDatabase{0}config.ldif

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW: secret
structuralObjectClass: olcDatabaseConfig
olcsyncrepl: rid=001 provider=ldap://tntest-ldap-1.example.com
type=refreshAndPersist retry=5 + searchbase=cn=config bindmethod=simple
binddn=uid=admin,dc=example,dc=com credentials=secret
olcsyncrepl: rid=002 provider=ldap://tntest-ldap-2.example.com
type=refreshAndPersist retry=5 + searchbase=cn=config bindmethod=simple
binddn=uid=admin,example,dc=com credentials=secret
olcMirrorMode: TRUE
olcAccess: to * by by dn=uid=admin,dc=example,dc=com write by
dn=uid=ldapadmin,ou=system,dc=oreillyauto,dc=com read by * none


Any ideas on where I should be looking to make a correction or any other
information you need to help me figure this out?

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Q: referral issue

2013-07-17 Thread espeake

Okay my referral chaining was working and then stopped working.  I get an
error 10 when I submit a change to my clustered consumers that are setup to
refer writes to my master LDAP server.  In looking at the configuration
help in the online documentation it shows how to setup the slapd.conf file
on the master.  The issue here is that everything is setup through
cn=config.  my consumers do have a slapd.conf file along with cn=config
files.  I have inherited these servers so I'm sure what the person here
before me was trying to do.  I have an idea but I didn't like that idea.

Here is the chaining command from my slapd.conf file.

overlaychain
chain-uri  ldap://tntest-ldap-master-1.example.com;
chain-rebind-as-user   TRUE
chain-idassert-bindbindmethod=simple
   binddn=uid=admin,dc=oreillyauto,dc=com
   credentials=password
   mode=self
chain-tls  start
chain-return-error TRUE


The the syncrepl area
syncrepl rid 002
provider=ldap://tntest-ldap-master-1.example.com
type=refreshOnly
interval=00:00:05:00
searchbase-dc=oreillyauto,dc=com
binddn=uuid=syncrepl,ou=system,dc=oreillyauto,dc=com
credentials=password

updatedn  uid=ldapadmin,ou=system,dc=example,dc=com
updateref ldap://tntest-ldap-master-1.example.com

I need to be pointed in the right direction please.
Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.



Fan-Out replication

2013-07-08 Thread espeake

Oracle talks about doing a fan-out replication that fits what we are
looking at doing.  What we want to do is once a day or once a week is to
replicate our production LDAP from our master to a master LDAP server at
our DR site.  That server would then push changes to the consumer LDAP
servers at our DR site.  We are trying to keep the sites basically mirrored
but I do not want changes made at the DR site to replicate back to the
production master.


Master LDAP
/\
/\
/\
/\
/\
DR Master LDAP\
/   \
/   \
/   \
/Production Consumers
/
/
DR Consumers

I hope that helps to visualize what we are trying to do.

Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.