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

RE: configure OpenLDAP to allow directory users - change pass



Tried it, like so:  ldappasswd -x -D
uid=testuser,ou=People,dc=mydomain,dc=com

And I tried: ldappasswd -x -D uid=testuser,ou=People,dc=mydomain,dc=com -w
newpassword

And I get this error each time: "additional info: unauthenticated bind (DN
with no password) disallowed"

Which means that the user can't change their own password, so I'm back to
where I started. 

I have this in my slapd.conf file:

#
# 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

# 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/slapd.pid
argsfile	/var/run/slapd.args

# Load dynamic backend modules:
# modulepath	/usr/sbin/openldap
# moduleload	back_bdb.la
# moduleload	back_ldap.la
# moduleload	back_ldbm.la
# moduleload	back_passwd.la
# moduleload	back_shell.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /usr/share/ssl/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 /usr/share/ssl/certs/ca-bundle.crt
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/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!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database	bdb
suffix		"dc=mydomain,dc=com"
rootdn		"cn=manager,dc=mydomain,dc=com"
# rootpw		secret
rootpw {SSHA}4O8ghrU5sdfIz4QJ/C676eIHZE4mDCI96c3K

# 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/mydomain.com

# 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

-----Original Message-----
From: openldap-software-bounces+diabeticithink=yahoo.com@OpenLDAP.org
[mailto:openldap-software-bounces+diabeticithink=yahoo.com@OpenLDAP.org] On
Behalf Of Kurt Zeilenga
Sent: Friday, September 14, 2007 10:22 AM
To: Anne Moore
Cc: openldap-software@openldap.org
Subject: Re: configure OpenLDAP to allow directory users - change pass


On Sep 14, 2007, at 3:17 PM, Anne Moore wrote:

> We've tried the ldappasswd on the clients and receive this error:
>
> "ldap_sasl_interactive_bind_s: Internal (implementation specific) 
> error (80) additional info: SASL(-13): user not found: no secret in 
> database"

Are you intending to use SASL?  If not, you simply are misusing
ldappasswd(1).  Read the manual page, especially the part about the - x
option.
>
> Obviously something is not configure correctly.
>
> Any ideas on this error?

Are you intending to use SASL?  Assuming not, you simply are misusing
ldappasswd(1).  You need to specify -x for ldappasswd(1) to perform a simple
DN/password authentication.  See the ldappasswd(1) for details.

-- Kurt