Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
Hi!
After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted:
slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
The next line logged was:
slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389)
(the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice)
The server is one of three MM servers that all have the same configuration and the same version.
The schema knows in olcAttributeTypes (olcSchemaConfig):
( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd?
Regards,
Ulrich
2 years, 8 months
Change OID of existing custom Attribute
by Tobias Hachmer
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 years, 5 months
N-Way Multimaster with syncrepl and delta-repl - LDAP Server not able to start after configuring
by Oliver Dörr
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
3 years, 6 months
How do I add the 'dialupAccess' attribute ....
by Paul Pathiakis
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
3 years, 6 months
MDB indices operations (MIT Kerberos with OpenLDAP backend)
by Дилян Палаузов
Hello,
https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sekti...
(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 years, 6 months
header tag value
by Gustavo Rios
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
3 years, 6 months
Consistency issue (probably with me)
by Paul Pathiakis
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
3 years, 6 months
Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount
--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>
3 years, 6 months
