problems with openldap and TLS

rene04 · Post by **rene04** » 2011/09/27 12:36:47

Hi,

i have set up openldap server with this document:

http://home.roadrunner.com/~computertaijutsu/ldap.html#TLS

the client is set to TLS but when i try to login nothing happens. no ask for password. in the logs i found:

getent: nss_ldap: could not search LDAP server - Server is unavailable

when client is set up without TLS i can login with a username but when i do a ldapwhoami the stands anonymous.

i dont know where to start searching for the problem. perhaps someone of you could help me.

/etc/openldap/slapd.conf:
[code]
#
# 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:
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# modulepath /usr/lib/openldap # or /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
## To load this module, you have to install openldap-server-sql first
# moduleload back_sql.la
## Following two modules can't be loaded simultaneously
# 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 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/openldap/cacerts/ldap01.pem
TLSCertificateFile /etc/openldap/cacerts/ldap01.pem
TLSCertificateKeyFile /etc/openldap/cacerts/ldap01.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!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database bdb
suffix "dc=xxx,dc=local"
checkpoint 1024 15
rootdn "cn=manager,dc=xxx,dc=local"
# 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
rootpw {SSHA}xxx

# 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@EXAMPLE.COM

# enable monitoring
database monitor

# allow onlu rootdn to read the monitor
#access to *
# by dn.exact="cn=Manager,dc=xxx,dc=local" read
# by * read

access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=manager,dc=xxx,dc=local" write
by * none

access to *
by self write
by dn.base="cn=manager,dc=xxx,dc=local" write
by users read

[/code]

what is strange to: when i do a ldapsearch i get

[code]
ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found)
[/code]

when i do a ldapsearch -x i get all infos.

what can i do now? all i wanna have is an ldap server with working TLS. i dont know why i get an kerberos error message above.

greetings,

rene

rene04 · Post by **rene04** » 2011/09/27 13:41:52

Hi again,

i have started slapd in debugging mode and it shows me when i want to connect via TLS:

[code]
conn=0 fd=12 ACCEPT from IP=xxx.xxx.xxx.xxx:54849 (IP=0.0.0.0:389)
conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037
conn=0 op=0 STARTTLS
conn=0 op=0 RESULT oid= err=0 text=
conn=0 fd=12 TLS established tls_ssf=256 ssf=256
conn=0 op=1 UNBIND
conn=0 fd=12 closed
connection_read(12): no connection!
[/code]

perhaps that helps to find the problem.

greetings, rene

Post by **scottro** » 2011/09/27 17:49:05

That article was written for CentOS 5.x

If you're using 6.x, there some changes. Not sure what they are, I'm afraid, save for what's briefly mentioned in that article.

rene04 · Post by **rene04** » 2011/09/28 06:30:11

is there anywhwere a documentation for centos 6?

greetings, rene

rene04 · Post by **rene04** » 2011/09/28 08:19:50

Hi,

it seems like i fixed a little bit of my problems. I habe now used the common name of the ldap server instead of the ip in authconfig-tui and i set this name up in /etc/hosts. because of the certificate common name ;) now i geht this:

[code]
ldapsearch -x -H ldaps://ldap01.xxx.local -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=xxx,dc=local

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[/code]

now i can login as a user.

the next problem i have is that when i now login with a user and do a ldapwhoami i get anonymous. why that?

greetings, rene

r_hartman · Post by **r_hartman** » 2011/09/28 08:53:54

Never used ldapwhoami and don't have it installed on CentOS6. I do have it on CentOS5 and there it also returns 'anonymous'.
Just use 'id' or 'whoami'; these return the correct info.

rene04 · Post by **rene04** » 2011/09/28 09:07:10

Hi,

yes that works :) thanks. last but not least, when i try to change my password it wont work:

[code]
-bash-3.2$ passwd
Changing password for user xxx.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Insufficient access

passwd: Permission denied
[/code]

my access control:
[code]
access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=manager,dc=xxx,dc=local" write
by * none

access to *
by self write
by dn.base="cn=manager,dc=xxx,dc=local" write
by users read
[/code]

r_hartman · Post by **r_hartman** » 2011/09/28 09:45:54

Here are my access directives. Not sure where this would make a difference, as yours appear to be more loose.
In 'access to *' you have 'users' where I have '*'. And I have 'access to dn.base' defined as well.
Not sure I remember why; I did a lot of trial and error when setting up LDAP.
[code]access to attrs=userPassword
by dn="<root-dn>" write
by anonymous auth
by self write
by * none

access to attrs=shadowLastChange
by dn="<root-dn>" write
by self write
by * read

access to dn.base=""
by * read

access to *
by dn="<root-dn>" write
by * read[/code]

Edit: almost missed that you have 'access by dn.base=' where I have 'access by dn='.

rene04 · Post by **rene04** » 2011/09/28 11:12:05

Hi,

that seems not to be the problem. i have startet slapd wit -d 128 and when i try to change my password i get:

[code]
=> slap_access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access granted by read(=rscxd)
=> access_allowed: result not in cache (userPassword)
=> access_allowed: auth access to "uid=xxx,ou=People,dc=xxx,dc=local" "userPassword" requested
=> slap_access_allowed: backend default auth access granted to "(anonymous)"
=> access_allowed: auth access granted by read(=rscxd)
=> access_allowed: backend default write access denied to "uid=xxx,ou=People,dc=xxx,dc=local"
[/code]

what makes my thinking is "granted to anonymous". but i am logged in as a user.

greetings, rene

rene04 · Post by **rene04** » 2011/09/28 12:17:03

Hi,

i figured it out:

[code]
# enable monitoring
database monitor

# allow onlu rootdn to read the monitor
#access to *
# by dn.exact="cn=Manager,dc=xxx,dc=local" read
# by * read

access to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=manager,dc=xxx,dc=local" write
by * none

access to *
by self write
by dn.base="cn=manager,dc=xxx,dc=local" write
by users read
[/code]

the

# enable monitoring
database monitor

stands infront of the ACLs :-? changing this ...and i am able to change my password now.

greetings, rene

CentOS