iNetOrgPerson doesn't exist?
by Luca Stancapiano
Hi all, I'm triing to create a user with openldap 2.4
dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com
objectClass: iNetOrgPerson
uid: iiiiii
but it doesn't seem recognize the objectClass producing this error:
adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
Using other object classes is ok. What's the problem?
2 weeks, 6 days
[About lmdb's write performance] mdb_txn_commit blocking for a long time
by Wang Zhiyong
Hello all.
We are using lmdb in our own storage service and recently found a write performance issue.
The phenomenon is that lmdb batch write is very slow, and a write transaction operation takes several minutes.
For example, if a transaction writes 100,000 kv, the average value size is 100 bytes, and it takes 5 minutes.
The size of lmdb data file is 460G.
The analysis using perf is as follows:
53.14% liblgraph.so [.] mdb_page_alloc.isra.21
46.81% liblgraph.so [.] mdb_midl_xmerge
0.01% [kernel] [k] __check_object_size
0.01% [kernel] [k] __do_page_fault
0.01% [kernel] [k] __fput
0.01% [kernel] [k] get_futex_value_locked
0.01% [kernel] [k] radix_tree_descend
0.01% libpthread-2.17.so [.] __errno_location
The cpu are consumed on the two functions mdb_page_alloc and mdb_midl_xmerge.
By adding time statistics, I found that the blocking is in the mdb_freelist_save function in mdb_txn_commit.
I'm not familiar with lmdb source code, can anyone explain why mdb_freelist_save consumes so much time?
is this the expected result when lmdb data gets bigger?
Is there any way to restore the write performance after the write becomes worse?
What is the suggestion to improve the write performance of lmdb?
1 month
Unable to filter only group name
by BANDANI MAHARANA
Hi team,
I am facing problem with filtering the group names in Ad server using
openldap libraries.
I am using ldap search api to get the list of group.
My requirement is, with the provided input, i need to display all the
available group similar to the entered group name.
For example, if user types dev, it should display all the group names
starting with dev. Like develop, development
Kindly suggest how to achieve this.
Thank you
Bandani
1 month
olcPPolicyForwardUpdates not working
by Benjamin Renard
Hello,
I have problem with the olcPPolicyForwardUpdates option that seem not
working : On master and slave, I configured Ppolicy with pwdLockout.
When I try to connect on master with a bad password, the pwdFailureTime
attribute of the entry is successfully updated, but not if I do the same
on the slave. On slave, my ppolicy configuration is exactly the same as
on master but I add olcPPolicyForwardUpdates=TRUE. I also configured the
chain overlay and the updateref parameter on the database.
Extract of my slave configuration :
olcDatabase={1}mdb,cn=config
[...]
olcSyncrepl: [...]
olcUpdateRef: ldaps://ldap-master
olcOverlay={0}chain,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
objectClass: top
olcOverlay: {0}chain
olcChainReturnError: TRUE
olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}mdb,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
objectClass: top
olcDatabase: {0}ldap
olcDbURI: ldaps://ldap-master
olcDbIDAssertBind: bindmethod=simple binddn="[same user used in
olcSyncrepl of the database]" credentials="secret" mode=self
olcDbRebindAsUser: TRUE
olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
objectClass: top
olcOverlay: {1}ppolicy
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE
olcPPolicyForwardUpdates: TRUE
Do you have any idea of what I doing wrong ?
Thanks,
--
Benjamin Renard - Easter-eggs
44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com
1 month
idea for possible RFE: universally unique connection IDs
by Christopher Paul
Hello OpenLDAP-Technical,
I would like to seek comments on an idea I have had for a while. Does anyone agree with me that it would be nice if connection IDs were uuids? Because when your slapd restarts, your monitoring system has no good way to track one "conn=1000" from another one (or from one server to another), and so forth. Would there be any downsides to this?
Are there any upsides to re-using integers starting at 1000? I can think of one: with incrementing integers, you can tell the order of the connections with them.
Thanks,
Chris Paul | Rex Consulting | https://www.rexconsulting.net
1 month, 1 week
Constructed attributes?!
by Marco Gaiarin
There's some way, in OpenLDAP, to have attributed 'calculated on the fly'
like the AD 'Constructed Attributes'?
For a sake of an example, an attribute 'userStatus: disabled' if
userPassword start with an '!'?
Thanks.
--
Di questa cavolo di pianura, di questa gente senza misura, che gia`
confonde la notte e il giorno, e la partenza con il ritorno, e la
richezza con i rumore, ed il diritto con il favore (F. De Gregori)
1 month, 1 week
Write bottlenecks
by Sam Dave
Hi,
My write pipelines have a bottleneck at the bottom (LMDB writing). Work piles on top up-front, waiting for LMDB writes to complete.
Therefore the earlier work cannot really parallelize as much as it could if I could somehow make the writes go faster.
Are there any tips/tricks around this? I wonder if it could pay off to parallelize the writes into a few LMDB environments - and merge them in the end. This could have the advantage of more parallelization on the up-front work, but disadvantage of the final merging work.
Regards,
Sam
1 month, 1 week
leave
by Alceu Rodrigues de Freitas Junior
leave
1 month, 2 weeks
openldap 2.3 and user passwords
by aurfalien
Hello list and Happy Friday.
First and foremost I am not an OpenLDAP admin, well I guess that I am now for the purposes of this email.
I’ve been thrust into an environment running an older version of openldap on CentoOS 5 and have been tasked to simply allow users in changing their passwords via passwd.
Once a user has logged in on their respective workstation and types passwd we get this;
Changing password for user johndoe.
Current Password:
New password:
Retype new password:
passwd: Authentication token manipulation error
This tells me that I need to allow them self write access to userPassword Attribute of the LDAP database?
However after reading a decent amount of literature, it's suggesting to use olcAccess but as far as I can tell this does not apply to my specific environment. All of the openldap data looks to be in /var/lib/ldap versus what I’ve been reading of /etc/openldap/slapd.d.
The /etc/openldap/slapd.conf has this section which looks like what I should focus on;
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
It sounds like I should start here and see if this solves the issue.
However where and how do I modify the default access control policy for this environment in allowing users to modify there userPassword attribute?
Like I had mentioned, all of the reading thus far suggests olcAccess however my database is not in that format?
Again very very new here and am forced to work with openldap 2.3 on a Centos 5 server for now. This is not to say that I would fair any better in a newer environment due to my lack of any real knowledge in this subject matter.
At any rate thank you in advance.
Humbly yours,
- aurf
1 month, 2 weeks
Use of olcTLSECName directive returns ‘wrong attibuteType’ error
by Lemons, Terry
Hi
I’m attempting to modify the TLS ciphers that are used in an openldap2-2.4.41-22.16.1.x86_64 environment in our lab, running on SLES 12 SP5. I’ve used the following command to set the cipher list value to the returned value of ‘openssl ciphers HIGH’:
ldpdd041:/tmp # cat set-ciphersuite.ldif
dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: HIGH
ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ciphersuite.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldpdd041:/tmp # openssl ciphers HIGH
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA
ldpdd041:/tmp #
So I had expected to see that all of these ciphers were being offered for use by the OpenLDAP server; instead, I see that only a subset of the list is offered:
sslyze ldpdd041.hop.lab.emc.com:636
.
.
.
* TLS 1.0 Cipher Suites:
Attempted to connect using 80 cipher suites.
The server accepted the following 4 cipher suites:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_CBC_SHA 128
The group of cipher suites supported by the server has the following properties:
Forward Secrecy INSECURE - Not Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.1 Cipher Suites:
Attempted to connect using 80 cipher suites.
The server accepted the following 4 cipher suites:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_CBC_SHA 128
The group of cipher suites supported by the server has the following properties:
Forward Secrecy INSECURE - Not Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.2 Cipher Suites:
Attempted to connect using 156 cipher suites.
The server accepted the following 8 cipher suites:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128
TLS_RSA_WITH_AES_256_GCM_SHA384 256
TLS_RSA_WITH_AES_256_CBC_SHA256 256
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_GCM_SHA256 128
TLS_RSA_WITH_AES_128_CBC_SHA256 128
TLS_RSA_WITH_AES_128_CBC_SHA 128
I believe I know why the DHE-based ciphers are not being offered: I haven’t enabled use of the olcTLSDHParamFile directive. Rather than mess around with generating the DH param file, etc., I’d like to use ECDHE-based ciphers. According to p. 160 of https://www.openldap.org/doc/admin24/OpenLDAP-Admin-Guide.pdf, the ‘TLSECName’ directive allows an ECDHE curve to be specified. When I tried to enable use of the directive, I received a ‘wrong attibuteType’ error:
ldpdd041:/tmp # cat set-ecname.ldif
dn: cn=config
changetype: modify
add: olcTLSECName
olcTLSECName : secp384r1
ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ecname.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldapmodify: wrong attributeType at line 4, entry "cn=config"
ldpdd041:/tmp #
Does OpenLDAP 2.4.41 not support this directive?
Thanks
tl
Terry Lemons
Senior Principal Software Engineer, Dell EMC
Dell Technologies | Data Management
Terry.Lemons(a)dell.com<mailto:Terry.Lemons@dell.com>
Internal Use - Confidential
1 month, 2 weeks
