TLS, integrity and root DSE
by Ulrich Windl
Hi!
When trying to require integrity for LDAP connections by specifying "ssf=1" in Security, I have a problem with Perl where the cat bites its tail:
It's recommended to query the root DSE for TLS extension before trying to use TLS like this:
my $dse = $ldap->root_dse();
if ($dse->supported_extension(LDAP_EXTENSION_START_TLS)) {
my $msg = $ldap->start_tls('verify' => 'require',
'capath' => '/etc/ssl/certs');
...
Unfortunately the root_dse() fails with the security restriction: "confidentiality required"
Note: The manual says: "0 (zero) implies no protection, 1 implies integrity protection only"
So is "confidentiality" actually "integrity" here, and are here any solutions to this problem?
Regards,
Ulrich Windl
7 years, 9 months
root cannot change user password with command "passwd", sssd, pam, openldap
by Augustin Wolf
Hi list,
I'm using CentOs 6.4, and moved user management to OpenLDAP. As far as
it works fine for user - user can login, do `passwd` to change his
password, etc. - it fails for root to change users passwords. Root
have to use ldapmodify. Is
it normal behavior, or do I have some configuration errors?
For now, LDAP ACL was "turned off" - every user has manage permission.
I know it's a security issue, but I wanted to remove potential
interference. I will change this as soon as root can change users
password.
SELlinux was also turned off to eliminate it's potential interference.
Iptables was "turned off", as well, though I thing it doesn't matter
as long as port 389 is open.
My configs, logs, etc are in here: http://fpaste.org/26708/
Thanks in advance,
Augustyn
7 years, 9 months
undocumented TLSProtocolMin
by Manuel Gaupp
Hi,
OpenLDAP seems to support an undocumented configuration parameter "TLSProtocolMin" when linked against OpenSSL. It allows to set the minimum SSL/TLS protocol version:
* TLSProtocolMin 768 # (3 << 8) disables SSLv2
* TLSProtocolMin 769 # ((3 << 8)+1) disables SSLv2 and SSLv3
As there's no documentation for TLSProtocolMin:
Is this feature ready for production or is it experimental?
Best regards,
Manuel
7 years, 9 months
need help interpreting "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?"
by Steve Eckmann
The answer would be obvious if we had a misconfigured URI, but I don't think we do. In fact, we are getting this error from the ldap/translucent proxy on a first attempt to retrieve a DN from a remote Active Directory, then a second identical ldapsearch always succeeds. That makes us think there might be a timing issue getting from our openldap server, through a forwarding proxy out of a DMZ, and finally to the target AD server. But since all the openldap log messages appear with the same timestamp, there would have to be a sub-second timeout somewhere in the path. Does openldap have any default sub-second timeouts? I haven't configured any of the slapd or slapd-ldap timeout options.
Here is a typical log from a failed search:
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 ACCEPT from IP=172.20.11.85:54864 (IP=0.0.0.0:636)
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 TLS established tls_ssf=256 ssf=256
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 BIND dn="cn=localuser,ou=users,ou=Native,dc=example,dc=com" method=128
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 BIND dn="cn=localuser,ou=users,ou=Native,dc=example,dc=com" mech=SIMPLE ssf=0
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 RESULT tag=97 err=0 text=
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(sAMAccountName=steve.eckmann)"
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SRCH attr=cn
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 ldap_back_retry: retrying URI="ldap://172.30.11.20" DN="cn=remoteuser,ou=users,ou=system accounts,dc=example,dc=com"
Jul 15 09:46:09 eck1 slapd[9198]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?
Jul 15 09:46:09 eck1 slapd[9198]: <= mdb_equality_candidates: (sAMAccountName) not indexed
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=2 UNBIND
Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 closed
Thanks.
Steve
7 years, 9 months
cn=config chaining or authzTo Strong(er) authentication required (8)
by espeake＠oreillyauto.com
I am working on setting up a provider/consumer setup for openLDAP version
2.4.28. Everything seems to be working other than referrals. I can query
the consumers, I can write directly to the provider. But I get the
following when I try to sent a ldapmadify to a consumer and it refers it to
the provider.
ldapmodify -W -D "uid=ldapadmin,ou=system,dc=example,dc=com" -H
ldap://tntest-ldap.example.com -c -f /tmp/epseake.ldif
Enter LDAP Password:
modifying entry "uid=ESPEAKE,ou=Users,dc=example,dc=com"
ldap_modify: Strong(er) authentication required (8)
If I run the modify against the provider with the same credentials it will
modify the record. I have added authzTo dn.regex:^uid=
[^,]*,ou=system,dc=example,dc=com$. I also added authzTo
ldap:///dc=example,dc=com???(objectClass=top) This got rid of my error 10
on the referral but now it is asking for strong(er) authentication. I do
have certificates on my servers in the correct locations and
olcTLSCertificate statements with the directories for the certs and keys.
THis is the final step I hope in getting the test environment completed and
ready for testing. All help is appreciated.
Thank you,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
7 years, 9 months
OpenLdap from OpenCSW installation
by michał kępkowski
Hey,
Has anyone of you install OpenLdap from OpenCSW repositories on Solaris?
I've try to install using pkgutils:
pkgutil -yi CSWopenldap
than I read something more an add
pkgutil -iy berkeleydb48
pkgutil -i CSWopenldap-back-bdb
however my slaptest shows
Unrecognized database type (bdb)
51ed5c62 /etc/opt/csw/openldap/slapd.conf: line 53: <database> failed init
(bdb)
Line 53 is the beginning of database configuration:
database bdb
Do you have any ideas? Am I configured something bad?
7 years, 9 months
Slapd starts with "-h" not working as described
by Nathanel Sulimanov
Hi,
I am trying to configure /etc/sysconfig/ldap with following:
SLAPD_LDAP=no
SLAPD_URLS="ldap://${HOSTNAME} ldaps://${HOSTNAME} ldap://127.0.0.1" ---> This works and Slapd start ok.
But While using:
SLAPD_URLS="ldap://${HOSTNAME} ldaps://${HOSTNAME} ldap://localhost" ---> Does NOT work.
My /etc/hosts looks like this:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
following RPM installed:
openldap-2.4.34-1.el6.x86_64
openldap-clients-2.4.34-1.el6.x86_64
openldap-servers-2.4.34-1.el6.x86_64
And one more issue:
How I could verify that ldap server start with proper olcServerID ?
Is there any logging should be enabled and what values to look for ?
How I could present olcServerID along with ldap://${HOSTNAME} ldaps://${HOSTNAME} ldap://127.0.0.1 command ?
Regards,
7 years, 9 months
Re: ldap syncrepl issue.
by Ashok Kumar Shah
I am running OpenLDAP 2.4.23. Looks like syncrepl has stuck i am seeing
this message from last 2 days every minute i see this message popping up on
the logs perhaps this the reason of huge slave lag is 2 days and some
hours. Is there a fix for this?
*syncrepl_message_to_op: rid=011 be_modrdn
uid=user.name,ou=xxxxx,dc=xxxx,dc=com
(68)*
* do_syncrepl: rid=011 rc 68 retrying*
*
*
Thanks,
Ashok
On Fri, Jul 12, 2013 at 9:26 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Friday, July 12, 2013 5:40 PM +0530 Ashok <ashok.shah(a)flipkart.com>
> wrote:
>
>
>>
>>
>>
>>
>> Hi,
>>
>> I am running ldap master and multiple slave with RefreshandPersist config.
>> ldap search for an user shows different set of records. ContextCSN on
>> master and slave are exactly same.
>> What can i do to fix this. I tried restarting slave ldap but didn't help.
>> Also i keep getting do_syncrepl: rid=112 rc 68 retrying every minute. I
>> doubt if there is replication issue.
>>
>
> It sounds like it is resyncing the DB, and skipping entries that already
> exist: LDAP_ALREADY_EXISTS is error code 68.
>
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
7 years, 9 months
Antw: Q: Multi-Master setup
by Ulrich Windl
>>> I wrote on 16.07.2013 at 09:02:
[...]
> 2) What is the correct syntax for the second argument (URI): Do you need a
> final slash, do you need the port? Currently I'm using a syntax like
> "olcServerID: 1 ldap://ldap.domain.org"
[...]
As nobody did answer, I guess nobody knows how the server matches the ServerID. So let me ask a diffenent question:
(How) can I query the ServerID a server uses?
Regards,
Ulrich
7 years, 9 months
Openldap-2.4.33 bind problem
by Darouichi, Aziz
Hi all,
I am trying to bind openldap-2.4.33 to vendor SSO using simple bind and I am getting invalid credentials. I have reset the rootdn password more than once to make sure there were no typos, and I am still getting same Invalid Credentials error.
This is a copy of my slapd.conf
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /opt/local/etc/openldap/schema/core.schema
include /opt/local/etc/openldap/schema/ppolicy.schema
# Define global ACLs to disable default read access.
include /opt/local/etc/openldap/schema/cosine.schema
include /opt/local/etc/openldap/schema/nis.schema
include /opt/local/etc/openldap/schema/inetorgperson.schema
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /opt/local/var/run/slapd.pid
argsfile /opt/local/var/run/slapd.args
sizelimit unlimited
#serverID 1
allow bind_v2
loglevel sync
"/opt/local/etc/openldap/slapd.conf" 180L, 5417C
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /opt/local/etc/openldap/schema/core.schema
include /opt/local/etc/openldap/schema/ppolicy.schema
# Define global ACLs to disable default read access.
include /opt/local/etc/openldap/schema/cosine.schema
include /opt/local/etc/openldap/schema/nis.schema
include /opt/local/etc/openldap/schema/inetorgperson.schema
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
# Load dynamic backend modules:
# modulepath /opt/local/libexec/openldap
# moduleload back_bdb.la
# moduleload back_hdb.la
# moduleload back_ldap.la
#modulepath /usr/lib/openldap
#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 syncprov
#moduleload translucent.la
moduleload unique.la
moduleload valsort.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# 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!
# CA singed Certificate and server cert entries:
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /opt/local/etc/openldap/cacert.pem
TLSCertificateFile /opt/local/etc/openldap/ldap-tls.curry.edu.cert.pem
TLSCertificateKeyFile /opt/local/etc/openldap/ldap-tls.curry.edu.key.pem
# Clinet verification not required
#TLSVerifyClient never
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=curry,dc=edu"
rootdn "cn=ldap,dc=curry,dc=edu"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}gMePUFraA8Fjn63t8FzpYHbp+6g8N6Mz
#access to *
# by dn.base="cn=ldap,dc=curry,dc=edu" read
# by * break
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /opt/local/var/openldap-data
syncrepl rid=006
provider=ldap://192.168.60.42
tls_cert=/etc/pki/tls/certs/ldap-tls.curry.edu.cert.pem
tls_key=/etc/pki/tls/private/ldap-tls.curry.edu.key.pem
tls_cacert=/etc/pki/tls/certs/cacert.pem
tls_reqcert=demand
searchbase="dc=curry,dc=edu"
schemachecking=on
timelimit=unlimited
sizelimit=unlimited
type=refreshAndPersist
retry="60 +"
# Index to maintain
index entryUUID eq
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres
index nisMapName,nisMapEntry eq,pres,sub
#mirrormode TRUE
mirrormode on
# define the provider to use the syncprov overlay
# (last directives in database section)
overlay syncprov
# contextCSN saved to database every 100 updates or ten minutes
syncprov-checkpoint 100 1
syncprov-sessionlog 100
#################################################################################
# Password Policy #
################################################################################
#################################################################################
# This implies the password policy should be for the entire base DN
#ppolicy_default
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=curry,dc=edu"
# This implies the passwords should not be in clear text and this directive takes no parameters
ppolicy_hash_cleartex
7 years, 9 months
