Slapd database goes corrupt repeatedly after recovery

2010-03-25 Thread Kaspar Fischer
Dear list,

We are using an OpenLDAP/slapd server to manage the user accounts of our Samba 
server and have recently run into the problem that users cannot connect to 
Samba drives anymore after some time. Samba complains that it cannot connect to 
the LDAP server (see below for error message in Samba log) and the slapd log 
shows

  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: 
(gidNumber) not indexed
  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: 
(gidNumber) not indexed
  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: (uid) 
not indexed
  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: 
(gidNumber) not indexed
  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: 
(sambaSID) not indexed
  Mar 25 11:38:15 office-server slapd[3433]: = bdb_equality_candidates: 
(sambaSID) not indexed
  Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): file 
id2entry.bdb has LSN 1/382892, past end of log at 1/283666
  Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): Commonly 
caused by moving a database from one database environment
  Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): to another 
without clearing the database LSNs, or by removing all of
  Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): the log files 
from a database environment
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): 
DB_ENV-log_flush: LSN of 1/382892 past current end-of-log of 1/283666
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): Database 
environment corrupt; the wrong log files may have been removed or incompatible 
database files imported from another environment
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: 
DB_RUNRECOVERY: Fatal error, run database recovery
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): id2entry.bdb: 
unable to flush page: 5
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): 
DB_ENV-log_flush: LSN of 1/378772 past current end-of-log of 1/283666
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): Database 
environment corrupt; the wrong log files may have been removed or incompatible 
database files imported from another environment
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: 
DB_RUNRECOVERY: Fatal error, run database recovery
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): id2entry.bdb: 
unable to flush page: 7
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): 
DB_ENV-log_flush: LSN of 1/373647 past current end-of-log of 1/283666
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): Database 
environment corrupt; the wrong log files may have been removed or incompatible 
database files imported from another environment
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: 
DB_RUNRECOVERY: Fatal error, run database recovery
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): id2entry.bdb: 
unable to flush page: 8
  Mar 25 11:38:17 office-server slapd[3433]: bdb(dc=foo,dc=org): 
txn_checkpoint: failed to flush the buffer cache: DB_RUNRECOVERY: Fatal error, 
run database recovery
  Mar 25 11:38:51 office-server slapd[3433]: conn=62 op=29 do_search: invalid 
dn (sambaDomainName=,sambaDomainName=foo,dc=foo,dc=org)
  Mar 25 11:38:51 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:39:01 office-server slapd[3433]: last message repeated 26 times
  Mar 25 11:39:01 office-server CRON[3657]: (root) CMD (  [ -x 
/usr/lib/php5/maxlifetime ]  [ -d /var/lib/php5 ]  find /var/lib/php5/ 
-type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
  Mar 25 11:39:14 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:39:47 office-server slapd[3433]: last message repeated 35 times
  Mar 25 11:39:48 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:39:49 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:39:50 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:40:51 office-server slapd[3433]: last message repeated 164 times
  Mar 25 11:40:51 office-server slapd[3433]: last message repeated 3 times
  Mar 25 11:40:52 office-server slapd[3433]: bdb(dc=foo,dc=org): PANIC: fatal 
region error detected; run recovery
  Mar 25 11:41:53 office-server slapd[3433]: last message repeated 294 times

Strangely, restarting slapd helps and users can use Samba again for a limited 
and arbitrary period of time until the problem pops up again. I tried fixing 
the database using

  db4.7_recover  -v -h /var/lib/ldap

but again, the problem pops up again later.

I realized that when I shut down 

Re: Slapd database goes corrupt repeatedly after recovery

2010-03-25 Thread Dieter Kluenter
Kaspar Fischer kaspar.fisc...@baselgovernance.org writes:

 Dear list,

 We are using an OpenLDAP/slapd server to manage the user accounts of
 our Samba server and have recently run into the problem that users
 cannot connect to Samba drives anymore after some time. Samba
 complains that it cannot connect to the LDAP server (see below for
 error message in Samba log) and the slapd log shows
[...]

   Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): file
 id2entry.bdb has LSN 1/382892, past end of log at 1/283666
[...]
 Strangely, restarting slapd helps and users can use Samba again for a
 limited and arbitrary period of time until the problem pops up
 again. I tried fixing the database using

   db4.7_recover -v -h /var/lib/ldap

 but again, the problem pops up again later.
[...]

For some unknown reason the last transaction logfile has been removed,
therefor the database connot be recovered. Unfortunately you have to
rebuild the database

-Dieter

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


RE: Problem with getent passwd

2010-03-25 Thread Lynn York
I attempted to use setup to setup ldap auth.   That did not work.  When
I run getent passwd it prints all the local users, then hangs for about
5 seconds and doesn't print the ldap users.  However, it does query the
ldap server, I can see the queries in the ldap logs.  I have added copies
of my configs with hopes someone can help me more :)

/etc/ldap.conf

base cn=users,dc=ldaptest,dc=com
uri ldap://ldaphost/
binddn cn=mwldap,cn=users,dc=ldaptest,dc=com
bindpw password
scope sub
timelimit 120
bind_policy soft
bind_timelimit 120
idle_timelimit 3600
ssl no
pam_password ad
# nss_ldap configurations
nss_base_passwd cn=users,dc=ldaptest,dc=com?sub
nss_base_shadow
cn=users,dc=ldaptest,dc=com?sub?(objectCategory=users)(uidnumber=*)
nss_base_group
cn=users,dc=ldaptest,dc=com?sub?(objectCategory=group)(gidnumber=*)
nss_map_attribute user SAMACCOUNTNAME
sasl_secprops maxssf=0
#tls_cacertdir /etc/openldap/cacerts

Slapd.conf

##
# database definitions
##
database ldap
suffix  cn=users,dc=ldaptest,dc=com
uri  ldap://ads.ldaptest.com;
overlay rwm
rebind-as-user
chase-referrals no

acl-bind
bindmethod=simple
binddn=cn=mwldap,cn=users,dc=ldaptest,dc=com
credentials=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 for this database
#index objectClass   eq
#index ou,cn,mail,surname,givenname  eq,pres,sub
#index uidNumber,gidNumber,loginShelleq,pres
#index uid,memberUid eq,pres,sub
#index nisMapName,nisMapEntryeq,pres,sub

rwm-map objectclass posixAccount organizationalPerson
rwm-map attribute uid sAMAccountname
rwm-map attribute uidNumber uidNumber
rwm-map attribute gidNumber gidNumber
rwm-map attribute givenName cn
rwm-map attribute unixHomeDirectory homeDirectory
rwm-map attribute unixUserPassword UserPassword



Any help is greatly appreciated...
-Original Message-
From: Tyler Gates [mailto:tgate...@gmail.com]
Sent: Wednesday, March 24, 2010 9:31 PM
To: Lynn York; openldap-technical@openldap.org
Subject: Re: Problem with getent passwd

Actually I misspoke earlier -I meant run the command 'setup' from the
terminal and select authentication. From there you should see User
Information and Authentication columns. Just check LDAP in User
Information and you should see getent populate the passwords.
That normally does the trick.. pretty simple but if that doesn't work
I'd check your /etc/ldap.conf is setup correctly (I mostly have to just
add the host information and base dn). Other wise your LDAP server
doesn't have the attributes its' expecting from its queries to generate
user account information.

On 03/24/2010 08:09 AM, Lynn York wrote:
 Here is my /etc/pam.d/system-auth file



 cat /etc/pam.d/system-auth

 #%PAM-1.0

 # This file is auto-generated.

 # User changes will be destroyed the next time authconfig is run.

 authrequired  pam_env.so

 authsufficientpam_unix.so nullok try_first_pass

 authrequisite pam_succeed_if.so uid = 500 quiet

 authsufficientpam_ldap.so use_first_pass

 authrequired  pam_deny.so



 account required  pam_unix.so broken_shadow

 account sufficientpam_succeed_if.so uid  500 quiet

 account [default=bad success=ok user_unknown=ignore] pam_ldap.so

 account required  pam_permit.so



 passwordrequisite pam_cracklib.so try_first_pass retry=3

 passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
 use_authtok

 passwordsufficientpam_ldap.so use_authtok

 passwordrequired  pam_deny.so



 session optional  pam_keyinit.so revoke

 session required  pam_limits.so

 session [success=1 default=ignore] pam_succeed_if.so service in
crond
 quiet use_uid

 session required  pam_unix.so

 session optional  pam_ldap.so





 Also, when I ran authconfig, that didn't help.  The server still queries
the
 ldap server, but the users don't actually show when I run getent
passwd...
 could it be something with the rwm mappings?



 *From:* Tyler Gates [mailto:tgate...@gmail.com]
 *Sent:* Tuesday, March 23, 2010 8:26 PM
 *To:* Lynn York
 *Subject:* Re: Problem with getent passwd



 Sounds like it's a problem with your client side pam_ldap
authentication.
 There's a whole buch of steps to get that working, just google it. If
you
 have a redhat variant authconfig or setup will step you through it. It
would
 help if you could post your system_auth file.

 On Mar 23, 2010, at 11:40 AM, Lynn York lynn.y...@mavenwire.com wrote:

  Hello,



 When I issue getent passwd I can see it query the ldap
 server for all the information and the server is returning the 

Re: Slapd database goes corrupt repeatedly after recovery

2010-03-25 Thread Kaspar Fischer
On 25.03.2010, at 14:27, Dieter Kluenter wrote:

 Kaspar Fischer kaspar.fisc...@org writes:
 
 Dear list,
 
 We are using an OpenLDAP/slapd server to manage the user accounts of
 our Samba server and have recently run into the problem that users
 cannot connect to Samba drives anymore after some time. Samba
 complains that it cannot connect to the LDAP server (see below for
 error message in Samba log) and the slapd log shows
 [...]
 
  Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): file
 id2entry.bdb has LSN 1/382892, past end of log at 1/283666
 [...]
 Strangely, restarting slapd helps and users can use Samba again for a
 limited and arbitrary period of time until the problem pops up
 again. I tried fixing the database using
 
  db4.7_recover -v -h /var/lib/ldap
 
 but again, the problem pops up again later.
 [...]
 
 For some unknown reason the last transaction logfile has been removed,
 therefor the database connot be recovered. Unfortunately you have to
 rebuild the database
 
 -Dieter

Dieter,

First of all, thanks for your prompt and helpful reply!

I have just rebuild the database and will check now whether that did it.

For the sake of completeness (for others with similar problems), here's how I 
rebuilt the db:

  /etc/init.d/slapd stop
  slapcat -l slapd-export.ldif -f /etc/ldap/slapd.conf -b dc=foo,dc=org
  rm -fr /var/lib/ldap/ # make sure this IS the path to your db as specified in 
slapd.conf
  mkdir /var/lib/ldap/
  chgrp -R openldap /var/lib/ldap/; chown -R openldap /var/lib/ldap/
  /etc/init.d/slapd start # creates an empty db
  /etc/init.d/slapd stop
  slapadd -l slapd-export.ldif -f /etc/ldap/slapd.conf -b dc=foo,dc=org
  chgrp -R openldap /var/lib/ldap/; chown -R openldap /var/lib/ldap/
  /etc/init.d/slapd start

Best,
Kaspar

Re: Problem with getent passwd

2010-03-25 Thread Benjamin Griese
Hi,
could you please also provide the appropriate log entries that show the
query to the slapd from the client?

thanks

On Thu, Mar 25, 2010 at 13:52, Lynn York lynn.y...@mavenwire.com wrote:

 I attempted to use setup to setup ldap auth.   That did not work.  When
 I run getent passwd it prints all the local users, then hangs for about
 5 seconds and doesn't print the ldap users.  However, it does query the
 ldap server, I can see the queries in the ldap logs.  I have added copies
 of my configs with hopes someone can help me more :)

 /etc/ldap.conf
 
 base cn=users,dc=ldaptest,dc=com
 uri ldap://ldaphost/
 binddn cn=mwldap,cn=users,dc=ldaptest,dc=com
 bindpw password
 scope sub
 timelimit 120
 bind_policy soft
 bind_timelimit 120
 idle_timelimit 3600
 ssl no
 pam_password ad
 # nss_ldap configurations
 nss_base_passwd cn=users,dc=ldaptest,dc=com?sub
 nss_base_shadow
 cn=users,dc=ldaptest,dc=com?sub?(objectCategory=users)(uidnumber=*)
 nss_base_group
 cn=users,dc=ldaptest,dc=com?sub?(objectCategory=group)(gidnumber=*)
 nss_map_attribute user SAMACCOUNTNAME
 sasl_secprops maxssf=0
 #tls_cacertdir /etc/openldap/cacerts

 Slapd.conf
 
 ##
 # database definitions
 ##
 database ldap
 suffix  cn=users,dc=ldaptest,dc=com
 uri  ldap://ads.ldaptest.com;
 overlay rwm
 rebind-as-user
 chase-referrals no

 acl-bind
bindmethod=simple
binddn=cn=mwldap,cn=users,dc=ldaptest,dc=com
credentials=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 for this database
 #index objectClass   eq
 #index ou,cn,mail,surname,givenname  eq,pres,sub
 #index uidNumber,gidNumber,loginShelleq,pres
 #index uid,memberUid eq,pres,sub
 #index nisMapName,nisMapEntryeq,pres,sub

 rwm-map objectclass posixAccount organizationalPerson
 rwm-map attribute uid sAMAccountname
 rwm-map attribute uidNumber uidNumber
 rwm-map attribute gidNumber gidNumber
 rwm-map attribute givenName cn
 rwm-map attribute unixHomeDirectory homeDirectory
 rwm-map attribute unixUserPassword UserPassword



 Any help is greatly appreciated...
 -Original Message-
 From: Tyler Gates [mailto:tgate...@gmail.com]
 Sent: Wednesday, March 24, 2010 9:31 PM
 To: Lynn York; openldap-technical@openldap.org
 Subject: Re: Problem with getent passwd

 Actually I misspoke earlier -I meant run the command 'setup' from the
 terminal and select authentication. From there you should see User
 Information and Authentication columns. Just check LDAP in User
 Information and you should see getent populate the passwords.
 That normally does the trick.. pretty simple but if that doesn't work
 I'd check your /etc/ldap.conf is setup correctly (I mostly have to just
 add the host information and base dn). Other wise your LDAP server
 doesn't have the attributes its' expecting from its queries to generate
 user account information.

 On 03/24/2010 08:09 AM, Lynn York wrote:
  Here is my /etc/pam.d/system-auth file
 
 
 
  cat /etc/pam.d/system-auth
 
  #%PAM-1.0
 
  # This file is auto-generated.
 
  # User changes will be destroyed the next time authconfig is run.
 
  authrequired  pam_env.so
 
  authsufficientpam_unix.so nullok try_first_pass
 
  authrequisite pam_succeed_if.so uid = 500 quiet
 
  authsufficientpam_ldap.so use_first_pass
 
  authrequired  pam_deny.so
 
 
 
  account required  pam_unix.so broken_shadow
 
  account sufficientpam_succeed_if.so uid  500 quiet
 
  account [default=bad success=ok user_unknown=ignore] pam_ldap.so
 
  account required  pam_permit.so
 
 
 
  passwordrequisite pam_cracklib.so try_first_pass retry=3
 
  passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
  use_authtok
 
  passwordsufficientpam_ldap.so use_authtok
 
  passwordrequired  pam_deny.so
 
 
 
  session optional  pam_keyinit.so revoke
 
  session required  pam_limits.so
 
  session [success=1 default=ignore] pam_succeed_if.so service in
 crond
  quiet use_uid
 
  session required  pam_unix.so
 
  session optional  pam_ldap.so
 
 
 
 
 
  Also, when I ran authconfig, that didn't help.  The server still queries
 the
  ldap server, but the users don't actually show when I run getent
 passwd...
  could it be something with the rwm mappings?
 
 
 
  *From:* Tyler Gates [mailto:tgate...@gmail.com]
  *Sent:* Tuesday, March 23, 2010 8:26 PM
  *To:* Lynn York
  *Subject:* Re: Problem with getent passwd
 
 
 
  Sounds like it's a problem with your client side pam_ldap
 authentication.
  There's a whole buch of steps to get that working, just google it. If
 you
  

Re: Slapd database goes corrupt repeatedly after recovery

2010-03-25 Thread Quanah Gibson-Mount
--On Thursday, March 25, 2010 4:06 PM +0100 Kaspar Fischer 
kaspar.fisc...@baselgovernance.org wrote:



On 25.03.2010, at 14:27, Dieter Kluenter wrote:


Kaspar Fischer kaspar.fisc...@org writes:


Dear list,

We are using an OpenLDAP/slapd server to manage the user accounts of
our Samba server and have recently run into the problem that users
cannot connect to Samba drives anymore after some time. Samba
complains that it cannot connect to the LDAP server (see below for
error message in Samba log) and the slapd log shows

[...]


 Mar 25 11:38:15 office-server slapd[3433]: bdb(dc=foo,dc=org): file
id2entry.bdb has LSN 1/382892, past end of log at 1/283666

[...]

Strangely, restarting slapd helps and users can use Samba again for a
limited and arbitrary period of time until the problem pops up
again. I tried fixing the database using

 db4.7_recover -v -h /var/lib/ldap

but again, the problem pops up again later.

[...]

For some unknown reason the last transaction logfile has been removed,
therefor the database connot be recovered. Unfortunately you have to
rebuild the database

-Dieter


Dieter,

First of all, thanks for your prompt and helpful reply!

I have just rebuild the database and will check now whether that did it.

For the sake of completeness (for others with similar problems), here's
how I rebuilt the db:

  /etc/init.d/slapd stop
  slapcat -l slapd-export.ldif -f /etc/ldap/slapd.conf -b dc=foo,dc=org
  rm -fr /var/lib/ldap/ # make sure this IS the path to your db as
specified in slapd.conf   mkdir /var/lib/ldap/
  chgrp -R openldap /var/lib/ldap/; chown -R openldap /var/lib/ldap/


These next two steps are wrong.  slapadd will create the database.


  /etc/init.d/slapd start # creates an empty db
  /etc/init.d/slapd stop



--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


Re: Problem with getent passwd

2010-03-25 Thread Tyler Gates
Looks like you are only logging conn and acl. Try config and stats for
more useful information about what exactly is being queried and returned.


On 03/25/2010 01:29 PM, Lynn York wrote:
 Below is part of the log from slapd….



 Mar 25 13:25:16 hltraindb01 slapd[28836]:  dnPrettyNormal: CN=Lynn
 Testing,CN=Users,dc=ldaptest,DC=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]:  dnPrettyNormal: cn=Lynn
 Testing,cn=Users,dc=ldaptest,dc=com, cn=lynn
 testing,cn=users,dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: [rw] searchEntryDN: cn=Lynn
 Testing,cn=Users,dc=ldaptest,dc=com - cn=Lynn
 Testing,cn=Users,dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = send_search_entry: conn 3
 dn=cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access to
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com entry requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = dn: [1] dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] matched

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter

 Mar 25 13:25:16 hltraindb01 slapd[28836]: PRESENT

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: search access
 to cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com objectClass requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter 6

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] attr entry

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: access to entry
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com, attr entry requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: to all values by
 cn=mwldap,cn=users,dc=ldaptest,dc=com, (=0)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = check a_dn_pat: users

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] applying
 read(=rscxd) (stop)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] mask:
 read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access
 granted by read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access to
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com objectClass requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = dn: [1] dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] matched

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter

 Mar 25 13:25:16 hltraindb01 slapd[28836]: PRESENT

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: search access
 to cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com objectClass requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter 6

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] attr objectClass

 Mar 25 13:25:16 hltraindb01 slapd[28836]: access_allowed: no res from state
 (objectClass)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: access to entry
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com, attr objectClass requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: to value by
 cn=mwldap,cn=users,dc=ldaptest,dc=com, (=0)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = check a_dn_pat: users

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] applying
 read(=rscxd) (stop)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] mask:
 read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access
 granted by read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access to
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com uid requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = dn: [1] dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] matched

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter

 Mar 25 13:25:16 hltraindb01 slapd[28836]: PRESENT

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: search access
 to cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com objectClass requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = test_filter 6

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: [1] attr uid

 Mar 25 13:25:16 hltraindb01 slapd[28836]: access_allowed: no res from state
 (uid)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: access to entry
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com, attr uid requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: to value by
 cn=mwldap,cn=users,dc=ldaptest,dc=com, (=0)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = check a_dn_pat: users

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] applying
 read(=rscxd) (stop)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_mask: [1] mask:
 read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access
 granted by read(=rscxd)

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = access_allowed: read access to
 cn=Lynn Testing,cn=Users,dc=ldaptest,dc=com uidNumber requested

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = dn: [1] dc=ldaptest,dc=com

 Mar 25 13:25:16 hltraindb01 slapd[28836]: = acl_get: 

Re: tls private key

2010-03-25 Thread Alexander Samad
On Wed, Mar 24, 2010 at 4:02 AM, Chris Jacobs
chris.jac...@apollogrp.edu wrote:
 Alexander,

Just Alex :) (getting used to google mail) Alexander reminds me of
being in trouble from the parents


 I don't know if they only get read at startup or not... but it does bring up 
 the question: Why?

I would like to have another layer of protection on the machine /
certificates. I would have thought it would have been a quick and easy
question - yes I could go and read the src,  but.

 Protect the file with chmod 440 permissions (with root/root or ldap/ldap or 
 whatever the user/group you use to run slapd).

yep I do, root.openldap (debian)


 If there are others with root permission to this box that shouldn't or you 
 don't want to have access to these files - you /really should/ fix that issue 
 first.  Then trust the file system permissions to do their job.

so why allow for encrypted private keys :)


 Sadly, I suspect though that you're dead set on keeping the certs password 
 protected, and won't be doing the above.

The above is already done.


 However, you could always just /try/ - if it works, then you know the answer. 
  Just get used to restarting/starting slapd being a needless PITA.

not sure where you got the idea I haven't already done this ?

And I am note sure why its bad to look for another layer of security




 Thanks,
 - chris

 -Original Message-
 From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.org 
 [mailto:openldap-technical-bounces+chris.jacobs=apollogrp@openldap.org] 
 On Behalf Of Alexander Samad
 Sent: Monday, March 22, 2010 11:21 PM
 To: openldap-technical@openldap.org
 Subject: Fwd: tls private key

 Hi

 THought I would re ask, do certificates only get read at start up, I store my 
 cert's with password, can i unpassword protect and then start slapd and then 
 remove the unpassworded cert private file ?

 will this be okay until such a time as slapd get restart ?

 Alex


 -- Forwarded message --
 From: Alex Samad a...@samad.com.au
 Date: Sat, Jan 16, 2010 at 6:03 PM
 Subject: tls private key
 To: openldap-technical@openldap.org


 Hi


 I am setting up my sync repl to use certificates, my problem is I don't want 
 to leave my private key for the server un encrypted.

 the file pointed to by TLSCertificateKeyFile is is just read at slapd load up 
 time, ie can i unencrypt  the file start slapd and then remove the un 
 encrypted file ?

 Alex


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAktRZMcACgkQkZz88chpJ2MJYQCeIJ5FtSLGRpQJpr1Gco0NSjr8
 VlYAnRmvR+YgJTplXoiX9Xsp+JgQH5VH
 =iN8i
 -END PGP SIGNATURE-

 This message is private and confidential. If you have received it in error, 
 please notify the sender and remove it from your system.





Re: tls private key

2010-03-25 Thread Tyler Gates

Alex,
  encrypting the private key really isn't necessary and I highly  
doubt it would work for your application nor be worth the hassel.  
Securing via file permisssions as mentioned previously is really the  
best way to tackle this. Think of 'other layers of protection' being  
firewalls, intrusion detection, restricted logins, chroot jails, etc.,  
etc...
Encryption really works best for UDP like transportation like email  
where you cannot guarantee the recipient is the only person able to  
'see' the document ;)


On Mar 25, 2010, at 6:32 PM, Alexander Samad a...@samad.com.au wrote:


On Wed, Mar 24, 2010 at 4:02 AM, Chris Jacobs
chris.jac...@apollogrp.edu wrote:

Alexander,


Just Alex :) (getting used to google mail) Alexander reminds me of
being in trouble from the parents



I don't know if they only get read at startup or not... but it does  
bring up the question: Why?


I would like to have another layer of protection on the machine /
certificates. I would have thought it would have been a quick and easy
question - yes I could go and read the src,  but.


Protect the file with chmod 440 permissions (with root/root or ldap/ 
ldap or whatever the user/group you use to run slapd).


yep I do, root.openldap (debian)



If there are others with root permission to this box that shouldn't  
or you don't want to have access to these files - you /really  
should/ fix that issue first.  Then trust the file system  
permissions to do their job.


so why allow for encrypted private keys :)



Sadly, I suspect though that you're dead set on keeping the certs  
password protected, and won't be doing the above.


The above is already done.



However, you could always just /try/ - if it works, then you know  
the answer.  Just get used to restarting/starting slapd being a  
needless PITA.


not sure where you got the idea I haven't already done this ?

And I am note sure why its bad to look for another layer of security





Thanks,
- chris

-Original Message-
From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.org 
 [mailto:openldap-technical-bounces 
+chris.jacobs=apollogrp@openldap.org] On Behalf Of Alexander  
Samad

Sent: Monday, March 22, 2010 11:21 PM
To: openldap-technical@openldap.org
Subject: Fwd: tls private key

Hi

THought I would re ask, do certificates only get read at start up,  
I store my cert's with password, can i unpassword protect and then  
start slapd and then remove the unpassworded cert private file ?


will this be okay until such a time as slapd get restart ?

Alex


-- Forwarded message --
From: Alex Samad a...@samad.com.au
Date: Sat, Jan 16, 2010 at 6:03 PM
Subject: tls private key
To: openldap-technical@openldap.org


Hi


I am setting up my sync repl to use certificates, my problem is I  
don't want to leave my private key for the server un encrypted.


the file pointed to by TLSCertificateKeyFile is is just read at  
slapd load up time, ie can i unencrypt  the file start slapd and  
then remove the un encrypted file ?


Alex


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktRZMcACgkQkZz88chpJ2MJYQCeIJ5FtSLGRpQJpr1Gco0NSjr8
VlYAnRmvR+YgJTplXoiX9Xsp+JgQH5VH
=iN8i
-END PGP SIGNATURE-

This message is private and confidential. If you have received it  
in error, please notify the sender and remove it from your system.






Re: tls private key

2010-03-25 Thread Howard Chu

Chris Jacobs wrote:

There's one sure fire way to find out...

Start it up with a syncrepl, then move the private key, and see if it syncs 
fine both ways.

Wait a day or so, and make a change and see if that synced.

If I had to put a dollar on it, if guess that it doesn't need the key
after

startup. I could be horribly wrong though - I'm not a dev, just a user of the
software.

It probably depends on which crypto library you built with. I'm pretty sure 
OpenSSL and GnuTLS cache the PEM credentials in memory. Not sure what MozNSS 
does. And of course, if you're paranoid, you can build these libraries to use 
smart tokens and leave the credentials there instead.


:)

- chris

Chris Jacobs, Jr. Unix System Administrator
Apollo Group  |  Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
email: chris.jac...@apollogrp.edu

- Original Message -
From: 
openldap-technical-bounces+chris.jacobs=apollogrp@openldap.orgopenldap-technical-bounces+chris.jacobs=apollogrp@openldap.org
To: openldap-technical@openldap.orgopenldap-technical@openldap.org
Sent: Thu Mar 25 18:44:47 2010
Subject: Re: tls private key

HI

On Fri, Mar 26, 2010 at 12:09 PM, Tyler Gatestgate...@gmail.com  wrote:

Alex,
  encrypting the private key really isn't necessary and I highly doubt it
would work for your application nor be worth the hassel. Securing via file
permisssions as mentioned previously is really the best way to tackle this.
Think of 'other layers of protection' being firewalls, intrusion detection,
restricted logins, chroot jails, etc., etc...


yep go those, firewalls, permissions etc.

I am not sure why every one is against me trying to use another layer
of protection, just because I permission it as root.root 440, doesn't
mean its safe. I could make it safer, but unecrypting the private key,
starting slapd and removing the unecrypted file.

Or thing of it another way, my private key could be on a usb key, that
i insert into the machine on start up and remove once slapd has
started.

I have seen secure machine compromised before, somebody installed cvs
forgot to change the cvs userid password, root hack and a remote user
had access to the system.  Some times people do silly things

on my laptop - I encrypt the fs and the swap space and my gpg key have
userid/passwords and my certs have userid password protection, like to
do the same for my ldap setup as well :)

I understand the reasons for encrypting and signing packets or
information, just asking if slapd needs access to the private key
after it has read the file on startup.


Encryption really works best for UDP like transportation like email where
you cannot guarantee the recipient is the only person able to 'see' the
document ;)


[snip]


This message is private and confidential. If you have received it in error, 
please notify the sender and remove it from your system.





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