openldap-technical February 2018

openldap-technical@openldap.org

13 participants
12 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

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

5 9

dynamic config replication
by Gerard Ranke 07 Mar '18

07 Mar '18

Hello list, Openldap 2.4.45 here, on 1 producer and 4 consumers. ( I'll attach relevant parts of the configuration at the end of this message. ) Following the scripts from test059, I configured the producer to serve up a cn=config backend for the consumers. This seems to work nicely at first: When you start a consumer from a minimal config, it loads the producers schemafiles and the cn=config, and replication of the main database is fine. Also, when fi. changing the loglevel on the producers cn=config,cn=slave, the consumers pick up this change in their cn=config. However, when I modify an olcAccess line on the producers cn=config,cn=slave database, I get these errors on the consumer: slapd[26324]: syncrepl_message_to_entry: rid=002 DN: olcDatabase={1}mdb,cn=config,cn=slave, UUID: 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[26324]: syncrepl_entry: rid=002 inserted UUID 7cff5ef6-90b1-1037-9d95-6dfd3149c2dc slapd[26324]: syncrepl_entry: rid=002 be_search (0) slapd[26324]: syncrepl_entry: rid=002 olcDatabase={1}mdb,cn=config slapd[26324]: null_callback : error code 0x43 slapd[26324]: syncrepl_entry: rid=002 be_modify olcDatabase={1}mdb,cn=config (67) slapd[26324]: syncrepl_entry: rid=002 be_modify failed (67) slapd[26324]: do_syncrepl: rid=002 rc 67 retrying >From the error code ox43, it seems that the replication is somehow trying to change the rdn, olcDatabase{1}mdb, on the consumer, which makes no sense to me. >From the producer, cn=config,cn=slave: ( This is identical to the consumer's cn=config ) dn: cn=config,cn=slave objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: slaveconfig cn: config olcArgsFile: /var/run/slapd/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d/ olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogFile: none olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: 20000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/ssl/certs olcTLSCertificateFile: /etc/ssl/certs/hkuwildcardcacert.cert olcTLSCertificateKeyFile: /etc/ssl/private/hkuwildcardcacert.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 2 I'll leave the rest PM, except for: dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config olcRootDN: cn=root,cn=config olcRootPW: xxxxxxxxxxxxxx olcSyncrepl: {0}rid=002 provider=ldap://xxx.xx.xx bindmethod=simple binddn="cn=config,cn=slave" credentials="xxxx" tls_cert="/etc/ssl/certs/xxx.cert" tls_key="/etc/ssl/private/xxx.key" tls_cacertdir="/etc/ssl/certs" tls_reqcert=demand tls_crlcheck=none searchbase="cn=config,cn=slave" schemachecking=off type=refreshAndPersist retry="5 5 10 +" suffixmassage="cn=config" olcSyncUseSubentry: FALSE This is identical to the consumers olcDatabase={0}config,cn=config entry. Hopefully somebody can point me in the right direction! Many thanks in advance, gerard

3 4

LMDB: EIO/MDB_INVALID and use of pwrite/pread
by opensource＠gmx-topmail.de 28 Feb '18

28 Feb '18

1 0

Acl on a replicated tree: unable to bind as user
by Giuseppe Civitella 27 Feb '18

27 Feb '18

Hi all, I've got a master / slave replica setup. I did use this tutorial to set up the replica: https://wiki.debian.org/LDAP/OpenLDAPSetup My ldap tree is something like: Root -> o=(first level local branch), o=(first level replicated branch). The local branch is just a cut and paste of the replicated branch. On the slave server I can use the replicated branch to authenticate against a Radius server. On the master server I realized I cannot let web users authenticate against the replicated branch. If I try to bind as a user from the replicated branch, on both the master and the slave, I get: ldapwhoami -H ldap://localhost -D "uid=gcivitella,ou=users,o=isiline,dc=who,dc=is" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) On the master, on the local branch, I get: ldapwhoami -H ldap://localhost -D "cn=gcivitella,ou=users,o=area51,dc=who,dc=is" -W Enter LDAP Password: dn:cn=gcivitella,ou=users,o=area51,dc=who,dc=is I did try to configure the acl on the server to disallow anonymous bind. And, once found this problem, I did try to create a bind user (uid=read_only) able to read the replicated branch, userPassword attrs included. Unfortunately this did not solve the problem. My acl on the master are: dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=who,dc=is olcAccess: {0}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=read_only,ou =binds,dc=who,dc=is" read olcAccess: {1}to dn.subtree="o=isiline,dc=who,dc=is" by dn="uid=isi_replica, ou=binds,dc=who,dc=is" read olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * non e olcAccess: {3}to attrs=shadowLastChange by self write by * read olcAccess: {4}to * by users read I'm quite new to this kind of setup, is this something to be expected? Is there a way to bind directly on the replicated branch? Regards, Giuseppe

2 1

LMDB: Delete data after MDB_MAP_FULL
by opensource＠gmx-topmail.de 26 Feb '18

26 Feb '18

2 1

Re: Syncrepl and multipe values
by Quanah Gibson-Mount 24 Feb '18

24 Feb '18

--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio Morais <matheus_morais(a)sicredi.com.br> wrote: > > > > Issue 8559 opened. > > > > I'm trying to work on a patch but I'm not sure if the best solution is to > fix accesslog to avoid duplicated values or if the sample LDIF (in its > description) should result in a constraint violation. What do you think? The accesslog should never write an operation that can't be replicated. If the MOD is a valid LDAP operation (which I think it is), then it should be accepted at the frontend. The issue may be more in delta-syncrepl's handling of the write op than anything else. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

consumer abort with chain overlay
by Michael Wandel 24 Feb '18

24 Feb '18

hallo , i'm not sure if I it is a configuration failure or a openldap error. I have tested this with centos 7 , original RPM, SLES12SP3 and the ltb-project binäries. Every enviroment failed. this is a setup consumer / provider with chain overlay and proxyauth. a minimized slapd.conf global section ... authz-policy to overlay chain chain-uri "ldap://ldap1.example.test" chain-rebind-as-user FALSE chain-idassert-bind bindmethod="simple" binddn="cn=chainadmin,dc=example,dc=test" credentials="secret" mode=legacy flags=override chain-return-error TRUE ... the java code snipplet which makes a connection and then switch the proxyauth and make a password change. --- try { LDAPConnection connection = openLDAPConnection(); BindRequest bindRequest = new SimpleBindRequest(modDN, oldPwd, new DraftBeheraLDAPPasswordPolicy10RequestControl()); BindResult bindResult = connection.bind(bindRequest); DraftBeheraLDAPPasswordPolicy10ResponseControl pwpResponse = DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult); DraftBeheraLDAPPasswordPolicy10WarningType warningType = pwpResponse.getWarningType(); System.out.println("Bind Result " + bindResult.toString()); System.out.println("PwdResponse " + pwpResponse.toString()); connection.close(); connection = openLDAPConnection(); Control[] controls = { new ProxiedAuthorizationV2RequestControl("dn:" + modDN) }; PasswordModifyExtendedRequest passwordModifyRequest = new PasswordModifyExtendedRequest(modDN, oldPwd, newPwd, controls); PasswordModifyExtendedResult passwordModifyResult = (PasswordModifyExtendedResult) connection .processExtendedOperation(passwordModifyRequest); System.out.println("passwordModifyResult " + passwordModifyResult.toString()); connection.close(); connection = openLDAPConnection(); bindRequest = new SimpleBindRequest(modDN, newPwd, new DraftBeheraLDAPPasswordPolicy10RequestControl()); bindResult = connection.bind(bindRequest); pwpResponse = DraftBeheraLDAPPasswordPolicy10ResponseControl.get(bindResult); warningType = pwpResponse.getWarningType(); System.out.println("Bind Result " + bindResult.toString()); System.out.println("PwdResponse " + pwpResponse.toString()); } the gdb output of the crash is here: 5a8c6d3d conn=1001 op=1 RESULT oid= err=123 text=not authorized to assume identity *** Error in `/usr/local/openldap/libexec/slapd': munmap_chunk(): invalid pointer: 0x00007f2b14100986 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7ada4)[0x7f2d8a9d7da4] /usr/local/openldap/libexec/slapd(ldap_back_controls_free+0xc1)[0x5181a1] /usr/local/openldap/libexec/slapd[0x522ba8] /usr/local/openldap/libexec/slapd[0x51a959] /usr/local/openldap/libexec/slapd[0x51c193] /usr/local/openldap/libexec/slapd[0x4a5118] /usr/local/openldap/libexec/slapd[0x44f286] /usr/local/openldap/libexec/slapd[0x44f787] /usr/local/openldap/libexec/slapd(slap_send_ldap_extended+0xc0)[0x450880] /usr/local/openldap/libexec/slapd(fe_extended+0xba)[0x46f26a] /usr/local/openldap/libexec/slapd(overlay_op_walk+0x92)[0x4a5c42] /usr/local/openldap/libexec/slapd[0x4a5d7e] /usr/local/openldap/libexec/slapd(do_extended+0x24e)[0x46efbe] /usr/local/openldap/libexec/slapd[0x4407ee] /usr/local/openldap/libexec/slapd[0x440aca] /usr/local/openldap/libexec/slapd[0x590769] /lib64/libpthread.so.0(+0x7dc5)[0x7f2d8be00dc5] /lib64/libc.so.6(clone+0x6d)[0x7f2d8aa5473d] ======= Memory map: ======== 00400000-00683000 r-xp 00000000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00882000-00883000 r--p 00282000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00883000-00893000 rw-p 00283000 fd:00 68054818 /usr/local/openldap/libexec/slapd 00893000-00939000 rw-p 00000000 00:00 0 022d2000-02768000 rw-p 00000000 00:00 0 [heap] 7f2b14000000-7f2b1411f000 rw-p 00000000 00:00 0 7f2b1411f000-7f2b18000000 ---p 00000000 00:00 0 7f2b1afff000-7f2b1c000000 rw-p 00000000 00:00 0 7f2b1c000000-7f2b1c021000 rw-p 00000000 00:00 0 7f2b1c021000-7f2b20000000 ---p 00000000 00:00 0 7f2b20000000-7f2b20117000 rw-p 00000000 00:00 0 7f2b20117000-7f2b24000000 ---p 00000000 00:00 0 7f2b24000000-7f2b24021000 rw-p 00000000 00:00 0 I'm not sure if it is a known bug or misconfiguration. If someone wants the java testprogram i'll can send it per pm or give a download link. best regards Michael -- Michael Wandel Braakstraße 43 33647 Bielefeld

2 1

contextCSN not found on consumer!
by Sam Culley 24 Feb '18

24 Feb '18

I have recently set up a provider/consumer using OpenLDAP 2.4.40, everything appears to be working. Changes made on the provider are replicated to the consumer but when querying the contextCSN I am only able to retrieve results for the provider. [root@prod-mail-ldap-master ~]# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=domain,dc=cp, contextCSN dn: dc=domain,dc=com contextCSN: 20180222075803.816626Z#000000#000#000000 [root@prod-mail-ldap-slave-1 ~]# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=domain,dc=cp, contextCSN dn: dc=domain,dc=com As you can see from the command outputs above when running the same commands on both provider/consumer only the provider returns the contextCSN. Why is this happening, what do I need to do to retrieve the contextCSN from the consumer? Regards, Sam

2 1

IETF opinion change on "implicit TLS" vs. StartTLS
by Michael Ströder 16 Feb '18

16 Feb '18

HI! To me this rationale for SMTP submission with implicit TLS seems also applicable to LDAPS vs. StartTLS: https://tools.ietf.org/html/rfc8314#appendix-A So LDAPS should not be considered deprecated. Rather it should be recommended and the _optional_ use of StartTLS should be strongly discouraged. Ciao, Michael.

4 6

Re: placeholder problems
by Côme Chilliet 12 Feb '18

12 Feb '18

Le jeudi 8 février 2018, 09:59:03 CET Joeri Casteels a écrit : > Now i would like to assign them directly to the correct unix group depending on the base you start from or Primary group you select. > If i use this placeholder:Home directory*: /home/%primaryGroup%/%uid% i get the option in the template to select my primary group but it does not fill in the Home Directory correct nor it fills in the correct group. Hum primaryGroup is not an LDAP field so I don’t think you can use it like that. You can use %gidNumber% but I’m not sure it will help. You can open an issue to make the primary group name available as %primaryGroup% in templates but I can’t guarantee it will be added. > Also setting the passord expiration does not work correctly with the info on the website under placeholder i tried epoch time and it does not work at all to fetch the day of today and add 4years on top for example. Even just fetching the day of today does not work under unix Password Expiration data: The epoch modifier was added in FusionDirectory 1.2.1 which is not out yet. > Then there is another small matter i would like to know if there is an easy change for this. My users are allowed to change some info on their own but non of them find the edit button since it’s in the bottom right corner where nobody looks. Is it possible to make these buttons directly under the last frame? Can i edit this myself in de code? You can create you own CSS theme in which you can change the button display. See https://fusiondirectory-developer-documentation.readthedocs.io/en/latest/th… Côme

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2018