openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

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

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

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

05 Nov '24

Yes, indeed the way was to use a simple bind of an email user with admin permissions in Google, and with that, I was able to do the bind. Thank you! El mar, 5 nov 2024 a las 13:16, Quanah Gibson-Mount (<quanah(a)fast-mail.org>) escribió: > > > --On Tuesday, November 5, 2024 1:06 PM -0300 tmp 2810 <t2810mp(a)gmail.com> > wrote: > > > 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. > > I've no idea if Google's LDAP supports SASL/EXTERNAL. You'd have to ask > Google. We used simple binds to Google w/o issue at a prior job I worked > at to sync data from OpenLDAP to it. > > --Quanah > > > >

1 0

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

05 Nov '24

Thank you for the response! No, no... these are example data that I put together to understand how Google users are structured and the issue that uppercase letters are causing me. In the Google LDAP audit, I see that the user fails and appears in lowercase. 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" credentials="password-fake" tls_reqcert=demand tls_reqsan=demand starttls=critical tls_cert=/root/ldapcerts/ldap_cert.crt tls_key=/root/ldapcerts/ldap_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem if i use: idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand starttls=critical i have the error : "Unauthenticated"

2 1

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

04 Nov '24

Hello everyone! I have been trying to configure slapd for a week to use it as a proxy for Google's LDAP service in order to connect some legacy applications. Since I have multiple domains in Google, I need to centralize all users into a common "dc." Everything is working well, but the problem is that, apparently, when connecting to Google, I am provided with a certificate that I download from the admin console. However, with that certificate alone, slapd cannot connect to the target. So, I generate some credentials from the Google LDAP admin and add them to the slapd configuration. The issue is that, for some reason, slapd converts the username to lowercase, and Google rejects it because it is case-sensitive. Is it possible to disable this function? (There is no way to create a user in Google that is only in lowercase) Here is my current slapd configuration: ################################################################ include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.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 "ldap://172.25.3.127:2636/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=simple binddn="ChiwewDaw" credentials="ASk0i9ejiosej9o303" tls_reqcert=demand tls_reqsan=demand starttls=critical tls_cert=/root/ldapcerts/ldap_cert.crt tls_key=/root/ldapcerts/ldap_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ################################################################## Thank you for your assistance! (ps: If anyone knows how to make it work using only the certificate, that would be great.)

2 1

Re: multi-master OpenLDAP with SASL/GSSAPI
by Travis Bean 04 Nov '24

04 Nov '24

On Tue, Jul 30, 2024 at 2:29 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Sunday, July 28, 2024 7:09 PM -0700 Travis Bean <tbean74(a)gmail.com> > wrote: > > > I developed a Bash script (https://launchpad.net/linuxha) to automate > > the installation and configuration of complex Linux software that is > > out of reach for most people. I want the syntax of this script to be > > perfect so I can use it as a teaching tool to educate people about > > Linux. > > > > If anyone on this mailing list is knowledgeable about multi-master > > OpenLDAP with SASL/GSSAPI authentication, please review the > > OpenLDAP/SASL/GSSAPI code that is part of my LinuxHA script and > > provide feedback. Thank you. > Just glancing at your script I see errors, such as: > > SASL_MECH GSSAPI PLAIN > > for ldap.conf. The man page clearly notes this takes a SINGLE mechanism. If ldap.conf(5) only supports one SASL mechanism for the SASL_MECH variable, then the man page at https://www.openldap.org/software/man.cgi?query=ldap.conf needs to be updated to clarify this. I originally configured the SASL_MECH variable for OpenLDAP's ldap.conf(5) the same way I configured the mech_list variable for Postfix's smtpd.conf and the auth_mechanisms variable for Dovecot's 10-auth.conf. I configured multiple SASL mechanisms for each of these variables for testing purposes. For a local area network, a system administrator has complete control over all the workstations and can make sure they all have Kerberos installed. For internet facing servers providing services to the wide area network (WAN), it makes sense to use a second SASL mechanism (something other than SASL/GSSAPI) in case any WAN devices do not have Kerberos installed, since a sysadmin may have no control over what is installed on WAN devices. I recently replaced libpam-ldap and libnss-ldap with sssd-ldap and sssd-krb5 for LinuxHA, since SSSD is a much better solution for identity and authentication. > Also, SASL/PLAIN is insecure and should never be used. Technically this is true. Even though when SASL/PLAIN is used in conjunction with Transport Layer Security, the credentials are encrypted. When ldap.conf(5) is installed on a server (as was the case when I was testing ldap.conf(5) on LinuxHA), using SASL/PLAIN is not insecure because it is only connected to a local socket on the local machine. > Another note is that SASL/GSASPI is extremely dependent on valid hostname > resolution. The pam ldap.conf seems unlikely to work (ldap://localhost for > the URI). When /etc/ldap.conf (the configuration file for PADL’s pam_ldap and nss_ldap modules) or /etc/ldap/ldap.conf (the configuration file for client applications such as ldapsearch, ldapadd, ldapmodify, and ldapdelete) is installed on a server rather than a workstation, you use "uri ldap://localhost", or "uri ldap://127.0.0.1", or better yet use LDAP over IPC mechanisms (LDAP over Inter-Process Communication) a.k.a. UNIX domain sockets (i.e., "uri ldapi:///"). See the following webpage for further details: https://datatracker.ietf.org/doc/html/draft-chu-ldap-ldapi-00 > I see so many things that are bad practice in this script in general I'm > not going to spend any more time reviewing it. I have tried very hard to make sure there are no “bad practices” incorporated into LinuxHA. From a security standpoint, I have attempted to design LinuxHA so it is one step ahead of standard security policies. Everytime Canonical releases a new version of Ubuntu Server, the configuration for LinuxHA has to be updated. I have tested LinuxHA on seven versions of Ubuntu Server thus far — from 12.04 to 24.04. Even though I try to go through all the software packages incorporated into LinuxHA everytime Canonical releases a new version of Ubuntu Server to see if any configuration file has changed and needs to be updated, it may take awhile to complete these updates. If you find any misconfiguration in LinuxHA, please submit a bug report: https://bugs.launchpad.net/linuxha/+filebug Kind regards, Travis Bean

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