RE: ACL doesn't work on my Centos 6
by Dong Xi
Hi Quanah,
I am using RHEL build, so in this case, slaps.conf. Can you please tell me how to apply the ACL in my case (disable anonymous access to any except rootdn, and allow self and bind user write to userPassword)? I am new to openldap, any help is really appreciated.
dxi
-----Original Message-----
From: "Quanah Gibson-Mount" <quanah(a)zimbra.com>
Sent: 2014-08-04 12:31
To: "Dong Xi" <dxi188(a)gmail.com>; "openldap-technical(a)openldap.org" <openldap-technical(a)openldap.org>
Subject: Re: ACL doesn't work on my Centos 6
--On Saturday, August 02, 2014 10:39 PM -0400 Dong Xi <dxi188(a)gmail.com>
wrote:
>
>
>
> Hi,
>
> Just set up openldap on my CentOS 6.5.
Are you using the RHEL build of OpenLDAP or your own? If you are using the
RHEL build, be aware that it uses cn=config, not slapd.conf, so making
changes to slapd.conf will not have any effect.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 4 months
Need help in undertsanding server certification verification by the client
by SOMA SEKHAR
Hi ,
I have my ca cert in a dir and I am setting the CACERTDIR option in
openldap global options.
*ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR, <my dir path>)*.
After that , I started the tls connection using '*ldap_start_tls_s*' ,
followed by '*ldap_bind_s*'. This worked fine.
What I did not understand is that , even after removing the ca cert from
that directory , ldap bind succeeds. Does it mean that certificate
verification is not done for the second time by SSL_connect?
I have just started on openldap and gone through the code in version 2.4
and openssl-fips-1.2 , searched in google,stackoverflow etc .
Can anyone please help me with some information or pointers on this.
--
Thanks&Regards,
SomaSekhar.
9 years, 4 months
Re: Will lmdb suit my needs ?
by Florian Weimer
* Sankar P.:
> SELECT DISTINCT column2 FROM autocomplete WHERE column1 LIKE
> '<prefix>%' ORDER BY column3 DESC LIMIT 5
>
> where column1 and column2 are strings and column3 is int.
>
> So, what my query essentially does is get a prefix string from user
> and get the top (sorted by column3) 5 records where column1 start with
> the input prefix and return the column2 of those records.
>
> In my sqlite, the first time query for each key (a or b or c ...) is
> taking about 350 seconds (with an index on all columns) and about 500
> seconds (with an index on only column1).
Do you use PRAGMA case_sensitive_like? How many candidate does the
"column1 LIKE '<prefix>%'" expression select?
9 years, 4 months
ACL doesn't work on my Centos 6
by Dong Xi
Hi,
Just set up openldap on my CentOS 6.5. Looks like very easy to set up. And
it is working. However, I found ACL doesn't work as expected. I am trying
to disable read access to anonymous, and give userPassword write access to
self and binduser. But it doesn't work: anonymous can still read whole ldap
entries, and no one except cn=Manager,dc=domain,dc=com can change
userPassword. I even change following section to access to * by * none to
lock down ldap, but still anonymous can read all.
===
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
by users read
by anonymous auth
===
to
===
access to * by * none
===
Here is the complete slapd.conf. Look like only default ACL works, whatever
ACL policy I am trying to apply. Please help.
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
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
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 * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=domain,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=com"
rootpw {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
loglevel 256
sizelimit unlimited
# 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 {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
# 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
9 years, 4 months
Groups in ACLs on MDB
by Johannes Löthberg
Hello,
I've been trying to get using groups working in ACLs, but no matter what
I do the group ACL isn't applied. It seems it might be a LMDB bug, and
I'm planning on switching to hdb to see if it works there when I get the
time.
I've attached the olcAccess.ldif that doesn't work and the output of
slapacl -D uid=kyrias,ou=users,dc=kyriasis,dc=com \
-b ou=users,dc=kyriasis,dc=com -dacl
which shows that the group ACL isn't applied to the user
uid=kyrias,ou=users,dc=kyriasis,dc=com even tho it is a member of the
cn=admins,ou=security,dc=kyriasis,dc=com group and that the 'to *' ACL
is above the other ones.
--
Sincerely,
Johannes Löthberg
PGP Key ID: 3A9D0BB5
9 years, 4 months
Password Failure for one user
by brown wrap
I am trying to track down why one user all of a sudden can't log into a machine. He can use his LDAP passwd through our network, but gets an immediate login failure on a particular machine. I can 'su' to his account, from my account using his password, but when I try to log into this machine remotely, I get the failure and it terminates the sessions. There have been no changes to the system at all. I am looking for step to troubleshoot this issue. Thanks.
9 years, 4 months
Q: cn=Connection 0,cn=Connections,cn=Monitor
by Ulrich Windl
Hi!
I'm browsing the monitor database for routine, and I founf this "Connectio 0":
# Connection 0, Connections, Monitor
dn: cn=Connection 0,cn=Connections,cn=Monitor
monitorConnectionNumber: 0
monitorConnectionProtocol: 0
monitorConnectionOpsReceived: 4
monitorConnectionOpsExecuting: 0
monitorConnectionOpsPending: 0
monitorConnectionOpsCompleted: 4
monitorConnectionGet: 6
monitorConnectionRead: 6
monitorConnectionWrite: 0
monitorConnectionMask: L
monitorConnectionListener:
monitorConnectionPeerDomain: unknown
monitorConnectionPeerAddress: unknown
monitorConnectionLocalAddress:
monitorConnectionStartTime: 19700101000000Z
monitorConnectionActivityTime: 19700101000000Z
Is it a bug that Start and Activity time are both unset? If the reads and writes of the connection can be counted, the timestamps could be updated as well, I guess. It's 2.4.26 here, so maybe it has been fixed meanwhile...
I just saw that I have a second "connection 0":
# Connection 0, Connections, Monitor
dn: cn=Connection 0,cn=Connections,cn=Monitor
monitorConnectionNumber: 0
monitorConnectionProtocol: 0
monitorConnectionOpsReceived: 4
monitorConnectionOpsExecuting: 0
monitorConnectionOpsPending: 0
monitorConnectionOpsCompleted: 4
monitorConnectionGet: 6
monitorConnectionRead: 6
monitorConnectionWrite: 0
monitorConnectionMask: L
monitorConnectionListener:
monitorConnectionPeerDomain: unknown
monitorConnectionPeerAddress: unknown
monitorConnectionLocalAddress:
monitorConnectionStartTime: 19700101000000Z
monitorConnectionActivityTime: 19700101000000Z
Doing a simple quick-and-dirty test, I found out that I have multiple "Connection 0"s:
sh monitor2.sh |grep '^# Connection' |sort -n
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 0, Connections, Monitor
# Connection 1000, Connections, Monitor
# Connection 1001, Connections, Monitor
# Connection 1008, Connections, Monitor
# Connection 1013, Connections, Monitor
# Connection 1016, Connections, Monitor
# Connection 1017, Connections, Monitor
# Connection 1018, Connections, Monitor
# Connection 1020, Connections, Monitor
# Connection 1021, Connections, Monitor
# Connection 1024, Connections, Monitor
# Connection 1036, Connections, Monitor
# Connection 1040, Connections, Monitor
# Connection 1042, Connections, Monitor
# Connection 1043, Connections, Monitor
# Connection 1118, Connections, Monitor
# Connection 1201, Connections, Monitor
# Connection 1247, Connections, Monitor
# Connection 1380, Connections, Monitor
# Connection 14755, Connections, Monitor
# Connection 14758, Connections, Monitor
# Connection 15369, Connections, Monitor
# Connection 15800, Connections, Monitor
# Connection 15886, Connections, Monitor
# Connection 16674, Connections, Monitor
# Connection 20526, Connections, Monitor
# Connection 20626, Connections, Monitor
# Connection 21044, Connections, Monitor
# Connection 21460, Connections, Monitor
# Connection 21474, Connections, Monitor
# Connection 21688, Connections, Monitor
# Connection 25846, Connections, Monitor
# Connection 30396, Connections, Monitor
# Connection 30665, Connections, Monitor
# Connection 31948, Connections, Monitor
# Connection 35407, Connections, Monitor
# Connection 35953, Connections, Monitor
# Connection 36575, Connections, Monitor
# Connection 36576, Connections, Monitor
# Connection 36577, Connections, Monitor
# Connection 36648, Connections, Monitor
# Connection 50382, Connections, Monitor
# Connection 50599, Connections, Monitor
# Connection 50706, Connections, Monitor
# Connection 51477, Connections, Monitor
# Connection 55650, Connections, Monitor
# Connection 55651, Connections, Monitor
# Connection 56206, Connections, Monitor
# Connection 61141, Connections, Monitor
# Connection 61144, Connections, Monitor
# Connection 61152, Connections, Monitor
# Connection 61153, Connections, Monitor
# Connection 61162, Connections, Monitor
# Connection 61163, Connections, Monitor
# Connection 61164, Connections, Monitor
# Connection 61165, Connections, Monitor
# Connection 61166, Connections, Monitor
# Connection 61167, Connections, Monitor
# Connection 61168, Connections, Monitor
# Connection 62161, Connections, Monitor
# Connection 65286, Connections, Monitor
# Connection 67224, Connections, Monitor
# Connection 70109, Connections, Monitor
# Connection 70162, Connections, Monitor
# Connection 70516, Connections, Monitor
# Connection 70528, Connections, Monitor
# Connection 70529, Connections, Monitor
# Connections, Monitor
Regards,
Ulrich
9 years, 4 months
Antw: Setting up Monitor Backend
by Ulrich Windl
>>> Leonard Smith <lrsmith(a)umich.edu> schrieb am 31.07.2014 um 21:52 in Nachricht
<CAP9L-w5pR5z80_aTgt_ux2xUpH4gu-kA_Y5zd2VZuNfE9kgfQg(a)mail.gmail.com>:
> To all,
>
> I'm trying to setup the monitoring backend so I can get metrics in OpenLDAP
> 2.4.23 on Centos 6. I have it setup and I can query but I don't seem to be
> getting any metrics/values. I check the olcAccess rules and it should be
> allowing access so I"m not sure why I cannot see any values for any of the
> monitoring points.
>
>
> sh-4.1# ldapsearch -Y EXTERNAL -H ldapi:/// -b
> 'cn=Total,cn=Connections,cn=Monitor'
Hi!
Try " ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Total,cn=Connections,cn=monitor' -s sub '(objectClass=*)' monitorCounter". I got:
# Total, Connections, Monitor
dn: cn=Total,cn=Connections,cn=Monitor
monitorCounter: 70315
Regards,
Ulrich
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> # extended LDIF
> #
> # LDAPv3
> # base <cn=Total,cn=Connections,cn=Monitor> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # Total, Connections, Monitor
> dn: cn=Total,cn=Connections,cn=Monitor
> objectClass: monitorCounterObject
> cn: Total
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> dn: olcDatabase={1}monitor
> objectClass: olcDatabaseConfig
> olcDatabase: {1}monitor
> olcAddContentAcl: FALSE
> olcLastMod: TRUE
> olcMaxDerefDepth: 15
> olcReadOnly: FALSE
> olcSyncUseSubentry: FALSE
> olcMonitoring: FALSE
> structuralObjectClass: olcDatabaseConfig
> entryUUID: 4313fd2c-b0ec-1032-8c14-c907d74f027d
> creatorsName: cn=config
> createTimestamp: 20130913181549Z
> olcAccess: {0}to * by
> dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by
> dn.base="cn=manager
> ,dc=foo,dc=com" read by dn.base="cn=monitor,dc=foo,dc=com" read by * none
9 years, 4 months
