openldap-technical

openldap-technical@openldap.org

23 participants
9790 discussions

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

Removing AutoCA overlay, objectClass, etc
by Brendan Kearney 29 Oct '24

29 Oct '24

list members, i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below: dn: olcOverlay={5}autoca objectClass: olcOverlayConfig objectClass: olcAutoCAConfig objectClass: top olcOverlay: {5}autoca structuralObjectClass: olcAutoCAConfig entryUUID: 739501f2-49ad-103e-911a-3dc9b40470bf creatorsName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com createTimestamp: 20240117175614Z olcAutoCADays: 3650 olcAutoCAKeybits: 2048 olcDisabled: TRUE olcAutoCAserverKeybits: 2048 olcAutoCAuserClass: inetOrgPerson olcAutoCAserverClass: device olcAutoCAserverDays: 1826 olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 2048 entryCSN: 20240117192443.210024Z#000000#001#000000 modifiersName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com modifyTimestamp: 20240117192443Z note, olcDisabled is set to true. it seems that something went awry and even though i didn't want the capability active, i wound up with some caCertificate and caPrivateKey objects created in the DIT. it looks like i may have added the overlay in an active state and disabled it after the caCertificate/PrivateKey objects were created. i want to clean up things and remove the AutoCA pieces until i can test them better. what process is needed to remove the objects and overlay, as replication may play a part in some of the effort? i could imagine that deleting the caCertificate and caPrivateKey objects would be relatively straight forward, but the overlay may prove a bit more complicated. i found a message on this list from some time ago, https://www.openldap.com/lists/openldap-technical/201811/msg00075.html, that says i can stop the slapd instance, remove the overlay ldif files and restart the instance, to accomplish this task. the issue that i am trying to avoid is having to take down the entire fully replicated DIT, in order to delete the overlay and not have replication recreate it because one active node "didn't get the memo". are there any insights into how i can delete overlays without having replication recreate the objects i want to remove, all while still providing at least one instance to service requests? if it clarifies things, i am running 3 slapd instances behind a load balancer and both the config DB and DIT are replicated between all nodes. if it comes to it, i could take down all instances to perform this work, but i would like to avoid it if possible. thanks in advance, brendan kearney

3 8

Unnamed sub-databases in LMDB
by ruben.soh＠rutgers.edu 26 Oct '24

26 Oct '24

Background: I am trying to implement a fully dynamic connectivity algorithm, based on this paper (https://dl.acm.org/doi/10.1145/502090.502095), using LMDB as the backend. Other implementations use an in-memory binary search tree. I am currently working on trying to implement an Euler Tour Forest using LMDB. Essentially, an Euler Tour of an unbalanced tree is obtained by doing a DFS and assigning an increasing index every time we visit a node (https://en.m.wikipedia.org/wiki/Euler_tour_technique). An Euler Tour Tree is simply a balanced tree containing the euler tour index as the key and a pointer to the node as the value, so I plan to store each Euler Tour Tree using an LMDB database. Problem: I need an unlimited amount of sub-databases - my first thought was to use mdb_dbi_open, however, it seems like this doesn't scale well because a list of named sub-databases is stored in every transaction. In the talk about LMDB's functionality at CMU (https://www.youtube.com/watch?v=tEa5sAh-kVk) there is some reference to sub-databases, but from reading the code it seems like unnamed sub-databases are only used for sorted duplicate keys. Am I correct in thinking that I'm going to need to add some new code to support unnamed sub-databases, or is there some way to do it that I'm not recognizing? And if I do need to change things, where should I start? Ruben Soh

2 1

Error after OpenLDAP update from 2.4 to 2.5 - ppolicy schema
by sharbich＠t-online.de 21 Oct '24

21 Oct '24

Hello, unfortunately I missed the update version note for the schema ppolicy. After updating and restarting the slapd service, I can no longer delete the schema. I get the following error message: "root@dsme01:~# slapcat -n0 > config.ldif olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" config error processing cn={15}ppolicy,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" slapcat: bad configuration file!" What can I do now? Greetings from Stefan Harbich

3 2

Help me understand LMDB internals
by ruben.soh＠rutgers.edu 20 Oct '24

20 Oct '24

I am a student trying to understand the code for LMDB. One thing I am confused about - there is apparently no mutex for creating a reader transaction. In the function mdb_txn_renew0, which is called by mdb_txn_begin to create the transaction, I see that if we are creating a read-only transaction, we select a meta page without acquiring any mutex. Then, the meta page snapshotted in these lines (and accessed later in the function as well): /* Copy the DB info and flags */ memcpy(txn->mt_dbs, meta->mm_dbs, CORE_DBS * sizeof(MDB_db)); /* Moved to here to avoid a data race in read TXNs */ txn->mt_next_pgno = meta->mm_last_pg+1; What happens if a write transaction commits to the meta page while this copy is happening? Isn't it possible that the reader transaction will have copied an inconsistent view of the meta page? Sincerely, Ruben

2 1

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Falgon 16 Oct '24

16 Oct '24

Hello, I'm working on the same project as Meheni. Thanks for your answer, we'll try version 2.6 OpenLDAP using the lastbind-precision. However we have several questions for the current version we're using. Is this a known problem and referenced somewhere? (we haven't found it) Is it normal to find no replication error logs even in stats + sync mode? We ran some tests in sequential mode (300,000 accounts one after the other) and managed to reproduce the problem. -Denis Le mer. 11 oct. 2023 à 14:11, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni > <mehani06(a)gmail.com> wrote: > > > > > > > Hello, we are working on a project and we've come across a problem with > > the replication after performance testing : > > You need to use OpenLDAP 2.6 and then set the: > > lastbind-precision > > value. I use 5 minutes. > > --Quanah >

4 8

← Newer
1
2
3
4
5
6
7
...
979
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical