Dieter Klünter wrote:
> Am Mon, 16 Jan 2012 11:03:25 +0100
> schrieb "Angel L. Mateo"<amateo(a)um.es>:
>
>> Hi,
>>
>> I'm trying to configure chain overlay in a ldap replica
>> consumer. My final purpose is that if this node receives an update,
>> it directly tries to make it in the provider node, instead of
>> returning the referrral. Is that possible? I think so...
>>
>> But I have a problem with the configuration. My config is
>>
>> ...
>> moduleload back_ldap
>> moduleload syncprov
>> ...
>> database hdb
>> suffix dc=<mysuffix>
>> ...
>> overlay syncprov
>>
>> syncrepl rid=31
>> provider="ldap://<provider>"
>> binddn="<replica user dn>"
>> bindmethod=simple
>> credentials=<password>
>> searchbase="dc=<mysuffix>"
>> type=refreshAndPersist
>> interval=00:00:00:10
>> retry="5 5 300 +"
>> timeout=1
>>
>> overlay chain
>> chain-max-depth 1
>> chain-return-error true
>>
>> chain-uri ldap://<provider>
>> chain-rebind-as-user yes
>> chain-idassert-bind bindmethod=simple
>> binddn=<replica user dn>
>> credentials=<password>
>> starttls=no
>> mode="self"
>>
>> But when I test configuration with slaptest, I get:
>>
>> root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf
>> syncprov_db_open: invalid config, lastmod must be enabled
>> backend_startup_one (type=hdb, suffix="<mysuffix>"): bi_db_open
>> failed! (-1) slap_startup failed (test would succeed using the -u
>> switch)
>>
>> and I can't run slapd. Any idea?
>>
>> I'm running slapd 2.4.21 (ubuntu lucid package)
>>
>
> The chain overlay has to be configured in the global part, prior to any
> database declaration.
That might be true, but the actual error here is that the syncprov overlay has
been included even though there is no need for it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On 11/30/2011 08:01 AM, Jayavant Patil wrote:
>
>
> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>
>
> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >>Hi
>
> >>I think you mean SSL connection or the STARTTLS Layer...?
> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> >Ok.
>
> >>And tree security:
> >>On my server, a client user can only see his own object:
> >Are you using simple authentication mechanism?
>
> >>Maybe create a rule like this:
> >>access to filter=(objectClass=
> >>simpleSecurityObject)
> >> by self read
> >> by * none
>
> >I am not getting what the ACL rule specifies. Any suggestions?
>
>
> I have two users ldap_6 and ldap_7. I want to restrict a user to
> see his own data only.
> In slapd.conf, I specified the rule as follows:
> access to *
> by self write
> by * none
>
> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> "ou=People,dc=abc,dc=com" "uid=ldap_7"
>
> Any suggestions?
>
Yes, that's exactly the rule I wrote above.
access to filter=(objectClass=simpleSecurityObject)
by self read
by * none
Maybe you have to change the objectClass to posixAccount, or both or
whatever....
access to
filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount))
by self read
by * none
Just add this rule before the global rule "access to *"
>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
"ou=People,dc=abc,dc=com" "uid=ldap_7"
And if you search like this with bind "admin dn", you will see every
object....
You have to bind with user ldap_6 and not with root
>
>
> --
>
> Thanks & Regards,
>
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
Hi
As I have read the StartTLS extended operation seems to be preferred over
SSL:
http://www.openldap.org/faq/data/cache/605.html
Therefore* I have always* used -ZZ with ldap://URI to bind to my server.
Eg:
ldapsearch -ZZ -b base -H ldap://server -D uid=admin,ou=users,base -W
cn=search
I thought this would thus encrypt my password by encapsulating the TCP 389
connection with TLS encryption. However, to my severe dismay, I can see my
password in "-d3" debug output, using the above command, as well as when
dropping the -ZZ and using ldaps://
Can you please provide guidance?
ldap_url_parse_ext(ldap://ldap.server.domain)
ldap_create
ldap_url_parse_ext(ldap://ldap.server.domain:389/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.server.domain:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying LDAP_SERVER:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_write: want=31, written=31
0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31
0....w...1.3.6.1
0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37
.4.1.1466.20037
ldap_result ld 0xdea060 msgid 1
wait4msg ld 0xdea060 msgid 1 (infinite timeout)
wait4msg continue ld 0xdea060 msgid 1 all 1
** ld 0xdea060 Connections:
* host: ldap.server.domain port: 389 (default)
refcnt: 2 status: Connected
last used: Fri Sep 22 10:23:35 2017
TLS certificate verification: subject:
CN=ldap.server.domain,OU=BLAH,issuer: CN=InCommon RSA Server
CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US, cipher: *AES-256*, *security
level: high*, secret key bits: 256, total key bits: 256, cache hits: 0,
cache misses: 0, cache not reusable: 0
Enter LDAP Password: <-- I Enter Password
The server logs show:
Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin"
method=128
Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin"
mech=SIMPLE ssf=0
The password then appears in -d3 output after I authenticate.
However, I do not see the password in tcpdump using a full packet capture
on both the client and ldap server.
As expected I do see the password in tcpdump when dropping the -ZZ and
using -x for simple bind.
So in summary seeing credentials when using -ZZ and -d3 should not bring
concern as they're encrypted over the wire. So I guess can you explain how
"-d3" works?
Thanks,
Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Physiology and Biophysics
Weill Cornell Medicine
E: doug(a)med.cornell.edu
O: 212-746-6305
F: 212-746-8690
Hi,
since it is working for a lot of people (including some of our
customers) it seems that you are doing something wrong.
What about the contents of your entries: Are you sure that you have the
attribute userPassword with the value
{SASL}<username>@<AD-realm>
set in all entries that are to bind via AD?
Cheers,
Peter
Am 22.11.2013 15:05, schrieb Willy Ramos:
> Em 22/11/2013 09:21, Andrew Findlay escreveu:
>> On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
>>
>>> Subject: Re: Openldap for proxy AD
>> Have you tried following the examples in the Admin Guide?
>>
>> http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentica…
>>
>>
>> There is a detailed setup and diagnosic guide there which should help
>> you
>> to isolate the problem.
>>
>> Andrew
>
> Thanks Andrew,
>
> I was testing based in this Admin Guide.
>
> When I Check that the user can bind to AD:
>
> ldapsearch -x -H ldap://dc1.example.com/ \
> -D cn=user,cn=Users,DC=ad,DC=example,DC=com \
> -w userpassword \
> -b cn=user,cn=Users,DC=ad,DC=example,DC=com \
> Or with
> -s base \
> "(objectclass=*)"
> Or
>
> testsaslauthd -u user -p userpassword
>
> It´s works.
>
> I was reading about and Seems don´t find the schemas of objectclass or
> userPassword attribute;
>
> But I could not resolve yet.
>
> See the logs
>
>
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from
> IP=127.0.0.1:51698 (IP=0.0.0.0:636)
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established
> tls_ssf=256 ssf=256
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1
> text=TLS already started
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND
> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
>
> Thanks.
>
--
Peter Gietz, CEO
DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany
phone: +49 7071 407109-0
fax: +49 7071 407109-9
email: peter.gietz(a)daasi.de
web: www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz
Hi,
I'm having trouble to run the replica LDAP with TLS, without TLS, all works
!!
Provider and Consumer are identical
CentOS release 6.5
rpm -qa | grep ldap
openldap-clients-2.4.23-34.el6_5.1.x86_64
openldap-2.4.23-34.el6_5.1.x86_64
apr-util-ldap-1.3.9-3.el6_0.1.x86_64
nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64
mod_authz_ldap-0.26-16.el6.x86_64
pam_ldap-185-11.el6.x86_64
openldap-servers-2.4.23-34.el6_5.1.x86_64
Provider config, file cn\=config.ldif
olcTLSCACertificateFile: /etc/openldap/certs/ldapscert.pem
olcTLSCertificateFile: /etc/openldap/certs/ldapscert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/keys/ldapskey.pem
olcTLSCipherSuite: TLSv1+RSA:!EXPORT:!NULL
olcTLSVerifyClient: never
Consumer config:
olcSyncrepl: {0}rid=000
provider=ldap://ldpsoc01devpom.sociale.it
starttls=yes
type=refreshonly
retry="5 5 300 +"
searchbase="dc=example,dc=it"
attrs="*,+"
bindmethod=simple
binddn="uid=xxxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it"
credentials=xxxxxxx
interval=60
and, in /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ldapscert.pem
TLS_REQCERT never
the certificate is self-signed
On the slave, if I try the following command:
ldapsearch -ZZ -x -H ldap://ldpsoc01devpom -D
'uid=xxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it' -W
'objectclass=*' -v
everything is ok but when I try to use TLS in replication, the process goes
wrong.
In the Provider log:
connection_get(16)
connection_get(16): got connid=1030
connection_read(16): checking for input on id=1030
connection_read(16): TLS accept failure error=-1 id=1030, closing
connection_closing: readying conn=1030 sd=16 for close
connection_close: conn=1030 sd=16
daemon: activity on 1 descriptor
daemon: activity on:
In the Consumer log:
slapd[6508]: =>do_syncrepl rid=000
slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it Warning,
ldap_start_tls failed (-11)
slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it
DN="uid=bind_replica,ou=admin_bind,ou=utenze_amministratori,dc=sociale,dc=it"
ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=000 rc -1 retrying (3 retries left)
daemon: activity on 1 descriptor
daemon: activity on:
Help, I do not know where to turn !!!!
Thanks
Ing. Stefano Elmopi
Cooperativa Capodarco - Resp. Area ICT Gestione Esercizio
Via Ostiense 131/L Corpo B, 00154 Roma
cell. 3466147165
tel. 0657060500
email:stefano.elmopi@sociale.it
--
"Ai sensi e per gli effetti della legge sulla tutela dei dati personali
(D.lgs 196/2003),
le informazioni contenute nella presente @mail sono di natura riservata e
destinate
ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale;
come tali,
pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E'
proibito leggere,
copiare, usare o diffondere il contenuto della presente @mail senza
autorizzazione.
Se avete ricevuto questa @mail per errore, siete pregati di rispedire la
stessa al mittente.
Grazie"
Hi,
http://pastebin.de/41448
-Dieter
Am Wed, 5 Mar 2014 22:04:05 +0800
schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>:
> Hi Michael and Dieter,
>
>
> Thanks for your kindly replies.
> In my case, I didn't use any SASL or TLS but "simple" method with
> operation mode of user/password authenticated. However, I need the
> rootpw hashed (not cleartext) and the 2 servers (master & slave)
> synchronized. Could you pls advise how i should modify the syncrepl
> part? or could you pls provide a sample of the slapd.conf file
> configuration?
>
>
> Best regards,
>
>
> Eileen
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Michael Ströder";<michael(a)stroeder.com>;
> 发送时间: 2014年3月5日(星期三) 下午4:09
> 收件人: "Dieter Klünter"<dieter(a)dkluenter.de>;
> "openldap-technical"<openldap-technical(a)openldap.org>;
>
> 主题: Re: mirror mode & sasl question
>
>
>
> Dieter Klünter wrote:
> > Am Wed, 5 Mar 2014 14:38:04 +0800
> > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>:
> >> This is Eileen from China SINAP. I am a beginner for openldap
> >> soft. I encountered a problem in my study on two LDAP services
> >> replication. I have 2 LDAP services, one name LDPA1, the other is
> >> LDAP2 . I want to make them synchronously in mirror mode. But when
> >> I set LDAP services rootpw both in hash, the 2 LDAP serivces can’t
> >> be synchronous. My question is
> >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If
> >> I must use sasl method, can I put the sasl service in the same ldap
> >> service? If bindmethod=sasl then what is the saslmech should be?
> >> 2. If I change to sasl method, do I need change my database
> >> record?
> >
> > In order to use sasl, passwords must be cleartext and you should
> > configure an apropriate authz-regexp, see man slapd.conf(5)
> > You may use any sasl mechanism that you sasl framework provides.
> > [...]
>
> To be more precise: In order to use password-based SASL mechs the
> passwords have to be stored in clear-text.
>
> Well, if working with SASL and TLS (LDAPS, StartTLS) one should
> consider using client certs and SASL/EXTERNAL for replication.
>
> Ciao, Michael.
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
Hi all,
i have a problem getting openldap to run monitor backend AND syncrepl
overlay.
i'm running freebsd-7.2-release-p6 in combination with
openldap-server-2.4.19 with sasl support compiled in.
i use the following slapd config:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/misc.schema
include /usr/local/etc/openldap/schema/ldapns.schema
include /usr/local/etc/openldap/schema/radius.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
logfile /var/log/slapd.log
password-hash {SSHA}
modulepath /usr/local/libexec/openldap
moduleload back_bdb
moduleload back_monitor
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
by ssf=128 dn="cn=admin,dc=example,dc=de" write
by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
by anonymous auth
by * none
access to attrs=userPassword
by self write
by anonymous auth
by * none
database bdb
suffix "dc=example,dc=de"
rootdn "dc=example,dc=de"
directory /var/db/openldap-data
index objectClass,entryCSN,entryUUID eq
index uid pres,eq,sub
index memberUID eq
index uidNumber,gidNumber eq
index host eq
database monitor
rootdn "cn=monitoring,cn=Monitor"
rootpw monitoring
access to dn.subtree="cn=Monitor"
by dn="cn=nssadmin,dc=example,dc=de"
by * none
syncrepl rid=041
provider=ldap://ldap-master.example.de
type=refreshOnly
interval=00:00:35:00
searchbase="dc=example,dc=de"
schemachecking=off
bindmethod=simple
starttls=yes
binddn="cn=syncuser,dc=example,dc=de"
credentials="strongsecretpassword"
TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
loglevel 256
now, when i run slaptest i receive following error:
/usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
support operations required for syncrepl
slaptest: bad configuration file!
Line 59 corresponds to the credentials option in the synrepl statement.
i can't figure out whats wrong, so if anyone can point me in the right
direction that would be really helpful.
thanks in advance,
david
Hello Sebastian,
Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
> Dieter Kluenter schrieb:
>> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
>>
>>
>>> Hello,
>>>
>>> I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also
>>> the TLS is activated. All clients are set to "TLS_REQCERT demand"
>>> and is working.
>>> Then I created client certificates by using the servers Yast2 CA-
>>> management. I copied teh client certificates and also the servers
>>> "cacert" into the "/etc/openldap/" directory on client computer. With
>>> "TLSVerifyClient allow" clients can login, but if I activate the
>>> "TLSVerifyClient demand" option in servers slapd.conf no user can
>>> perform an login and it causes errors in /var/log/messages:
>>>
>> [...]
>>
>>
>>> What is wrong? The clients certificate "common name" is set to the
>>> clients hostname. Is this ok?
>>>
>>
>> Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with
>> debug level 3 to analyse the tls session.
>>
>> -Dieter
>>
>>
> Hello Dieter,
>
> Now I have set the loglevel to "3" and I get the following output if I
> try to login (still fails):
loglevel is != debug level, man slapd(8), run slapd -d3
> -------------------/var/log/messages---------------------------------------------------------------------
[...]
> Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search
> LDAP server - Server is unavailable
[...]
> Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s:
> Connect error
> -------------------/var/log/messages---------------------------------------------------------------------
>
> I am not sure, if this is an configuration or certificate error? Do You
> understand this output above?
The clients are nss_ldap and pam_ldap, check the clients
configuration for starttls parameters.
With debug level 3 you should see something like
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=11
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write certificate request A
tls_write: want=1931, written=1931
TLS trace: SSL_accept:SSLv3 flush data
TLS trace: SSL3 alert write:warning:close notify
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
sip: +49.180.1555.7770535
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
i was experimenting a bit with adding new databases to the config, and found that if the olcsuffix attribute was not provided, it would fail:
>cat db.ldif
dn: olcDatabase=hdb,cn=config
changetype: add
objectClass: olcHdbConfig
olcDatabase: hdb
olcDbDirectory: /var/lib/ldap/example.org
>ldapadd -xWZZH 'ldap://dsa.example.com/' -D 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com' -f db.ldif
Enter LDAP Password:
adding new entry "olcDatabase=hdb,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: <olcDbDirectory> failed startup
>tail -F slapd.log
Feb 21 19:39:41 flip slapd[19134]: conn=1535 fd=64 ACCEPT from IP=192.168.1.1:36891 (IP=0.0.0.0:389)
Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 STARTTLS
Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 RESULT oid= err=0 text=
Feb 21 19:39:41 flip slapd[19134]: conn=1535 fd=64 TLS established tls_ssf=128 ssf=128
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" method=128
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" mech=SIMPLE ssf=0
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 RESULT tag=97 err=0 text=
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=2 ADD dn="olcDatabase=hdb,cn=config"
Feb 21 19:39:43 flip slapd[19134]: hdb_db_open: need suffix.
Feb 21 19:39:43 flip slapd[19134]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1)
Feb 21 19:39:43 flip slapd[19134]: olcDbDirectory: value #0: <olcDbDirectory> failed startup (0?:?X#024c?/ldap/example.org)!
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=2 RESULT tag=105 err=80 text=<olcDbDirectory> failed startup
Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=3 UNBIND
Feb 21 19:39:43 flip slapd[19134]: conn=1535 fd=64 closed
providing an olcSuffix attribute in the ldif allowed the new database to be added without error:
>ldapadd -xWZZH 'ldap://dsa.example.com/' -D 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com' -f db.ldif
Enter LDAP Password:
adding new entry "olcDatabase=hdb,cn=config"
>tail -F slapd.log
Feb 21 19:43:21 flip slapd[19134]: conn=1537 fd=44 ACCEPT from IP=192.168.1.1:36900 (IP=0.0.0.0:389)
Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 STARTTLS
Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 RESULT oid= err=0 text=
Feb 21 19:43:21 flip slapd[19134]: conn=1537 fd=44 TLS established tls_ssf=128 ssf=128
Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" method=128
Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" mech=SIMPLE ssf=0
Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 RESULT tag=97 err=0 text=
Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=2 ADD dn="olcDatabase=hdb,cn=config"
Feb 21 19:43:24 flip slapd[19134]: conn=1537 op=2 RESULT tag=105 err=0 text=
Feb 21 19:43:24 flip slapd[19134]: conn=1537 op=3 UNBIND
this behavior wasn't really all that surprising to me, as i don't really know in what capacity there might be a database without a suffix defined, even if it were just "", but what i am curious about is the schema definition for the olcHdbConfig object class. the best i can tell, only olcDatabase and olcDbDirectory are MUST attributes, while olcSuffix is not:
>ldapsearch -xH 'ldap://dsa.example.com/' -s base -b 'cn=subschema' '*' '+' | grep -iFA 5 "NAME 'olcHdbConfig'"
objectClasses: ( 1.3.6.1.4.1.4203.1.12.2.4.2.1.2 NAME 'olcHdbConfig' DESC 'HDB
backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory
MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbCryptFile $ olcDb
CryptKey $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ ol
cDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey
$ olcDbCacheFree $ olcDbDNcacheSize $ olcDbPageSize ) )
>ldapsearch -xH 'ldap://dsa.example.com/' -s base -b 'cn=subschema' '*' '+' | grep -iFA 7 "NAME 'olcDatabaseConfig'"
objectClasses: ( 1.3.6.1.4.1.4203.1.12.2.4.0.4 NAME 'olcDatabaseConfig' DESC '
OpenLDAP Database-specific options' SUP olcConfig STRUCTURAL MUST olcDatabase
MAY ( olcHidden $ olcSuffix $ olcSubordinate $ olcAccess $ olcAddContentAcl
$ olcLastMod $ olcLimits $ olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcRe
plica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplicationInterval $ olc
ReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ olcSchemaDN
$ olcSecurity $ olcSizeLimit $ olcSyncUseSubentry $ olcSyncrepl $ olcTimeLimi
t $ olcUpdateDN $ olcUpdateRef $ olcMirrorMode $ olcMonitoring ) )
why is olcSuffix not a MUST attribute if the database can't be added without it? are there cases different than my exercise where a database might be added without the need for a suffix? it's not anything that's causing an insurmountable hurdle, just mostly curious if this was intended.
-ben
Hi Prajith,
Please find the details,
1) let us know the client application are you using.
Apache Directory Studio, Version: 2.0.0.v20150606-M9
2) Paste here your 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
include /etc/openldap/schema/misc.schema
#include /usr/share/doc/openssh-ldap-6.4p1/openssh-lpk-openldap.schema
# Added for policy
include /etc/openldap/schema/ppolicy.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/lib64/openldap
# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# 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 syncprov.la
moduleload accesslog.la
moduleload auditlog.la
#logging level
loglevel -1
logfile /var/log/slapd.log
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.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.
#TLSCipherSuite
SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC
TLSProtocolMin 3.2
TLSCipherSuite HIGH:MEDIUM:+TLSv1.2:!RC4
TLSCertificateFile /etc/openldap/cacerts/ldapsrv.crt
TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
TLSCACertificateFile /etc/openldap/cacerts/ca.crt
# 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!
disallow bind_anon
access to attrs=userPassword
by self write
by dn.base="cn=mirrormode,dc=rnd,dc=com" read
by dn.base="cn=binduser,dc=rnd,dc=com" read
by * auth
access to *
by dn.base="cn=mirrormode,dc=rnd,dc=com" read
by dn.base="cn=binduser,dc=rnd,dc=com" read
by * break
access to *
by dn="cn=Manager,dc=rnd,dc=com"
by users read
by self write
by * auth
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
# DIT will act as a provider
overlay syncprov
suffix "dc=rnd,dc=com"
rootdn "cn=Manager,dc=rnd,dc=com"
rootpw {SSHA}KOXKk4vkP1X3nF2GY09MQXiaAdxkLyk7
# PPolicy Configuration
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=rnd,dc=com"
ppolicy_use_lockout
# 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
Thanks & Regards
Raj
From: PRAJITH <prajithpalakkuda(a)gmail.com>
To: Rajagopal Rc <rajagopal.rc(a)tcs.com>
Cc: openldap-technical(a)openldap.org
Date: 11/22/2015 09:55 AM
Subject: Re: Problem with "force user to password reset at first
login
Sent by: "openldap-technical"
<openldap-technical-bounces(a)openldap.org>
Hi Rajagopal,
Can you confirm the below points?
1) let us know the client application are you using.
2) Paste here your slapd.conf file.
On 20 November 2015 at 13:16, Rajagopal Rc <rajagopal.rc(a)tcs.com> wrote:
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
