openldap-technical

openldap-technical@openldap.org

9951 discussions

Change OID of existing custom Attribute
by Tobias Hachmer 30 Sep '19

30 Sep '19

Hello, running here OpenLDAP 2.4.42 on Ubuntu 16.04 with a hdb Database. Some old admin have added 2 custom attributes to the standard nis.schema, years ago. For this OIDs from nis schema has been chosen (1.3.6.1.1.1.1.2.x). I would like to fix that: Is it possible to move these custom Attributes to our custom Schema, while changing OIDs, also? Or do we have to clear the data DB, move the attrs and reimport a data backup? Thanks in advance, Tobias

3 9

N-Way Multimaster with syncrepl and delta-repl - LDAP Server not able to start after configuring
by Oliver Dörr 26 Sep '19

26 Sep '19

Hi, I already found two mail threads regarding my post but they do not help. I'm trying to setup a N-Way Multi-Master configuration following https://openldap.org/doc/admin24/replication.html section 18.3.3 with two masters.(su40v314 / su40v315) Using my process list I have started my server su40v314 with root 35523 1 0 Sep25 ? 00:00:02 /opt/symas/lib64/slapd -u root -g ldapadmi -h ldap://0.0.0.0:8653/ ldaps://0.0.0.0:8652/ -F /solshg/test2/etc So I believe that olcServerID should be olcServerID: 1 ldaps://su40v314:8652/ olcServerID: 2 ldaps://su40v315:8652/ but when I restart the server I get Sep 26 11:05:40 su40v314 slapd[129788]: read_config: no serverID / URL match found. Check slapd -h arguments. Same behaviour, if I change the HOST_LIST to "ldap://su40v314:8653/ ldaps://su40v314:8652/" Any ideas what I missed? Regards Oliver

2 1

How do I add the 'dialupAccess' attribute ....
by Paul Pathiakis 24 Sep '19

24 Sep '19

Quanah, Thank you for everything. It all works. :) (Something very strange had occurred with the 389 port being in a strange state that forced me to, finally, reboot as there was nothing running and even netstat, netcat and everything else said somethign was running but ps -elf said slapd wasn't there. *shrug*) My latest problem: I have the freeradius schema in my schemas. I verified this: ls -sal /etc/openldap/slapd.d/cn=config/cn=schema/cn={12}freeradius.ldif I also verified that the attribute that I want to access, dialupAccess is in there with a grep for it on that file. I'm trying to figure out how to make this attribute part of my user profiles so that I can check to see if this is set to 'yes' or 'no' for VPN access. dn: cn={12}freeradius objectClass: olcSchemaConfig cn: {12}freeradius...olcAttributeTypes: {56}( 1.3.6.1.4.1.11344.4.3.1.57 NAME 'dialupAccess' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) .. I can see this is an object class of olcSchemaConfig but how do I add that to my user profiles? THank you! Paul

2 2

MDB indices operations (MIT Kerberos with OpenLDAP backend)
by Дилян Палаузов 22 Sep '19

22 Sep '19

Hello, https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion… (man slapd-mdb) is not clear about indices. Is olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B,A" as equivalent, it does not, so a query has to be tuned to make use of existing indices. The particular use-case is the OpenLDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug output of OpenLDAP, when there is no objectClass eq index, but a krbPrincipal eq index, is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH base="cn=X.NET,cn=krbContainer" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <= mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=1117 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenerates the index, and when running slapindex is necessary. My reading of https://www.openldap.org/doc/admin24/tuning.html , Section 21.3.2. “What to watch out for”, is that the output “mdb_equality_candidates” means inefficient searches. But a different interpretation is possible: This equality_candidates may be targeted at the simple case, where the search filter is just one equality test, and where an index could significantly reduce the number of candidates to be loaded and checked. For a krb5 LDAP KDB get_principal operation, the filter expression is (&(|(objectclass=krbprincipalaux)(objectclass=krbprincipal))(krbprincipalname=...)), so the objectClass equality test is intersected with a krbPrincipalName equality test. If the Kerberos LDAP DB is large and isn't shared with a lot of other LDAP data, almost every object in the database will match one of the objectClass equality tests, but only one will match the krbPrincipalName test. In that scenario, an objectClass index is useless, as it doesn't reduce the number of candidates significantly, while the krbPrincipalName index is useful. In fact, it is possible for the objectClass index to slow down the search, relative to having only a krbPrincipalName index--slapd might have to read in a large list of krbprincipal objects, then intersect that with a one-element list of objects matching the krbPrincipalName. While that would be much faster than loading and checking every principal object, it would still be O(n) in space and time rather than O(1). Regards Дилян

3 3

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 19 Sep '19

19 Sep '19

--On Thursday, September 19, 2019 10:26 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, i mean what are the other benefits (like performance) of > using delta replication over full replication other than the ITS#8125 This is covered in the admin guide already: <https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20repl…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

header tag value
by Gustavo Rios 19 Sep '19

19 Sep '19

Hi folks. i am studying the ldap protocol and i have some doubts. I wonder what is the header tag value for the unbind request message. For the bind request the header value is 0x30. May someone here tell me the value for the unbind request tag header? Thanks in advance. -- Pag Bem Fácil Ltda www.pagbemfacil.com.br

1 0

Consistency issue (probably with me)
by Paul Pathiakis 18 Sep '19

18 Sep '19

Hi all, I just went through all of this previously. I documented everything. I don't believe (yeah... believe) I changed anything. I verified that my firewall rules are correct (although this is all local) I just shutdown slapd with: systemctl stop slapd I did: rm -rf /var/lib/ldap/* /etc/openldap/slapd.d/* Changed my password with slappasswd and put the new one in my slapd.conf . Re-initialized everything with: slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d Got that the configuration passed. Checked slapd.d and /var/lib/ldap. Both had expected values/files. Did: chown -R ldap:ldap /etc/openldap/slapd.d /var/lib/ldap systemctl start slapd Tried to add my memberof.ldif file with: ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://newldap.hq.example.com -W -c Got prompted for the password and got an "invalid credentials (49)" (I tried re-doing this multiple times with simple passwords....but same issue...) slapd -d -1 shows me: 5d8267a3 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 5d8267a3 backend_startup_one: starting "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: database "dc=hq,dc=example,dc=com": dbenv_open(/var/lib/ldap). 5d8267a3 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5d8267a3 slapd starting 5d8267a3 daemon: added 4r listener=(nil) 5d8267a3 daemon: added 7r listener=0x565118e8b500 5d8267a3 daemon: added 8r listener=0x565118e8b330 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267a3 daemon: activity on 1 descriptor 5d8267a3 daemon: activity on: 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 slap_listener_activate(7): 5d8267b8 daemon: epoll: listen=7 busy 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 >>> slap_listener(ldap:///) 5d8267b8 daemon: listen=7, new connection on 12 5d8267b8 daemon: added 12r (active) listener=(nil) 5d8267b8 conn=1000 fd=12 ACCEPT from IP=192.168.2.60:39984 (IP=0.0.0.0:389) 5d8267b8 daemon: activity on 2 descriptors 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 27 02 01 01 60 22 02 0'...`". ldap_read: want=33, got=33 0000: 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 80 12 62 ....cn=config..b 0010: 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 72 69 6e 0020: 67 g ber_get_next: tag 0x30 len 39 contents: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e00 end=0x7f21bc001e27 len=39 0000: 02 01 01 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e ...`".....cn=con 0010: 66 69 67 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 fig.. 0020: 6e 65 65 72 69 6e 67 neering 5d8267b8 op tag 0x60, time 1568827320 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 5d8267b8 conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e03 end=0x7f21bc001e27 len=36 0000: 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 `".....cn=config 0010: 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0020: 72 69 6e 67 ring ber_scanf fmt (m}) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e13 end=0x7f21bc001e27 len=20 0000: 00 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0010: 72 69 6e 67 ring 5d8267b8 >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5d8267b8 <<< dnPrettyNormal: <cn=config>, <cn=config> 5d8267b8 conn=1000 op=0 BIND dn="cn=config" method=128 5d8267b8 do_bind: version=3 dn="cn=config" method=128 5d8267b8 send_ldap_result: conn=1000 op=0 p=3 5d8267b8 send_ldap_result: err=49 matched="" text="" 5d8267b8 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... 5d8267b8 conn=1000 op=0 RESULT tag=97 err=49 text= 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x7f21bc000a80 ptr=0x7f21bc000a80 end=0x7f21bc000a85 len=5 0000: 02 01 02 42 00 ...B. 5d8267b8 op tag 0x42, time 1568827320 ber_get_next ldap_read: want=8, got=0 5d8267b8 ber_get_next on fd 12 failed errno=0 (Success) 5d8267b8 connection_read(12): input error=-2 id=1000, closing. 5d8267b8 connection_closing: readying conn=1000 sd=12 for close 5d8267b8 connection_close: deferring conn=1000 sd=12 5d8267b8 conn=1000 op=1 do_unbind 5d8267b8 conn=1000 op=1 UNBIND 5d8267b8 connection_resched: attempting closing conn=1000 sd=12 5d8267b8 connection_close: conn=1000 sd=12 5d8267b8 daemon: removing 12 5d8267b8 conn=1000 fd=12 closed 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero

2 1

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 16 Sep '19

16 Sep '19

--On Monday, September 16, 2019 9:34 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > Any reason you recommend delta replication? It's the only way to mitigate ITS#8125. Running standard syncrepl is just asking for data loss and endless problems. > can you share results of > delta replication over full replication? I'm not sure what you mean. I've been advising delta-syncrepl since OpenLDAP 2.3. > is there any guide/procedure > to change from full to delta replication with out downtime? If you're using cn=config, you can ldapmodify the configuration to enable delta-syncrepl. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

LDAPcon 2019 schedule
by Michael Ströder 16 Sep '19

16 Sep '19

HI! LDAPcon 2019 conference program is now publicly available: https://cfp.ldapcon.org/ldapcon2019/schedule/ Hope to see you all in Sofia in November: https://ldapcon.org/2019/ Ciao, Michael.

2 1

slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by Norman Gray 13 Sep '19

13 Sep '19

Greetings. I'm having difficulty creating a non-trivial olcUniqueURI spec. Can anyone advise me? The problems are: * A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. * The manpage doesn't make it terribly clear what I should expect from a plausible-looking spec. Details follow: I want to specify something like dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. If I do this, however, then slapadd spins its wheels: $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] (I'm taking it that there should be a space between those `URI[URI...]`) in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc * So that's clearly permitting multiple URIs -- perhaps the quotes are required (as the manpage hints). But if I try olcUniqueURI: "ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub" ...then I get 5d77d617 ==> unique_new_domain <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> 5d77d617 olcUniqueURI: value #0: <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> invalid ldap urilist from slapadd (so that's not the problem). But the example there does look VERY much like what I tried. So: * I'm pretty sure I shouldn't be able to make slapadd spin its wheels like that. * The manpage text might be a little too telegraphic. While I'm sure it's not _wrong_, it is quite hard to go from that text to a working spec with any confidence. Googling olcUniqueURI produces very little of use. Is this not the correct way to do this? This looks somewhat similar, in symptoms and module, to ITS#8162, but it does seem distinct. Thanks for any pointers. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical