March 2020 - openldap-technical

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

Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl 22 Jul '20

22 Jul '20

Hi! After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted: slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. The next line logged was: slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389) (the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice) The server is one of three MM servers that all have the same configuration and the same version. The schema knows in olcAttributeTypes (olcSchemaConfig): ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd? Regards, Ulrich

4 10

pwdChangedTime not defined when creating new entry
by Manuela Mandache 05 Jun '20

05 Jun '20

Hello all, We have a directory running on OpenLDAP 2.4.44 with the ppolicy overlay on the main database. When a new entry with a userPassword defined is created, pwdChangedTime is not defined, so this initial userPassword never expires. The directory has been migrated from its OpenLDAP 2.3.34 instance (yes, we missed some steps...), and there the pwdChangedTime is set, and naturally equal to createTimestamp. The overlay is configured as follows: dn: olcOverlay={2}ppolicy,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyDefault: ou=ppolicy,dc=example,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE Is there a parameter I missed which would switch on setting pwdChangedTime at entry creation? Do I have to provide some other configuration elements? Or is it unreasonable to expect this initialisation of the attribute this way, and only a password change can set it? I think the setting at creation is rather handy... Using pwdMustChange would be difficult, we have a lot of client apps which would be forced to check and probably adapt their authentication procedures. Thank you and regards, Manuela Sent with [ProtonMail](https://protonmail.com) Secure Email.

5 11

Re: NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias 02 Apr '20

02 Apr '20

On Thu, Mar 26, 2020 at 3:44 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Try it and see? I can't find any concrete documentation one way or the > other, although it seems BuildRequires generally follows what Requires > does. You may need to ask the people who maintain RPM. > > There are other issues in the spec file, however, like: > > --with-libfreeradius-ldap-include-dir=/usr/local/openldap/include \ > --with-libfreeradius-ldap-lib-dir=/usr/local/openldap/lib64 \ > > are specific to LTB, might want to do something like they did around line > 447 to only do this if the LTB openldap is in use. > Awesome! Thank you very much for the input! Will report how things go -Dave

2 2

AD proxy / CAPITAL letters in attributes
by Kevin Olbrich 31 Mar '20

31 Mar '20

Hi! How can I disable the behavior of CAPITAL letters when OpenLDAP proxies an AD? I know they should be case insensitive but I had to debug Rocketchat for two hours to find, they use sAMAccountName (case sensitive) and the app crashed because mine was named SAMACCOUNTNAME. (I will open a bug there but I bet there is a lot of broken SW). Kind regards Kevin

3 6

NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias 26 Mar '20

26 Mar '20

Good day Everyone, Back Story: We wanted to install the latest release of Freeradius from NetworkRadius and got a conflict. See post: http://lists.freeradius.org/pipermail/freeradius-users/2020-March/097718.ht… Their response was of course, figure it out and fix it yourself, which I have no problem with. I personally never compiled a rpm file before but i think i have an idea of what needs to be adjusted on their specs file. Wanted to run my changes by you guys, if you could please kindly review.... https://github.com/davama/freeradius-server/commit/7fa0f49e25de874bb5034584… https://github.com/davama/freeradius-server/commit/dab208186d440196c297821f… Not too sure if "BuildRequires" uses the same syntax but "Requires" does, at least what it says here: https://rpm.org/user_doc/boolean_dependencies.html Hope it's clear. Please let me know, if you need any info from me. Any input is much appreciated! Thank you, Dave

3 3

OpenLDAP-Proxy in front of AD - Non-DN bind
by Kevin Olbrich 26 Mar '20

26 Mar '20

Hi! I'm new to OpenLDAP / Slapd and try to integrate it into our AD setup. I followed this howto: https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD ... and ended up with this config: https://bitbucket.org/code-orange/django-cdstack-tpl-openldap-proxy/src/mas… Proxy mode works fine, I can bind with DN and password. So far so good. TLS works perfectly. On AD, I can bind using either domain\username or username(a)example.com. Can I enable this again for my proxy? Atm this does not work: Invalid DN-Syntax, invalid DN. I try to provide a secure way to connect a remove machine to our AD to read the contacts (a pbx). Using the DN worked for some devices but some have issues because of the length. If the DN is several OUs deep, the string is to long. Thats why I would like to allow the sAMAccountName as username (or USN, etc.). How can I solve this? Do I need SASL for this? Thank you very much! Kind regards Kevin

1 0

issues while modifying the LDAP on Production
by Guni Hanchate 25 Mar '20

25 Mar '20

Hi, we are getting some issues while modifying the LDAP on Production. We restarted LDAP instance but same issue persist. I request you to suggest on this . Let us know if you need any further information . I can read an entry From Cricetid via the VirtIP [u5356968@cricetid ~]$ldapsearch -x -LLL -h 192.168.154.33 -b "o=mobistar.be" "uid=u5356968" cn dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be cn: DEMOULIN Philippe From Mousedeer to Mousedeer u5356968@mousedeer # ldapsearch -x -LLL -p 3898 -h 192.168.154.97 -b "o=mobistar.be" "uid=u5356968" cn dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be cn: DEMOULIN Philippe But we cannot modify the entry. u5356968@mousedeer # ldapmodify -p 3898 -h 192.168.154.97 -D"cn=directory manager, o=mobistar.be" -w8ZQ7HUJS dn: uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be changetype: add add: mail mail: 013test.test_osp_fr_hq(a)orange.be adding new entry "uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be" ldap_add: Undefined attribute type (17) additional info: add: attribute type undefined This is the error I get: Error while executing LDIF - [LDAP: error code 17 - Undefined Attribute Type] java.lang.Exception: [LDAP: error code 17 - Undefined Attribute Type] at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1280) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$4.run(DirectoryApiConnectionWrapper.java:726) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1175) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkConnectionAndRunAndMonitor(DirectoryApiConnectionWrapper.java:1109) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.modifyEntry(DirectoryApiConnectionWrapper.java:748) at org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdifRecord(ImportLdifRunnable.java:514) at org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdif(ImportLdifRunnable.java:272) at org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.executeLdif(ExecuteLdifRunnable.java:157) at org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.run(ExecuteLdifRunnable.java:123) at org.apache.directory.studio.ldapbrowser.core.jobs.UpdateEntryRunnable.run(UpdateEntryRunnable.java:59) at org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:112) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) [LDAP: error code 17 - Undefined Attribute Type]

3 4

logging through systemd-journald is bottleneck
by Markus.Storm＠t-systems.com 20 Mar '20

20 Mar '20

Dear all, we're currently testing performance of OpenLDAP on Oracle/RedHat Linux and quite unexpected actually hit systemd-journald to be a bottleneck. While OpenLDAP happily makes use of all available CPUs, that one is single threaded, braking everything. The only way around I have found is to set olcLoglevel to 0, speeding up my test run by a factor of 6(!). That now of course is not an option to use in production. I'd happily directly write to a file as I did in the old days but I cannot get olcLogfile to work. And even if I was able to get there, how do I stop OpenLDAP from logging to syslogd (which is inevitably forwarding everything to system-journald ....) ? Can anyone give advice how to handle this ? Any hint appreciated (short of "get a decent OS" - that is not an option). Thanks, Markus

3 3

Antw: [EXT] Re: logging through systemd-journald is bottleneck
by Ulrich Windl 19 Mar '20

19 Mar '20

>>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am 18.03.2020 um 19:57 in Nachricht <30206_1584557842_5E726F12_30206_1570_1_20200318195706.1d992aa0(a)pink.fritz.box>: > Am Wed, 18 Mar 2020 17:16:53 +0000 > schrieb <Markus.Storm(a)t-systems.com>: > >> Dear all, >> >> we're currently testing performance of OpenLDAP on Oracle/RedHat >> Linux and quite unexpected actually hit systemd-journald to be a >> bottleneck. While OpenLDAP happily makes use of all available CPUs, >> that one is single threaded, braking everything. The only way around >> I have found is to set olcLoglevel to 0, speeding up my test run by a >> factor of 6(!). That now of course is not an option to use in >> production. I'd happily directly write to a file as I did in the old >> days but I cannot get olcLogfile to work. And even if I was able to >> get there, how do I stop OpenLDAP from logging to syslogd (which is >> inevitably forwarding everything to system-journald ....) ? Can >> anyone give advice how to handle this ? Any hint appreciated (short >> of "get a decent OS" - that is not an option). > > I support Qanah's advice! > Beside this, consider a logging strategy based on required information > and neglected information, as well as min. and max. server load. > > Based on my experience I would disable logging as default, but enable > logging for a short given time, just a modify operation on atribute > olcLogLevel. > With regard to journald I advice to define filters, see man > journalctl(1). > If syslog is a requirement, change to rsyslog. Don't make use of > logstash! Can't openLDAP simply log to a different port than the default syslog port? If so, just set up some alternate local syslog server. Or, in case an external syslog server is supported, just use one that isn't using systemd-journald. Sorry, I neved had the need to use a different syslog mechanism... > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E

4 3

write ACL
by Thomas Elsäßer 18 Mar '20

18 Mar '20

Hi ACL Gurus i would like following ACL , but i'm to stupid. cn=app1,ou=application,dc=company,dc=de -> groupOfNames Our Customer Admins are here cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de -> groupOfNames cn=GroupLdapAdmin,o=customer2,ou=customer,dc=company,dc=de -> groupOfNames member is the admin of this tree example member=cn=customer2.admin,ou=user,o=customer2,ou=customer,dc=company,dc=de I have 600 Customerx How can i write one ACL for all customer to access to cn=app1,ou=application,dc=company,dc=de to write access for groupLDAPAdmin for every company? This work for one customer access to dn.regex="cn=([^,]),ou=application,dc=company,dc=de" by by set.expand="(user) & ([cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de])/member" write How can write this for all without write 600 ACL? Thanx and stays healthy Thomas

1 0

archiving test #2, ignore ;)
by Quanah Gibson-Mount 12 Mar '20

12 Mar '20

Ignore again.. -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene 12 Mar '20

12 Mar '20

Dear Quanah, Herewith the ldapwhoami without and with -H ldap:/// to compare. Regards, Thierry server# ldapwhoami -x -D "cn=Manager,dc=be" -w password -d -1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 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_dump: buf=0x55c5863df610 ptr=0x55c5863df610 end=0x55c5863df636 len=38 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ber_scanf fmt ({i) ber: ber_dump: buf=0x55c5863df610 ptr=0x55c5863df615 end=0x55c5863df636 len=33 0000: 60 1f 02 01 03 04 10 63 6e 3d 4d 61 6e 61 67 65 `......cn=Manage 0010: 72 2c 64 63 3d 62 65 80 08 70 61 73 73 77 6f 72 r,dc=be..passwor 0020: 64 d ber_flush2: 38 bytes to sd 3 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ldap_write: want=38, written=38 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ldap_result ld 0x55c5863d6050 msgid 1 wait4msg ld 0x55c5863d6050 msgid 1 (infinite timeout) wait4msg continue ld 0x55c5863d6050 msgid 1 all 1 ** ld 0x55c5863d6050 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Thu Mar 12 08:33:07 2020 ** ld 0x55c5863d6050 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x55c5863d6050 request count 1 (abandoned 0) ** ld 0x55c5863d6050 Response Queue: Empty ld 0x55c5863d6050 response count 0 ldap_chkResponseList ld 0x55c5863d6050 msgid 1 all 1 ldap_chkResponseList returns ld 0x55c5863d6050 NULL ldap_int_select read1msg: ld 0x55c5863d6050 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a80 end=0x55c5863e0a8c len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x55c5863d6050 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0a8c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x55c5863d6050 0 new referrals read1msg: mark request completed, ld 0x55c5863d6050 msgid 1 request done: ld 0x55c5863d6050 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0a8c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0a8c len=0 ldap_msgfree ldap_extended_operation ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x55c5863df610 ptr=0x55c5863df610 end=0x55c5863df630 len=32 0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 .4.1.4203.1.11.3 ber_scanf fmt ({) ber: ber_dump: buf=0x55c5863df610 ptr=0x55c5863df615 end=0x55c5863df630 len=27 0000: 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 34 32 30 33 2e 31 2e 31 31 2e 33 4203.1.11.3 ber_flush2: 32 bytes to sd 3 0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 .4.1.4203.1.11.3 ldap_write: want=32, written=32 0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 .4.1.4203.1.11.3 ldap_result ld 0x55c5863d6050 msgid -1 wait4msg ld 0x55c5863d6050 msgid -1 (timeout 100000 usec) wait4msg continue ld 0x55c5863d6050 msgid -1 all 1 ** ld 0x55c5863d6050 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Thu Mar 12 08:33:07 2020 ** ld 0x55c5863d6050 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x55c5863d6050 request count 1 (abandoned 0) ** ld 0x55c5863d6050 Response Queue: Empty ld 0x55c5863d6050 response count 0 ldap_chkResponseList ld 0x55c5863d6050 msgid -1 all 1 ldap_chkResponseList returns ld 0x55c5863d6050 NULL ldap_int_select read1msg: ld 0x55c5863d6050 msgid -1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 21 02 01 02 78 1c 0a 0!...x.. ldap_read: want=27, got=27 0000: 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e 3d 4d 61 ........dn:cn=Ma 0010: 6e 61 67 65 72 2c 64 63 3d 62 65 nager,dc=be ber_get_next: tag 0x30 len 33 contents: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a80 end=0x55c5863e0aa1 len=33 0000: 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e ...x..........dn 0010: 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 :cn=Manager,dc=b 0020: 65 e read1msg: ld 0x55c5863d6050 msgid 2 message type extended-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30 0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e x..........dn:cn 0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be read1msg: ld 0x55c5863d6050 0 new referrals read1msg: mark request completed, ld 0x55c5863d6050 msgid 2 request done: ld 0x55c5863d6050 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30 0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e x..........dn:cn 0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be ber_scanf fmt (x) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0aa1 len=21 0000: 8b 13 64 6e 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c ..dn:cn=Manager, 0010: 64 63 3d 62 65 dc=be ber_scanf fmt (}) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0aa1 end=0x55c5863e0aa1 len=0 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30 0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e x..........dn:cn 0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be ber_scanf fmt (O) ber: ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0aa1 len=21 0000: 8b 13 64 6e 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c ..dn:cn=Manager, 0010: 64 63 3d 62 65 dc=be dn:cn=Manager,dc=be ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed server# ldapwhoami -x -H ldap://192.168.100.11/ -D "cn=Manager,dc=be" -w password -d -1 ldap_url_parse_ext(ldap://192.168.100.11/) ldap_create ldap_url_parse_ext(ldap://192.168.100.11:389/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.100.11:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.100.11: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_dump: buf=0x559745d846c0 ptr=0x559745d846c0 end=0x559745d846e6 len=38 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ber_scanf fmt ({i) ber: ber_dump: buf=0x559745d846c0 ptr=0x559745d846c5 end=0x559745d846e6 len=33 0000: 60 1f 02 01 03 04 10 63 6e 3d 4d 61 6e 61 67 65 `......cn=Manage 0010: 72 2c 64 63 3d 62 65 80 08 70 61 73 73 77 6f 72 r,dc=be..passwor 0020: 64 d ber_flush2: 38 bytes to sd 3 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ldap_write: want=38, written=38 0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d 0$...`......cn=M 0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61 anager,dc=be..pa 0020: 73 73 77 6f 72 64 ssword ldap_result ld 0x559745d7b070 msgid 1 wait4msg ld 0x559745d7b070 msgid 1 (infinite timeout) wait4msg continue ld 0x559745d7b070 msgid 1 all 1 ** ld 0x559745d7b070 Connections: * host: 192.168.100.11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 20:54:07 2020 ** ld 0x559745d7b070 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x559745d7b070 request count 1 (abandoned 0) ** ld 0x559745d7b070 Response Queue: Empty ld 0x559745d7b070 response count 0 ldap_chkResponseList ld 0x559745d7b070 msgid 1 all 1 ldap_chkResponseList returns ld 0x559745d7b070 NULL ldap_int_select read1msg: ld 0x559745d7b070 msgid 1 all 1 ber_get_next ldap_read: want=8, got=0 ber_get_next failed. ldap_err2string ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 1, msgid 1) ldap_free_connection 1 1 ldap_free_connection: actually freed Op do 12 mrt. 2020 om 00:04 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > > > --On Wednesday, March 11, 2020 9:59 PM +0100 Thierry Debaene > <thierry.debaene(a)gmail.com> wrote: > > > > > ldap_chkResponseList returns ld 0x55bbbd3ec070 NULL > > ldap_int_select > > read1msg: ld 0x55bbbd3ec070 msgid 1 all 1 > > ber_get_next > > ldap_read: want=8, got=0 > > It successfully connected to port 389 on that IP address, but got no > response back from whatever is listening to that port on that IP address. > I'd suggest comparing the output to the same command with no -H option > specified. > > --Quanah > >

1 1

Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene 11 Mar '20

11 Mar '20

Dear Quanah, Herewith the requested info. Thanks a lot for you help and time ! Kind Regards, Thierry client# ldapwhoami -x -H ldap://192.168.100.11/ -D "cn=Manager,dc=be" -w password -d 1 ldap_url_parse_ext(ldap://192.168.100.11/) ldap_create ldap_url_parse_ext(ldap://192.168.100.11:389/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.100.11:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.100.11: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 ({i) ber: ber_flush2: 38 bytes to sd 3 ldap_result ld 0x55d49a4a3070 msgid 1 wait4msg ld 0x55d49a4a3070 msgid 1 (infinite timeout) wait4msg continue ld 0x55d49a4a3070 msgid 1 all 1 ** ld 0x55d49a4a3070 Connections: * host: 192.168.100.11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 20:32:08 2020 ** ld 0x55d49a4a3070 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x55d49a4a3070 request count 1 (abandoned 0) ** ld 0x55d49a4a3070 Response Queue: Empty ld 0x55d49a4a3070 response count 0 ldap_chkResponseList ld 0x55d49a4a3070 msgid 1 all 1 ldap_chkResponseList returns ld 0x55d49a4a3070 NULL ldap_int_select read1msg: ld 0x55d49a4a3070 msgid 1 all 1 ber_get_next ldap_err2string ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 1, msgid 1) ldap_free_connection 1 1 ldap_free_connection: actually freed server# ldapwhoami -x -D "uid=thierry,ou=People,ou=linux,dc=be" -w password -d 1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 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 ({i) ber: ber_flush2: 58 bytes to sd 3 ldap_result ld 0x563d667e3060 msgid 1 wait4msg ld 0x563d667e3060 msgid 1 (infinite timeout) wait4msg continue ld 0x563d667e3060 msgid 1 all 1 ** ld 0x563d667e3060 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 20:30:44 2020 ** ld 0x563d667e3060 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x563d667e3060 request count 1 (abandoned 0) ** ld 0x563d667e3060 Response Queue: Empty ld 0x563d667e3060 response count 0 ldap_chkResponseList ld 0x563d667e3060 msgid 1 all 1 ldap_chkResponseList returns ld 0x563d667e3060 NULL ldap_int_select read1msg: ld 0x563d667e3060 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x563d667e3060 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x563d667e3060 0 new referrals read1msg: mark request completed, ld 0x563d667e3060 msgid 1 request done: ld 0x563d667e3060 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_extended_operation ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 32 bytes to sd 3 ldap_result ld 0x563d667e3060 msgid -1 wait4msg ld 0x563d667e3060 msgid -1 (timeout 100000 usec) wait4msg continue ld 0x563d667e3060 msgid -1 all 1 ** ld 0x563d667e3060 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 20:30:44 2020 ** ld 0x563d667e3060 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x563d667e3060 request count 1 (abandoned 0) ** ld 0x563d667e3060 Response Queue: Empty ld 0x563d667e3060 response count 0 ldap_chkResponseList ld 0x563d667e3060 msgid -1 all 1 ldap_chkResponseList returns ld 0x563d667e3060 NULL ldap_int_select read1msg: ld 0x563d667e3060 msgid -1 all 1 ber_get_next ber_get_next: tag 0x30 len 53 contents: read1msg: ld 0x563d667e3060 msgid 2 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x563d667e3060 0 new referrals read1msg: mark request completed, ld 0x563d667e3060 msgid 2 request done: ld 0x563d667e3060 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (O) ber: dn:uid=thierry,ou=People,ou=linux,dc=be ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed Op wo 11 mrt. 2020 om 18:15 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > > > --On Wednesday, March 11, 2020 10:08 AM +0100 Thierry Debaene > <thierry.debaene(a)gmail.com> wrote: > > > > > > > Dear Quanah, OpenLDAPs, > > > > > > Herewith the proof that slapd is listening on port 389. > > I also included the slapd.conf, /etc/sysconfig/slapd and ldap.conf files. > > I would: > > a) Start with ldapwhoami (rather than ldapsearch), just for simplicity > b) add a -d -1 for full client side debugging to see where it's getting > hung up > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 2

Information about source code of mobiuniquemember
by HANCHATE Ravikiran (u5574292) 11 Mar '20

11 Mar '20

Dear, we need information about source code of mobiuniquemember. How can we find source code of mobiuniquemember for our Opneldap infra ? Kindly assist here . Regards, Ravikiran. *********DISCLAIMER********* This electronic transmission (and any attached document) is intended exclusively for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any disclosure, copying, distribution or other action based upon the information by persons or entities other than the intended recipient is prohibited. If you receive this message in error, please contact the sender and delete the material from any and all computers. Orange Belgium does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. Unless clearly and unambiguously stated otherwise, the content of this e-mail and its attachment is provided to you for information purposes only, and nothing herein shall be binding upon, or shall constitute or be construed as a binding offer of Orange Belgium. *****END OF DISCLAIMER*****

2 1

Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene 11 Mar '20

11 Mar '20

Dear Quanah, OpenLDAPs, Herewith the proof that slapd is listening on port 389. I also included the slapd.conf, /etc/sysconfig/slapd and ldap.conf files. Regards, Thierry # netstat -ltn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::389 :::* LISTEN tcp6 0 0 :::3306 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN # nc -zv 192.168.100.11 389 Ncat: Version 7.50 ( https://nmap.org/ncat ) Ncat: Connected to 192.168.100.11:389. Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds. # cat /etc/openldap/slapd.conf 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/ppolicy.schema allow bind_v2 idletimeout 10 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload ppolicy.la moduleload syncprov password-hash {CRYPT} password-crypt-salt-format "$6$%.86s" access to * by * read database bdb suffix "dc=be" rootdn "cn=Manager,dc=be" rootpw {CRYPT}$6$DAn/HuEvv8oxXzht$4...k4ZUiJG4qUKzqUTCQVtuUY1 directory /var/lib/ldap 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 overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=be" ppolicy_use_lockout # cat /etc/sysconfig/slapd SLAPD_URLS="ldapi:/// ldap:///" # cat /etc/openldap/ldap.conf #TLS_CACERTDIR /etc/openldap/certs #TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT never SASL_NOCANON on Op di 10 mrt. 2020 om 19:42 schreef Quanah Gibson-Mount <quanah(a)symas.com>: > --On Tuesday, March 10, 2020 12:03 PM +0100 Thierry Debaene > <thierry.debaene(a)gmail.com> wrote: > > ># ldapsearch -x -H ldap://192.168.100.11 -D > ># "uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be > ># -LLL memberUid -v > > ldap_initialize( ldap://192.168.100.11:389/??base ) > > ldap_result: Can't contact LDAP server (-1) > > Please provide evidence that slapd is listening to 192.168.100.11 on port > 389 and that it can be accessed (i.e., no firewall etc blocking access). > > For example on my local system: > > nc -zv 10.2.0.74 389 > Connection to 10.2.0.74 389 port [tcp/ldap] succeeded! > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene 10 Mar '20

10 Mar '20

Hello OpenLDAPs, Any LDAP search request with '-H ldap://<IP_LDAP_server>/' option returns 'Can't contact LDAP server (-1)' (see below). When the '-H ...' option is left out or when '-H ldap:///' is used, the expected result is returned (see below). The 'ldapsearch -x -H ldap://<IP_LDAP_server>/ ...' behaves the same from the server as from a client on the same LAN. Thanks for helping me to get rid of this problem. Thierry # ldapsearch -x -H ldap://192.168.100.11 -D "uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be -LLL memberUid -v ldap_initialize( ldap://192.168.100.11:389/??base ) ldap_result: Can't contact LDAP server (-1) # ldapsearch -x -D "uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be -LLL memberUid -v ldap_initialize( <DEFAULT> ) filter: (objectclass=*) requesting: memberUid dn: cn=thierry,ou=Group,ou=linux,dc=be memberUid: thierry # ldapsearch -x -H ldap:/// -D "uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be -LLL memberUid -v ldap_initialize( ldap://:389/??base ) filter: (objectclass=*) requesting: memberUid memberUid: thierry

2 1

Re: back-ldap SASL proxy authorization
by Dieter Bocklandt 09 Mar '20

09 Mar '20

Hi Quanah, Of course! Submitted this as ITS#9179. Regards, //Dieter On Fri, 6 Mar 2020 at 17:52, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, March 5, 2020 8:04 PM +0000 Howard Chu <hyc(a)symas.com> > wrote: > > >> Actually, I spent some more time on this today and I /think/ I might > >> know what's happening here: > > > > Your analysis makes sense. Would have to ask Pierangelo why he wrote it > > the way he did but it seems that it should use op->o_ndn. > > Hi Dieter, > > Can you file an ITS on this issue at http://www.openldap.org/its > including > your analysis? > > Thanks! > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Memory mapping questions
by Sam Dave 08 Mar '20

08 Mar '20

Hi, 1. Is it possible to disable memory mapping in LMDB? 2. If I create a brand-new database and write data into it (but haven't read it yet) can I be assured it won't be memory-mapped yet? The purpose of these question is to get more consistent/reproducible time benchmarks for some stuff I'm doing. (As you know the drive vs. memory-mapped performance varies heavily.) Thanks, Sam

3 3

Re: back-ldap SASL proxy authorization
by Dieter Bocklandt 06 Mar '20

06 Mar '20

Hey Quanah, Thanks for getting back to me! So as I understood it, I expected the proxied identity to be the identity that the client successfully authorized as instead of the identity it initially started with. The session tracking request is just there to confirm that piece of information is actually present but not used. That initial identity is also used for ACL evaluation on the producer side, leading to insufficient access (as expected). To give a maybe more clear example, assume the following users (stripped down to just the relevant attributes in play): *dn: cn=proxy,ou=System,dc=example,dc=netauthzTo: dn:** *dn: cn=service,ou=System,dc=example,dc=net * *authzTo: dn:uid=user,ou=People,dc=example,dc=net * *dn: uid=dieter,ou=People,dc=example,dc=net * *and the following idassert config:* *olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX * When I perform an operation like this: ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f modifications.ldif I would assume the following takes place: - The service user binds to the consumer and assumes dieter's identity, which should be the same net effect as binding with dieter's user in the first place. - The proxy user binds to the provider and assumes dieter's identity - The provider tries to perform the write, using dieter's identity for ACL evaluation What actually happens: - The service user binds to the consumer and assumes dieter's identity - The proxy user binds to the provider and assumes the service user's identity - The provider tries to perform the write, using the service user's identity for ACL evaluation Actually, I spent some more time on this today and I *think* I might know what's happening here: (from servers/slapd/back-ldap/bind.c in master): line 2222 - 2227: *if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; }* line 2549 - 2557: *if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn; } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; }* It seems it tries to use op->o_conn->c_ndn if it's not null, which is (correct me if I'm wrong) the original authcID. That value however doesn't change when performing a proxy authorization, while op->o_ndn does properly reflect that. Shouldn't OpenLDAP always use op->o_ndn? Again, let me know if I can provide more information or tell me if I'm grossly misunderstanding how this is all supposed to work in the first place :) Thanks! // Dieter On Wed, 4 Mar 2020 at 23:12, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt > <dieterbocklandt(a)gmail.com> wrote: > > > However, we also have a service using SASL proxy authorization, in which > > case the authcid is used in the ProxyAuthz instead of the authorized > > authzid. > > > > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ > > dn="cn=service,ou=system,dc=internal,dc=machines" > > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 > > [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD > > dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" > > > > Am I misunderstanding how this is supposed to work, am I hitting a > > certain limitation or maybe a bug? Let me know if you need any more > > details! > > This looks to me like it: > > a) Logs what the proxied identity is (PROXYAUTHZ > dn="cn=service,ou=system,dc=internal,dc=machine") > > b) Logs what the actual identity making the changes is > (USERNAME=cn=enduser,ou=People,dc=example,dc=net) and what IP address it > came from (IP=10.243.72.199) so that if questions arise about who made a > change, those questions can be answered from the logs. > > I.e., I see both bits of information provided in the connection operation. > > What makes you think you are hitting a limitation or a bug? > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

4 3

Re: openldap-technical Digest, Vol 148, Issue 6
by Dieter Bocklandt 06 Mar '20

06 Mar '20

Hey Michael, I would assume that for the proxy it shouldn't matter how the client got authenticated to the consumer. Mode=self should just try and assert the resulting authzID to the target. The identity of the proxy is only there so we have something to bind with to the producer. With mode=none, that identity would also be used for the actual ACL evaluation, but that would just lead to all writes being done by seemingly 1 user, making auditing impossible ... Cheers, //Dieter On Fri, 6 Mar 2020 at 13:00, <openldap-technical-request(a)openldap.org> wrote: > > ---------- Forwarded message ---------- > From: "Michael Ströder" <michael(a)stroeder.com> > To: openldap-technical(a)openldap.org > Cc: > Bcc: > Date: Thu, 5 Mar 2020 21:46:12 +0100 > Subject: Re: back-ldap SASL proxy authorization > On 3/5/20 9:04 PM, Howard Chu wrote: > > Dieter Bocklandt wrote: > >> I would assume the following takes place: > >> - The service user binds to the consumer and assumes dieter's identity, > which should be the same net effect as binding with dieter's user in the > first place. > >> - The proxy user binds to the provider and assumes dieter's identity > >> - The provider tries to perform the write, using dieter's identity for > ACL evaluation > >> > >> What actually happens: > >> - The service user binds to the consumer and assumes dieter's identity > >> - The proxy user binds to the provider and assumes the service user's > identity > >> - The provider tries to perform the write, using the service user's > identity for ACL evaluation > >> > >> Actually, I spent some more time on this today and I /think/ I might > know what's happening here: > > > > Your analysis makes sense. Would have to ask Pierangelo why he wrote it > the way he > > did but it seems that it should use op->o_ndn. > > Hmm, is the semantics of proxying the SASL proxy authorization clearly > defined? The consumer proxy itself also has an identity. > > Just asking... > > Ciao, Michael. > > > _______________________________________________ > openldap-technical mailing list > openldap-technical(a)openldap.org > http://www.openldap.org/lists/mm/listinfo/openldap-technical >

1 0

Antw: [EXT] Re: pwdChangedTime not defined when creating new entry
by Ulrich Windl 05 Mar '20

05 Mar '20

>>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am 05.03.2020 um 10:10 in Nachricht <25580_1583399661_5E60C2EC_25580_1796_1_20200305101027.4c15a1d1(a)pink.fritz.box>: > Am Wed, 04 Mar 2020 13:36:08 +0000 > schrieb Manuela Mandache <manuela.mandache(a)protonmail.com>: > >> Hello all, >> >> We have a directory running on OpenLDAP 2.4.44 with the ppolicy >> overlay on the main database. When a new entry with a userPassword >> defined is created, pwdChangedTime is not defined, so this initial >> userPassword never expires. >> >> The directory has been migrated from its OpenLDAP 2.3.34 instance >> (yes, we missed some steps...), and there the pwdChangedTime is set, >> and naturally equal to createTimestamp. >> >> The overlay is configured as follows: >> dn: olcOverlay={2}ppolicy,olcDatabase={2}mdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcPPolicyConfig >> olcOverlay: {2}ppolicy >> olcPPolicyDefault: ou=ppolicy,dc=example,dc=com >> olcPPolicyHashCleartext: TRUE >> olcPPolicyUseLockout: TRUE >> >> Is there a parameter I missed which would switch on setting >> pwdChangedTime at entry creation? Do I have to provide some other >> configuration elements? >> >> Or is it unreasonable to expect this initialisation of the attribute >> this way, and only a password change can set it? I think the setting >> at creation is rather handy... Using pwdMustChange would be >> difficult, we have a lot of client apps which would be forced to >> check and probably adapt their authentication procedures. > [...] > The password attribute value must be set by a password modify exented > operation in order to set password policy in effect, see man > slapo-ppolicy(5) Yes, but shouldn't there be some magic to add it to all existing passweords when enabling it? Without having each user to change the password... > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E

2 1

back-ldap SASL proxy authorization
by Dieter Bocklandt 04 Mar '20

04 Mar '20

Hi! We have a fairly standard OpenLDAP setup (on 2.4.49) running well, where our replica instances chain writes back to the master using the chain overlay. Relevant bits of configuration we're using below: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 8 olcDbSessionTrackingRequest: TRUE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbIdleTimeout: 5 . . . dn: cn=proxy,ou=System,dc=example,dc=net cn: proxy objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: XXXXX authzTo: {0}dn.regex:^uid=[^,],ou=People,dc=example,dc=net$ Above works great, with the client identity being authorized through the ProxyAuthz control. However, we also have a service using SASL proxy authorization, in which case the authcid is used in the ProxyAuthz instead of the authorized authzid. Ldapwhoami works as expected and the username mentioned in the session tracking request (visible in the producer's logs) is actually the authzdn (being cn=enduser,ou=People,dc=example,dc=net in this example, whereas cn=service,ou=system,dc=internal,dc=machines is the authcdn): ldapwhoami -H ldaps://$(cat /etc/service_hostname) -U service -X dn:cn=enduser,ou=People,dc=example,dc=net -Y PLAIN SASL/PLAIN authentication started Please enter your password: SASL username: dn:cn=enduser,ou=People,dc=example,dc=net SASL SSF: 0 dn:cn=enduser,ou=People,dc=example,dc=net Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD attr=klarnaItNote Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] RESULT tag=103 err=0 text= Am I misunderstanding how this is supposed to work, am I hitting a certain limitation or maybe a bug? Let me know if you need any more details! Thanks! Dieter Bocklandt

2 1

identifying anonymouns binds
by Geert Hendrickx 04 Mar '20

04 Mar '20

Hi I'd like to inventorise (and eventually disable) anynomous binds on an LDAP server with many different client applications. I am evaluating stats logs, and I see that most anonymous binds are logged as: conn=32743 op=0 BIND dn="" method=128 conn=32743 op=0 RESULT tag=97 err=0 text= However some connections log no BIND operation at all, just SRCH ops etc. I cannot replicate this behaviour with ldapsearch, it comes from an old java client. So looking for 'BIND dn=""' is not enough - how can I reliably identify anonymous binds? Looking for each op=0 and if it's not a SRCH, assume it's an anonymous bind as well? We have no "features" like bind_v2, bind_anon_cred etc enabled. Second question is what is the proper way to disable anonymous access? Through access controls (which we already have in place for fine-grained write access control), or on server-wide level by 'disallow bind_anon' ? Thanks Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

2 1

ldap_sasl_interactive_bind_s: Local error (-2) for SASL/GSS-SPNEGO
by Debashis Chaki 02 Mar '20

02 Mar '20

Hi , I have installed openldap but I am getting the following error while executing some basic command using SASL/GSS-SPNEGO authentication Where as SASL/EXTERNAL authentication working perfectly. [root@dtgldap103 LdapCfg]# ldapsearch SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapwhoami SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcDatabase=config SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: olcDatabase=config # requesting: ALL # # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage by * none # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@dtgldap103 openldap]# rpm -qa | grep ldap sssd-ldap-1.15.2-50.el7_4.2.x86_64 openldap-clients-2.4.44-5.el7.x86_64 openldap-servers-sql-2.4.44-5.el7.x86_64 openldap-servers-2.4.44-5.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-devel-2.4.44-5.el7.x86_64 openldap-2.4.44-5.el7.x86_64 nss-pam-ldapd-0.8.13-8.0.1.el7.x86_64 Please help me how can I get out of this issue ? I am not able to proceed further for our openldap project without that. Please let me know if you need any more details. Thanks & Regards <http://www.proquest.com/> Debashis Chaki ProQuest | The Quorum, Barnwell Road | Cambridge | CB5 8SW | UK debashis.chaki(a)proquest.com tel: +44 (0)1223 271257 Better research. Better learning. Better insights.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2020