Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59
by Nick Milas
Hello,
Our main OpenLDAP Server (running on CentOS 7) has been working fine
with 2.4.58.
Since yesterday, after a (minor, see at the end) OS upgrade which
included an update to LTB Openldap 2.4.59, SSL clients see:
# ldapwhoami -H ldaps://ldap.noa.gr:636 -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
In the log I see, for example:
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 ACCEPT from
IP=195.251.xxx.xxx:44016 (IP=0.0.0.0:389)
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 STARTTLS
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 RESULT oid= err=0 text=
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 closed (TLS
negotiation failure)
...
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:52018 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 TLS established
tls_ssf=256 ssf=256
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND
dn="uid=full,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND
dn="uid=Full,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 RESULT tag=97 err=0 text=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH
base="dc=noa,dc=gr" scope=2 deref=0 filter="(objectClass=*)"
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH attr=* +
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search:
got a persistent search with a
cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findbase:
searching
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search:
registered persistent search
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
csn==20200910151806.461875Z#000000#000#000000 not found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
csn<=20200910151806.461875Z#000000#000#000000 found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn:
mode=FIND_PRESENT csn=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo:
present syncIdSet cookie=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 INTERM
oid=1.3.6.1.4.1.4203.1.9.1.4
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo:
present syncIdSet cookie=
...
Oct 21 17:11:34 ldap slapd[18532]: send_search_entry: conn 1172 ber
write failed.
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 closed (connection
lost on write)
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
<many more entries like this>
...
Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:33466 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 closed (TLS
negotiation failure)
Is there some settings change in 2.4.59 or something is getting wrong?
My settings:
olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv.crt
olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert.crt
olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/GeantCA.crt
I also tried:
olcTLSCipherSuite: ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
without success.
Interestingly, I can see random successes like:
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:47206 (IP=[::]:636)
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 TLS established
tls_ssf=256 ssf=256
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 RESULT tag=97 err=0 text=
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH
base="ou=people,dc=noa,dc=gr" scope=2 deref=0
filter="(&(&(objectClass=inetOrgPerson)(!(schacUserStatus=internal)))(|(mail=jackie(a)noa.g
r)))"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH attr=cn sn
givenname title mail telephonenumber o ou;lang-en-us objectClass
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 ENTRY
dn="uid=jackie,ou=people,dc=noa,dc=gr"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=2 UNBIND
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 close
...
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 ACCEPT from
IP=[2001:648:2011:xxxx::xxxx]:35456 (IP=[::]:389)
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 STARTTLS
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=0 RESULT oid= err=0 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 TLS established
tls_ssf=256 ssf=256
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 BIND
dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=1 RESULT tag=97 err=0 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH
base="ou=people,dc=noa,dc=gr" scope=2 deref=0 filter="(uid=gate)"
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SRCH attr=uid
uidNumber gidNumber homeDirectory loginShell
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 ENTRY
dn="uid=gate,ou=webad,ou=people,dc=noa,dc=gr"
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 op=3 UNBIND
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 closed
then failures start again, esp. when SYNCRPOV sessions take place (we
have 4 SYNCRPOV consumers).
Latest updates (from /var/log/yum.log):
Oct 20 21:54:24 Updated: 1:grub2-common-2.02-0.87.el7.centos.7.noarch
Oct 20 21:54:24 Updated: 32:bind-license-9.11.4-26.P2.el7_9.7.noarch
Oct 20 21:54:24 Updated: 1:grub2-pc-modules-2.02-0.87.el7.centos.7.noarch
Oct 20 21:54:25 Updated: libX11-common-1.6.7-4.el7_9.noarch
Oct 20 21:54:26 Updated: kernel-headers-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:54:28 Updated: ca-certificates-2021.2.50-72.el7_9.noarch
Oct 20 21:54:29 Updated: tzdata-2021c-1.el7.noarch
Oct 20 21:54:30 Updated: nss-softokn-freebl-3.67.0-3.el7_9.x86_64
Oct 20 21:54:36 Updated: glibc-common-2.17-325.el7_9.x86_64
Oct 20 21:54:38 Updated: glibc-2.17-325.el7_9.x86_64
Oct 20 21:54:39 Updated: nspr-4.32.0-1.el7_9.x86_64
Oct 20 21:54:39 Updated: nss-util-3.67.0-1.el7_9.x86_64
Oct 20 21:54:40 Updated: 1:openssl-libs-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:41 Updated: 1:grub2-tools-minimal-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:41 Updated: libX11-1.6.7-4.el7_9.x86_64
Oct 20 21:54:41 Updated: gd-last-2.3.3-2.el7.remi.x86_64
Oct 20 21:54:43 Updated: 32:bind-libs-lite-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:43 Updated: nss-softokn-3.67.0-3.el7_9.x86_64
Oct 20 21:54:44 Updated: nss-sysinit-3.67.0-3.el7_9.x86_64
Oct 20 21:54:44 Updated: nss-3.67.0-3.el7_9.x86_64
Oct 20 21:54:45 Updated: rpm-4.11.3-46.el7_9.x86_64
Oct 20 21:54:45 Updated: rpm-libs-4.11.3-46.el7_9.x86_64
Oct 20 21:54:46 Updated: 1:grub2-tools-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: 1:grub2-tools-extra-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: 1:grub2-pc-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:54:47 Updated: rpm-build-libs-4.11.3-46.el7_9.x86_64
Oct 20 21:54:47 Updated: nss-tools-3.67.0-3.el7_9.x86_64
Oct 20 21:54:48 Updated: openldap-2.4.44-24.el7_9.x86_64
Oct 20 21:54:48 Updated: 12:dhcp-libs-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:54:48 Updated: 12:dhcp-common-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:54:49 Updated: 32:bind-libs-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:50 Updated: 32:bind-export-libs-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:54:50 Updated: httpd-tools-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:54:52 Updated: httpd-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:54:54 Updated: 1:openssl-devel-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:56 Updated: 1:openssl-1.0.2k-22.el7_9.x86_64
Oct 20 21:54:56 Updated: oniguruma5php-6.9.7.1-1.el7.remi.x86_64
Oct 20 21:54:56 Updated: gssproxy-0.7.0-30.el7_9.x86_64
Oct 20 21:54:57 Installed: libzstd-1.5.0-1.el7.x86_64
Oct 20 21:54:57 Updated: libzip5-1.8.0-2.el7.remi.x86_64
Oct 20 21:55:00 Updated: kernel-tools-libs-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:55:01 Updated: glibc-headers-2.17-325.el7_9.x86_64
Oct 20 21:55:05 Installed: libicu69-69.1-2.el7.remi.x86_64
Oct 20 21:55:07 Updated: epel-release-7-14.noarch
Oct 20 21:55:08 Updated: remi-release-7.9-2.el7.remi.noarch
Oct 20 21:55:10 Updated: glibc-devel-2.17-325.el7_9.x86_64
Oct 20 21:55:12 Updated: kernel-tools-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:55:25 Updated: 1:nfs-utils-1.3.0-0.68.el7.2.x86_64
Oct 20 21:55:26 Updated: 1:mod_ssl-2.4.6-97.el7.centos.1.x86_64
Oct 20 21:55:30 Updated: 12:dhclient-4.2.5-83.el7.centos.1.x86_64
Oct 20 21:55:33 Updated: 32:bind-utils-9.11.4-26.P2.el7_9.7.x86_64
Oct 20 21:55:36 Updated: openldap-ltb-2.4.59-1.el7.x86_64
Oct 20 21:55:37 Updated: sudo-1.8.23-10.el7_9.2.x86_64
Oct 20 21:55:38 Updated: rpm-python-4.11.3-46.el7_9.x86_64
Oct 20 21:55:39 Updated: 1:grub2-2.02-0.87.el7.centos.7.x86_64
Oct 20 21:55:40 Updated: rsyslog-8.24.0-57.el7_9.1.x86_64
Oct 20 21:55:40 Updated: kpartx-0.4.9-135.el7_9.x86_64
Oct 20 21:56:00 Updated: 2:microcode_ctl-2.1-73.11.el7_9.x86_64
Oct 20 21:56:01 Updated: kexec-tools-2.0.15-51.el7_9.3.x86_64
Oct 20 21:56:01 Updated: unzip-6.0-22.el7_9.x86_64
Oct 20 21:56:02 Updated: virt-what-1.18-4.el7_9.1.x86_64
Oct 20 21:56:04 Updated: glib2-2.56.1-9.el7_9.x86_64
Oct 20 21:56:05 Updated: python-perf-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:56:30 Installed: kernel-3.10.0-1160.45.1.el7.x86_64
Oct 20 21:56:32 Updated: openldap-ltb-debuginfo-2.4.59-1.el7.x86_64
Please advise.
Would you suggest an openldap downgrade to 2.4.58 and/or to
openssl-1.0.2k-21?
Any other ideas?
Nick
3 years, 7 months
Re: Security between server and client nodes.
by Raffael Sahli
On 12/01/2011 02:42 PM, Jayavant Patil 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.
Why??? Thats not really secure...
You can write the password of the admin dn in a separate file with chmod
0400 (root ower)
Please read the man pages for that, its diffrent in every distr.
>
> 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.
>
--
Raffael Sahli
public(a)raffaelsahli.com
13 years, 6 months
OpenLDAP proxy to Active Directory
by Jonathan van der Wat
Greetings,
I'm new to OpenLDAP and am trying to implement the following:
User authentication (PAM + SSSD) on CentOS Linux servers via OpenLDAP
proxy to Active Directory. I am able to perform the following search
from the OpenLDAP proxy without any apparent issues:
*
[root@openldap ~]# ldapsearch -x -h /mydomaincontroller/ -LLL -b
dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W
'(sAMAccountName=jonathanv)' cn sAMAccountName
Enter LDAP Password:
dn: CN=jonathan,CN=Users,DC=msad,DC=inet,DC=com
cn: jonathan
sAMAccountName: jonathanv
#
refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC…
#
refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC…
# refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com*
However, when asking the OpenLDAP proxy:
*[root@openldap ~]# ldapsearch -x -h /localhost/ -LLL -b
dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W
'(sAMAccountName=jonathanv)' cn sAMAccountName
Enter LDAP Password:
#
refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC…
#
refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC…
# refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com*
Also, I've configured my CentOS server's using SSSD. When trying to
authenticate as user jonathanv, I receive a message that user jonathanv
is not found.
I am using OpenLDAP server version 2.4.23-20.
I am starting the OpenLDAP from the command line as follows:
*slapd -f -d 2 -f /etc/openldap/slapd.conf -g ldap -h ldap:/// -l LOCAL4
-u ldap -n slapd-ldap*
Here is the output of my slapd.conf file:
*#
# 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 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!
# 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=inet,dc=local"
checkpoint 1024 15
rootdn "cn=Manager,dc=inet,dc=local"
rootpw xxxxxxxxxxxxxxxx
# 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
# Our slapd-ldap back end to connect to AD
database ldap
suffix "dc=msad,dc=inet,dc=com"
#subordinate
rebind-as-user
uri "ldap://172.16.132.253/"
chase-referrals yes
overlay rwm
rwm-suffixmassage dc=msad,dc=inet,dc=com
rwm-map attribute uid sAMAccountName
rwm-map attribute cn cn
rwm-map attribute displayName displayName
rwm-map attribute givenName givenName
rwm-map attribute sn sn
rwm-map attribute mail mail
rwm-map attribute userPassword userPassword
rwm-map attribute *
rwm-map objectclass inetOrgPerson user
# 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
#*
Any ideas as to why I'm unable to authenticate my user against the AD?
Any advice or info on this topic would be greatly appreciated.
Greetings,
Jonathan
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem-ppc.
13 years
Re: Security between server and client nodes.
by Jayavant Patil
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.
13 years, 6 months
CSN Too Old potential Bug
by Burton, Kris - Acision
All,
I want to ask the list about this before I try to open an ITS to make sure that I am understanding everything correctly. We are running OpenLDAP 2.4.11. I selectively tried to back post ITS 5709 to our source, because we were losing replications. Applying this seemed to help and reduced the number of lost replications. We are running in mirror mode using refreshAndPersist, and doing a high volume of adds to the master, on the order of 100/s. We have run numerous iterations of the same test with very aggressive NTP updates that are keeping both the master and consumer within 50 microseconds of one another. Which I saw recommended as a possible solution in a previous message thread. This seemed to make little to no difference in the replication loss.
>From looking at the code I was thinking that the lost replications might be due to entries being queued on the master side in non-ascending order which I was seeing preceding the replication that would be rejected on the consumer side. What I thought was happening is that the logic that traverses the queue to mark committed CSNs and updates the contextCSN was getting out of sync because of this, and orphaning replications that were still pending, because they are too old, but in reality they have never been added to the consumer.
I just pulled the latest code from RE24 and reran the test, the latest code is better than before with just the back post of 5709 on 2.4.11, but we are still losing a small percentage of the replications with the "CSN too old" message. With the latest code I am still seeing a correlation between the out of sync queuing on the master and the replications that are rejected on the consumer.
During this run NTP was keeping the 2 systems within 10 microseconds of each other, with the most aggressive synch interval that is configurable at 16 seconds.
Below I have log snippets and some of the relevant configuration information. If more is desired then please let me know and I will provide it.
#### MASTER #####
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b4c9568b0 20081114194304.892065Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x42803100 20081114194305.078713Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: conn=14 op=17167 ADD dn="uniqueIdentifier=Evad_Added_tele_5450408582,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x4680b100 20081114194305.078878Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43004100 20081114194305.078653Z#000000#001#000000
Nov 14 14:43:05 ng04be03 slapd[7582]: conn=12 op=13844 RESULT tag=105 err=0 text=
Nov 14 14:43:05 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b4c87e670 20081114194305.068251Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x41000100 20081114194502.917316Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=10 op=19719 ADD dn="uniqueIdentifier=Evad_Added_tele_5450009858,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43805100 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x4780d100 20081114194502.917288Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=12 op=17496 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5a7f8340 20081114194502.917316Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=13 op=19983 ADD dn="uniqueIdentifier=Evad_Added_tele_5450509990,ou=subscribers,ou=SINGP,o=ricuc…"
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=10 op=19719 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5ae77160 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=14 op=19598 ADD dn="umbillingnumber=5450409797,uniqueIdentifier=Evad_Added_tele_5450409797,ou=s…"
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x41000100 20081114194502.936884Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: conn=11 op=16763 RESULT tag=105 err=0 text=
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_queue_csn: queing 0x43805100 20081114194502.947725Z#000000#001#000000
Nov 14 14:45:02 ng04be03 slapd[7582]: slap_graduate_commit_csn: removing 0x2b5ad51170 20081114194502.917288Z#000000#001#000000
### CONSUMER ###
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 be_add (0)
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194305.078653Z#000000#001#000000
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: rid=002 CSN too old, ignoring 20081114194305.078653Z#000000#001#000000
Nov 14 14:43:36 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 14 14:43:36 ng04be04 slapd[24622]: syncrepl_entry: rid=002 be_search (0)
Nov 14 14:45:39 ng04be04 slapd[24622]: slap_queue_csn: queing 0x2b4737c990 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: slap_graduate_commit_csn: removing 0x2b473ca890 20081114194502.917523Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194502.917288Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: rid=002 CSN too old, ignoring 20081114194502.917288Z#000000#001#000000
Nov 14 14:45:39 ng04be04 slapd[24622]: do_syncrep2: cookie=rid=002,sid=002,csn=20081114194502.936884Z#000000#001#000000
### Replication Config ###
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
...
olcSyncrepl: {0}rid=2 provider=ldap://ldap.server.com bindmethod=si
mple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=ricuc.com" cr
edentials="secret" starttls=no filter="(objectclass=*)" searchbase="o=ricuc.com"
scope=sub schemachecking=off type=refreshandpersist retry="60 +"
olcMirrorMode: TRUE
dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
### Hardware ###
Dual Quad Core Xeon 2.83GHz
32GB RAM
8x15000rpm RAID10
Separate LUNS for db and txn logs
Kris Burton
Software Engineer
________________________________________
Acision. Innovation. Assured.
www.acision.com
4870 Sadler Road
Suite 200
Glen Allen, VA
23060
USA
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
16 years, 6 months
phpldapadmin and openldap
by Juan Diego Calle
Hi,
I have being trying to solve this for more than a month. I installed Openldap, Samba, smbldap-tools, and phpmyadmin in a Red Hat 5.6 server. I have many users created with smbldap-tools.
Almost everything works, there are 2 things that I need help with.
One is with phpldapadmin. I can log with the user administrator, but can not change anything, this is the error in phpldapadmin
Could not perform ldap_modify operation.
LDAP said: Insufficient access
Error number: 0x32 (LDAP_INSUFFICIENT_ACCESS)
Description: You do not have sufficient permissions to perform that operation.
This error on the log
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 fd=11 ACCEPT from IP=127.0.0.1:59487 (IP=0.0.0.0:389)
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 BIND dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec" method=128
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 BIND dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec" mech=SIMPLE ssf=0
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=0 RESULT tag=97 err=0 text=
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 MOD dn="uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec"
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 MOD attr=loginShell
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=1 RESULT tag=103 err=50 text=
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 op=2 UNBIND
Jun 7 17:43:58 pruebas03 slapd[11983]: conn=10 fd=11 closed
This is my slapd.conf
############################################
#
# 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
include /etc/openldap/schema/samba.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 /usr/lib64/openldap
# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# 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 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!
#access to *
# by self write
# by users read
# by anonymous auth
#access to attrs=userpassword
# by self =xw
# by anonymous auth by anonymous auth
#access to *
# by self write
# by users read
#access to attrs=userpassword by self write by anonymous auth by * none
#access to * by self write by users read by anonymous read by * none
#access to * by uid=Administrator,ou=People,dc=mydomain,dc=com,dc=ec write
#access to dn.regex = "ou = personal_addressbook or =(.+),, dc = korrigan, dc = org"
#by dn.regex="cn=$1,ou=Users,dc=korrigan,dc=org" write by dn.regex = "cn = $ 1, ou = Users, dc = korrigan, dc = org" write
#by dn="cn=admin,dc=korrigan,dc=org" write by dn = "cn = admin, dc = korrigan, dc = org" write
#by * none by * none
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=mydomain,dc=com,dc=ec"
rootdn "cn=Manager,dc=mydomain,dc=com,dc=ec"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# 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
# Extras para ser servidor master de ldap
loglevel 256
(I already posted this once)
##########################################3
When i add this line
access to * by self write by users read by anonymous read by * none
Users are allowed to change their info. I just want a group of users that can change the info of other users, users that have more privileges .
I also tried adding a group called miniadmins, it didnt work.
dn: cn=MiniAdmins,ou=People,dc=mydomain,dc=com,dc=ec
objectClass: groupOfNames
objectClass: top
cn: MiniAdmins
member: uid=jdc,ou=People,dc=mydomain,dc=com,dc=ec
member: uid=user2,ou=People,dc=mydomain,dc=com,dc=ec
structuralObjectClass: groupOfNames
entryUUID: a3e66d90-19b0-1030-9c61-73ebddf12515
creatorsName: cn=Manager,dc=mydomain,dc=com,dc=ec
modifiersName: cn=Manager,dc=mydomain,dc=com,dc=ec
createTimestamp: 20110523174841Z
modifyTimestamp: 20110523174841Z
entryCSN: 20110523174841Z#000012#00#000000
with the following acl
access to *
by group/groupOfNames/member="cn=MiniAdmins,ou=People,dc=iess,dc=gob,dc=ec" write
Also for the second part I dont know if you are able to do this with openldap: All users are part of dn: cn=Domain Users,ou=Group,dc=mydomain,dc=com,dc=ec. Also this users belong to others groups like city1, city2, city3. In each city there is and admin that has control over that group, example admincity1, admincity2,etc. They can manage users in their respective cities, but they can not change anything on another city.
I need help with the slapd.conf, I have a basic understanding, but my logic here is failing.
I have found people with similar problems but no answers.
Thanks,
Juan Diego
14 years
Re: fedora and openldap
by ldap＠mm.st
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
>
>
14 years, 1 month
Whenchanged or modifyTimestamp filter
by Sébastien MALHEIRO
Hi,
I want to configure openldap to work as a proxy for Active Directory.
I have :
A ldap database section to connect to active directory
a dbd database to store local ldap
A relay database to map Active Directory OU on a local OU
This work fine but I have a problem with this type of filter :
- ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(whenChanged>=20080812000000.0Z))"
- ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(modifyTimestamp>=20080812000000.0Z))"
=> I have no result
But with this type of filter : ldapsearch -x -D "cn=manager,dc=opencg21,dc=priv" -W "(&(objectClass=*)(uid=MyUsername))"
=> I can see the whenChanged and modifyTimestamp attributes.
Can someone help me?
I don't know how to have an error code to see where is the pb
Thanks a lot.
----------------------------------------------
here is my 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
include /etc/openldap/schema/microsoft-minimal.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
moduleload back_ldap
moduleload rwm
# 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=opencg21,dc=priv" read
by * none
############################################################
#LDAP
############################################################
database ldap
suffix "OU=MYOU,DC=MYDC,DC=PRIV"
uri ldap://mydc.cg21.priv
rebind-as-user
acl-bind
bindmethod=simple
binddn="CN=****,DC=PRIV"
credentials="***"
idassert-bind
bindmethod=simple
binddn="CN=****,DC=PRIV"
credentials="***"
mode=none
lastmod on
idassert-authzFrom *
access to *
by * read
############################################################
#RELAY
############################################################
database relay
suffix "ou=myOU,dc=openldap,dc=priv"
relay "ou=myOU,dc=mydc,dc=priv"
subordinate
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext default
rwm-rewriteRule "(.+,)?ou=myOU,dc=openldap,dc=priv$" "$1ou=myOU,dc=mydc,dc=priv" ":"
rwm-rewriteContext searchEntryDN
rwm-rewriteContext searchAttrDN
rwm-rewriteRule "(.+,)?dc=openldap,dc=priv$" "$1dc=openldap,dc=priv" ":"
rwm-rewriteContext searchFilter
rwm-rewriteContext referralAttrDN
rwm-rewriteContext referralDN
rwm-map attribute uid sAMAccountName
rwm-map attribute modifyTimestamp modifyTimestamp
#rwm-map objectclass inetOrgPerson *
rwm-map objectclass groupOfNames group
rwm-normalize-mapped-attrs yes
#############################################################
#DATABASE PRINCIPALE
############################################################
database bdb
suffix "dc=openldap,dc=priv"
checkpoint 1024 15
rootdn "cn=Manager,dc=openldap,dc=priv"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}qGb9L/sewV24o10bQNynt3Kb2Uyv0Ac8
# 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
lastmod on
# 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
#index samaccountname
# 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
Ce message (pièces jointes comprises) est protégé par des règles relatives
au secret des correspondances ; il peut en outre contenir des informations à
caractère confidentiel ; il est établi à destination exclusive de son destinataire.
Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de
ce message, ou des informations qu'il contient, doit être préalablement autorisée.
Tout message électronique est susceptible d'altération et son intégrité ne peut
être assurée. Le Conseil Général de la Côte d'Or décline toute responsabilité
au titre de ce message, s'il a été modifié ou falsifié.
Si vous n'êtes pas destinataire de ce message, merci de le détruire
immédiatement et d'avertir l'expéditeur de l'erreur de distribution et de la
destruction du message.
Toute opinion contenue dans ce message appartient à son auteur : pour qu'il
engage la responsabilité de l'institution, il doit être confirmé par un écrit et son
auteur doit être dûment habilité.
11 years, 10 months
overlay pcache and cn=config
by Stefan Kania
Hello,
I've got the following working slapd.conf:
--------------------
include /opt/symas/etc/openldap/schema/core.schema
include /opt/symas/etc/openldap/schema/cosine.schema
include /opt/symas/etc/openldap/schema/inetorgperson.schema
include /opt/symas/etc/openldap/schema/misc.schema
include /opt/symas/etc/openldap/schema/nis.schema
include /opt/symas/etc/openldap/schema/msuser.schema
modulepath /opt/symas/lib/openldap
moduleload back_ldap
moduleload back_mdb
moduleload rwm.la
moduleload memberof.la
moduleload pcache.la
loglevel any
pidfile /var/symas/run/slapd.pid
argsfile /var/symas/run/slapd.args
database ldap
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldap://192.168.56.201:389"
suffix "dc=example1,dc=net"
rootdn "cn=admin,dc=example1,dc=net"
idassert-bind bindmethod=simple
mode=none
binddn="CN=Administrator,cn=users,dc=example1,dc=net"
credentials=Passw0rd
tls_cacertdir=/opt/symas/etc/openldap
tls_reqcert=never
idassert-authzFrom "*"
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixAccount person
overlay memberof
memberof-group-oc groupOfuniqueNames
memberof-member-ad uniquemember
memberof-dangling error
overlay pcache
pcache mdb 100000 6 1000 100
pcachePersist TRUE
directory "/var/symas/pcache"
pcacheAttrset 0 1.1
pcacheTemplate (uid=) 0 3600
pcacheTemplate (&(|(objectClass=))) 0 3600
pcacheAttrset 1 employeetype givenName cn sn uid mail
pcacheTemplate (uid=) 1 3600
pcacheBind (uid=) 1 3600 sub dc=de
pcacheAttrset 2 givenName cn sn uid mail uidNumber
pcacheTemplate (objectClass=) 2 3600
pcacheAttrset 3 userPassword
pcacheTemplate (uid=) 3 3600
pcacheTemplate (objectClass=) 2 3600
pcacheAttrset 4 employeetype givenName cn sn uid mail
pcacheTemplate (uid=) 1 3600
pcacheAttrset 5 memberOf
pcacheTemplate (objectClass=*) 2 3600
--------------------
Search for an entry in AD is working:
----------------------
root@ldap-proxy01:~/server-setup/proxy# ldapsearch -x -b
dc=example1,dc=net cn=administrator -LLL dn
dn: cn=Administrator,cn=Users,dc=example1,dc=net
----------------------
Now I want to convert it to cn=config but Im getting the following error:
--------------------
root@ldap-proxy01:/opt/symas/etc/openldap# slaptest -F ./my-slapd.d/ -f
slapd.conf
Entry
(olcDatabase={0}mdb,olcOverlay={2}pcache,olcDatabase={1}ldap,cn=config):
object class 'olcMdbBkConfig' requires attribute 'olcBackend'
config_build_entry: build "olcDatabase={0}mdb" failed: "(null)"
config file testing succeeded
mdb_opinfo_get: err Permission denied(13)
--------------------
Then I try to create my own LDIFs:
basic config:
-----------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: any
olcPidFile: /var/symas/run/slapd.pid
olcArgsFile: /var/symas/run/slapd.args
olcToolThreads: 1
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/symas/lib/openldap
olcModuleLoad: back_mdb
olcModuleLoad: back_ldap
olcModuleLoad: back_monitor
olcModuleLoad: argon2
include: file:///opt/symas/etc/openldap/schema/core.ldif
include: file:///opt/symas/etc/openldap/schema/cosine.ldif
include: file:///opt/symas/etc/openldap/schema/nis.ldif
include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
include: file:///opt/symas/etc/openldap/schema/msuser.ldif
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcSizeLimit: 500
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by * break
olcAccess: {1}to dn="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"
by dn.exact=cn=admin,cn=config read
by dn.exact=cn=admin,dc=example,dc=net read
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth read
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=example1,dc=net
olcAddContentAcl: FALSE
olcLastMod: FALSE
olcLastBind: FALSE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: TRUE
olcRootDN: cn=admin,dc=example1,dc=net
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
olcDbURI: "ldap://dc-net01.example.net:389"
olcDbStartTLS: none starttls=no
olcDbIDAssertBind: mode=none flags=prescriptive,proxy-authz-non-critical
bindm
ethod=simple timeout=0 network-timeout=0
binddn="cn=administrator,cn=users,dc
=example1,dc=net" credentials="Passw0rd" keepalive=0:0:0
tcp-user-timeout=0 t
ls_cacertdir="/opt/symas/etc/openldap" tls_reqcert=never
tls_reqsan=allow tls
_crlcheck=none
olcDbIDAssertAuthzFrom: *
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: FALSE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
-----------------
LDIF for rwm
------------------
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm.la
dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: {0}rwm
olcRwmTFSupport: false
olcRwmMap: {0}objectClass posixAccount person
olcRwmMap: {1}attribute uid sAMAccountName
------------------
LDIF for pcache
------------------
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: pcache.la
dn: olcOverlay={3}pcache,olcDatabase={2}ldap,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcPcacheConfig
olcOverlay: {3}pcache
olcPcache: mdb 100000 5 1000 100
olcPcacheAttrset: 0 employeeType givenName cn sn uid mail
olcPcacheAttrset: 1 givenName cn sn uid mail uidNumber
olcPcacheAttrset: 2 userPassword
olcPcacheAttrset: 3 employeeType givenName cn sn uid mail
olcPcacheAttrset: 4 memberOf
olcPcacheTemplate: "(objectClass=*)" 2 3600 0 0 0
olcPcacheTemplate: (&(objectClass=)(memberUid=)) 2 300
olcPcacheTemplate: (&(objectClass=)(uid=)) 0 300
dn: olcDatabase=mdb,olcOverlay={3}pcache,olcDatabase={2}ldap,cn=config
changetype: add
objectClass: olcMdbConfig
objectClass: olcPcacheDatabase
olcDbDirectory: /var/symas/pcache
olcDbIndex: pcacheQueryID eq
------------------
But wenn I do a ldapsearch I got the following result:
----------------
root@ldap-proxy01:~/server-setup/proxy# ldapsearch -x -b
dc=example1,dc=net cn=administrator -LLL dn
# refldap://example1.net/CN=Configuration,DC=example1,DC=net
# refldap://example1.net/DC=DomainDnsZones,DC=example1,DC=net
# refldap://example1.net/DC=ForestDnsZones,DC=example1,DC=net
----------------
I only got the Referrals from AD, but not the object I'm looking for.
It's nearly impossible to find a good documentation on how to setup
pcache overlay via cn=config. As i said with slapd.conf everyting works.
Any hint that get things working as expected?
When I'm starting the slapd the log is showing:
-----------
mdb_db_open: database "dc=example1,dc=net": dbenv_open(/var/symas/pcache).
-----------
Same Server different problem
I did not add memberof, because everytime I add the overlay with the
following LDIF (should be replaced by dynlist in the near future) But I
think it should work:
--------------
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: memberof.la
dn: olcOverlay={1}memberof,olcDatabase={2}ldap,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcMemberOfConfig
olcOverlay: {1}memberof
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
--------------
The slapd chrashes and "slapcat -n0" is giving e the following error:
---------------
root@ldap-proxy01:~/server-setup/proxy# slapcat -n0
olcAttributeTypes: value #741 olcAttributeTypes: Duplicate
attributeType: " z*V"
config error processing cn={4}msuser,cn=schema,cn=config:
olcAttributeTypes: Duplicate attributeType: " z*V"
slapcat: bad configuration file!
---------------
2 years, 2 months
Re: Slapd Security based on port
by harry.jede＠arcor.de
Chris Jackson wrote:
> On Feb 16, 2011, at 3:46 AM, <harry.jede(a)arcor.de>
>
> <harry.jede(a)arcor.de> wrote:
> > Chris Jackson wrote:
> >> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
> >>
> >> Is it possible to prevent anonymous and unauthenticated binds to
> >> ldaps:// 636 but allow them on ldap:// 389?
> >>
> >> I want to allow staff to query my ldaps:// outside of my network
> >> while requiring them to login to do so but allow anyone to bind
> >> (anonymous, unauthenticated, or authenticated) internally on
> >> ldaps//: 389.
> >>
> >> I know:
> >> Anonymous bind can be disabled by "disallow bind_anon" and
> >> Unauthenticated bind mechanism is disabled by default. But if I
> >> use "disallow bind_anon it stops in on both ports.
> >
> > Sure, this are global directives.
> >
> >> I want to stop it just on ldaps://.
> >
> > You don't need ldaps:// in your local network? May be.
> > I think a easier solution is to identify your Internet Gateway by
> > IP.
> >
> >> Chris Jackson
> >>
> >>
> >> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
> >>
> >> Stopping users that are "unauthenticated" makes no sense;
> >> everything's unauthenticated at time=0. You might as well stop
> >> slapd if you want a 100% inability to serve data.
> >>
> >> You can deny anonymous users that aren't plaintext, including any
> >> ldaps:/// connections, with something like:
> >>
> >> access to *
> >> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
> >> by anonymous none
> >>
> >> early on in your ACL stanzas. I'm pretty sure this'll deny
> >> anonymous StartTLS users on 389, though; not sure if that's what
> >> you want. I can't think of any way to use the slapd access
> >> language to differentiate based on listeners, which would probably
> >> be the most elegant way to handle what you asked. To be fair, this
> >> entire exercise seems really odd from where I sit -- are you
> >> positive that this will have the desired effect? (If somebody out
> >> in Peru is permitted to connect in unencrypted and make anonymous
> >> queries, why not allow them to make those same queries encrypted?
> >> What's the difference?)
> >>
> >> here is a scenario:
> >>
> >> Site has a ldap server on ldap://389. Firewall blocks access to
> >> 389 from internet. Everyone queries the ldap via anonymous binds.
> >> Site would like to allow staff the ability to query the ldap
> >> from outside the firewall. This would be done via ldaps:// 636 to
> >> users who have authenticated via username/password. They do not
> >> want to allow anonymous queries outside the firewall.
> >>
> >> Using the "disallow bind_anon" would prevent anon binds on both
> >> ldap:// and ldaps://. This would break the inside machines
> >> ability to query. If we dont use "disallow bind_anon" then
> >> machines outside of the firewall could query the ldap.
> >>
> >> ---Is the only option for them to setup two separate ldap servers?
> >
> > No. You should use ACLs to solve this problem. Read man
> > slapd.access an/or search the openldap archives.
> >
> > Assuming you have a NAT gatway as Firewall machine.
> >
> > Replace all "by anonymous" statements with these 6 statements:
> >
> > by anonymous auth continue
> > by peername.ip="127.0.0.1" read continue
> > by peername.ip="10.0.0.0%255.0.0.0" read continue
> > by peername.ip="172.16.0.0%255.240.0.0" read continue
> > by peername.ip="192.168.0.0%255.255.0.0" read continue
> > by peername.ip="gateway-ip" auth
> >
> > One may write these statements more effective, but in general they
> > will do.
> >
> >
> > Replace "gateway-ip" with yours.
> >
> > Put the above statements also in every ACL just before the
> > by *
> > when this ACL do NOT have an "by anonymous" statement.
> >
> > Maybe the last line could/should be:
> > by ssf=56 peername.ip="gateway-ip" auth
> >
> > Caveats:
> > Your gateway can no longer access your LDAP Server with
> > the "gateway-ip". But this is a Firewall Design Question.
> >
> > I've tested this only with unencrypted sessions; anoymous and
> > authenticated. But TLS or SSL will not grant more rights, if you do
> > not tell the ACLs to do so.
> >
> >
> > Here the output from the two searches:
> >
> > # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
> > Insufficient access (50)
> >
> > # ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
> > cn=admin,dc=kronprinz,dc=xx -W
> > dn: dc=kronprinz,dc=xx
> >
> > dn: cn=admin,dc=kronprinz,dc=xx
> >
> >> One with "disallow bind_anon" and one without. Then only open the
> >> firewall for port 636 to the ldap server which has "disallow
> >> bind_anon".
> >>
> >> Chris Jackson
> >
> > --
> >
> > Harry Jede
>
> The above example got me started in the right direction.
fine, but have you read "man slapd.access"?
> Everything appears to be doing exactly what I wanted to do.
I can not believe.
> I did notice that
> the anonymous bind users from ip addresses not 10, give an error 32.
> Anyone see any flaws in this?
When you got errors, then something must be wrong.
> The below ACL should be allowing anon binds when ip address is
> 10.*.*.* or allow authenticated binds from any ip address.
>
>
access to attrs=userpassword
by anonymous auth
by self read
by * none
access to *
by anonymous auth continue
by peername.ip="10.0.0.0%255.0.0.0" read
by users read
by * none
This looks better. ACLs are evaluated in order. The continue clause
extends the current line with the folloing line. So both are just one
ACL statement.
This is OK:
by anonymous auth continue
by peername.ip="10.0.0.0%255.0.0.0" read
This is bad:
by anonymous auth continue
by users read
Here you try to extend anonymous with users; which will not work.
BTW
These ACLs does not allow any user to change his password by himself.
> Chris
--
Harry Jede
14 years, 3 months