openldap-technical

openldap-technical@openldap.org

6 participants
9858 discussions

pwdAccountLockedTime does not have any impact
by CVZ 11 Jul '23

11 Jul '23

Hi Everybody, <https://stackoverflow.com/posts/76341444/timeline> Sorry, we are figghting with pwdAccountLockedTime. I want to use "pwdAccountLockedTime" attribute to automatically lock an account using OpenLDAP (v.2.5.14). Whatever the value in the field, the account is never locked. I first started by activating the "ppolicy" module using slapadd and a ppolicy-module.ldif file suh as mentioned here "https://stackoverflow.com/questions/49257247/how-to-activate-ppolicy-module…", then I have checked that the module is loaded and I did not have any problem: |$ sudo slapcat -n 0 | grep olcModuleLoad | grep ppolicy olcModuleLoad: {0}ppolicy | Then, I have extended the LDAP scheme to allow using of ppolicy attributes such as "pwdAccountLockedTime". I have set it to "00000101000000Z" in order to lock permanently an account (to check if it was working). But I still can connect (using LDAP Admin tools) with the account that was supposed to be locked. We also tried to modify the value dn: uid=... replace: pwdAccountLockedTime pwdAccountLockedTime: 20221021135537Z And even with dates in the future, but we are still able to connect. With whoami command, or from a SOGo webmail connected to the LDAP server. Any idea? Thank in advance for your help. Best Damien

3 2

Re: CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Thanks for confirming what we already suspected (and hoped as well) :-) On Tue, 11 Jul 2023 at 16:54, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Tuesday, July 11, 2023 2:26 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems > > to work perfectly now. With some (highly appreciated) help from this > list. > > > > > But actually: content *is* replicated instantly (within the same second) > > and the actual served contents between the four ldap (MultiMaster) > > servers matches. > > The RID changes, and is always one of the configured replication lines, > > and the date/time on the four involved hosts is in sync. > > > > > > > > Is this 'just an informational message', and 'normal', and should we > > ignore it? Or is it something to worry about and investigate further? > > Yes, it's informational. Think of it this way: > > Server A receives the modification. Servers B, C, D, replicate the change. > Server A sees that a change was made on Server B, then sees it's too old > and discards it. Same happens when Server A sees the change show up on > Servers C & D as well. And same thing happens for B with servers C & D, > and Server C with B & D, etc. The replication protocol can be very chatty > with MMR because it's constantly noting it is skipping changes it already > received. > > --Quanah > > > >

1 0

CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi, We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems to work perfectly now. With some (highly appreciated) help from this list. However, there is one observation we don't understand, that we would appreciate feedback on. On directory edits, such as a password change, using the rootDN: ldappasswd -H ldaps://ldap01.company.com -D "cn=admin,o=company,c=com" -W -S "uid=username,ou=Users,o=company,c=com" New password: <new_userpw> Re-enter new password: <new_userpw> Enter LDAP Password: <very_secret_root_pw> we always receive several (mostly three, sometimes four) of these messages instantly: do_syncrep2: rid=212 CSN too old, ignoring 20230710140929.887114Z#000000#0de#000000 (uid=username,ou=Users,o=company,c=com)" But actually: content *is* replicated instantly (within the same second) and the actual served contents between the four ldap (MultiMaster) servers matches. The RID changes, and is always one of the configured replication lines, and the date/time on the four involved hosts is in sync. Is this 'just an informational message', and 'normal', and should we ignore it? Or is it something to worry about and investigate further? In the latter case, of course I will share our configs, which are taken from https://www.openldap.org/doc/admin25/replication.html#N-Way%20Multi-Master As otherwise everything seems to be working correctly, I don't expect major issues there. (but again: of course willing to share!)

2 1

Re: trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi Quanah, Thanks again for your answer. From what you have written, we understand now that we should not aim for four identical timestamps in contextCSN attributes on each node. As contextCSN is updated (as you said) only when a server receives a direct write. (and NOT for writes received through replication) So, as long as the contextCSN output across all four MM-ldap nodes is identical, replication is doing it's thing. Specifically, from my original post: > contextCSN: 20230622151102.137085Z#000000#001#000000 > contextCSN: 20230622151105.174343Z#000000#002#000000 > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > contextCSN: 20230627112536.529512Z#000000#0de#000000 The first two servers (001/002) are just as up-to-date as the last two, only: more recent writes have come into the cluster through the 0de/0dd servers. I have written a script to compare actual ldap served content, and that confirms that they all serve the same data. If any of the above is wrong, I'd appreciate to be corrected :-) On Wed, 5 Jul 2023 at 17:09, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > serverID 222 ldaps://ldapm01.company.com > > serverID 221 ldaps://ldapm02.company.com > > serverID 212 ldaps://ldapm03.company.com > > serverID 211 ldaps://ldapm04.company.com > > > > And when I (quick and dirty) check contextCSN using slapcat (I know that > > ldapsearch is the better way) I get: > > > > [root@ldapm04 ~]# slapcat | grep contextcsn -i > > contextCSN: 20180917142109.765066Z#000000#000#000000 > > contextCSN: 20230622151102.137085Z#000000#001#000000 > > contextCSN: 20230622151105.174343Z#000000#002#000000 > > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > > contextCSN: 20230627112536.529512Z#000000#0de#000000 > > > > The first 2018 contextCSN is irrelevant (it has alwas been there, and I > > should probably try to get rid of it) but the last four seem to be the > > "actual" configured replication 'lines' on each node to the other three, > > like this: > > > > > > Yet: all info I can find tells me that the third field of contextCSN is > > "the SID". > > > > > > Can anyone explain? Are they perhaps HEX? If why the large gap between to > > consequtive pairs..? > > > Hi! > > So #000# is as you noted an old SID from when the system used single > provider. > > The SID values are indeed in hex. Your current non-zero SIDS indicate: > > You have servers with SID values 001, 002 that last received a direct > write > operation on 2023/06/22, about 3 seconds apart. > > You have servers with SID values 221 (0dd) and 222 (0de) that last > received > a direct write operation on 2023/06/27, during the same second. > > Any server that has a different SID value that has never received a direct > write operation will not appear in the list. > > Regards, > Quanah > >

3 6

OpenLDAP 2.5 + GSSAPI + Kerberos
by dbarstis＠nd.edu 06 Jul '23

06 Jul '23

Total newbie here so please be gentle. I'm trying to set up a simple ldap server that uses SASL and Kerberos for authentication. I built OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service principal and testsaslauthd works. I used slapadd to build the initial config (from slapd.ldif) and ldapadd to define a rootdn and basedn (basically ou=people and ou=groups). Added a user (me) and a group. I have a slapd.conf file at /usr/lib/sasl2 that defines keytab: krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd, saslauthd_path: /run/saslauthd/mux. Running pluginviewer, I see GSSAPI. Running ldapsearch ... supportedSASLMechanisms, it returns nothing. I've found websites that talk about adding sasl-realm <Kerberos-Realm> sasl-host <ldap-host> sasl-secprops none to slapd.conf. But this isn't the same slapd.conf I mentioned above correct? And since I used slapd.ldif to do the inital load, I don't have another slapd.conf. How to I define these variables? Also, it looks like I need a direct mapping i.e. authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=com Where and how does that get defined? Any and all help would be greatly appreciated!

3 5

-Y external and SUSE
by Stefan Kania 06 Jul '23

06 Jul '23

Hi to all, I just installed openSUSE 15.5 and the actual symas packages. After installing OpenLDAP I could start slapd but "ldapsearch -Y external -H ldapi:///" is giving me a "can't connect to ldapserver" I found out that the ldap-socket on SUSE is (the same a on Debian systems) in /var/symas/run/ldapi and I can see: ss -lp | grep slapd u_str LISTEN 0 2048 /var/symas/run/ldapi 15214 * 0 users:(("slapd",pid=1431,fd=9)) but doing a ldapsearch: provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5 ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 3 ldap_connect_to_path: Trying /run/slapd/ldapi ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_close_socket: 3 ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) You can see, that ldapsearch is looking in /run/slapd/ for the socket. How can I change this? I tested with setting a link: ln -s /var/symas/run/ldapi /run/slapd/ and ldapseach wit "external" is working. But this was only a test. After rebooting the system the link is gone. So how can I either change the behavior of the ldap-commands or changing the path where the socket will be stored? Thank's for any help

5 5

trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 05 Jul '23

05 Jul '23

Hi! Trying to better understand the contextCSN attribute. ContextCSN is formatted like: TIMESTAMP#COUNT#SID#MOD My question is on the SID part: ServerID. I have the following serverID configuration in our 4-server Multi-Master PoC setup: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230622151102.137085Z#000000#001#000000 contextCSN: 20230622151105.174343Z#000000#002#000000 contextCSN: 20230627112536.529432Z#000000#0dd#000000 contextCSN: 20230627112536.529512Z#000000#0de#000000 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand Now the actual question: contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above. Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Curious :-) Thanks!

2 1

RE: [EXT] Re: What drives CPU usage spikes?
by Quanah Gibson-Mount 03 Jul '23

03 Jul '23

--On Monday, July 3, 2023 2:25 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I'm wondering: Did you examine whether some indices might help? Those don't help with the issue being addressed in regards to accesslog databases. --Quanah

1 0

Re: [EXT] Re: Proposal to strengthen slapd EXTERNAL authentication
by Jordan Brown 30 Jun '23

30 Jun '23

On 6/29/2023 11:29 PM, Windl, Ulrich wrote: > I think there's something missing: When *creating* the certificate "It proves that the bearer owns the DN" (done by RA/CA), but when *using* the certificate (by a client) the server should still check whether the certificate matches the client. Otherwise any stolen certificate could be used to gain access from everywhere. MHO. When you say "matches the client", what do you mean? That the client's IP address maps to a name on the certificate? Remember that in DNS the mapping from IP address to name is under the control of the person who owns the IP address, not the person who owns the name. Remember also that the client may be behind a NAT that hides their IP address. Finally, remember that the client may legitimately change its IP address and DNS name (if any) from time to time as it is moved from one location to another (think phone, or laptop, or desktop moving from one office to another) or networks are reconfigured around it. This is asymmetric from the more common server authentication. For server authentication, the server has a stable name, and that name was supplied by the human and so can be trusted (more or less) and checked against the certificate. In fact, that human-supplied name serves exactly the same purpose as an "authorized DN" list: it says which certificates are acceptable. Net... you're absolutely right, if somebody steals your certificate - more precisely, your private key - they can use it to gain access. It is exactly as for a password: a username and password authenticates the user, but if somebody steals your password, they can masquerade as you. Depending on your particular scenario, it might be appropriate to have *additional* checks - acceptable networks, et cetera - or require multiple factors (e.g. certificate plus password). Those additional checks are not part of the certificate-based authentication process. Somebody stealing your private key may well be Game Over. Don't let people steal it. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

1 0

Re: What drives CPU usage spikes?
by David Hawes 30 Jun '23

30 Jun '23

On Fri, 23 Jun 2023 at 12:04, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > In our 2.6.4 deployment, we had a significant spike in CPU usage one day > last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC). > During this time, some clients started timing out when talking to the LDAP > service, and search response times spiked as well, up to 9.5 seconds on > searches that normally take < 3 seconds (they do have large result sets). > This happened on all 6 of the read nodes that we have in our load balance > pool, so whatever the issue was hit all of them at the same time. It did > not happen to 2 specialized read nodes that only serve one specific > service, so it was something about the traffic going to those 6 nodes. The > number of ops/second during that time frame was actually lower than usual > across the cluster, with a peak of 200 ops/second. We often have higher > peaks than that without this type of CPU usage spiking. I've noticed similar behavior on large accesslog purges. High CPU, poor response times, sometimes slapd even becomes unresponsive. Do these systems have an accesslog that gets purged?

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical