Error when try modify olcTLS*
by Igor Sousa
Hi everyone,
I've tried a common proceeded: insert CA and server certificates on
cn=config. I've created CA and server certificate in PEM format and I've
signed server certificate with CA certificate. Then I've created a
5tls.ldif with following content:
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem
But server has returned following error when I've ran ldapmodify -Y
EXTERNAL -H ldapi:/// -f 5tls.ldif:
[root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
ldap.local.crt, ldap.local.key and ca.cert.pem are /etc/openldap/certs and
they own read permission to ldap group.
I don't understand this behavior and I have no idea what is wrong.
OBS: I've mounted environment on CentOS 7, added symas' repository and
install from yum.
Here some relevant info below.
OpenLDAP version - 2.4.47
[root@localhost ldifs]# slapd -V
@(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $
build@c7rpm
:/home/build/git/rheldap/RHEL7_x86_64/BUILD/symas-openldap-2.4.47/openldap-2.4.47/servers/slapd
STATUS after run ldapmodify
[root@localhost ldifs]# systemctl status slapd -l
● slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor
preset: disabled)
Active: active (running) since Fri 2019-06-28 01:51:50 -03; 1h 36min ago
Docs: man:slapd
man:slapd-config
man:slapd-hdb
man:slapd-mdb
file:///usr/share/doc/openldap-servers/guide.html
Process: 4654 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS}
$SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
Process: 4641 ExecStartPre=/usr/libexec/openldap/check-config.sh
(code=exited, status=0/SUCCESS)
Main PID: 4656 (slapd)
CGroup: /system.slice/slapd.service
└─4656 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:///
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 ACCEPT
from PATH=/var/run/ldapi (PATH=/var/run/ldapi)
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND
dn="" method=163
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND
authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND
dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL
sasl_ssf=0 ssf=71
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 RESULT
tag=97 err=0 text=
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD
dn="cn=config"
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD
attr=olcTLSCACertificateFile
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 RESULT
tag=103 err=80 text=
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=2 UNBIND
Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 closed
Best regards,
--
Igor Sousa
3 years, 11 months
Cluster takes around 48 hours to synchronize after deletion
by x0101
Dear all,
We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7.
We noticed that deletion of an entry (done from a Windows machine onto the first node via Oracle's tool ldapmodify.exe) takes a long time (about 48 hours) to be replicated in the cluster.
Here's the relevant extract of cn=config for the first node:
olcSyncrepl: {0}rid=001 provider=ldap://mynode2:389/ bindmethod=simple
binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist
retry="30 5 300 +" keepalive="60:5:10"
olcSyncrepl: {1}rid=002 provider=ldap://mynode3:389/ bindmethod=simple
binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist
retry="30 5 300 +" keepalive="60:5:10"
olcMirrorMode: TRUE
We looked up for the offending entry (thisentry) in all nodes' logs and we found this line on mynode3:
Jun 18 14:18:20 mynode3 slapd[8871]: conn=1987936 op=14 DEL dn="dc=thisentry,ou=myou,ou=foobars,dc=mydomain,dc=org"
There are no other references to thisentry (apart from SRCH operations) on node1 and node2, even if the entry was originally deleted from node1, as said above.
What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.
3 years, 11 months
debug incoming modify operations
by Mark Coetser
Hi
changing my loglevel to trace or stats, shows me search queries but I
need a way to debug a remote client doing a php ldap modify that is failing?
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
3 years, 11 months
Invalid DN reported during authentication
by Chris K
Hello experts,
I setup an openLDAP server some time ago and am to create a newer server
for TLS 1.3 support.
I am using a fully patched CentOS 7 server with OpenLDAP 2.4.44 and am
seeing 'invalid DN' when authenticating to the server from my Linux client.
I will attempt to supply all the config and tests I have done thus far:
########################################
ldap.conf:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net
URI ldap://openldapsec.brm.acslab.wokyourdog.net
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3
TLS_CACERTDIR /etc/openldap/certs
TLS_CACERT /etc/openldap/certs/RootCA.pem
TLSCACertificateFile /etc/openldap/certs/RootCA.pem
TLSCertificateFile /etc/openldap/certs/Identity.pem
TLSCertificateKeyFile /etc/openldap/certs/Identity.key
TLSVerifyClient never
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON on
########################################
slapd.conf
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Added for policy
include /etc/openldap/schema/ppolicy.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
moduleload ppolicy.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
TLSCACertificateFile /etc/openldap/certs/RootCA.pem
TLSCertificateFile /etc/openldap/certs/Identity.pem
TLSCertificateKeyFile /etc/openldap/certs/Identity.key
database bdb
suffix "dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net"
rootdn "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net"
rootpw {SSHA}C6RcppHr0rweEVCQW6pio6tnPCIHCGnt
# PPolicy Configuration
overlay ppolicy
ppolicy_default
"cn=default,ou=policies,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net"
ppolicy_use_lockout
ppolicy_hash_cleartext
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
########################################
ldapsearch output:
[root@OpenLDAP_Server openldap]# ldapsearch -H ldap://
openldapsec.brm.acslab.wokyourdog.net -D
"cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -w
Siladmin123 -ZZ
# extended LDIF
#
# LDAPv3
# base <dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net> (default)
with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# openldapsec.brm.acslab.wokyourdog.net
dn: dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net
dc: openldapsec
objectClass: top
objectClass: domain
# people, openldapsec.brm.acslab.wokyourdog.net
dn: ou=people,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net
objectClass: top
objectClass: organizationalUnit
ou: people
# swadmin3, openldapsec.brm.acslab.wokyourdog.net
dn: cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net
objectClass: person
objectClass: uidObject
cn: swadmin3
sn: admin user
uid: swadmin3
userPassword:: e1NTSEF9WDdRQ2xzallYUDUvWU9sZnJyc3ZWVXhnS0xkbXB2U1o=
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
########################################
ldapwhoami
[root@OpenLDAP_Server openldap]# ldapwhoami -vvv -h
openldapsec.brm.acslab.wokyourdog.net -p 389 -D
"cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -x -w
Siladmin123
ldap_initialize( ldap://openldapsec.brm.acslab.wokyourdog.net:389 )
dn:cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net
Result: Success (0)
########################################
client authentication failure logs
ber_dump: buf=0x7fe684117870 ptr=0x7fe684117870 end=0x7fe68411788d len=29
0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34
...w...1.3.6.1.4
0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037
ber_dump: buf=0x7fe684117870 ptr=0x7fe684117873 end=0x7fe68411788d len=26
0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
w...1.3.6.1.4.1.
0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be0 end=0x7fe684115c23 len=67
0000: 02 01 02 60 3e 02 01 03 04 2c 73 77 61 64 6d 69
...`>....,swadmi
0010: 6e 33 40 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 n3(a)openldapsec.b
0020: 72 6d 2e 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63
rm.acslab.wokyou
0030: 6f 6d 2e 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e
rdog.net..Siladmin
0040: 31 32 33 123
ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be3 end=0x7fe684115c23 len=64
0000: 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 6e 33 40 `>....,swadmin3@
0010: 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 72 6d 2e
openldapsec.brm.
0020: 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 6f 6d 2e
acslab.wokyourdog.
0030: 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33
net..Siladmin123
ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115c16 end=0x7fe684115c23 len=13
0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123
5d10d347 conn=1048 op=1 do_bind: invalid dn (
swadmin3(a)openldapsec.brm.acslab.wokyourdog.net)
0000: 30 16 02 01 02 61 11 0a 01 22 04 00 04 0a 69 6e
0....a..."....in
0010: 76 61 6c 69 64 20 44 4e valid DN
ber_dump: buf=0x7fe6841171a0 ptr=0x7fe6841171a0 end=0x7fe6841171a5 len=5
0000: 02 01 03 42 00 ...B.
ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb0 end=0x7fe684107ecd len=29
0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34
...w...1.3.6.1.4
0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037
ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb3 end=0x7fe684107ecd len=26
0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
w...1.3.6.1.4.1.
0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
ber_dump: buf=0x7fe684002250 ptr=0x7fe684002250 end=0x7fe6840022ae len=94
0000: 02 01 02 60 59 02 01 03 04 47 63 6e 3d 73 77 61
...`Y....Gcn=swa
0010: 64 6d 69 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64
dmin3,cn=users,d
0020: 63 3d 6f 70 65 6e 6c 64 61 70 73 65 63 2c 64 63
c=openldapsec,dc
0030: 3d 62 72 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64
=brm,dc=acslab,d
0040: 63 3d 62 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65
c=wokyourdog,dc=ne
0050: 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 t..Siladmin123
ber_dump: buf=0x7fe684002250 ptr=0x7fe684002253 end=0x7fe6840022ae len=91
0000: 60 59 02 01 03 04 47 63 6e 3d 73 77 61 64 6d 69
`Y....Gcn=swadmi
0010: 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 63 3d 6f
n3,cn=users,dc=o
0020: 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 3d 62 72
penldapsec,dc=br
0030: 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 63 3d 62
m,dc=acslab,dc=w
0040: 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 74 80 0b
kyourdog,dc=net..
0050: 53 69 6c 61 64 6d 69 6e 31 32 33 Siladmin123
ber_dump: buf=0x7fe684002250 ptr=0x7fe6840022a1 end=0x7fe6840022ae len=13
0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123
0000: 30 0c 02 01 02 61 07 0a 01 31 04 00 04 00 0....a...1....
ber_dump: buf=0x7fe684118dd0 ptr=0x7fe684118dd0 end=0x7fe684118dd5 len=5
0000: 02 01 03 42 00 ...B.
Please let me know if you can see my mis-configuration or if you have any
questions about my setup.
Thanks,
Chris
3 years, 11 months
Hide pwdHistory field from anonymous
by Kyle Sloan
I am able to hide the userPassword and any other single/unique fields on a query, but I cannot figure out the pwdHistory and how to disable it from anonymous queries. I keep getting syntax errors and am unsure what the syntax is.
This works for userPassword, but fails when I replace or add pwdHistory
access to attrs=userPassword
by self write
by anonymous auth
by * none
Here is what my my query looks like
/usr/bin/ldapsearch -h 1.2.3.4 -x -b 'ou=People,dc=company,dc=com' '(uid=myuser)' '*' '+'
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=copmany,dc=com> with scope subtree
# filter: (uid=myuser)
# requesting: * +
#
# myuser, People, company
dn: uid=myuser,ou=People,dc=company,dc=com
uidNumber: 31518
gidNumber: 100
shadowExpire: 99999
shadowMax: 90
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
uid: myuser
pwdHistory: 20180718212202Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}bTWu9btdOzp
pwdHistory: 20181015214815Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Ys8LvXcdnsr
pwdHistory: 20181016164512Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}nQLIieWGwt7
pwdHistory: 20190114155333Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}j3d+hxGalnC
pwdHistory: 20190412183313Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}7r2E2DdryKa
pwdHistory: 20190412185409Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}ZbqMWB0x4v+
3 years, 11 months
How to filter all entries by multi-value attributes?
by Tankman 六四
Hi everyone
Is there a way to find all people whose telephoneNumber is
multi-valued through the use of LDAP filter?
Searched around there are only ways to search into multiple values but
not based on the number of values.
Thanks:)
Regards
3 years, 11 months
LDAP with TLS Enable/Disable not working
by Sunkad, Abhilash
Hi All,
I am facing a strange problem. I am using FreeRadius 3.16 version for my Proxy authentication.
I have an AD server and I make an authentication request enabling TLS. So the TLS connection passes and authentication is successful.
Now I have one more LDAP server where its non TLS. Now if I make a call, even though TLS is disabled on this server, Client tries to make a TLS connection and fails. I have tried freeing connections but with no luck. Please help.
Thanks
Abhilash
3 years, 11 months
Re: Extensible filters and ordering searches: filtering shadowExpire by range?
by Côme Chilliet
Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit :
> > So, there is no way to filter on shadowExpire values which are less than
> > today's timestamp?
>
> shadowExpire is defined as an integer type, not as a timestamp, so no.
>
> > It sounds crazy that such basic needs are not covered by LDAP protocol,
> > have I missed something?
>
> It's not clear to me what this has to do with the LDAP protocol. The
> definition of the "expire" field from /etc/shadow is:
>
> Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute
> date specifying when the login may no longer be used.
>
> So it's an integer (just as the RFC defines it). I would imagine you could
> write something that converts a current timestamp into the number of days,
> etc, and then perform a search.
Yeah this is what I was calling timestamp sorry, getting the integer for today is easy, but it seems there is no way for writing a search filter with greater-than or lesser-than for this attribute.
It has to do with the LDAP protocol that LDAP lets schema define attributes in ways that forbid substring and range filters. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used.
And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane.
Côme
3 years, 11 months
Extensible filters and substring searches
by Côme Chilliet
Hello,
I’m trying to understand if it is possible or not to do a substring search on an attribute which does not specify a substring matching rule.
I was expecting to be able to use an extensible filter and specify the sub matching rule to use, but it does not seem to work ldapsearch says "ldap_search_ext: Bad search filter (-7)" as soon as the filter contains an asterisk.
And indeed reading https://tools.ietf.org/html/rfc4515 it does look like extensible filter does not allow asterisk, but it is surprising to me.
Is there really no way to do an extensible search on a substring?
I found some examples on the web of such filters, like here: http://www.zytrax.com/books/ldap/apa/search.html
They give these examples:
> # override SUBSTR match with case sensitive match
> sn:caseExactSubstringMatch:=*S* # only finds Smith
> # functionally same as above using OID
> sn:2.5.13.7:=*S*
But these do not work if I try them in ldapsearch I get bad search filter.
Côme
3 years, 11 months
Uniqueness across multiple attributes
by Stefan Schmidt
Hello,
is it possible define a unique constraint across attributes? We have a mail
field and a mailAlias field and would like to assure that if a mail address
exists either in mail or mailAlias it cannot be added again to either
field, meaning mail addresses are unique in the complete tree.
We are using OpenLDAP 2.4 and currently we use the following LDIF to load
the unique module and assure that the mail attribute is unique:
dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcmoduleload: unique
olcmodulepath: /usr/lib/ldap
dn: olcOverlay=unique,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: {0}unique
olcUniqueAttribute: mail
Which LDIF would I use to assure uniqueness across mail and mailAlias?
Cheers,
Stefan Schmidt
3 years, 11 months
