Re: Strange slapadd behavior
by Ezsra McDonald
We were hoping to carry over all the operational attributes associated with
objects in the LDAP. If I remember correctly, ldapadd will not apply
operational attributes.
On Mon, Apr 15, 2019 at 11:31 AM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> --On Monday, April 15, 2019 9:17 AM -0500 Ezsra McDonald
> <ezsra.mcdonald(a)gmail.com> wrote:
>
> > I am in the process of migrating my OpenLdap 2.3 system to a new OpenLdap
> > 2.4 system but something is not working right for the import(slapadd) to
> > the new system. There are 35,895 objects defined in the LDIF generated by
> > slapcat.
>
> I would suggest you start with ldapadd to import, rather than slapadd, as
> you likely need the additional validation steps initially when doing the
> migration from 2.3 to 2.4.
>
> I'd also avoid using RH's native packages and use a current release. The
> LTB project and Symas both provide free alternatives to RH's builds.
>
> <https://ltb-project.org/download#openldap>
> <https://repo.symas.com/sofl/rhel7/>
>
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 5 months
Strange slapadd behavior
by Ezsra McDonald
I am in the process of migrating my OpenLdap 2.3 system to a new OpenLdap
2.4 system but something is not working right for the import(slapadd) to
the new system. There are 35,895 objects defined in the LDIF generated by
slapcat.
RPM: openldap-servers-2.4.44-21.el7_6.x86_64
Example:
Importing the following object by slapadd:
dn: cn=demokag,ou=Groups,dc=somewhere,dc=org
*cn*: demokag
*description*: KAG Demo
*owner*: cn=manager,dc=somewhere,dc=org
objectClass: top
objectClass: groupOfUniqueNames
*uniqueMember*: uid=sombody,ou=People,dc=somewhere,dc=org
*uniqueMember*: uid=somebodyelse,ou=People,dc=somewhere,dc=org
structuralObjectClass: groupOfUniqueNames
entryUUID: 78450864-a24e-1030-9086-8baf95aed3fc
creatorsName: cn=Manager,dc=somewhere,dc=org
createTimestamp: 20111113142106Z
entryCSN: 20121116140519Z#000000#00#000000
modifiersName: cn=Manager,dc=somewhere,dc=org
modifyTimestamp: 20121116140519Z
Produces this object:
dn: cn=demokag,ou=groups,dc=somewhere,dc=org
*givenName*: demokag
*owner*: KAG Demo
*uniqueMember*: cn=manager,dc=somewhere,dc=org
objectClass: top
objectClass: groupOfUniqueNames
*gidNumber*: uid=somebody,ou=People,dc=somewhere,dc=org
*gidNumber*: uid=somebodyelse,ou=People,dc=somewhere,dc=org
structuralObjectClass: groupOfUniqueNames
entryUUID: 78450864-a24e-1030-9086-8baf95aed3fc
creatorsName: cn=Manager,dc=somewhere,dc=org
createTimestamp: 20111113142106Z
entryCSN: 20121116140519Z#000000#00#000000
modifiersName: cn=Manager,dc=somewhere,dc=org
modifyTimestamp: 20121116140519Z
1. I bolded the impacted attributes.
2. I am unable to do ldapsearch for this object. I believe this is
because the cn is being replaced with givenName.
3. Spot checking it appears this is happening to all of the objects
under the groups OU. Maybe other object types are bad too. I do not know
yet.
I have been beating my head on this for several days.Any help would be
appreciated.
4 years, 5 months
Help
by A. Yuesuen
hello,
i'm trying to implement Ssha512 on my openldap server. i found out that the
Building concepts on the www are old. there are nor slapd.conf file. So
there is written i have to work with the cn=config file cause. Can someone
help me please?
I'm using ubuntu 18.10 and the openldap version slapd.
Thank you
best wishes
Ajdar yüsün
4 years, 5 months
Quick question about OpenLDAP Server CA certificate handling
by Mark Cairney
Hi,
Having just updated our SSL certificates on our OpenLDAP server led us
to review the contents of our "bundle" file referenced in
"olcTLSCACertificateFile".
According to the documentation at:
https://www.openldap.org/doc/admin24/tls.html it states "This directive
specifies the PEM-format file containing certificates for the CA's that
slapd will trust. The certificate for the CA that signed the server
certificate must be included among these certificates. If the signing CA
was not a top-level (root) CA, certificates for the entire sequence of
CA's from the signing CA to the top-level CA should be present. Multiple
certificates are simply appended to the file; the order is not significant."
However based on our understanding of how SSL works we should only
actually need the intermediate(s) in there as the client should have the
root and then compare the intermediate provided by the server and only
trust it if it can use this in conjunction with it's copy of the root
certificate to complete the chain of trust.
Based on this we configure our web servers to only have the
intermediate(s) in their chain (and in fact SSL Labs marks you down if
you have the root in there too).
Of course we do realise LDAP is not HTTP!
We're running OpenLDAP 2.4.47 linked against OpenSSL on Scientific Linux
7.5.
Kind regards,
Mark
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
PGP: 0x435A9621
*******************************/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
4 years, 5 months
strange regexp behaviour
by Dieter Kluenter
Hi,
I face a strange behaviour of a authz regexp. This is part of my
slapd.conf
authz-regexp "gidNumber=(.*)\+uidNumber=(.*),cn=peercred,cn=external,cn= auth"
"ldap:///o=avci,c=de?dn?sub?(&(uidNumber=$2)(gidNumber=$1))"
The result of a ldapwhoami:
SASL/EXTERNAL authentication started
SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn:gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth
A result of search
ldapsearch -Y EXTERNAL -H ldapi:/// -b o=avci,c=de -s sub
"(&(gidNumber=100)(uidNumber=1000))" dn
dn: cn=Dieter Kluenter,ou=Partner,o=avci,c=de
result: 0 Success
This regexp has been working for ages, in fact it hasn't been changed
since Ando's first announcement.
Any idea what might have been changed?
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
4 years, 5 months
changes in libldap?
by Dieter Kluenter
Hi,
I face some more strange error reports from some updated tools. There is
for example ldapfuse, introduced in 2011, built with
ldd /usr/bin/ldapfuse
linux-vdso.so.1 (0x00007ffe8c92a000)
libHX.so.28 => /usr/lib64/libHX.so.28 (0x00007fdf144de000)
libfuse.so.2 => /lib64/libfuse.so.2 (0x00007fdf1449d000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fdf1448c000)
libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007fdf14436000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdf14415000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdf14250000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fdf14249000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdf14230000)
libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007fdf14211000)
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007fdf141a3000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fdf13f17000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdf1451f000)
libz.so.1 => /lib64/libz.so.1 (0x00007fdf13efb000)
§ ldapfuse ldap://localhost ~/adbook
Unhandled LDAP error code -1
LDAP Can't contact LDAP server
Even gcc doesn't produce more information :-)
What has been changed in libldap?
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
4 years, 5 months
Help
by A. Yuesuen
Hello,
When i try the Instruction on following page:
https://github.com/winlibs/openldap/tree/master/contrib/slapd-modules/pas...
i missed I'm not sure with point 1. and i can run the make function. Is
there a example with pictures? Or could you please explain me easier how i
can implement the sha2 / SSHA512 modul?
Hope you can help me. Thank you in advance.
best wishes
Ajdar Yüsün
4 years, 5 months
Re: Question about OID / feedback on schema
by Mikael Bak
Hi,
On 2019. 04. 06. 21:19, Harry Jede wrote:
> Am 05.04.19 um 16:36 schrieb Michael Ströder:
>> You need to register an IANA enterprise ID to obtain your own OID space.
>>
>> AFAIK there is no OID space reserved for private use.
>
> Both statements are true.
>
> But Mikael Bak says that he wont register his organization. OK, if
> someting goes wrong with the registered oid space, your company may get
> reputation problems. That is what people told often to me.
>
I actually said that I would like to avoid it, if possible. I forsee a
lot of paper work here to get this done properly.
> The solution is register an oid for a private person aka Mikael Bak. If
> all is Ok and everyone feels good transfer the registerd oid to your
> company or register a new oid and modify your schema to match the new oid.
>
Since there seems to be no concept of private OID space, then I will
start the procedure to register the Hungarian National Library with IANA
to obtain OID number.
Thank you all!
Mikael
4 years, 5 months
Replication delay
by Ángel L. Mateo
Hello,
I've been running a multi master configuration without any problem for
years. This running servers are running in 5 ubuntu 14.04 servers with
openldap 2.4.43.
The configuration is:
dn: olcDatabase={3}mdb,cn=config
...
olcSyncrepl: {0}rid=31 provider=ldap://canis31.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1
olcSyncrepl: {1}rid=32 provider=ldap://canis32.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1
olcSyncrepl: {2}rid=33 provider=ldap://canis33.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1
olcSyncrepl: {3}rid=34 provider=ldap://canis34.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="300 +" timeout=1
dn: olcOverlay={0}dynlist,olcDatabase={3}mdb,cn=config
objectClass: olcDynamicList
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {0}dynlist
olcDlAttrSet: {0}labeledURIObject labeledURI
dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config
objectClass: olcPPolicyConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {1}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=Telematica
dn: olcOverlay={2}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {2}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
where each server has 4 olcSyncrepl attributes pointing to the other
servers.
I had no problem with this configuration for years
Now I'm deploying an update of these servers in a new ubuntu 18.04
server with openldap 2.4.47. In order to synchronize entries between
them, I have linked this new server to one of the other (and this one to
the new one).
Configuration in the new one (named canis41) is:
dn: olcDatabase={3}mdb,cn=config
...
olcSyncrepl: {0}rid=39 provider=ldap://canis39.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="60 +" timeout=1
schemache
cking=off scope=sub
olcSyncrepl: {1}rid=42 provider=ldap://canis42.um.es binddn=<repl user
dn> bindmethod=simple credentials=XXXXXXXX searc
hbase=dc=Telematica type=refreshAndPersist retry="30 +" timeout=1
logbase="
cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemaCh
ecking=on syncdata=accesslog exattrs="pwdFailureTime"
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
dn: olcOverlay={1}ppolicy,olcDatabase={3}mdb,cn=config
objectClass: olcPPolicyConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {1}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=Telematica
dn: olcOverlay={2}dynlist,olcDatabase={3}mdb,cn=config
objectClass: olcDynamicList
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {2}dynlist
olcDlAttrSet: {0}labeledURIObject labeledURI
where canis39 is one the former servers and canis42 is a new server too
synchronizing just with canis41.
My problem is that synchronization is working, but sometimes
modifications done in the canis3x farm are delayed a lot of time until
they are replicated to the new one (sometimes in the order of 40-60
minutes).
I'm logging sync logs, but I haven't found much information about these
logs. Is there any way to debug it? How?
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 868888337
4 years, 5 months
