[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with K5KEY implementation

To: Kent Nasveschuk <knasveschuk@mbl.edu>
Subject: Re: Problem with K5KEY implementation
From: Howard Chu <hyc@symas.com>
Date: Wed, 05 Dec 2007 06:02:36 -0800
Cc: OpenLDAP <openldap-software@openldap.org>
In-reply-to: <1196786271.3338.47.camel@mbl2.klnc.net>
References: <1196786271.3338.47.camel@mbl2.klnc.net>
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9b2pre) Gecko/2007111122 SeaMonkey/2.0a1pre

Kent Nasveschuk wrote:

Hello,

I'm having a problem with OpenLDAP using Heimdal Kerberos via the
{K5KEY} entry in userPassword. The problem is with the second KDC, works
fine on the master LDAP/KDC just not the second one.

Some info:
This is an OpenLDAP server with Heimdal storing Kerberos stuff in LDAP.
Master (mbauth01) Slave (mblauth02)
OSs: CentOS5
OpenLDAP 2.3.39
Heimdal 1.0.1

On the second KDC I can use kadmin -l and do klist -l Princ and get
results fine, so I know that the KDC can talk to the LDAP backend via
ldapi.

I don't think it is acls because I removed all and get the same result.

From a remote machine if I search the master:


ldapsearch -Z -x  -h mblauth01.mbl.edu -b ou=users,dc=mbl,dc=edu -D
cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn

I get results

From a remote machine if I search the slave:


ldapsearch -Z -x  -h mblauth02.mbl.edu -b ou=users,dc=mbl,dc=edu -D
cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn

I get:
ldap_bind: Invalid credentials (49)

It doesn't look like the mechanism in LDAP that refers userPassword with
{K5KEY} to KDC is working on the slave machine. A couple things might
cause this to fail.

The K5KEY mechanism doesn't refer any requests to any KDC. It directly processes Kerberos data that a KDC has stored in LDAP.


The {K5KEY} entry never made it from the Master to the slave via
syncrepl. I verified that the entries are there. I also changed a
password using kadmin cpw and verified that the change was replicated to
the slave and they were.

Any suggestions on how to troubleshoot this or get it working.


Yes. Reread the smbk5pwd/README file.

Your slave slapd.conf is missing the "overlay smbk5pwd" statement.

Couple things about slapd.conf. I added write access to ldapi which
should be read on the slave. The password-hash directive not quite sure
what that should be set at. On the master it works fine with this
omitted.

slapd.conf on slave:

include         /opt/openldap-2.3.39/etc/openldap/schema/core.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/cosine.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/inetorgperson.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/nis.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/autofs.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/samba.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/RADIUS-LDAPv3.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/hdb.schema
#include                /opt/openldap-2.3.39/etc/openldap/schema/rfc822.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/qmail.schema
include         /opt/openldap-2.3.39/etc/openldap/schema/mblPerson.schema

schemacheck on
sasl-realm      MBL.EDU
sasl-host       mblauth02.mbl.edu
sasl-authz-policy       both
sasl-regexp "uidNumber=0\\\
+gidNumber=.*,cn=peercred,cn=external,cn=auth"
        "cn=admin,ou=users,dc=mbl,dc=edu"
# logLevel 128(ACL proc) + 32(search filter) + 64(config proc)
# loglevel 256(stats log connections/operations/results) + 8 (connection
mamangement)
#loglevel       288
loglevel       64
allow bind_v2

#modulepath      /opt/openldap-2.3.39/libexec/openldap
moduleload              /opt/openldap-2.3.39/lib/smbk5pwd.la
pidfile         /opt/openldap-2.3.39/var/run/slapd.pid
argsfile        /opt/openldap-2.3.39/var/run/slapd.args
password-hash {CLEARTEXT} {SSHA} {CRYPT}

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

database        hdb
suffix          "dc=mbl,dc=edu"
rootdn          "cn=admin,ou=users,dc=mbl,dc=edu"
rootpw          "secret"
directory       /opt/openldap-2.3.39/var/openldap-data

syncrepl rid=111
        provider=ldaps://mblauth01.mbl.edu:636
        type=refreshAndPersist
        interval=00:00:01:00
        scope sub
        searchbase="dc=mbl,dc=edu"
        bindmethod=simple
        updatedn="uid=syncrepl,ou=Users,dc=mbl,dc=edu"
        binddn="uid=syncrepl,ou=Users,dc=mbl,dc=edu"
        credentials=secret
updateref       ldaps://mblauth01.mbl.edu:636


index   objectClass                             eq
index   cn                                      pres,sub,eq
index   sn                                      pres,sub,eq
index   givenName                               pres,sub,eq
index   uid                                     pres,sub,eq
index   sambaPrimaryGroupSID                    eq
index   sambaSID                                eq
index   sambaDomainName                         eq
index   uidnumber                               eq
index   gidNumber                               eq
index   sambaHomePath                           eq
index   entryUUID                               eq
index   automountinformation                    eq
index   proxNumber                              eq
index   krb5PrincipalName,krb5PrincipalRealm    eq
index   memberUid                               eq
index   default                                 sub

limits dn.exact="uid=Devicemgr,ou=users,dc=mbl,dc=edu"
        size=unlimited
        time=unlimited
limits  dn.exact="uid=syncrepl,ou=users,dc=mbl,dc=edu"
        size=unlimited
        time=unlimited
limits  dn.exact="uid=onecard,ou=users,dc=mbl,dc=edu"
        size=unlimited
        time=unlimited

access to dn.subtree="ou=users,dc=mbl,dc=edu"
attrs=userPassword,sambaNTPassword,sambaLMPassword,proxNumber,employeeNumber
        by self read
        by sockurl.exact=ldapi:/// write
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by anonymous auth
        by * none

access to dn.subtree="ou=users,dc=mbl,dc=edu"
attrs=krb5key,krb5EncryptionType,krb5PasswordEnd,krb5KeyVersionNumber,krb5ValidEnd
        by sockurl.exact=ldapi:/// write
        by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by self read
        by * none

access to dn.subtree="ou=Groups,dc=mbl,dc=edu"
        by sockurl.exact=ldapi:/// write
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by anonymous auth
        by users read
        by * none

access to dn.subtree="ou=Devices,ou=Network,dc=mbl,dc=edu"
        by sockurl.exact=ldapi:/// write
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by
group.exact="cn=mac_admins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu"
read
        by anonymous auth
        by self read
        by * none

access to dn.subtree="ou=Servers,ou=Network,dc=mbl,dc=edu"
        by sockurl.exact=ldapi:/// write
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by anonymous auth
        by self read
        by * none

access to dn.subtree="ou=Computers,ou=Network,dc=mbl,dc=edu"
        by sockurl.exact=ldapi:/// write
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by dn="uid=search,ou=users,dc=mbl,dc=edu" read
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by anonymous auth
        by self read
        by * none
access to *
        by sockurl.exact=ldapi:/// write
        by self read
        by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read
        by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write
        by
group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read
        by users read
        by * none


TLSCipherSuite  HIGH:MEDIUM:LOW:+SSLv2+TLSv1
# CA cert file
TLSCACertificateFile    /opt/openldap-2.3.39/etc/openldap/cacert.pem
# Signed cert file
TLSCertificateFile      /opt/openldap-2.3.39/etc/openldap/newcert.pem
# Private key
TLSCertificateKeyFile   /opt/openldap-2.3.39/etc/openldap/newkey.pem

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/

References:
- Problem with K5KEY implementation
  - From: Kent Nasveschuk <knasveschuk@mbl.edu>

Prev by Date: [Fwd: Re: KDC {K5KEY} userPassword problem] Solved!!
Next by Date: Re: [Fwd: Re: KDC {K5KEY} userPassword problem] Solved!!
Index(es):
- Chronological
- Thread