Change user Password from an AIX on openLDAP server
by CASEIRO Philippe
Hello
I'm running openldap-2.3.43 on an RHEL 5.3 All works fine (like usual) with the linux clients but I have some troubles with AIX
I have done this tests with An AIX 5.3 TL9 host.
When I change my password with AIX it runs like that
[user@host] $ passwd
Changing password for "user"
user's Old password:
user's New password:
Enter the new password again:
And it's done, over.
When I check the modification on openLDAP server the password is in clear in the field < userPassword >.
On my linux clients it ask the new password 2 times (normal ?) and is not in clear in userPassword filed.
[user@host] $ passwd
Changing password for user user.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
New password:
Re-enter new password:
LDAP password information changed for user
passwd: all authentication tokens updated successfully.
An extract of logs :
>From an Aix :
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=0 BIND dn="uid=user,ou=users,dc=xxx,dc=xx" method=128
Sep 17 14:51:19 srvldap slapd[8270]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=0 BIND dn="uid=user,ou=users,dc= xxx,dc=xx" mech=SIMPLE ssf=0
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=0 RESULT tag=97 err=0 text=
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=1 MOD dn="uid=user,ou=users,dc= xxx,dc=xx"
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=1 MOD attr=userpassword userpassword
Sep 17 14:51:19 srvldap slapd[8270]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=1 RESULT tag=103 err=0 text=
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 op=2 UNBIND
Sep 17 14:51:19 srvldap slapd[8270]: conn=9 fd=22 closed
Sep 17 14:51:19 srvldap slapd[8270]: conn=7 op=6 SRCH base="ou=users,dc= xxx,dc= xx " scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=in205))"
Sep 17 14:51:19 srvldap slapd[8270]: conn=7 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text=
Sep 17 14:51:19 srvldap slapd[8270]: conn=7 op=7 MOD dn="uid=user,ou=users,dc= xxx,dc= xx "
Sep 17 14:51:19 srvldap slapd[8270]: conn=7 op=7 MOD attr=shadowlastchange
Sep 17 14:51:19 srvldap slapd[8270]: conn=7 op=7 RESULT tag=103 err=8 text=modifications require authentication
... some troubles ....
>From Linux :
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 fd=34 ACCEPT from IP=192.168.3.30:51023 (IP=0.0.0.0:636)
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 fd=34 TLS established tls_ssf=256 ssf=256
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=0 BIND dn="" method=128
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=0 RESULT tag=97 err=0 text=
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=1 SRCH base="ou=users,dc=xxx,dc=xx" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1001))"
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=2 SRCH base="ou=users,dc=xxx,dc=xx" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=user))"
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Oct 6 15:37:40 srvldap slapd[2420]: conn=5764 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 fd=38 ACCEPT from IP=192.168.3.30:51024 (IP=0.0.0.0:636)
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 fd=38 TLS established tls_ssf=256 ssf=256
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 op=0 BIND dn="" method=128
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 op=0 RESULT tag=97 err=0 text=
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 op=1 SRCH base="ou=users,dc=xxx,dc=xx" scope=2 deref=0 filter="(&(|(&(accessTo=host22)(trustModel=byhost))(trustModel=fullaccess))(uid=user))"
Oct 6 15:37:40 srvldap slapd[2420]: <= bdb_equality_candidates: (accessTo) not indexed
Oct 6 15:37:40 srvldap slapd[2420]: <= bdb_equality_candidates: (trustModel) not indexed
Oct 6 15:37:40 srvldap slapd[2420]: <= bdb_equality_candidates: (trustModel) not indexed
Oct 6 15:37:40 srvldap slapd[2420]: conn=5765 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=2 BIND dn="uid=user,ou=users,dc=xxx,dc=xx" method=128
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=2 BIND dn="uid=user,ou=users,dc=xxx,dc=xx" mech=SIMPLE ssf=0
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=2 RESULT tag=97 err=0 text=
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=3 BIND anonymous mech=implicit ssf=0
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=3 BIND dn="" method=128
Oct 6 15:37:43 srvldap slapd[2420]: conn=5765 op=3 RESULT tag=97 err=0 text=
Oct 6 15:37:46 srvldap slapd[2420]: conn=5764 op=3 SRCH base="ou=users,dc=xxx,dc=xx" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1001))"
Oct 6 15:37:46 srvldap slapd[2420]: conn=5764 op=3 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Oct 6 15:37:46 srvldap slapd[2420]: conn=5764 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=4 BIND dn="uid=user,ou=users,dc=xxx,dc=xx" method=128
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=4 BIND dn="uid=user,ou=users,dc=xxx,dc=xx" mech=SIMPLE ssf=0
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=4 RESULT tag=97 err=0 text=
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=5 PASSMOD id="uid=user,ou=users,dc=xxx,dc=xx" new
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=5 RESULT oid= err=0 text=
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=6 MOD dn="uid=user,ou=users,dc=xxx,dc=xx"
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=6 MOD attr=shadowLastChange
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=6 RESULT tag=103 err=0 text=
Oct 6 15:37:52 srvldap slapd[2420]: conn=5764 fd=34 closed (connection lost)
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 op=7 UNBIND
Oct 6 15:37:52 srvldap slapd[2420]: conn=5765 fd=38 closed
Thanks for your help.
--
Philippe Caseiro
11 years, 6 months
ppolicy password warnings
by Gustavo Schroeder
Hi,
I'm planning to implement the ppolicy overlay in our repository and a
major doubt came out.
Suppose I got ppolicy overlay up and running and pwdMaxAge=10368000
(120 days) and as I've been googling around pam_ldap has the ability
to provide user warnings about password expiration.
My question is, will the userland apps like Thunderbird, Horde IMP
(via passwd module), Samba provide password warnings to the end user?
How will the user get warned when his/her password is about to expire?
Is this something that the directory server will provide?
Regards
-Gustavo
11 years, 6 months
ldap-back usage
by John Kane
I have a new requirement to proxy requests to a partner's LDAP (3rd
party), based on organization. These request come into my slave
servers. The slaves are chaining referrals to a single master (for my
company's users).
I have set up the proxy using back-ldap, along with the rewrite/map
overlay (to massage the domain and map attrs). All requests to the
partner's LDAP will be read-only.
First question: Is back-ldap the correct approach for this? Is there a
better way? This set-up is fairly simple and it 'seems' to be working.
Second question: If this is the way, are there any rules that apply as
far as where the chain overlay (order) should appear in slapd.conf?
Here's a portion my slave slapd.conf (with openldap 2.3.43):
modulepath /usr/lib/openldap
moduleload ppolicy.la
moduleload rwm.la
#===================================================================
# chain to master for updates
overlay chain
chain-uri ldap://172.1.1.1
chain-idassert-bind bindmethod="simple"
binddn="cn=ldapChain,o=myorg,dc=mycompany,dc=net"
credentials="chainsecret"
mode="self"
chain-max-depth 2
chain-return-error TRUE
chain-rebind-as-user TRUE
#===================================================================
# back-ldap (partner database)
database ldap
uri "ldap://172.2.2.2"
suffix "o=partnerorg,dc=mycompany,dc=net"
lastmod off
#===================================================================
# Rewrite/map overlay
overlay rwm
rwm-suffixmassage "o=partnerorg,dc=mycompany,dc=net"
"o=partnerorg,dc=partner,dc=net"
rwm-map objectclass top top
rwm-map objectclass person person
rwm-map objectclass posixAccount posixAccount
rwm-map attribute DiagAccessLevel gecos
rwm-map attribute DiagGroup description
<etc, snip>
#===================================================================
# Local database definitions
database bdb
suffix "dc=mycompany,dc=net"
rootdn "cn=ldaproot,dc=mycompany,dc=net"
rootpw bigsecret
lastmod on
directory /var/lib/ldap
mode 0660
checkpoint 100 30
# Indices to maintain for this database
index objectclass,entryCSN,entryUUID eq,pres
<etc>
#-------------------------------------------------------------------
# ACLs for this database
access to attrs=userPassword
by self write
by group.exact="cn=administrators,o=myorg,dc=mycompany,dc=net"
write
by dn.sub="o=partnerorg,dc=partner,dc=net" none
by anonymous auth
by * none
access to *
by group.exact="cn=administrators,o=myorg,dc=mycompany,dc=net"
write
by dn.sub="o=partnerorg,dc=partner,dc=net" none
by anonymous none
by * read
#===================================================================
syncrepl rid=004
type=refreshAndPersist
provider=ldap://172.1.1.1
retry="30 10 300 3"
searchbase="dc=mycompany,dc=net"
filter="(objectClass=*)"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncRepl,o=myorg,dc=mycompany,dc=net"
credentials="secretsync"
updateref ldap://172.1.1.1
Thanks in advance,
John
This message is confidential to Prodea Systems, Inc unless otherwise indicated
or apparent from its nature. This message is directed to the intended recipient
only, who may be readily determined by the sender of this message and its
contents. If the reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to the intended
recipient:(a)any dissemination or copying of this message is strictly
prohibited; and(b)immediately notify the sender by return message and destroy
any copies of this message in any form(electronic, paper or otherwise) that you
have.The delivery of this message and its information is neither intended to be
nor constitutes a disclosure or waiver of any trade secrets, intellectual
property, attorney work product, or attorney-client communications. The
authority of the individual sending this message to legally bind Prodea Systems
is neither apparent nor implied,and must be independently verified.
11 years, 6 months
LDAP password information update failed: Insufficient access
by Roberto Gherardi de Candei
Hi i'm a newbie
doesn't succeed has change the password of the on maturity consumer of the
password
help where is my error
#
# 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/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# modules available in openldap-servers-overlays RPM package:
# 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 translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.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/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/certs/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/certs/slapdkey.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!
#access to dn.subtree="ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=adminU,ou=Utenti,dc=ldap=dc=inail,dc=it"
# by dn="cn=anonymous,dc=ldap,dc=inail.dc=it" read
# by self write
# by anonymous auth
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=ldap,dc=inail,dc=it"
rootdn "cn=admin,dc=ldap,dc=inail,dc=it"
#rootpw {SSHA}PU4cboMpOsn7YBWDaP9xwRdP82k5O7gV
rootpw {SSHA}mcFkKPNevo77jAq0+MdWNmX7F7roGk+v
# 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
# 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
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
thank's
--
RGdC
--
RGdC
11 years, 6 months
OpenLDAP Scaling
by Brian Zuromski
HI,
I'm trying to scale out a openldap server deployment to serve around 100K
users. I plan on having a master server and using syncrepl to create slaves
that sit behind a load-balancer. Is there a good rule of thumb to abide by
when creating a scenario like this? How many authentications/sec can a
server typically handle? I've seen the benchmark comparisons (
http://www.usenix.org/event/lisa07/htgr_files/chu.pdf) that have been posted
by Howard, but it doesn't say what the system specs were that the tests were
performed on? I will have pretty beefy systems to use (lots of RAM and
CPU)...
Thanks!!
11 years, 6 months
Question about using openLDAP with TLS
by Bryan Boone
Hi everyone, I had a question about the TLS/SSL side of openLDAP.
I would like to create a C program that runs on a computer that uses LDAP as one of its login methods. Of course I would need to use SSL or Kerberos for secure login.
My knowledge of SSL is small so forgive me.
My question is, when I have an administrator login to this program just after installation and he/she sets up the LDAP parameters along with the option for TLS LDAP, he/she should obtain an SSL ticket from the LDAP server right?
The admin should be prompted by the program once to accept or reject the SSL ticket right?
Where is this ticket stored on the client computer?
Can I keep this ticket so that the user logging in doesn't have to accept the ticket every single time they log in? Only when the administrator changes LDAP servers is when he/she would need to accept a new SSL ticket.
Am I on the right track? Or do I completely have the wrong idea on how LDAP with TLS works?
thanks
11 years, 6 months
posible problema pam_group openldap pendrive -flash USB-
by Guillermo Lengemann
Greetings Comrades,
I installed an environment where customers (Debian GNU/Linux lenny)
authenticate against a data directory (openldap 2.4.x on Debian
GNU/Linux lenny). But there is a problem trying to mount the pendrive
It configure the /etc/pam.d/common-auth as follows:
auth required pam_group.so
auth sufficient pam_unix.so nullok_secure
auth required pam_ldap.so try_first_pass
and the configuration file /etc/security/group.conf:
*;*;*;Al0000-2359;netdev,plugdev,powerdev,scanner,video,audio,floppy,cdrom,dialout
The problem is when you try to mount a pendrive from the graphical
environment (gnome) and results in the following error.
/*****************
No se Puede montar el volumen
Error org.freedesktop.DBus.Error.AccessDenied
Rejected send message, 3 matched rules;
type="method_call", sender=":1.33"(uid=100055 pid=3578)
comm="/usr/bin/gnome-mount --hal-udi=/org/freedesktop/Ha"
interface="org.freedesktop.Hal.Device.Volume"
menber="Mount" error name"(unset)" requested_reply=0
destination="org.freedesktop.Hal"
(uid=0 pid=3044 comm="/usr/sbin/hald"))
***********************/
I checked the log and not succeeded in finding the error, pam_group may
be causing the problem?.
Thanks for your help.
--
--------------------
Guillermo Lengemann
FSF miembro # 7510
--------------------
11 years, 6 months
Re: TLS CA Chain Problem
by Iruwen
Brett @Google schrieb:
> Have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517188
> Openldap in Lenny is linked against GNUtls instead of openssl. GNUtls doesn't support the
>
> TLS_CACERTDIR configuration option, so we have to use TLS_CACERT to specify a file with
> trusted CA certificates.
>
> GNUtls is not the same as openssl, if you are affected by this bug
> then it will only load the first cert.
>
> Cheers
> Brett
I just noticed that I can remove the CA related directives and copy alle
required intermediate certificates and the root certificate directly
into the key file to build the trust chain. Problem solved.
Thanks for pushing my research into the right direction!
11 years, 6 months
Re: TLS CA Chain Problem
by Iruwen
Brett @Google schrieb:
> Have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517188
> Openldap in Lenny is linked against GNUtls instead of openssl. GNUtls doesn't support the
>
> TLS_CACERTDIR configuration option, so we have to use TLS_CACERT to specify a file with
> trusted CA certificates.
>
> GNUtls is not the same as openssl, if you are affected by this bug
> then it will only load the first cert.
>
> Cheers
> Brett
Yes this seems to affect me too. So I'll have to recompile against
openssl I guess. I can live with that.
Thanks!
11 years, 6 months
Re: TLS CA Chain Problem
by Iruwen
Brett Maxfield schrieb:
>
>> I just got an SSL certificate issued by Comodo which doesn't work as
>> expected with slapd.
>> Which means I get an untrusted certificate warning in Thunderbird.
>> Probably I just missed something.
>
> I'll ask the question, why would the trust chain in slapd affect
> thunderbird?
>
> What thunderbird considers trusted will be up to thunderbird itself,
> or the underlying OS.
>
> Cheers
> Brett
Isn't that what the certificate chain in TLSCACertificateFile (or the
corresponding directives in Apache, Postfix and so on) is good for?
To build the trust chain from the issued certificate up to the trusted
root certificate via intermediate certificates?
If it was a problem of the underlying OS, shouldn't openssl s_client
-connect localhost:<port> show exactly the same results for all services?
11 years, 6 months
