openldap-technical June 2019

openldap-technical@openldap.org

25 participants
22 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

Error when try modify olcTLS*
by Igor Sousa 28 Jun '19

28 Jun '19

Hi everyone, I've tried a common proceeded: insert CA and server certificates on cn=config. I've created CA and server certificate in PEM format and I've signed server certificate with CA certificate. Then I've created a 5tls.ldif with following content: dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem But server has returned following error when I've ran ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif: [root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) ldap.local.crt, ldap.local.key and ca.cert.pem are /etc/openldap/certs and they own read permission to ldap group. I don't understand this behavior and I have no idea what is wrong. OBS: I've mounted environment on CentOS 7, added symas' repository and install from yum. Here some relevant info below. OpenLDAP version - 2.4.47 [root@localhost ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $ build@c7rpm :/home/build/git/rheldap/RHEL7_x86_64/BUILD/symas-openldap-2.4.47/openldap-2.4.47/servers/slapd STATUS after run ldapmodify [root@localhost ldifs]# systemctl status slapd -l ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2019-06-28 01:51:50 -03; 1h 36min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 4654 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 4641 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 4656 (slapd) CGroup: /system.slice/slapd.service └─4656 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="" method=163 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 RESULT tag=97 err=0 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD dn="cn=config" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD attr=olcTLSCACertificateFile Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 RESULT tag=103 err=80 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=2 UNBIND Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 closed Best regards, -- Igor Sousa

2 1

Cluster takes around 48 hours to synchronize after deletion
by x0101 26 Jun '19

26 Jun '19

Dear all, We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7. We noticed that deletion of an entry (done from a Windows machine onto the first node via Oracle's tool ldapmodify.exe) takes a long time (about 48 hours) to be replicated in the cluster. Here's the relevant extract of cn=config for the first node: olcSyncrepl: {0}rid=001 provider=ldap://mynode2:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcSyncrepl: {1}rid=002 provider=ldap://mynode3:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcMirrorMode: TRUE We looked up for the offending entry (thisentry) in all nodes' logs and we found this line on mynode3: Jun 18 14:18:20 mynode3 slapd[8871]: conn=1987936 op=14 DEL dn="dc=thisentry,ou=myou,ou=foobars,dc=mydomain,dc=org" There are no other references to thisentry (apart from SRCH operations) on node1 and node2, even if the entry was originally deleted from node1, as said above. What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.

2 1

debug incoming modify operations
by Mark Coetser 25 Jun '19

25 Jun '19

Hi changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing? -- Thank you, Mark Adrian Coetser mark(a)pkfnet.co.za

4 7

Invalid DN reported during authentication
by Chris K 24 Jun '19

24 Jun '19

Hello experts, I setup an openLDAP server some time ago and am to create a newer server for TLS 1.3 support. I am using a fully patched CentOS 7 server with OpenLDAP 2.4.44 and am seeing 'invalid DN' when authenticating to the server from my Linux client. I will attempt to supply all the config and tests I have done thus far: ######################################## ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net URI ldap://openldapsec.brm.acslab.wokyourdog.net #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3 TLS_CACERTDIR /etc/openldap/certs TLS_CACERT /etc/openldap/certs/RootCA.pem TLSCACertificateFile /etc/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key TLSVerifyClient never # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on ######################################## slapd.conf # 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 # Added for policy include /etc/openldap/schema/ppolicy.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args moduleload ppolicy.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/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key database bdb suffix "dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootdn "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootpw {SSHA}C6RcppHr0rweEVCQW6pio6tnPCIHCGnt # PPolicy Configuration overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" ppolicy_use_lockout ppolicy_hash_cleartext # 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 ######################################## ldapsearch output: [root@OpenLDAP_Server openldap]# ldapsearch -H ldap:// openldapsec.brm.acslab.wokyourdog.net -D "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -w Siladmin123 -ZZ # extended LDIF # # LDAPv3 # base <dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # openldapsec.brm.acslab.wokyourdog.net dn: dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net dc: openldapsec objectClass: top objectClass: domain # people, openldapsec.brm.acslab.wokyourdog.net dn: ou=people,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: top objectClass: organizationalUnit ou: people # swadmin3, openldapsec.brm.acslab.wokyourdog.net dn: cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: person objectClass: uidObject cn: swadmin3 sn: admin user uid: swadmin3 userPassword:: e1NTSEF9WDdRQ2xzallYUDUvWU9sZnJyc3ZWVXhnS0xkbXB2U1o= # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 ######################################## ldapwhoami [root@OpenLDAP_Server openldap]# ldapwhoami -vvv -h openldapsec.brm.acslab.wokyourdog.net -p 389 -D "cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -x -w Siladmin123 ldap_initialize( ldap://openldapsec.brm.acslab.wokyourdog.net:389 ) dn:cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net Result: Success (0) ######################################## client authentication failure logs ber_dump: buf=0x7fe684117870 ptr=0x7fe684117870 end=0x7fe68411788d len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684117870 ptr=0x7fe684117873 end=0x7fe68411788d len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be0 end=0x7fe684115c23 len=67 0000: 02 01 02 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 ...`>....,swadmi 0010: 6e 33 40 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 n3(a)openldapsec.b 0020: 72 6d 2e 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 rm.acslab.wokyou 0030: 6f 6d 2e 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e rdog.net..Siladmin 0040: 31 32 33 123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be3 end=0x7fe684115c23 len=64 0000: 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 6e 33 40 `>....,swadmin3@ 0010: 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 72 6d 2e openldapsec.brm. 0020: 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 6f 6d 2e acslab.wokyourdog. 0030: 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 net..Siladmin123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115c16 end=0x7fe684115c23 len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 5d10d347 conn=1048 op=1 do_bind: invalid dn ( swadmin3(a)openldapsec.brm.acslab.wokyourdog.net) 0000: 30 16 02 01 02 61 11 0a 01 22 04 00 04 0a 69 6e 0....a..."....in 0010: 76 61 6c 69 64 20 44 4e valid DN ber_dump: buf=0x7fe6841171a0 ptr=0x7fe6841171a0 end=0x7fe6841171a5 len=5 0000: 02 01 03 42 00 ...B. ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb0 end=0x7fe684107ecd len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb3 end=0x7fe684107ecd len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684002250 ptr=0x7fe684002250 end=0x7fe6840022ae len=94 0000: 02 01 02 60 59 02 01 03 04 47 63 6e 3d 73 77 61 ...`Y....Gcn=swa 0010: 64 6d 69 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 dmin3,cn=users,d 0020: 63 3d 6f 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 c=openldapsec,dc 0030: 3d 62 72 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 =brm,dc=acslab,d 0040: 63 3d 62 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 c=wokyourdog,dc=ne 0050: 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 t..Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe684002253 end=0x7fe6840022ae len=91 0000: 60 59 02 01 03 04 47 63 6e 3d 73 77 61 64 6d 69 `Y....Gcn=swadmi 0010: 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 63 3d 6f n3,cn=users,dc=o 0020: 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 3d 62 72 penldapsec,dc=br 0030: 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 63 3d 62 m,dc=acslab,dc=w 0040: 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 74 80 0b kyourdog,dc=net.. 0050: 53 69 6c 61 64 6d 69 6e 31 32 33 Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe6840022a1 end=0x7fe6840022ae len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 0000: 30 0c 02 01 02 61 07 0a 01 31 04 00 04 00 0....a...1.... ber_dump: buf=0x7fe684118dd0 ptr=0x7fe684118dd0 end=0x7fe684118dd5 len=5 0000: 02 01 03 42 00 ...B. Please let me know if you can see my mis-configuration or if you have any questions about my setup. Thanks, Chris

2 1

Hide pwdHistory field from anonymous
by Kyle Sloan 21 Jun '19

21 Jun '19

I am able to hide the userPassword and any other single/unique fields on a query, but I cannot figure out the pwdHistory and how to disable it from anonymous queries. I keep getting syntax errors and am unsure what the syntax is. This works for userPassword, but fails when I replace or add pwdHistory access to attrs=userPassword by self write by anonymous auth by * none Here is what my my query looks like /usr/bin/ldapsearch -h 1.2.3.4 -x -b 'ou=People,dc=company,dc=com' '(uid=myuser)' '*' '+' # extended LDIF # # LDAPv3 # base <ou=People,dc=copmany,dc=com> with scope subtree # filter: (uid=myuser) # requesting: * + # # myuser, People, company dn: uid=myuser,ou=People,dc=company,dc=com uidNumber: 31518 gidNumber: 100 shadowExpire: 99999 shadowMax: 90 objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount uid: myuser pwdHistory: 20180718212202Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}bTWu9btdOzp pwdHistory: 20181015214815Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Ys8LvXcdnsr pwdHistory: 20181016164512Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}nQLIieWGwt7 pwdHistory: 20190114155333Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}j3d+hxGalnC pwdHistory: 20190412183313Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}7r2E2DdryKa pwdHistory: 20190412185409Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}ZbqMWB0x4v+

3 4

How to filter all entries by multi-value attributes?
by Tankman 六四 21 Jun '19

21 Jun '19

Hi everyone Is there a way to find all people whose telephoneNumber is multi-valued through the use of LDAP filter? Searched around there are only ways to search into multiple values but not based on the number of values. Thanks:) Regards

2 1

LDAP with TLS Enable/Disable not working
by Sunkad, Abhilash 20 Jun '19

20 Jun '19

Hi All, I am facing a strange problem. I am using FreeRadius 3.16 version for my Proxy authentication. I have an AD server and I make an authentication request enabling TLS. So the TLS connection passes and authentication is successful. Now I have one more LDAP server where its non TLS. Now if I make a call, even though TLS is disabled on this server, Client tries to make a TLS connection and fails. I have tried freeing connections but with no luck. Please help. Thanks Abhilash

2 1

Re: Extensible filters and ordering searches: filtering shadowExpire by range?
by Côme Chilliet 19 Jun '19

19 Jun '19

Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit : > > So, there is no way to filter on shadowExpire values which are less than > > today's timestamp? > > shadowExpire is defined as an integer type, not as a timestamp, so no. > > > It sounds crazy that such basic needs are not covered by LDAP protocol, > > have I missed something? > > It's not clear to me what this has to do with the LDAP protocol. The > definition of the "expire" field from /etc/shadow is: > > Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute > date specifying when the login may no longer be used. > > So it's an integer (just as the RFC defines it). I would imagine you could > write something that converts a current timestamp into the number of days, > etc, and then perform a search. Yeah this is what I was calling timestamp sorry, getting the integer for today is easy, but it seems there is no way for writing a search filter with greater-than or lesser-than for this attribute. It has to do with the LDAP protocol that LDAP lets schema define attributes in ways that forbid substring and range filters. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used. And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane. Côme

2 1

Extensible filters and substring searches
by Côme Chilliet 18 Jun '19

18 Jun '19

Hello, I’m trying to understand if it is possible or not to do a substring search on an attribute which does not specify a substring matching rule. I was expecting to be able to use an extensible filter and specify the sub matching rule to use, but it does not seem to work ldapsearch says "ldap_search_ext: Bad search filter (-7)" as soon as the filter contains an asterisk. And indeed reading https://tools.ietf.org/html/rfc4515 it does look like extensible filter does not allow asterisk, but it is surprising to me. Is there really no way to do an extensible search on a substring? I found some examples on the web of such filters, like here: http://www.zytrax.com/books/ldap/apa/search.html They give these examples: > # override SUBSTR match with case sensitive match > sn:caseExactSubstringMatch:=*S* # only finds Smith > # functionally same as above using OID > sn:2.5.13.7:=*S* But these do not work if I try them in ldapsearch I get bad search filter. Côme

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2019