openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Procedure going from search query to an acl
by Marc Roos 27 Aug '19

27 Aug '19

I have client that coredumps with these acl's. When I remove them, the client is getting data from the ldap server and I can see the queries it is doing on the server. I thougt the lines below would give access to ou=Services and below by test, but I guess not. dn: olcDatabase={-1}frontend,cn=config olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none olcAccess: {3} to dn.exact="ou=Services,dc=example,dc=local" attrs="children" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read by * break olcAccess: {4} to dn.children="ou=Services,dc=example,dc=local" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read olcAccess: {5} to * by * none acl_mask: access to entry "name=asdf,ou=Services,dc=example,dc=local", attr "bla" requested acl_mask: access to entry "ou=Services,dc=example,dc=local", attr "entry" requested I guess I should grep the log for the acl_mask entries not? What would be an adviced procedure to do this? I also do not want to get a huge list of acls for just one client type. Everything below "ou=Services,dc=example,dc=local" is test to read. (No password attributes stored there)

2 1

Q: Multiple accesslog overlays?
by Ulrich Windl 27 Aug '19

27 Aug '19

Hi! I have a question preparing a transition of syncrepl to delta-syncrepl: Our database already has an accesslog overlay (olcAccessLogOps: writes) and a corresponding database configured for monitoring purposes. Now that delta syncreply also requires an accesslog overlay/database with somewhat different setting compared to the existing database, I wonder whether it's possible (and practically being used/proven to work) to have multiple accesslog overlays. Thinking about it, I also wonder whether both needs for accesslog could be satisfied with one accesslog database, just using different LDAP filters. I guess the delta syncreply is using the acesslog database in a read-only manner (our monitoring also does), so it might actually work. Anybody went that way before? Finally a question on the requirement to backup the acesslog database in addition to the corresponding database (18.2.1: "Note: since the database state is stored in both the changelog DB and the main DB on the provider, it is important to backup/restore both the changelog DB and the main DB using slapcat/slapadd when restoring a DB or copying it to another machine."): Is it actually a hard requirement needed for consistency, or will it just improve the performance (avoiding a full refresh)? Also: Isn't it tricky to backup both databases consistently while the database is writable? Regards, Ulrich

3 10

Adding syncprov to running slapd
by Marc Roos 27 Aug '19

27 Aug '19

I am adding the syncprovider to a running server with these: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpCheckpoint: 100 10 olcSpSessionlog: 100 However when I do slapd -VVV the overlay is not listed. Do I need to 1. restart? 2. use syncprov.la instead of syncprov?

3 2

Socat tcp to local socket
by Marc Roos 27 Aug '19

27 Aug '19

Anyone having some experience using socat (or something similar?) to connect to a remote slapd server tcp/tls with a local socket? I have a client that requires the local ldapi socket. But I do not want to install there an instance of slapd.

1 2

RE: Socat tcp to local socket
by Marc Roos 26 Aug '19

26 Aug '19

Hi Harry, I just did a build from srpm, and currently I trying to get the scenario of a pipe between sockets working. Just to make sure this pipe is working correctly before I am moving to the tcp/tls connection. Of course my problem persists with socat using something like this. socat -s -d -d -d -t 3 UNIX-CONNECT:/var/run/ldapi,raw,ignoreeof UNIX-LISTEN:/var/run/bla,raw,ignoreeof,fork You have a suggestion how to to do this with dpipe, I have tried this dpipe vde_plug /var/run/ldapi = vde_plug /var/run/bla But it does not launch nor reports the error. -----Original Message----- Subject: Re: Socat tcp to local socket > > With this I am able to issue just one ldap search on the socket. > Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact > LDAP server (-1)' Sure, use either very long timeouts or use an other tool, i.e. dpipe. The problem with socat is, socat terminates after each ldapsearch. dpipe only stops, if manual terminated. Their are some other useful tools in vde2 package. > > socat -d -d > OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify= > 0, > keepalive,reuseaddr,ignoreeof > UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof > > I am just wondering if this is even possible, maybe the tcp > connections keeps an authorized session? Or ldapi communication is just different? > If this ldapi communication is different from ldaps. I guess I am only > left with the options like > - connecting with some forwarded ssh session to the local ldapi server > socket > - maybe export ldapi with stunnel on the server, and capture it again > with stunnel/socat > - look into slapd proxy/meta > > > > > > > > > -- Harry Jede

1 0

Complex setup to do back-ldap AND SASL auth in one go
by Markus.Storm＠t-systems.com 26 Aug '19

26 Aug '19

Dear all, I am desperately trying to setup an OpenLDAP instance "P" with a proxy or other backend or even chain of proxies to do the following and I just don't manage to wrap my head around it. I'd be thankful if someone could give me a helping hand and provide me with the missing link. Apologies upfront for the lengthy mail and complicated setup, but for organizational reasons, I have a couple of constraints that I cannot change. Scenario: Ultimately I want some UNIX machines using pam-ldap to authenticate against an Active Directory ("AD"). Logins to those machines require a number of attributes but I don't have authority/ability to store them in the AD. They are stored in an external (non-OpenLDAP !) server "S" instead. As the AD passwords cannot be read/replicated, I also cannot simply direct clients to S, so I want to direct them to an OpenLDAP instance "P" to "split" the request, i.e. do authentication against AD using external auth/SASL (that part already works) while retrieving the attributes from S. I have this working to some extent but needed to create a copy of the user data on S in my openLDAP server/proxy P. But I'm trying to avoid the need to have those copies in P, I want it to be dataless to avoid all need for synchronization (as S is non-OpenLDAP I cannot simply replicate). I'm open to suggestions but I think it would need to work like this: 1. Client "C" connects to P with say binddn cn=user,dc=domain and password pw 2. P proxies all requests for dc=domain to S using a generic binddn (instead of the user credentials) to have access to the subtree the users are in As of today I wouldn't know how to configure that binddn on P. 1. S has an entry for every user with userpassword={SASL}user@domain and a couple of attributes which all are returned to P S is the only place where we can store those attributes (and the instruction to use SASL - or is there another place for that ?) But authentication of C against S fails when I use the user's credentials (because of the "{SASL}..." contents on S). Obviously S is unable to interpret/execute SASL auth format (if it was able that would be an obvious solution to my problem). I also believe I cannot have ANOTHER userPassword attribute on S to have the user's password pw (S wouldn't know which of those 2 userPassword attributes to authenticate against). 1. P does SASL auth as user@domain and initially provided password against an Active Directory ("AD") The SASL part already works but only if I setup another DB in P to contain a copy of the user data tree on S and userPassword="{SASL}user@domain" for all users. Thanks in advance to anyone willing to wrap his head around my problem. Best regards Markus

2 2

Re: Socat tcp to local socket
by Giuseppe De Marco 25 Aug '19

25 Aug '19

Hi Marc, Slapd-proxy or slapd-meta could be the solution Il dom 25 ago 2019, 14:42 Marc Roos <M.Roos(a)f1-outsourcing.eu> ha scritto: > > Anyone having some experience using socat (or something similar?) to > connect to a remote slapd server tcp/tls with a local socket? I have a > client that requires the local ldapi socket. But I do not want to > install there an instance of slapd. > > > > > > >

1 0

openldap replication
by sami's strat 22 Aug '19

22 Aug '19

I'm trying to configure replication between two hosts using the following as a guideline: https://www.server-world.info/en/note?os=CentOS_7&p=openldap&f=5 Here are some notes I have based on the setup I've done: ##### REPLICATION ON Master ##### [root@ldap01 ~]# more mod_syncprov.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: syncprov.la [root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" [root@ldap01 ~]# more syncprov.ldif dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpSessionLog: 100 [root@ldap01 ~]# [root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" [root@ldap01 ~]# ##### REPLICATION ON Slave ##### [root@ldap02 ~]# more syncrepl.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://172.19.33.42:389/ bindmethod=simple binddn="cn=admin,dc=ZZZ,dc=ZZZ" credentials=password searchbase="dc=ZZZ,dc=ZZZ" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 [root@ldap02 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncrepl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}hdb,cn=config" [root@ldap02 ~]# # Testing LDAP ldapsearch -x -b 'uid=testaccount,ou=People,dc=ZZZ,dc=ZZZ' Both LDAP hosts work in the sense that I can authenticate to them. But replication is not working. Please help. TIA

2 1

any working documentation?
by Dmitri Seletski 21 Aug '19

21 Aug '19

Hello. I am new to the list, so if you gonna beat me with your feet - please don't hit me in the face. I did not find help/user list. So post here. Where can I find working documentation for OpenLDAP? Most current i found: https://www.openldap.org/doc/admin24/quickstart.html It says nothing of TLS encryption. I fail to start service See output below: TLSMC: MozNSS compatibility interception begins. tlsmc_intercept_initialization: INFO: entry options follow: tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap/certs' tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server' tlsmc_intercept_initialization: INFO: keyfile = `/etc/openldap/certs/password' tlsmc_convert: INFO: trying to open NSS DB with CACertDir = `/etc/openldap/certs'. tlsmc_open_nssdb: INFO: trying to initialize moznss using security dir `/etc/openldap` prefix `certs`. tlsmc_open_nssdb: WARN: could not initialize MozNSS context - error -8015. tlsmc_convert: INFO: cannot open the NSS DB, expecting PEM configuration is present. tlsmc_intercept_initialization: INFO: altered options follow: tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap' tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server' tlsmc_intercept_initialization: INFO: keyfile = `/etc/openldap/certs/password' tlsmc_intercept_initialization: INFO: successfully intercepted TLS initialization. Continuing with OpenSSL only. TLSMC: MozNSS compatibility interception ends. TLS: could not use certificate `OpenLDAP Server'. TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:402 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:404 TLS: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib ssl_rsa.c:468 5d5af51b main: TLS init def ctx failed: -1 5d5af51b slapd destroy: freeing system resources. 5d5af51b slapd stopped. 5d5af51b connections_destroy: nothing to destroy. Where can I submit errata to documentation maintainer?(as quick start clearly doesn't work in my default install of OpenLDAP on CentOS 7) And how can I start SLAPD without encryption? I can generate self signed private/public key and make ln -s of my CA cert folder to 'cacertdir = `/etc/openldap'', but this seems SOOO unnecessary. At least on 'try out' step. Thanks in advance Dmitri

5 6

BDB to LMDB migration and Linux kernel parameters
by openldap-technical＠kolttonen.fi 21 Aug '19

21 Aug '19

Hello! OpenLDAP Admin Guide says: [LMDB] supports indexing like the BDB backends, but it uses no caching and requires no tuning to deliver maximum search performance. We are planning migration from deprecated BerkeleyDB to recommended LMDB. Our OpenLDAP runs on RHEL7. Since the LMDB uses mmap() system calls, is it necessary to tweak any Linux kernel parameters to allow better caching etc.? Thanks for any information. Best regards, Jokke Hämäläinen

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical