openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Heavy load problems
by Angel L. Mateo 16 Jan '12

16 Jan '12

Hello, We have a openldap (2.3.30, debian etch version 32bits) with 4 nodes (xen vm with one cpu core, Intel Xeon 3.20GHz and 2GB of RAM). It that farm we have two databases one with 121K entries (for authenticating users, with lots of connections) and other with 40K entries (with public information of our students, for example). Now we have migrated to two openldap (2.4.21, ubuntu lucid 64btis) farms. One with 4 nodes (xen vm with two cpu cores, Xeon E5450 3GHz, 2 GB of RAM) for the authentication database, and other with 2 nodes (with the same resources than the other) for the other database. The problem is that in the authentication farm we are having lot of problems due to heavy load, although we are not completely migrate all clients to this new farm (we already have clients querying the old farm), but in the old farm we didn't have any problem (just some punctual problems long time ago). The only difference between the old and the new farm is that the old farm was replicating information with slurpd. The new one is a multimaster configuration. The configuration of the replica is: mirrormode on syncrepl rid=11 provider="ldap://<server1>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 syncrepl rid=12 provider="ldap://<server2>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 syncrepl rid=13 provider="ldap://<server3>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 syncrepl rid=14 provider="ldap://<server4>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 This configuration is in the 4 farm nodes. We have checked indexes and both farms have the same. Another difference is that authentication database entries have some attributes obtained from the other database via dynlist overlay. In the old farm, because the two databases are in the same server we had no problem, but in the new one we have to configure this database as an ldap proxy to the other farm, with cache overlay used in this. Heavy loads appears randomly in all nodes (not always with all nodes at the same time). When this happens, slapd is using 100% (well... top reports 200% because we have two cpus), there is no swap, no iowait.... Any idea of what could it be the problem? Is this multimaster configuration so heavy load? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

3 4

OpenLDAP 2.4.28 causing Apache 2.2 to hang
by Kyle Smith 15 Jan '12

15 Jan '12

I recently upgraded OpenLDAP 2.4.26 to 2.4.28. When I did that, a separate server running apache 2.2 and php 5 started to hang every 10-15 minutes. It freezes to the point that it no longer accepts requests. This apache server is using a wildcard cert for https and uses php5-ldap which depends on libgnutls26 and libldap2.4-2. I am currently investigating further, but was wondering if the changes to MozNSS or GNUTls in 2.4.27 (ITS #7051, 6980, 6998, 7001, 7002, 7022, 7034 & 7006) may be interfering with apache. I don't think OpenLDAP is the cause, I am leaning towards an apache/php configuration error but the problem only occurs when I use 2.4.28. OpenLDAP 2.4.26 operates normally and is stable across the board. Any ideas? ldapsearch -H ldaps://ldap.my.com works fine, no errors with connecting or searching.

2 2

Syncrepl: consumer ignores bindmethod=sasl
by Tim Dijkstra 15 Jan '12

15 Jan '12

Hi All, I'm trying to get syncrepl to work with TLS, and SASL External. I think I configured everything correctly; I explicitly state it should use bindmethod=sasl, but in the logs I see it is using simple nonetheless. Replication subsequently fails because lack of access rights. Using ldapsearch with identical setting in .ldaprc works... I'm at a loss. Anybody knows what is going on? Excerpt from slapd.conf of consumer: syncrepl rid=13 provider=ldaps://example.org:636 type=refreshAndPersist interval=00:00:30:00 searchbase="ou=People,dc=example,dc=org" scope=sub bindmethod=sasl saslmech=EXTERNAL schemachecking=off authcid=cn=kelderlied,ou=hosts,o=example authzid=cn=kelderlied,ou=hosts,o=example tls_cacert=/etc/ldap/trusted/ca.drs.p-cacert_root_3.pem tls_cert /etc/ssl/CA/kelderlied.crt tls_key /etc/ssl/CA/kelderlied.key tls_reqcert=demand starttls=critical When Syncrepl from the consumer is started in the logs of the provider I see: > ACCEPT from IP=A.B.C.D:55428 (IP=0.0.0.0:636) > TLS established tls_ssf=128 ssf=128 > BIND dn="" method=128 > conn=1099 op=0 RESULT tag=97 err=0 text= > SRCH BASE..... So, TLS is successful (I have TLS_REQ = demand on the provider), but bind simple is requested Here I do a search by hand with identical settings in my .ldaprc that succeeds > ldapsearch -H ldaps://example.org:636 -Y EXTERNAL -b "ou=people,dc=example,dc=org" "(objectClass=*)" > In the logs: > ACCEPT from IP=A.B.C.D:55434 (IP=0.0.0.0:636) > TLS established tls_ssf=128 ssf=128 > BIND dn="" method=163 > BIND authcid="cn=kelderlied,ou=hosts,o=example" authzid="cn=kelderlied,ou=hosts,o=example" > BIND dn="cn=libnss,dc=example,dc=org" mech=EXTERNAL sasl_ssf=0 ssf=128 > RESULT tag=97 err=0 text= > Any help is appreciated... Tim

1 0

what is the pretty function and the validate function in OpenLDAP?
by Tianyin Xu 14 Jan '12

14 Jan '12

Hi, all, I'm trying to understand the internal workflow of the attribute type checking and syntax validation in OpenLDAP. For example, if I use an attribute whose syntax is not implemented like "presentationAddress", the log message "no validator for syntax" will occur. I trace this message in the source code and find this's done by checking "pretty" and "validate", as follows: -------------------------------------servers/slapd/modify.c-------------------------------- slap_syntax_validate_func *validate = ad->ad_type->sat_syntax->ssyn_validate; slap_syntax_transform_func *pretty = ad->ad_type->sat_syntax->ssyn_pretty; if( !pretty && !validate ) { *text = "no validator for syntax"; snprintf( textbuf, textlen, "%s: no validator for syntax %s", ml->sml_type.bv_val, ad->ad_type->sat_syntax->ssyn_oid ); *text = textbuf; return LDAP_INVALID_SYNTAX; } ----------------------------------------------------------------------------------------------------- Moreover, the pretty function and validate function are treat differently in the latter code like: if ( pretty ) { rc = ordered_value_pretty( ad, &ml->sml_values[nvals], &pval, ctx ); // wrapper for pretty function } else { rc = ordered_value_validate( ad, &ml->sml_values[nvals], ml->sml_op ); // wrapper for validate function } I'm very confused on the "pretty" function and the "validate" function. I tried to google but no related results. Could anyone tell me WHAT is the pretty function and what is the validate function? And HOW can OpenLDAP knows which function is pretty and which is validate? Sorry for the newbie question. Thanks a lot!!! Best, Tianyin -- Tianyin XU, http://cseweb.ucsd.edu/~tixu/

3 2

View or filter based on ldaps://FQDN
by Ronie Gilberto Henrich 14 Jan '12

14 Jan '12

Hello, I need to be able to restrict ldap ou's access based on the ldaps://FQDN used to query the ldap server. Let say I have the following in my ldap server: ou=domain ou=raincoatcompany.com ou=umbrellacompany.com Considering that both ldap.raincoatcompany.com and ldap.umbrellacompany.com are resolving to IP address 10.0.0.10 So, querying the ldap server using ldaps://ldap.raincoatcompany.com/ou=domain should grant access only to the following: ou=domain ou=raincoatcompany.com Is there any way to accomplish that with OpenLDAP? Thanks, -- *Ronie Henrich* *GIT - Sistemas Ltda* <http://www.git.com.br> Novo Hamburgo, RS Brazil <http://maps.google.com/maps?q=%2CNovo+Hamburgo%2CRS%2CBrazil&hl=en> *http://br.linkedin.com/in/roniegh* See who we know in common <http://www.linkedin.com/e/wwk/11684020/>

5 7

Password Policy pwdFailureTime count limits?
by Jeffrey Crawford 14 Jan '12

14 Jan '12

Hello Everyone, I'm having trouble enforcing our password policy for login attempts within a particular time frame. After looking into the issue a little further it seems to stem from the fact that the operational attribute pwdFailureTime can only resolve time down to the second. so if there are three Bind attempts within a single second we only get a single pwdFailureTime entry for that time. Our policy is geared more to try and prevent brute force attacks since this instance of the ldap server will be available publicly. However someone can continuously try to bind and not lock the account for as many seconds as is defined in the pwdMaxFailure attribute in the policy definition. For example: if the following account locking configs are set pwdMaxFailure: 10 pwdFailureCountInterval: 3600 pwdLockout: TRUE pwdLockoutDuration: 30 If I try to lock my account by providing the incorrect credentials 11 times, it didn't lock if my 11 attempts were shorter than 10 seconds, I then tried 100 in a for loop which finished in 7 seconds, it still didn't lock. I looked at the account and counted the number of pwdFailureTime's and found 7. I then place a one second sleep between each bad bind attempt and low an behold it would lock as expected. Therefore there seems to be a limitation of pwdFailureTime to only resolve down to the second and its inability to store the same time multiple times. I'm not sure if this is expected behavior, but it makes locking policies against brute force attacks more difficult to fend against. I did a quick look to see if there was a way of delaying a incorrect credential bind so it wouldn't return for at least a second, but didn't see one. If such a config exists it might help if someone can point me to it. Thanks Jeffrey Crawford

2 1

Changing ACLs in dynamic configuration off-line
by Nick Milas 13 Jan '12

13 Jan '12

When we want to do some non-trivial re-engineering in ACLs, on-line configuration using ldapmodify might be cumbersome. So I think we could slapcat the config database, change ACLs in the output, and slapadd it while the server is offline. So, if we have a set of >100 ACL rules and we want to add one ACL rule after, say, 22, would we have to *manually* renumber all the ACLs after the new 23 so that they are numbered n+1? Or, when the config db is read, is OpenLDAP able to resolve such conflicts (two ACLs with the same number) and renumber automatically? If so, what is the logic? (Maintenance of ACLs in the dynamic configuration remains one of my concerns.) Thanks, Nick

2 1

Bind with alternative DN pattern
by Mathias 13 Jan '12

13 Jan '12

Hi, I have trouble understanding a rather simple LDAP config issue that I'm sure someone on this list can easily help with: How do I add a (or change the) pattern of the bind DN that slapd lets me authenticate with? I have a working slapd setup that I can happily bind to using DNs of the form "cn=Bob Parr,dc=example,dc=com". However, all accounts also have a unique "uid" attribute that I would like to use in addition to (or, if not possible, instead of) the "cn"-based RDN for binding. So, I'd like to (also) bind using the DN "uid=bob,dc=example,dc=com". My understanding is that one entry can have several DNs as long as each one is unambiguous. Shouldn't I be able to bind with anyone of these? I have spent hours on searching for documentation on this and turned up surprisingly little. The problem is not an ACL issue since the logged error when trying a "uid"-based bind is "DB_NOTFOUND: No matching key/data pair found" rather than anything else... I'd be _very_ grateful for any pointers on this... Cheers, Mathias

4 3

RE: How to check syncrepl?
by Juergen.Sprenger＠swisscom.com 13 Jan '12

13 Jan '12

Hi Marco, depending on Your needs this page might help: http://itsecureadmin.com/wiki/index.php/LDAP_Synchronization_Replication http://itsecureadmin.com/wiki/index.php/OpenLDAP_syncrepl_check Regards Jürgen

2 1

openldap admin guide and 'slapd from scratch'
by Stefan Skoglund 13 Jan '12

13 Jan '12

Howdy. I wonder if the ldif sample example the end of chapter 5 is correct ? See below: ---- 1. # example config file - global configuration entry 2. dn: cn=config 3. objectClass: olcGlobal 4. cn: config 5. olcReferral: ldap://root.openldap.org 6. Line 1 is a comment. Lines 2-4 identify this as the global configuration entry. The olcReferral: directive on line 5 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host root.openldap.org. Line 6 is a blank line, indicating the end of this entry. 7. # internal schema 8. dn: cn=schema,cn=config 9. objectClass: olcSchemaConfig 10. cn: schema 11. Line 7 is a comment. Lines 8-10 identify this as the root of the schema subtree. The actual schema definitions in this entry are hardcoded into slapd so no additional attributes are specified here. Line 11 is a blank line, indicating the end of this entry. 12. # include the core schema 13. include: file:///usr/local/etc/openldap/schema/core.ldif 14. Line 12 is a comment. Line 13 is an LDIF include directive which accesses the core schema definitions in LDIF format. Line 14 is a blank line. Next comes the database definitions. The first database is the special frontend database whose settings are applied globally to all the other databases. 15. # global database parameters 16. dn: olcDatabase=frontend,cn=config 17. objectClass: olcDatabaseConfig 18. olcDatabase: frontend 19. olcAccess: to * by * read 20. Line 15 is a comment. Lines 16-18 identify this entry as the global database entry. Line 19 is a global access control. It applies to all entries (after any applicable database-specific access controls). Line 20 is a blank line. The next entry defines the config backend. 21. # set a rootpw for the config database so we can bind. 22. # deny access to everyone else. 23. dn: olcDatabase=config,cn=config 24. objectClass: olcDatabaseConfig 25. olcDatabase: config 26. olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy 27. olcAccess: to * by * none 28. Lines 21-22 are comments. Lines 23-25 identify this entry as the config database entry. Line 26 defines the super-user password for this database. (The DN defaults to "cn=config".) Line 27 denies all access to this database, so only the super-user will be able to access it. (This is already the default access on the config database. It is just listed here for illustration, and to reiterate that unless a means to authenticate as the super-user is explicitly configured, the config database will be inaccessible.) ----- The trouble i had is regarding the olcDatabase=frontend and olcDatabase=config stanzas. slapadd could do its work but the layout in cn=config/ would look like this afterwards: ----- olcDatabase=frontent.ldif olcDatabase=config.ldif olcDatabase=hdb.ldif ----- And as soon as slapd started an extraneous ghostly olcDatabase={-1}frontend.ldif would show up. I had to instantiate the frontend and config as this. --- dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend --- and ---- dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ---- Which works for me.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical