openldap-technical

openldap-technical@openldap.org

12 participants
9770 discussions

Client IP address in accesslog ?
by Benjamin Renard 20 Nov '24

20 Nov '24

Hi, I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented. Thanks! -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

6 8

RE26 testing call (2.6.9) #1
by Quanah Gibson-Mount 19 Nov '24

19 Nov '24

This is the first testing call for OpenLDAP 2.6.9. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.9 Engineering Fixed libldap TLS connection timeout handling (ITS#8047) Fixed libldap GnuTLS incompatible pointer type (ITS#10253) Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223) Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224) Fixed slapd cn=config disallowed modification of cn=schema (ITS#10256) Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232) Fixed slapd syncrepl retry state during refreshDone (ITS#10234) Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237) Fixed slapd-mdb idl intersection (ITS#10233) Fixed slapd-wt idl intersection (ITS#10233) Fixed slapo-memberof to omit dynamic values (ITS#10230) Fixed slapo-nestgroup leak in nestgroup_memberFilter (ITS#10249) Fixed slapo-translucent regression with subordinate databases (ITS#10248) Fixed slapo-translucent regression when requesting attributes (ITS#10272) Fixed slappw-argon2 defaults to be more secure (ITS#9827) Minor Cleanup ITS#10155 ITS#10218 ITS#10219 ITS#10227 ITS#10231 ITS#10235 ITS#10263 ITS#10264 Regards, Quanah

3 2

Technical account impersonation or not
by BECOT Jérôme 19 Nov '24

19 Nov '24

Hello all, We currently use two distinct accounts for chaining and replication purpose. We want to use a passwordless policy and we go for certificates. As we only own a single certificate per slave server, this means that we authenticate as a single user. We see two way to do things: * Either we just use one account (bound by olcAuthzRegexp rule) and merge ACLs to allow this account to read the directory for sync and write authentication attributes for chaining * Or we keep two accounts and use Proxy Auth to impersonate the other one I personnaly would go for the first one as I don't see any value to use another mechanism given that these are technical accounts that have only one purpose each, except having a distinct login in the logs. What would you advice ? I may have miss something intersting, any security issue, or maybe there is another way. Thank you ! Jerome

2 1

Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Windl, Ulrich 19 Nov '24

19 Nov '24

Hi! Me again after 10 years with basically the same question (https://www.openldap.org/lists/openldap-technical/201411/msg00044.html): What is the meaning of messages like these (note the number of messages created): Nov 19 11:53:47 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040879 seconds Nov 19 11:53:50 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040876 seconds Nov 19 11:53:52 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040874 seconds Nov 19 11:53:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040872 seconds Nov 19 11:53:57 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040869 seconds Nov 19 11:53:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040867 seconds Nov 19 11:57:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040645 seconds Nov 19 11:57:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040642 seconds Nov 19 11:58:01 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040625 seconds ... Nov 19 13:18:35 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035791 seconds Nov 19 13:18:39 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035787 seconds Nov 19 13:18:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035785 seconds Nov 19 13:18:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035782 seconds Nov 19 13:18:46 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035780 seconds Nov 19 13:18:48 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035778 seconds Nov 19 13:18:51 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035775 seconds Nov 19 13:18:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035772 seconds Nov 19 13:18:56 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035770 seconds Nov 19 13:18:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035767 seconds Nov 19 13:19:02 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035764 seconds So the server logs such an entry every few seconds. I might guess that the user tried to authenticate every few seconds (for whatever reason). But what I wonder most: The LDAP server does not seed to "set" the password expiration; it just has to check the value. And for the latter I see no need to log it in syslog. It seems the number is the number of seconds until the password actually expired. So is that a (historic) bug? And yes, I'm still running a historic 2.4 version of OpenLDAP, so no need to tell me that it's quite old. (Despite of that we really intend to upgrade, but the more persons involved, the loger it takes...) Kind regards, Ulrich

1 0

PP/expiry issues with Ubuntu22 and RH6
by Felix Natter 18 Nov '24

18 Nov '24

Dear openldap experts, the company I work for recently migrated to Ubuntu 22.04, and we use openldap with password policies and password expiry (once per year), with no changes to OpenLDAP config. However, we also use a scientific linux 6 (SL6, ~RH6) compile machine for backwards compatibility purposes (also using OpenLDAP). Now what happens is: - user ldaptestuser1's password expires - she/he changes her/his password on Ubuntu (problem 1: no PP checking, maybe due to cache_credentials = yes in /etc/sssd/sssd.conf) - SL6 (host X) does not know about that (problem 2: pwd checking on SL6 _always_ yields a Constraint violation, so user ldaptestuser1 cannot login there): ldaptestuser1@X's password: You are required to change your password immediately (password aged) You are required to change your LDAP password immediately. Last login: DATE from Y WARNING: Your password has expired. You must change your password now and login again! Changing password for user ldaptestuser1. Enter login(LDAP) password: New password: Retype new password: LDAP password information update failed: Constraint violation Password fails quality checking policy passwd: Authentication token manipulation error Connection to X closed. I cannot see any relevant error in the server (sys)log (with stats logging). Which log level shall I enable? - is there a workaround / fix for problem 1? - Regarding problem 2: shall I disable password expiry (shadow extension)? Many Thanks and Best Regards! -- Felix Natter

2 1

ACL on userPassword attribute on a relay database
by ptitoliv+openldap＠ptitoliv.net 18 Nov '24

18 Nov '24

Hello dear Openldap community, I'm writing you this email because I'm trying to create a configuration using relay backend + rvm and settings ACLs in the virtual database and I must admit I'm a little bit confused about all these components are working together. I actually have two databases: - The real one dc=ptitoliv,dc=net - The virtual one dc=example,dc=com I did a simple configuration using the RWM overlay and the rwm-suffixmassage directive. Everything seems to be okay except for the ACL. More precisely, my concern is about the ACL to apply in order to restrict the access to the userPassword attribute to the "virtual self" on the virtual database. My current status is the following : - If I don't put any ACL on the relay database, the userPassword attribute is readable by any authenticated user which is a thing I don't want - If I put the following ACL "to attrs=userPassword by self write by anonymous auth by * none" on the relay database nobody can read the userPassword including the virtual self. About the second point, if I understood correctly it's because the virtual binddn is mapped directly to the real one and the ACL tries to be resolved using the real binddn and not the virtual one like it is shown in the next trace. 673bb5e0.21d77b65 0x7f0d33dbf700 => access_allowed: read access to "uid=user,ou=people,dc=example,dc=com" "userPassword" requested 673bb5e0.21d78357 0x7f0d33dbf700 => acl_get: [1] attr userPassword 673bb5e0.21d79164 0x7f0d33dbf700 => acl_mask: access to entry "uid=user,ou=people,dc=example,dc=com", attr "userPassword" requested 673bb5e0.21d798c0 0x7f0d33dbf700 => acl_mask: to value by "uid=user,ou=people,dc=ptitoliv,dc=net", (=0) 673bb5e0.21d7bab8 0x7f0d33dbf700 <= check a_dn_pat: self 673bb5e0.21d7cc2c 0x7f0d33dbf700 <= check a_dn_pat: anonymous 673bb5e0.21d7d9d5 0x7f0d33dbf700 <= check a_dn_pat: * 673bb5e0.21d7e601 0x7f0d33dbf700 <= acl_mask: [3] applying none(=0) (stop) 673bb5e0.21d7f6df 0x7f0d33dbf700 <= acl_mask: [3] mask: none(=0) 673bb5e0.21d7fda4 0x7f0d33dbf700 => slap_access_allowed: read access denied by none(=0) So my question is that if it is possible to have an ACL on a virtual database in order to make the userPassword only readable by the logged user itself. Or is it just something that is not possible and if i want to access the userPassword attribute, it can be only done on the real database ? I tried to do some rewrite operation on the binddn but without any success 🙁 Thanks for you help ! Regards, Olivier Bonhomme

1 0

RE25 testing call (2.5.19) #1
by Quanah Gibson-Mount 18 Nov '24

18 Nov '24

This is the first testing call for OpenLDAP 2.5.19. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.19 Engineering Fixed libldap GnuTLS incompatible pointer type (ITS#10253) Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223) Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224) Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232) Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237) Fixed slapd-mdb idl intersection (ITS#10233) Fixed slapd-wt idl intersection (ITS#10233) Fixed slapo-translucent regression with subordinate databases (ITS#10248) Fixed slapo-translucent regression when requesting attributes (ITS#10272) Fixed slappw-argon2 defaults to be more secure (ITS#9827) Minor Cleanup ITS#10155 ITS#10219 ITS#10221 ITS#10227 ITS#10231 ITS#10264 Regards, Quanah

1 0

Master crashing when restarting Replicas
by Suresh Veliveli 14 Nov '24

14 Nov '24

Hello, We have a single master with multiple replicas. Sometimes when replicas are restarted the master is crashing. Openldap version - 2.6.7 Backend Database - mdb (gdb) core core.slapd.3003.d7d7f844eec3408ba1dfc465ee8306a1.16323.1731327494000000 [New LWP 16333] [New LWP 16741] [New LWP 16327] [New LWP 16328] [New LWP 16329] [New LWP 16360] [New LWP 16325] [New LWP 17359] [New LWP 16794] [New LWP 16323] [New LWP 16324] [New LWP 17765] [New LWP 16998] [New LWP 16334] [New LWP 17766] [New LWP 16999] [New LWP 16361] [New LWP 16795] Core was generated by `/var/services/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /var/serv'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004389bb in ?? () [Current thread is 1 (LWP 16333)] (gdb) bt full #0 0x00000000004389bb in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) q Nov 11 07:18:14 aaa-prod-master-1 kernel: slapd[16333]: segfault at 18 ip 00000000004389bb sp 00007f79ccaf8650 error 4 in slapd[419000+12d000] likely on CPU 1 (core 1, socket 0) Nov 11 07:18:14 aaa-prod-master-1 kernel: Code: 89 e8 b9 0e 00 00 00 4c 89 e7 f3 48 ab 48 89 e8 48 8b ad 90 01 00 00 8b 90 c0 00 00 00 85 d2 75 35 48 8b 10 4c 89 e6 4c 89 f7 <8b> 52 18 c7 80 c0 00 00 00 01 00 00 00 48 8b 05 91 82 1b 00 89 94 Nov 11 07:18:14 aaa-prod-master-1 systemd[1]: Created slice Slice /system/systemd-coredump. Nov 11 07:18:14 aaa-prod-master-1 systemd[1]: Started Process Core Dump (PID 349553/UID 0). Nov 11 07:18:17 aaa-prod-master-1 systemd-coredump[349554]: Process 16323 (slapd) of user 3003 dumped core.#012#012Stack trace of thread 16333:#012#0 0x00000000004389bb n/a (slapd + 0x389bb)#012#1 0x000000000043a6f4 connection_closing (slapd + 0x3a6f4)#012#2 0x000000000043b5ce n/a (slapd + 0x3b5ce)#012#3 0x00007f9340de7d1a ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43d1a)#012#4 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#5 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16741:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16327:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16328:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16329:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16360:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16325:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 17359:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16794:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16323:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f934048b6d3 __pthread_clockjoin_ex (libc.so.6 + 0x8b6d3)#012#2 0x00000000004381ca slapd_daemon (slapd + 0x381ca)#012#3 0x000000000041e47f main (slapd + 0x1e47f)#012#4 0x00007f9340429590 __libc_start_call_main (libc.so.6 + 0x29590)#012#5 0x00007f9340429640 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29640)#012#6 0x000000000041e855 _start (slapd + 0x1e855Nov 11 07:18:17 aaa-prod-master-1 systemd[1]: systemd-coredump(a)0-349553-0.service: Deactivated successfully. Nov 11 07:18:17 aaa-prod-master-1 systemd[1]: systemd-coredump(a)0-349553-0.service: Consumed 3.288s CPU time. Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Main process exited, code=dumped, status=11/SEGV Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Failed with result 'core-dump'. Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Consumed 14h 31min 2.574s CPU time. Any thoughts? Thanks, -- Suresh Veliveli Sr. Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration

3 3

Trouble with UID Filter in OpenLDAP (slapd meta): Missing Schema or Configuration Issue?
by tmp 2810 07 Nov '24

07 Nov '24

Hi! I think I'm finally able to configure slapd with a meta backend, but I'm experiencing a strange issue when I perform a search with ldapsearch and try to filter by uid. If I use "uid=user" it doesn't work, but if I use "cn=user" it does work, and I need the searches to be by uid. I understand this could be related to the schemas I’m loading, but I thought uid was a standard attribute already loaded in core.schema. Just in case, I'm using Debian 12, and these are the schemas available: collective.schema corba.schema core.schema cosine.schema dsee.schema duaconf.schema dyngroup.schema inetorgperson.schema java.schema misc.schema msuser.schema namedobject.schema nis.schema openldap.schema pmi.schema These are the schemas I’m using to test: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema And as a detail, I find that this part referring to uid (I might be mistaken) is commented out: attributetype ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'RFC1274: user identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) but when I try to uncomment it, I get the error: 672b6c65.324d8768 0x7febb561d200 /etc/ldap/schema/core.schema: line 564 attributetype: Duplicate attributeType: "0.9.2342.19200300.100.1.1" Just in case, here’s my configuration. Could it be that something is missing so that a user can log in against this slapd? Since my applications search by uid (some are very legacy and I can't modify them), I'm unable to verify if everything is correctly set up to make a connection. The only indication that it’s working is that I can retrieve all users with ldapsearch and their attributes, but I can't filter by uid. ########################################## include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema modulepath /usr/lib/ldap moduleload back_meta.la moduleload back_ldap.la database meta suffix "dc=proxy" rootdn "cn=admin,dc=proxy" rootpw 1234 ## example.com uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on rebind-as-user yes chase-referrals yes idassert-bind bindmethod=simple binddn="uid=ldap,ou=Users,dc=example,dc=com" credentials="secret-password" tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/ldap.crt tls_key=/root/ldapcerts/ldap.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem idassert-authzFrom "*" ############################### Thanks for all the help!

3 2

Re: Issue with slapd and Google LDAP Integration (lowercase user)
by tmp 2810 05 Nov '24

05 Nov '24

Thats my actual config and the message on the logs is : Unauhtenticated ================================================ uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/google_cert.crt tls_key=/root/ldapcerts/google_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ================================================ I've actually been trying all kinds of configurations for the last 2 weeks. Is there a chance that this doesn't work with Google's LDAP? I can't find a single example on the entire internet of someone who has managed to do this whit the LDAP of google. El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah(a)fast-mail.org>) escribió: > > > --On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com> > wrote: > > > Once again, I apologize; I ran so many tests that I accidentally copied > > one where the binddn was incorrect. > > > > The target looks more like this: > > > >## example.com > > uri "ldaps://ldap.google.com/dc=proxy" > > suffixmassage "dc=proxy" "dc=example,dc=com" > > lastmod off > > readonly on > > idassert-bind bindmethod=simple > > binddn="cn=ChiwewDaw" > > cn, is by definition, case insensitive. If Google LDAP is forcing case > sensitivity in this attribute, it is gross violation of the LDAP RFCs. > However, having had to interface with it in the past, I don't believe that > is the case. I would generally suspect that this is not the full DN of > the > user. > > > idassert-bind bindmethod=sasl > > saslmech=EXTERNAL > > tls_reqcert=demand > > tls_reqsan=demand > > starttls=critical > > > This is not sufficient, please read the man page: > > > idassert-bind bindmethod=none|simple|sasl [binddn=<simple > DN>] > [credentials=<simple password>] [saslmech=<SASL > mech>] > [secprops=<properties>] [realm=<realm>] > [authcId=<authentication > ID>] [authzId=<authorization ID>] > [authz={native|proxyauthz}] > [mode=<mode>] [flags=<flags>] > [starttls=no|yes|critical] > [tls_cert=<file>] [tls_key=<file>] > [tls_cacert=<file>] > [tls_cacertdir=<path>] > [tls_reqcert=never|allow|try|demand] > [tls_reqsan=never|allow|try|demand] > [tls_cipher_suite=<ciphers>] > [tls_ecname=<names>] > [tls_protocol_min=<version>] > [tls_crlcheck=none|peer|all] > > > You *must* specify tls_cert, tls_key, and tls_cacert as a part of > idassert-bind as it provides the TLS identity to bind as. In your > configuration for simple bind, tls_cert and tls_key are unnecessary as > you're not doing SASL/EXTERNAL binds. > > --Quanah > > > >

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical