Re: Windows SSPI, NTLMSSP and OpenLDAP with SASL/GSSAPI
by Howard Chu
Diego Morales wrote:
> Hello,
>
> I have a proprietary windows application trying to bind on my OpenLDAP
> server using GSSAPI with NTLMSSP mechanism, instead of Kerberos. Is it
> possible to support this on a (unix) OpenLDAP server?
Yes, but this has nothing to do with OpenLDAP software. All of SASL/GSSAPI is
handled by the Cyrus SASL library. The Cyrus GSSAPI implementation depends on
the underlying GSSAPI library, which may be provided by MIT Kerberos or
Heimdal Kerberos. The Heimdal library definitely supports GSSAPI/NTLMSSP, I'm
not sure if the MIT library does or not.
It sounds like your installation is not using Heimdal.
> Another option would be to make the software use GSSAPI + Kerberos
> instead. Let me further explain:
>
> I have a working samba + openldap setup with many windows
> workstations. The said proprietary app has LDAP auth support, and
> according to its maker it works with Active Directory and Novell NDS.
> It does not support simple bind, nor LDAPS, (and probably not StartTLS
> either). We don't have access to the app's source code and help from
> its developers/tech-support is pretty unavailable.
>
> Checking slapd's debug, we saw the app trying to use SASL+GSSAPI to
> bind. So we went on and configured a minimal Kerberos setup and
> SASL+GSSAPI support for OpenLDAP on a test ldap server. It seems to be
> working perfectly. We acquire a ticket and run ldapsearch from another
> machine using -Y GSSAPI bind and it works. Logs from slapd debug seem
> ok.
>
> But that evil app still fails. Here's a piece from slapd debug log:
>
> conn=1000 op=1 do_bind
> ber_scanf fmt ({imt) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8813 end=0x7f73f6af8856 len=67
> 0000: 60 84 00 00 00 3d 02 01 03 04 00 a3 84 00 00 00 `....=..........
> 0010: 32 04 06 47 53 53 41 50 49 04 28 4e 54 4c 4d 53 2..GSSAPI.(NTLMS
> 0020: 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 SP..............
> 0030: 00 00 00 00 00 00 00 00 00 00 00 06 01 b1 1d 00 ................
> 0040: 00 00 0f ...
> ber_scanf fmt ({m) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af881e end=0x7f73f6af8856 len=56
> 0000: 00 84 00 00 00 32 04 06 47 53 53 41 50 49 04 28 .....2..GSSAPI.(
> 0010: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 NTLMSSP.........
> 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0030: 06 01 b1 1d 00 00 00 0f ........
> ber_scanf fmt (m) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af882c end=0x7f73f6af8856 len=42
> 0000: 00 28 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 .(NTLMSSP.......
> 0010: 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 0020: 00 00 06 01 b1 1d 00 00 00 0f ..........
> ber_scanf fmt (}}) ber:
> ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8856 end=0x7f73f6af8856 len=0
>
>>>> dnPrettyNormal: <>
> <<< dnPrettyNormal: <>, <>
> conn=1000 op=1 BIND dn="" method=163
> do_bind: dn () SASL mech GSSAPI
> ==> sasl_bind: dn="" mech=GSSAPI datalen=40
> SASL [conn=1000] Failure: GSSAPI Error: An unsupported mechanism was
> requested (Unknown error)
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_result: err=49 matched="" text="SASL(-13): authentication
> failure: GSSAPI Failure: gss_accept_sec_context"
> send_ldap_response: msgid=11 tag=97 err=49
> ber_flush2: 87 bytes to sd 13
> 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
> 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
> 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
> 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
> 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
> 0050: 63 6f 6e 74 65 78 74 context
> ldap_write: want=87, written=87
> 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA
> 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent
> 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure:
> 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure:
> 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_
> 0050: 63 6f 6e 74 65 78 74 context
> conn=1000 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication
> failure: GSSAPI Failure: gss_accept_sec_context
>
> (btw, this is slapd 2.4.21, from a 10.04 ubuntu package)
>
> I believe the application uses Windows SSPI, and I known SSPI supports
> several GSSAPI mechanisms, including NTLMSSP and Kerberos. I'm afraid
> Windows is auto selecting NTLMSSP cause its running on a pre-windows
> 2000 domain (non AD, in this case, Samba). Hoping to make windows use
> Kerberos instead, I've also tried publishing some SRV records on DNS.
> I have sniffed DNS queries from the workstation while the app tries to
> login, caught only one _ldap._tcp SRV request, registered that ... and
> nothing has changed.
>
> I don't know how could I force the app to use GSSAPI + kerberos
> without touching its source code. And I can't find much about a unix
> NTLM(SSP)-as-a-mechanism-of-GSSAPI implementation. Maybe there's
> something inside samba4 or in Likewise software, but I haven't found
> it yet.
>
> So ... does somebody have any advice or info?
>
> Thanks in advance,
>
>
> Diego Morales
> +55 (51) 3024-3568
> Propus Informática LTDA.
> http://www.propus.com.br
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
Re: openldap 2.4(slave) replication to openldap2.3(provider not working
by Andrew Belford
I have modified my slapd.conf file on consumer 2.4
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
#include /usr/share/doc/krb5-server-ldap-1.9/kerberos.schema
#include /usr/share/doc/sudo-1.8.5-1.el6/schema.OpenLDAP
# Primary database.
database bdb
directory /var/lib/ldap
suffix "dc=kinect,dc=co,dc=nz"
rootdn "cn=Manager,dc=kinect,dc=co,dc=nz"
rootpw {SSHA}vO/5mpk4CMOKDelv36BpjksRaHFjgqh1
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# syncrepl specific indices
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryUUID eq
index entryCSN eq
# syncrepl directives
syncrepl rid=3
provider=ldap://testaaa-int.dcnztest.co.nz:389
bindmethod=simple
starttls=no
binddn="cn=sync,dc=kinect,dc=co,dc=nz"
credentials="ieLeik8v"
searchbase="dc=kinect,dc=co,dc=nz"
logbase="cn=accesslog"
schemachecking=off
type=refreshAndPersist
retry="05 +"
syncdata=accesslog
# Refer updates to the master
updateref ldap://testaaa-int.dcnztest.co.nz
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
access to attrs=userPassword by self write by * auth
access to dn.base=dc=kinect,dc=co,dc=nz by * search
by * none
# Give access to this database to serveral important users.
#to dn.subtree="dc=kinect,dc=co,dc=nz"
access to attrs=userPassword
by dn.exact="cn=sync,dc=kinect,dc=co,dc=nz" read
by dn.exact="uid=client-root,ou=auth,dc=kinect,dc=co,dc=nz" write
by self write
by anonymous auth
by * none
# default allow all
access to *
by self write
by users read
by anonymous read
TLSCACertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateFile /etc/openldap/tls/test02aaa.pem
TLSCertificateKeyFile /etc/openldap/tls/test02aaa-key.pem
database monitor
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none
# Configure the config backend.
database config
# Again, let SASL EXTERNAL users with UID 0 & GID 0 users and the rootdn
manage
# the configuration. But not any other users.
access to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn.base="cn=admin,dc=kinect,dc=co,dc=nz" manage
by * none
Then run
#slapcat -f ldap/slap.conf.consumer -F /tmp/ldap -n 0
#cp -rp ldap/cn\=config* /etc/openldap/slapd.d/
#chown -R ldap:ldap /etc/openldap/slapd.d
#slaptest -uF /etc/openldap/slapd.d
#/etc/init.d/slapd start
Now it comes up with a different error
Mar 20 11:52:31 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:31 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:36 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:41 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:46 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:51 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: syncrepl_message_to_entry: rid=003
mods check (objectClass: value #2 invalid per syntax)
Mar 20 11:52:56 vm-nix-t01 slapd[13445]: do_syncrepl: rid=003 rc 21 retrying
This is the value of objectclass in /etc/openldap/slapd.d/
/root@vm-nix-t01 tmp]# grep -iR objectclass /etc/openldap/slapd.d/*
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass:
olcDatabaseConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:objectClass:
olcBdbConfig
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif: objectclass=*)"
searchbase="dc=kinect,dc=co,dc=nz" logbase="cn=accesslog" sco
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:olcDbIndex:
objectClass pres,eq
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:structuralObjectClass:
olcBdbConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:objectClass: olcSchemaConfig
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmObjectClasses 1.3.6.1.4.1.4203.666.3.16
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmSubSystemObjectClasses olmObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmGenericObjectClasses olmSubSystemObjectClasses:0
/etc/openldap/slapd.d/cn=config/cn=schema.ldif:olcObjectIdentifier:
olmDatabaseObjectClasses olmSubSystemObjectClasses:1
Any suggestions
On 18 March 2014 18:40, Philip Guenther <pguenther(a)proofpoint.com> wrote:
> On Mon, 17 Mar 2014, Andrew Belford wrote:
> > I have just registered on the mail list seeking for assistance of how to
> > get openldap replication working between 2.3 and 2.4 openldap.
>
> Time to read the "Changes Since Previous Release" section of the 2.4 admin
> guide:
> http://www.openldap.org/doc/admin24/appendix-changes.html
>
>
> > My provider is running on 2.3(openldap) which replicates successfully
> > to a 2.3(openldap slave). Recently we build a rhel6 host that comes
> > with openldap 2.4 with the intention to run openldap on it as slave.
> >
> > I have stand up the new slave(2.4 openldap) using the same configuration
> of
> > the other running slave(2.3openldap)
> > I have managed to slapadd the ldif of the master to the new slave
> > slapadd -l /tmp/AAA01_20140314.ldif
> >
> > However, if I try and search for entries, it shows the following but I am
> > expecting 32K objects
>
> Item B.2 at
> http://www.openldap.org/doc/admin24/appendix-upgrading.html
> ?
>
>
> > I also don't see any replication details in /var/log/slapd.log
>
> Since you don't mention how you configured replication to this 2.4 box or
> what output you were expecting, I can't help on this.
>
>
> Philip Guenther
>
11 years, 2 months
openldap 2.4.23 hangs
by rwsmith＠bislink.net
Hi,
Not sure if I should post this here or with the CentOS mailing list (I am hoping
they are monitoring this). I am using a stock CentOS 6.3 32-bit installation
with
# rpm -qa | grep openldap
openldap-devel-2.4.23-26.el6_3.2.i686
openldap-2.4.23-26.el6_3.2.i686
openldap-clients-2.4.23-26.el6_3.2.i686
openldap-servers-2.4.23-26.el6_3.2.i686
I have a 4-way multi-master sync replication set up on four virtual servers
using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one
machine and BDC on the other three. All servers are also running sssd-1.8.0 for
the Linux authentication.
The problem is that one or more of the LDAP servers will hang, usually the one
that acts as the PDC, since this is hit the hardest and is the more critical of
the four. Usually but not always the "hang" will trickle to the other
servers--usually when I am not watching during the middle of the night.
Fortunately we are not yet in full production.
Compiling from source is not yet an option. I must use the stock RPMs from
CentOS per our design guidelines.
LDAP will appear to hang but what appears to be happening is that only the
listener becomes busy and will not get out this state. Here is a short pull of
the logs that I am collecting:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS
Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text=
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:44 auth-us slapd[10357]: 69r
Aug 14 20:34:44 auth-us slapd[10357]:
Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]: 39r
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:34:54 auth-us slapd[10357]:
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:12 auth-us slapd[10357]: 42r
Aug 14 20:35:12 auth-us slapd[10357]:
Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor
Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on:
Aug 14 20:35:14 auth-us slapd[10357]: 40r
Aug 14 20:35:14 auth-us slapd[10357]:
Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy
Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
tvp=zero
Every log entry prior to this looks normal in that epoll: listen=7 goes between
active_threads=0 to busy when a connection comes in, sets up the connection, and
then goes back to active_threads=0. I have yet to understand what is going on to
cause it to go into the busy state and never to return until I manually stop and
restart the slapd process. It does appear however that slapd can still process
any queries on active connections as noted on descriptors 40r and 42r--it just
can't process any new connection requests as epoll: listen=7 has hung.
Looking through the archives this problem still appears to be present in a few
additional later releases but I have not found any thread yet which points to a
specific solution or patch that fixes this problem. Unless I can point to a
specific solution and/or patch I won't get approval to do a pull from the latest
source and compile--I'll have to stick with an hourly cron job that stops and
restart slapd.
Thanks,
Bob Smith
--bs
12 years, 9 months
Re: additional info: objectClasses: value #0 invalid per syntax
by Clément OUDOT
2013/2/28 Jimmy Royer <jimmy.royer(a)modelsolv.com>:
> Hello,
>
> I am starting out with openldap and I don't know it that much. I got
> the error mentioned in the title when trying to add an object class,
> which is apparently a very common one per my google searches. I've
> read that common causes are:
>
> * extraneous white space (especially trailing white space)
> * improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
> * empty values (few syntaxes allow empty values)
>
> This is the object class file I am trying to add, I picked it as an
> example on some website, to have something minimal and make it easier
> to test:
>
> # cat exObjectClasses.ldif
> dn: cn=schema
> changetype: modify
> add: objectClasses
> objectClasses: ( 2.16.840.1.113730.3.2.2.9
> NAME 'blogger'
> DESC 'Someone who has a blog'
> SUP inetOrgPerson STRUCTURAL
> MAY blog )
>
> I've checked if there was any trailing spaces at the end with the following:
>
> # cat -vte exObjectClasses.ldif
> dn: cn=schema$
> changetype: modify$
> add: objectClasses$
> objectClasses: ( 2.16.840.1.113730.3.2.2.9$
> NAME 'blogger'$
> DESC 'Someone who has a blog'$
> SUP inetOrgPerson STRUCTURAL$
> MAY blog )$
>
> I've made sure the file is UTF-8:
>
> # iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8
>
> And I don't think there are any empty values defined in the LDIF file.
> So when I type this command, I still have the "invalid per syntax
> error:
>
> # ldapmodify -x -W -H "ldaps://127.0.0.1" -D
> cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif
> Enter LDAP Password:
> modifying entry "cn=schema"
> ldap_modify: Invalid syntax (21)
> additional info: objectClasses: value #0 invalid per syntax
>
> This is the content of the /etc/openldap/slapd.conf file:
>
> # cat slapd.conf
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
>
> include /etc/openldap/schema/corba.schema
> include /etc/openldap/schema/core.schema
> include /etc/openldap/schema/cosine.schema
> include /etc/openldap/schema/duaconf.schema
> include /etc/openldap/schema/dyngroup.schema
> include /etc/openldap/schema/inetorgperson.schema
> include /etc/openldap/schema/java.schema
> include /etc/openldap/schema/misc.schema
> include /etc/openldap/schema/nis.schema
> include /etc/openldap/schema/openldap.schema
> include /etc/openldap/schema/ppolicy.schema
> include /etc/openldap/schema/collective.schema
>
> # Allow LDAPv2 client connections. This is NOT the default.
> allow bind_v2
>
> # Do not enable referrals until AFTER you have a working directory
> # service AND an understanding of referrals.
> #referral ldap://root.openldap.org
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
>
> # Load dynamic backend modules
> # - modulepath is architecture dependent value (32/64-bit system)
> # - back_sql.la overlay requires openldap-server-sql package
> # - dyngroup.la and dynlist.la cannot be used at the same time
>
> # modulepath /usr/lib/openldap
> # modulepath /usr/lib64/openldap
>
> # moduleload accesslog.la
> # moduleload auditlog.la
> # moduleload back_sql.la
> # moduleload chain.la
> # moduleload collect.la
> # moduleload constraint.la
> # moduleload dds.la
> # moduleload deref.la
> # moduleload dyngroup.la
> # moduleload dynlist.la
> # moduleload memberof.la
> # moduleload pbind.la
> # moduleload pcache.la
> # moduleload ppolicy.la
> # moduleload refint.la
> # moduleload retcode.la
> # moduleload rwm.la
> # moduleload seqmod.la
> # moduleload smbk5pwd.la
> # moduleload sssvlv.la
> # moduleload syncprov.la
> # moduleload translucent.la
> # moduleload unique.la
> # moduleload valsort.la
>
> # The next three lines allow use of TLS for encrypting connections using a
> # dummy test certificate which you can generate by running
> # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk
> # at self-signed certificates, however.
> TLSCACertificatePath /etc/openldap/certs
> TLSCertificateFile "\"OpenLDAP Server\""
> TLSCertificateKeyFile /etc/openldap/certs/password
>
> # 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
>
> # 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!
>
> # enable on-the-fly configuration (cn=config)
> database config
> access to *
> by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
> manage
> by * none
>
> # enable server status monitoring (cn=monitor)
> database monitor
> access to *
> by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
> read
> by dn.exact="cn=Manager,dc=my-domain,dc=com" read
> by * none
>
> #######################################################################
> # database definitions
> #######################################################################
>
> database bdb
> suffix "dc=modelsolv,dc=com"
> checkpoint 1024 15
> rootdn "cn=Manager,dc=modelsolv,dc=com"
> # Cleartext passwords, especially for the rootdn, should
> # be avoided. See slappasswd(8) and slapd.conf(5) for details.
> # Use of strong authentication encouraged.
> rootpw SECRET
> # rootpw {crypt}ijFYNcSNctBYg
>
> # 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,pres
> index ou,cn,mail,surname,givenname eq,pres,sub
> index uidNumber,gidNumber,loginShell eq,pres
> index uid,memberUid eq,pres,sub
> index nisMapName,nisMapEntry eq,pres,sub
>
> # Replicas of this database
> #replogfile /var/lib/ldap/openldap-master-replog
> #replica host=ldap-1.example.com:389 starttls=critical
> # bindmethod=sasl saslmech=GSSAPI
> # authcId=host/ldap-master.example.com(a)EXAMPLE.COM
>
>
> I was able to add a few entries in LDAP so far. So I know I am able to
> reach the server, the connection is fine, and LDAP is somewhat
> functional. But I can't modify the schema with objectclasses.
>
> Is there anything obvious that I am doing wrong? Do you have any
> recommendation for debugging further?
>
Hi,
you can't update schema by acting on cn=subschema branch, this is readonly.
As your are using the old slapd.conf file, you need to create a
.schema file and include it in slapd.conf.
If you want to update schema with LDIF file, change from slapd.conf to
cn=config configuration method.
Clément.
> Regards,
> Jimmy Royer
>
12 years, 3 months
Syncrepl and mmr
by Borresen, John - 0442 - MITLL
All,
The following are excerpts from my multi-master logs and at the end are the cn=config dbase for both systems. I can see that communications are being attempted, but not succeeding. The other day, entries were added to "cn=role2,ou=sudoers,dc=example,dc=ldap" to the Syncrepl...
I have opened up my ACLs (may not be reflected in the cn=config below) for "uid=replicator,ou=Admins,dc=example,dc=ldap" and "cn=ldapadmin,dc=example,dc=ldap". The replicator account is the rootDN for /var/lib/openldap/accesslog with read privs on olcDatabase={1}bdb (primary dbase). The ldapadmin account is the rootDN for the olcDatabase={1}bdb and full write privs on the accesslog dbase.
The olcSyncRepl rids are authenticating to ldapadmin (I removed the binding to replicator for troubleshooting -- alas no affect).
I am hoping some other eyes can see where my mistake(s) are and point me in the correct direction. Honestly, I am not even sure where to start asking questions. If I read the ACLs sections correctly (both in the Admin Guide and man-page), the rootDNs are granted full read/write everywhere privs by default to their respective Databases. So, with that logic I shouldn't have to put the "replicator" in the olcAccess for olcDataBase={2}bdb (accesslog dbase)...only the ldapadmin account should have an entry. Correct? And, I shouldn't have to put the ldapadmin account in the olcAccess for the olcDatabase={1}bdb (primary dbase). Correct?
What am I missing? And where?
MM-SERVER1:
52fce402 PRESENT
52fce402 => access_allowed: search access to "reqStart=20140211203819.000000Z,cn=accesslog" "objectClass" requested
52fce402 => acl_get: [1] attr objectClass
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "objectClass" requested
52fce402 => acl_mask: to all values by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: search access granted by write(=wrscxd)
52fce402 => access_allowed: search access granted by write(=wrscxd)
52fce402 <= test_filter 6
52fce402 => send_search_entry: conn 2109 dn="reqStart=20140211203819.000000Z,cn=accesslog"
52fce402 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "entry" requested
52fce402 => acl_get: [1] attr entry
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "entry" requested
52fce402 => acl_mask: to all values by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: result not in cache (reqType)
52fce402 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqType" requested
52fce402 => acl_get: [1] attr reqType
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqType" requested
52fce402 => acl_mask: to value by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: result not in cache (reqDN)
52fce402 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqDN" requested
52fce402 => acl_get: [1] attr reqDN
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqDN" requested
52fce402 => acl_mask: to value by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: result not in cache (reqMod)
52fce402 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "reqMod" requested
52fce402 => acl_get: [1] attr reqMod
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "reqMod" requested
52fce402 => acl_mask: to value by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: result was in cache (reqMod)
52fce402 => access_allowed: result was in cache (reqMod)
52fce402 => access_allowed: result was in cache (reqMod)
52fce402 => access_allowed: result not in cache (entryCSN)
52fce402 => access_allowed: read access to "reqStart=20140211203819.000000Z,cn=accesslog" "entryCSN" requested
52fce402 => acl_get: [1] attr entryCSN
52fce402 => acl_mask: access to entry "reqStart=20140211203819.000000Z,cn=accesslog", attr "entryCSN" requested
52fce402 => acl_mask: to value by "cn=ldapadmin,dc=example,dc=ldap", (=0)
52fce402 <= check a_dn_pat: uid=replicator,ou=admins,dc=example,dc=ldap
52fce402 <= check a_dn_pat: cn=ldapadmin,dc=example,dc=ldap
52fce402 <= acl_mask: [2] applying write(=wrscxd) (stop)
52fce402 <= acl_mask: [2] mask: write(=wrscxd)
52fce402 => slap_access_allowed: read access granted by write(=wrscxd)
52fce402 => access_allowed: read access granted by write(=wrscxd)
52fce402 conn=2109 op=1 ENTRY dn="reqStart=20140211203819Z,cn=accesslog"
MM-SERVER2:
52fce47a =>do_syncrep2 rid=001
ldap_result ld 0x97b3ed0 msgid 2
wait4msg ld 0x97b3ed0 msgid 2 (infinite timeout)
wait4msg continue ld 0x97b3ed0 msgid 2 all 0
** ld 0x97b3ed0 Connections:
* host: mm-server1.example.ldap port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Feb 13 10:27:54 2014
** ld 0x97b3ed0 Outstanding Requests:
* msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x97b3ed0 request count 1 (abandoned 0)
** ld 0x97b3ed0 Response Queue:
Empty
ld 0x97b3ed0 response count 0
ldap_chkResponseList ld 0x97b3ed0 msgid 2 all 0
ldap_chkResponseList returns ld 0x97b3ed0 NULL
ldap_int_select
read1msg: ld 0x97b3ed0 msgid 2 all 0
ber_get_next
ldap_read: want=8, got=8
0000: 30 81 b2 02 01 02 64 48 0.....dH
ldap_read: want=173, got=173
0000: 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 30 38 ..cn=accesslog08
0010: 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 04 28 06..entryCSN1*.(
0020: 32 30 31 34 30 32 30 33 31 38 33 38 33 31 2e 37 20140203183831.7
0030: 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 30 30 51838Z#000000#00
0040: 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 31 2e 1#000000.c0a..1.
0050: 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 3.6.1.4.1.4203.1
0060: 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 00 04 .9.1.2.E0C......
0070: 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 30 31 <rid=001,sid=001
0080: 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 38 33 ,csn=20140203183
0090: 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 30 30 831.751838Z#0000
00a0: 30 30 23 30 30 31 23 30 30 30 30 30 30 00#001#000000
ber_get_next: tag 0x30 len 178 contents:
ber_dump: buf=0x9764590 ptr=0x9764590 end=0x9764642 len=178
0000: 02 01 02 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 ...dH..cn=access
0010: 6c 6f 67 30 38 30 36 04 08 65 6e 74 72 79 43 53 log0806..entryCS
0020: 4e 31 2a 04 28 32 30 31 34 30 32 30 33 31 38 33 N1*.(20140203183
0030: 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 30 30 831.751838Z#0000
0040: 30 30 23 30 30 31 23 30 30 30 30 30 30 a0 63 30 00#001#000000.c0
0050: 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 a..1.3.6.1.4.1.4
0060: 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 203.1.9.1.2.E0C.
0070: 01 01 04 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 .....<rid=001,si
0080: 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 d=001,csn=201402
0090: 30 33 31 38 33 38 33 31 2e 37 35 31 38 33 38 5a 03183831.751838Z
00a0: 23 30 30 30 30 30 30 23 30 30 31 23 30 30 30 30 #000000#001#0000
00b0: 30 30 00
read1msg: ld 0x97b3ed0 msgid 2 message type search-entry
ber_scanf fmt ({xx) ber:
ber_dump: buf=0x9764590 ptr=0x9764593 end=0x9764642 len=175
0000: 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 dH..cn=accesslog
0010: 30 38 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 0806..entryCSN1*
0020: 04 28 32 30 31 34 30 32 30 33 31 38 33 38 33 31 .(20140203183831
0030: 2e 37 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 .751838Z#000000#
0040: 30 30 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 001#000000.c0a..
0050: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 1.3.6.1.4.1.4203
0060: 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 .1.9.1.2.E0C....
0070: 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 ..<rid=001,sid=0
0080: 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 01,csn=201402031
0090: 38 33 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 83831.751838Z#00
00a0: 30 30 30 30 23 30 30 31 23 30 30 30 30 30 30 0000#001#000000
ber_scanf fmt ({a) ber:
ber_dump: buf=0x9764590 ptr=0x97645df end=0x9764642 len=99
0000: 30 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 0a..1.3.6.1.4.1.
0010: 34 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 4203.1.9.1.2.E0C
0020: 0a 01 01 04 00 04 3c 72 69 64 3d 30 30 31 2c 73 ......<rid=001,s
0030: 69 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 34 30 id=001,csn=20140
0040: 32 30 33 31 38 33 38 33 31 2e 37 35 31 38 33 38 203183831.751838
0050: 5a 23 30 30 30 30 30 30 23 30 30 31 23 30 30 30 Z#000000#001#000
0060: 30 30 30 000
ber_scanf fmt (o) ber:
ber_dump: buf=0x9764590 ptr=0x97645fb end=0x9764642 len=71
0000: 04 45 30 43 0a 01 01 04 00 04 3c 72 69 64 3d 30 .E0C......<rid=0
0010: 30 31 2c 73 69 64 3d 30 30 31 2c 63 73 6e 3d 32 01,sid=001,csn=2
0020: 30 31 34 30 32 30 33 31 38 33 38 33 31 2e 37 35 0140203183831.75
0030: 31 38 33 38 5a 23 30 30 30 30 30 30 23 30 30 31 1838Z#000000#001
0040: 23 30 30 30 30 30 30 #000000
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
ber_dump: buf=0x9764590 ptr=0x9764593 end=0x9764642 len=175
0000: 64 48 04 0c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 dH..cn=accesslog
0010: 30 38 30 36 04 08 65 6e 74 72 79 43 53 4e 31 2a 0806..entryCSN1*
0020: 04 28 32 30 31 34 30 32 30 33 31 38 33 38 33 31 .(20140203183831
0030: 2e 37 35 31 38 33 38 5a 23 30 30 30 30 30 30 23 .751838Z#000000#
0040: 30 30 31 23 30 30 30 30 30 30 a0 63 30 61 04 18 001#000000.c0a..
0050: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 1.3.6.1.4.1.4203
0060: 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 01 01 04 .1.9.1.2.E0C....
0070: 00 04 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 ..<rid=001,sid=0
0080: 30 31 2c 63 73 6e 3d 32 30 31 34 30 32 30 33 31 01,csn=201402031
0090: 38 33 38 33 31 2e 37 35 31 38 33 38 5a 23 30 30 83831.751838Z#00
00a0: 30 30 30 30 23 30 30 31 23 30 30 30 30 30 30 0000#001#000000
ber_scanf fmt ({em) ber:
ber_dump: buf=0x950b980 ptr=0x950b980 end=0x950b9c5 len=69
0000: 30 43 0a 01 01 04 00 04 3c 72 69 64 3d 30 30 31 0C......<rid=001
0010: 2c 73 69 64 3d 30 30 31 2c 63 73 6e 3d 32 30 31 ,sid=001,csn=201
0020: 34 30 32 30 33 31 38 33 38 33 31 2e 37 35 31 38 40203183831.7518
0030: 33 38 5a 23 30 30 30 30 30 30 23 30 30 31 23 30 38Z#000000#001#0
0040: 30 30 30 30 30 00000
52fce47a do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
ldap_msgfree
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 17
0000: 30 05 02 01 03 42 00 0....B.
ldap_write: want=7, written=7
0000: 30 05 02 01 03 42 00 0....B.
ldap_free_connection: actually freed
52fce47a do_syncrepl: rid=001 rc -1 retrying
52fce47a daemon: activity on 1 descriptor
52fce47a daemon: activity on:52fce47a
52fce47a daemon: epoll: listen=7 active_threads=0 tvp=zero
MM-SERVER2:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 1b256f1e-2f15-4538-8a6f-5b021d015e35
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211613.134974Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211613Z
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: 1191cf8f-8d46-4f2e-8aba-e65537210029
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175231Z
entryCSN: 20140129175429.232704Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129175429Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 77451682-9629-4753-9a80-5cc0e69a7482
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: d7f25d3b-7ad1-4625-a577-a23a22b5494d
creatorsName: cn=config
createTimestamp: 20140122200748Z
entryCSN: 20140122200748.381523Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140122200748Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 5a87b5f1-c445-4e0e-ba97-6d2d63093704
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password>
interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password>
interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" read by * none
olcAccess: {1}to * by * read
entryCSN: 20140203200931.503493Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203200931Z
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 04afe1bf-40c7-425a-8b25-74f8687323fc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180447Z
entryCSN: 20140129180447.701059Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180447Z
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 54b5fa00-8244-41d3-923d-0743a10bf192
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180903Z
entryCSN: 20140129180903.479192Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180903Z
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: ff63820b-fbe4-4a65-8c00-99e2cc28fca5
creatorsName: cn=admin,cn=config
createTimestamp: 20140129175923Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190415.581904Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190415Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9246709d-7a9b-41f3-bca8-f665add4e4f2
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180331Z
entryCSN: 20140129180331.702641Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180331Z
MM-SERVER2:
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf
olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d
olcArgsFile: /var/lib/openldap/run/slapd.args
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcPidFile: /var/lib/openldap/run/slapd.pid
olcReadOnly: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
olcWriteTimeout: 0
structuralObjectClass: olcGlobal
entryUUID: 84a58742-a1ce-4714-a743-14daf3f40c75
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcLogLevel: stats
olcSecurity: tls=0
olcServerID: 1 ldap://mm-server1.example.ldap
olcServerID: 2 ldap://mm-server2.example.ldap
entryCSN: 20140131211906.564734Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140131211906Z
contextCSN: 20140206183618.370299Z#000000#002#000000
contextCSN: 20140121211615.993780Z#000000#004#000000
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}syncprov
olcModuleLoad: {1}accesslog
structuralObjectClass: olcModuleList
entryUUID: ab2c7f52-e10f-4233-aa17-ac8b051defcf
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
entryCSN: 20140129182642.147840Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182642Z
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by self write by users read by anonymous auth
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 46ec808c-285f-442f-8c70-d5bb8c2d39de
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 4354a8b6-8a36-4804-81f8-14a8550aef74
creatorsName: cn=config
createTimestamp: 20131218155313Z
entryCSN: 20131218155313.477459Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20131218155313Z
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 644d3984-d125-446e-aae2-1ddc541f4661
creatorsName: cn=admin,cn=config
createTimestamp: 20140121191314Z
entryCSN: 20140121191314.076259Z#000000#004#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140121191314Z
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=example,dc=ldap
olcRootPW:: <password>
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}#set_cachesize 0 268435456 1
olcDbConfig: {17}set_cachesize 0 2147483648 1
olcDbConfig: {18}
olcDbConfig: {19}# Data Directory
olcDbConfig: {20}#set_data_dir db
olcDbConfig: {21}
olcDbConfig: {22}# Archive/deletion
olcDbConfig: {23}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {24}
olcDbConfig: {25}# Transaction Log settings
olcDbConfig: {26}set_lg_regionmax 262144
olcDbConfig: {27}set_lg_bsize 2097152
olcDbConfig: {28}#set_lg_dir logs
olcDbConfig: {29}
olcDbConfig: {30}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezMxfSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: mail eq,sub
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 94ff450b-aa70-4507-9ca6-51cdd740ea3e
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcMirrorMode: TRUE
olcLimits: {0}dn.exact="cn=ldapadmin,dc=example,dc=ldap" size=unlimited time=u
nlimited
olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=si
mple binddn="uid=replicator,ou=Admins,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=no
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by dn.exact="cn=ldapadmin,dc=example,dc=ldap" write by dn.exact="uid=r
eplicator,ou=Admins,dc=example,dc=ldap" read
olcAccess: {1}to * by * read
entryCSN: 20140206183618.370299Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140206183618Z
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {0}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 6e4e1508-5eb9-4372-bbd1-813f859b0acc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182321Z
entryCSN: 20140129182321.004272Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182321Z
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9108e0db-ba9e-4b40-b743-4016c61582bc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129183014Z
entryCSN: 20140129183014.073365Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129183014Z
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/openldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
structuralObjectClass: olcBdbConfig
entryUUID: 9b42a346-de9b-42d5-8a3b-3167f80d4b01
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182320Z
olcAccess: {0}to * by dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" w
rite by * none
olcLimits: {0}dn.exact="uid=replicator,ou=Admins,dc=example,dc=ldap" time.soft
=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcRootDN: uid=replicator,ou=Admins,dc=example,dc=ldap
entryCSN: 20140203190210.968231Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140203190210Z
dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 0366206b-4295-4463-952c-0b233646c24d
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182831Z
entryCSN: 20140129182831.866738Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182831Z
dn: olcDatabase={3}monitor,cn=config
objectClass: olcDatabaseConfig
olcAccess: {0}to dn.children="cn=monitor" by dn.children="cn=admin,cn=config"
read
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig
entryUUID: 691d6dfc-82af-4e12-8f03-be93d5d5436b
creatorsName: cn=admin,cn=config
createTimestamp: 20140114170424Z
entryCSN: 20140114170424.436842Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140114170424Z
olcDatabase: {3}monitor
Thanks in advance,
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Surveillance Systems Group
244 Wood St
Lexington, MA 02420
Ph: (781) 981-1609
Email: john.borresen(a)ll.mit.edu
11 years, 3 months
Re: Security between server and client nodes.
by Raffael Sahli
On 12/02/2011 07:49 AM, Jayavant Patil wrote:
>
>
> On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil
> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>
> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
> >
> >
> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> > >> <jayavant.patil82(a)gmail.com
> <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>
>
> > <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>>> wrote:
> > >>
> > >>
> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>
> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com
> <mailto:public@raffaelsahli.com>>>> wrote:
> > >> >>Hi
> > >>
> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
> > >> >>Please read the manual
> http://www.openldap.org/doc/admin24/tls.html
> > >> >Ok.
> > >>
> > >> >>And tree security:
> > >> >>On my server, a client user can only see his own object:
> > >> >Are you using simple authentication mechanism?
> > >>
> > >> >>Maybe create a rule like this:
> > >> >>access to filter=(objectClass=
> > >> >>simpleSecurityObject)
> > >> >> by self read
> > >> >> by * none
> > >>
> > >> >I am not getting what the ACL rule specifies. Any suggestions?
> > >>
> > >>
> > >> I have two users ldap_6 and ldap_7. I want to restrict a
> user to
> > >> see his own data only.
> > >> In slapd.conf, I specified the rule as follows:
> > >> access to *
> > >> by self write
> > >> by * none
> > >>
> > >> But ldap_6 can see the ldap_7 user entries (or vice
> versa) with
> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> > >>
> > >> Any suggestions?
> > >>
> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>
> wrote:
> > >Yes, that's exactly the rule I wrote above.
> >
> > >access to filter=(objectClass=
> > >simpleSecurityObject)
> > > by self read
> > > by * none
> >
> >
> > >Maybe you have to change the objectClass to posixAccount, or
> both or
> > >whatever....
> >
> > >access to
> > >filter=(|(objectClass=
> simpleSecurityObject)(objectClass=posixAccount))
> > > by self read
> > > by * none
> >
> >
> > >Just add this rule before the global rule "access to *"
> >
> >
> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
> >
> > >And if you search like this with bind "admin dn", you will see
> every
> > >object....
> > >You have to bind with user ldap_6 and not with root
> > But anyway client user knows the admin dn and rootbindpassword. So,
> > with this he will look into all directory information to which he is
> > not supposed to do.
> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
> >
> > So, how to avoid this?
> >
>
>
> >>Why client user knows the admin dn and pw????????
>
> >Because /etc/ldap.conf file on client contains admin dn and pw.
>
> >Each user information in the directory contains the following
> entries(here, e.g. ldap_6)
>
>
> >dn: uid=ldap_6,ou=People,dc=abc,dc=com
> >uid: ldap_6
> >cn: ldap_6
> >sn: ldap_6
> >mail: ldap_6(a)abc.com <mailto:ldap_6@abc.com>
> >objectClass: person
> >objectClass: organizationalPerson
> >objectClass: inetOrgPerson
> >objectClass: posixAccount
> >objectClass: top
> >objectClass: shadowAccount
> >objectClass: hostObject
> >objectClass: simpleSecurityObject
> >shadowLastChange: 13998
> >shadowMax: 99999
> >shadowWarning: 7
> >loginShell: /bin/bash
> >uidNumber: 514
> >gidNumber: 514
> >homeDirectory: /home/ldap_6
> >host: *
> >userPassword::
> e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>
>
> >So, what should be the ACL rule so that each user can see his
> data only? I tried but not getting the required, even the >user
> himself is unable to see his own data.
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
> The user itself is unable to see its own info.
>
> [ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com" "(cn=ldap_6)" -h
> server
> ldap_initialize( ldap://server )
> filter: (cn=ldap_6)
> requesting: All userApplication attributes
> # extended LDIF
> #
> # LDAPv3
> # base <dc=abc,dc=com> with scope subtree
> # filter: (cn=ldap_6)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 32 No such object
>
> # numResponses: 1
>
>
Please inspect the debug log on your slapd server. If you set the log
level to 128 or 256, you will see any error about "32 No such object".
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
13 years, 6 months
cannot rename back-sql tables
by Matthew Hallsworth
Hi list,
I have searched far and wide for a solution to this but cannot find
anywhere where it is possible to configure back-sql as such.
I am trying to interface openldap with a MySQL backend using the
standard back-sql configuration, with one exception - every 'ldap_*'
prefixed table needs to be named 'custom_ldap_*' as we are trying to fit
in LDAP support into an existing product which requires the additional
tables to make this work to conform with existing schema.
What I've found is, I can get the LDAP requests working perfectly via a
test database using standard 'ldap_*' notation, but I cannot for the
life of me get the system to handle different table names properly.
My config file, "/etc/openldap/slapd.conf", on CentOS 5.2 shows the
following:
<snip>
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
#allow bind_v2
loglevel -1
logfile /var/log/ldap.log
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/lib64/openldap
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# 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
# 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!
#######################################################################
# sql definitions for mysql access
#######################################################################
database sql
dbname ldaptest
readonly on
suffix "dc=rams,dc=com,dc=au"
dbuser ldaptest
dbpasswd abc123
subtree_cond "custom_ldap_entries.dn LIKE CONCAT('%',?)"
children_cond "custom_ldap_entries.dn LIKE CONCAT('%',?)"
id_query "SELECT id,keyval,oc_map_id,dn FROM custom_ldap_entries
WHERE dn=?"
oc_query "SELECT
id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM
custom_ldap_oc_mappings"
at_query "SELECT
name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
FROM custom_ldap_attr_mappings WHERE oc_map_id=?"
has_ldapinfo_dn_ru no
lastmod off
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
#database bdb
#suffix "dc=my-domain,dc=com"
#rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# 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,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
</snip>
Now, when I run "/usr/sbin/slapd -d -5" and attempt to do a general
query on the ldap server using "ldapsearch -x -b 'dc=rams,dc=com,dc=au'"
I get the following feedback from openldap:
<snip>
# extended LDIF
#
# LDAPv3
# base <dc=rams,dc=com,dc=au> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 80 Other (e.g., implementation specific) error
# numResponses: 1
</snip>
And, the debug output displays:
<snip>
...
==>backsql_search(): base="dc=rams,dc=com,dc=au",
filter="(objectClass=*)", scope=2, deref=0, attrsonly=0, attributes to
load: all
==>backsql_get_db_conn()
==>backsql_open_db_conn(3)
daemon: epoll: listen=8 active_threads=0 tvp=NULL
<==backsql_open_db_conn(3)
backsql_open_db_conn(3): connected, adding to tree.
<==backsql_get_db_conn()
==>backsql_dn2id("dc=rams,dc=com,dc=au") matched expected
backsql_dn2id("dc=rams,dc=com,dc=au"): id_query "SELECT
id,keyval,oc_map_id,dn FROM custom_ldap_entries WHERE dn=?"
backsql_dn2id("dc=rams,dc=com,dc=au"): id=1 keyval=1 oc_id=1
dn=dc=rams,dc=com,dc=au
>>> dnPrettyNormal: <dc=rams,dc=com,dc=au>
<<< dnPrettyNormal: <dc=rams,dc=com,dc=au>, <dc=rams,dc=com,dc=au>
<==backsql_dn2id("dc=rams,dc=com,dc=au"): err=0
==>backsql_id2entry()
backsql_id2entry(): retrieving all attributes
==>backsql_get_attr_vals(): oc="organizationalUnit" attr="objectClass"
keyval=1
backsql_get_attr_vals(): error executing attribute count query 'SELECT
COUNT(*) FROM ldap_entry_objclasses,ldap_entries,company WHERE
company.id=? AND ldap_entries.id=ldap_entry_objclasses.entry_id AND
ldap_entries.keyval=company.id and ldap_entries.oc_map_id=1'
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entry_objclasses'
doesn't exist"
<==backsql_id2entry()
==>backsql_oc_get_candidates(): oc="inetOrgPerson"
==>backsql_srch_query()
==>backsql_process_filter()
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,contact.id,'inetOrgPerson' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,contact WHERE
contact.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
Constructed query: SELECT DISTINCT
ldap_entries.id,contact.id,'inetOrgPerson' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,contact WHERE
contact.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
id: '2'
backsql_oc_get_candidates(): error executing query
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entries' doesn't exist"
==>backsql_oc_get_candidates(): oc="organizationalUnit"
==>backsql_srch_query()
==>backsql_process_filter()
<==backsql_process_filter() succeeded
<==backsql_srch_query() returns SELECT DISTINCT
ldap_entries.id,company.id,'organizationalUnit' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,company WHERE
company.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
Constructed query: SELECT DISTINCT
ldap_entries.id,company.id,'organizationalUnit' AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,company WHERE
company.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3
id: '1'
backsql_oc_get_candidates(): error executing query
Return code: -1
nativeErrCode=1146 SQLengineState=S0002 msg="[unixODBC][MySQL][ODBC
3.51 Driver][mysqld-5.0.45]Table 'ldaptest.ldap_entries' doesn't exist"
send_ldap_result: conn=3 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=80
ber_flush: 14 bytes to sd 9
0000: 30 0c 02 01 02 65 07 0a 01 50 04 00 04 00 0....e...P....
ldap_write: want=14, written=14
0000: 30 0c 02 01 02 65 07 0a 01 50 04 00 04 00 0....e...P....
conn=3 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=
...
</snip>
In summary, I feel that there is some kind of missing configuration
variable either in documentation or tutorials online that really doesn't
allow you to fully specify alternate table names for the default 4 main
tables in the back-sql implementation. If this is due to the backend
being experimental then so be it - however I really need some kind of
quantified 'yes' or 'no' as to whether what I'm trying to achieve is
possible at all.
TIA
Matthew Hallsworth
16 years, 1 month
Re: Security between server and client nodes.
by Jayavant Patil
On Fri, Dec 2, 2011 at 12:19 PM, Jayavant Patil
<jayavant.patil82(a)gmail.com>wrote:
>
>
> On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil <jayavant.patil82(a)gmail.com
> > wrote:
>
>> On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli <
>> public(a)raffaelsahli.com> wrote:
>> >On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>> >
>> >
>> > >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
>> > >>
>> > >>
>> > >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
>> > >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
>> > <mailto:jayavant.patil82@gmail.com
>>
>> > <mailto:jayavant.patil82@gmail.com>>> wrote:
>> > >>
>> > >>
>> > >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
>> > >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
>> > <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>>
>> wrote:
>> > >> >>Hi
>> > >>
>> > >> >>I think you mean SSL connection or the STARTTLS Layer...?
>> > >> >>Please read the manual
>> http://www.openldap.org/doc/admin24/tls.html
>> > >> >Ok.
>> > >>
>> > >> >>And tree security:
>> > >> >>On my server, a client user can only see his own object:
>> > >> >Are you using simple authentication mechanism?
>> > >>
>> > >> >>Maybe create a rule like this:
>> > >> >>access to filter=(objectClass=
>> > >> >>simpleSecurityObject)
>> > >> >> by self read
>> > >> >> by * none
>> > >>
>> > >> >I am not getting what the ACL rule specifies. Any suggestions?
>> > >>
>> > >>
>> > >> I have two users ldap_6 and ldap_7. I want to restrict a user to
>> > >> see his own data only.
>> > >> In slapd.conf, I specified the rule as follows:
>> > >> access to *
>> > >> by self write
>> > >> by * none
>> > >>
>> > >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
>> > >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> > >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
>> > >>
>> > >> Any suggestions?
>> > >>
>> > >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
>> > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
>> > >Yes, that's exactly the rule I wrote above.
>> >
>> > >access to filter=(objectClass=
>> > >simpleSecurityObject)
>> > > by self read
>> > > by * none
>> >
>> >
>> > >Maybe you have to change the objectClass to posixAccount, or both or
>> > >whatever....
>> >
>> > >access to
>> > >filter=(|(objectClass=
>> simpleSecurityObject)(objectClass=posixAccount))
>> > > by self read
>> > > by * none
>> >
>> >
>> > >Just add this rule before the global rule "access to *"
>> >
>> >
>> > >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> > >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>> >
>> > >And if you search like this with bind "admin dn", you will see every
>> > >object....
>> > >You have to bind with user ldap_6 and not with root
>> > But anyway client user knows the admin dn and rootbindpassword. So,
>> > with this he will look into all directory information to which he is
>> > not supposed to do.
>> > e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>> >
>> > So, how to avoid this?
>> >
>>
>>
>> >>>Why client user knows the admin dn and pw????????
>>
>> >>Because /etc/ldap.conf file on client contains admin dn and pw.
>>
>> >>Each user information in the directory contains the following
>> entries(here, e.g. ldap_6)
>>
>>
>> >>dn: uid=ldap_6,ou=People,dc=abc,dc=com
>> >>uid: ldap_6
>> >>cn: ldap_6
>> >>sn: ldap_6
>> >>mail: ldap_6(a)abc.com
>> >>objectClass: person
>> >>objectClass: organizationalPerson
>> >>objectClass: inetOrgPerson
>> >>objectClass: posixAccount
>> >>objectClass: top
>> >>objectClass: shadowAccount
>> >>objectClass: hostObject
>> >>objectClass: simpleSecurityObject
>> >>shadowLastChange: 13998
>> >>shadowMax: 99999
>> >>shadowWarning: 7
>> >>loginShell: /bin/bash
>> >>uidNumber: 514
>> >>gidNumber: 514
>> >>homeDirectory: /home/ldap_6
>> >>host: *
>> >>userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>>
>>
>> >>So, what should be the ACL rule so that each user can see his data
>> only? I tried but not getting the required, even >>the user himself is
>> unable to see his own data.
>>
>>
>> --
>>
>> Thanks & Regards,
>> Jayavant Ningoji Patil
>> Engineer: System Software
>> Computational Research Laboratories Ltd.
>> Pune-411 004.
>> Maharashtra, India.
>> +91 9923536030.
>>
>>
>
> >The user itself is unable to see its own info.
>
> >[ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com" "(cn=ldap_6)" -h
> server
> >ldap_initialize( ldap://server )
> >filter: (cn=ldap_6)
> >requesting: All userApplication attributes
> ># extended LDIF
> >#
> ># LDAPv3
> ># base <dc=abc,dc=com> with scope subtree
> ># filter: (cn=ldap_6)
> ># requesting: ALL
> >#
>
> ># search result
> >search: 2
> >result: 32 No such object
>
> ># numResponses: 1
>
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
Can you show me your server as well as client side configuration settings?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
13 years, 6 months
Re: fedora and openldap
by Judith Flo Gaya
Hello ldap,
In fact in my authconfig instruction I have --enableforcelegacy, but
this only works on my f14 clients, rh refuses to accept this option, but
I already set the forcelegacy=yes in my /etc/sysconfig/authconfig.
At the very beginning sssd was a little crazy... but I have learnt to
get rid of it.
How do you set your authconfig system? right now is the only missing
part of the puzzle ;(
On 04/14/2011 07:40 PM, ldap(a)mm.st wrote:
> I came in late on this thread, so disregard if this has already been
> said or is not applicable. Also, we use standard RH packages, so if you
> are building your own, this may not be any use to you.
>
> We have a few RH6 boxes authenticating against our ldap servers. It's
> been awhile, but in addition to the CA certs being copied to the clients
> and the correct perms assigned we had come success enabling legacy mode
> in RH6 when running authconfig to set up the box. If I recall, in
> legacy mode sssd does not run and it uses a more RH5 way of
> authenticating clients. Unfortunately, I don't have a RH6 box in front
> of me, but you can edit /etc/sysconfig/authconfig to set legacy mode.
> Then run your authconfig command to set up the box. Also, look at
> /etc/pam_ldap.conf if you decide to try to authenticate in this manner.
> The settings in there are like they were in /etc/ldap.conf, RH5. Your
> system-auth file looks like ours does as far as I can remember.
>
> Just something else you may want to try if you haven't already.
>
> On Thu, 14 Apr 2011 18:55 +0200, "Judith Flo Gaya"<jflo(a)imppc.org>
> wrote:
>> Hello,
>>
>> After doing all you suggest with the pki keys I'm stuck in the very same
>> place, the system is able to do ldapsearch but all user auth is not
>> working, I do this in order to configure the auth in the clients
>> # authconfig --disablecachecreds --enableldaps --enableldapauth
>> --ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
>> --disablefingerprint --disablewinbind --disablewins --disablesssd
>> --disablesssdauth --disablenis --enablecache --enablelocauthorize
>> --disablemd5 --passalgo=sha512 --updateall
>>
>>
>> The pam.d files look ok:
>>
>> # 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.
>> auth required pam_env.so
>> auth sufficient pam_unix.so nullok try_first_pass
>> auth requisite pam_succeed_if.so uid>= 500 quiet
>> auth sufficient pam_ldap.so use_first_pass
>> auth required pam_deny.so
>>
>> account required pam_unix.so broken_shadow
>> account sufficient pam_localuser.so
>> account sufficient pam_succeed_if.so uid< 500 quiet
>> account [default=bad success=ok user_unknown=ignore] pam_ldap.so
>> account required pam_permit.so
>>
>> password requisite pam_cracklib.so try_first_pass retry=3 type=
>> password sufficient pam_unix.so sha512 shadow nullok
>> try_first_pass use_authtok
>> password sufficient pam_ldap.so use_authtok
>> password required 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
>>
>> This is the message in ldap server when I do id<ldap_user>
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
>> IP=[::1]:36208 (IP=[::]:636)
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
>> tls_ssf=256 ssf=256
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
>> oid=1">oid=1.3.6.1.4.1.1466.20037
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
>> text=TLS already started
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
>> Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
>>
>> Aparently is ok but the id is not known
>> Any ideas?
>> Thanks a lot!
>> j
>>
>> On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
>>> Hello Aaron,
>>>
>>> On 04/13/2011 09:07 PM, Aaron Richton wrote:
>>>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
>>>>
>>>>> I see, I also have those files that you mention... I created my own CA
>>>>> as lots of tutorials explain.. Then I transmitted it to the clients and
>>>>> used it in the ldap.conf file. Do you suggest me to send those to the
>>>>> server and use them instead of the ones I generated with openssl?
>>>>
>>>> Well, you'll need the CA on the client to match the CA that signed the
>>>> server's certificate. In other words...if you generated your own CA for
>>>> both the client and the server, trust issues would be completely
>>>> expected...
>>> I don't know if I understood you or I didn't make myself clear on that
>>> point. I created a CA in the server and the copied the file to the
>>> client, is that wrong?
>>>>
>>>>> What's your server?
>>>>
>>>> OpenLDAP software is on both sides of the equation; it's just that some
>>>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
>>>> ALL servers are OpenSSL.
>>> I was talking about the operating system, for some reason I think that
>>> having red hat (with openldap compiled using openssl) and clients with
>>> fedora (openldap compiled against moznss) created my problems.
>>> Now that you said that this is your case (I think) then it may be
>>> something related to... I don't know what.
>>>>
>>>>> Well my final problem were not ldapsearch but the user autenticacion.
>>>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
>>>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
>>>>> That's when I was told that the problem may be caused by the
>>>>> implementation of the ldap client (with moznss support).
>>>>
>>>> Well, when troubleshooting, it's often easiest to look with a narrow
>>>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
>>>> will probably offer a better debugging platform than an ssh
>>>> implementation? One step at a time...
>>> Yes, I totally agree, that's why I setup my own openldap installation
>>> and only care about ldapsearch working, then when ldapsearch finally
>>> worked, then I start looking at the user auth part, changing passw,
>>> etc.. as this part wasn't working and it appear to be a moznss problem,
>>> I got stuck... until you arrived, I will try what you suggest about
>>> using the pki certs instead of the openssl ones..
>>>
>>> Thanks a lot for the suggestion, hope this finally fix the issue.
>>> j
>>
>> --
>> Judith Flo Gaya
>> Systems Administrator IMPPC
>> e-mail: jflo(a)imppc.org
>> Tel (+34) 93 554-3079
>> Fax (+34) 93 465-1472
>>
>> Institut de Medicina Predictiva i Personalitzada del Càncer
>> Crta Can Ruti, Camí de les Escoles s/n
>> 08916 Badalona, Barcelona,
>> Spain
>> http://www.imppc.org
>>
>>
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
14 years, 1 month
Re: openldap 2.4.23 hangs
by Howard Chu
rwsmith(a)bislink.net wrote:
>
>
> Hi,
>
>
>
> Not sure if I should post this here or with the CentOS mailing list (I am
> hoping they are monitoring this). I am using a stock CentOS 6.3 32-bit
> installation with
>
>
>
> # rpm -qa | grep openldap
> openldap-devel-2.4.23-26.el6_3.2.i686
> openldap-2.4.23-26.el6_3.2.i686
> openldap-clients-2.4.23-26.el6_3.2.i686
> openldap-servers-2.4.23-26.el6_3.2.i686
>
>
>
> I have a 4-way multi-master sync replication set up on four virtual servers
> using Citrix XenServer 6.2. I am also running Samba 3.5.10 as a PDC on one
> machine and BDC on the other three. All servers are also running sssd-1.8.0
> for the Linux authentication.
>
>
>
> The problem is that one or more of the LDAP servers will hang, usually the one
> that acts as the PDC, since this is hit the hardest and is the more critical
> of the four. Usually but not always the "hang" will trickle to the other
> servers--usually when I am not watching during the middle of the night.
> Fortunately we are not yet in full production.
>
>
>
> Compiling from source is not yet an option. I must use the stock RPMs from
> CentOS per our design guidelines.
>
>
>
> LDAP will appear to hang but what appears to be happening is that only the
> listener becomes busy and will not get out this state. Here is a short pull of
> the logs that I am collecting:
Sounds like this was fixed in 2.4.25, git commit ID
0ae659ad87c64bef938f729e87573ff3ce04bd28 (master),
commit a3f40e5601c0c522f2bda418374fb415bdcbd75c (release).
There was no ITS submitted for this change, so it is not in the CHANGES file.
If you can reproduce the problem with 2.4.32 please submit an ITS for it. I
will note that all of this listener code is targeted for a major rewrite in
OpenLDAP 2.5.
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 STARTTLS
> Aug 14 20:34:44 auth-us slapd[10357]: conn=1742 op=0 RESULT oid= err=0 text=
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:44 auth-us slapd[10357]:
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:44 auth-us slapd[10357]: 69r
> Aug 14 20:34:44 auth-us slapd[10357]:
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: read active on 69
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:44 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:46 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:51 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:54 auth-us slapd[10357]: 39r
> Aug 14 20:34:54 auth-us slapd[10357]:
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: read active on 39
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:34:54 auth-us slapd[10357]:
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:34:54 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:34:56 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:01 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:06 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:11 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: activity on:
>
> Aug 14 20:35:12 auth-us slapd[10357]: 42r
> Aug 14 20:35:12 auth-us slapd[10357]:
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: read active on 42
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:12 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on 1 descriptor
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: activity on:
> Aug 14 20:35:14 auth-us slapd[10357]: 40r
> Aug 14 20:35:14 auth-us slapd[10357]:
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: read active on 40
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:14 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:16 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:21 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:26 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
> Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=7 busy
> Aug 14 20:35:31 auth-us slapd[10357]: daemon: epoll: listen=8 active_threads=0
> tvp=zero
>
>
>
> Every log entry prior to this looks normal in that epoll: listen=7 goes
> between active_threads=0 to busy when a connection comes in, sets up the
> connection, and then goes back to active_threads=0. I have yet to understand
> what is going on to cause it to go into the busy state and never to return
> until I manually stop and restart the slapd process. It does appear however
> that slapd can still process any queries on active connections as noted on
> descriptors 40r and 42r--it just can't process any new connection requests as
> epoll: listen=7 has hung.
>
>
>
> Looking through the archives this problem still appears to be present in a few
> additional later releases but I have not found any thread yet which points to
> a specific solution or patch that fixes this problem. Unless I can point to a
> specific solution and/or patch I won't get approval to do a pull from the
> latest source and compile--I'll have to stick with an hourly cron job that
> stops and restart slapd.
>
>
>
> Thanks,
>
> Bob Smith
>
> --bs
>
>
>
>
>
>
>
>
>
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months