openldap-software April 2007

openldap-software@openldap.org

90 participants
96 discussions

OpenLDAP 2.4
by Howard Chu 08 Nov '07

08 Nov '07

The Admin Guide still has not been updated with all of the relevant changes, so here are some notes on new features in the 2.4 release... I believe all of the manpages are up to date, so you can get specifics from them. More complete cn=config functionality: There is a new slapd-config(5) manpage for the cn=config backend. the original design called for auto-renaming of config entries when you insert or delete entries with ordered names, but that was not implemented in 2.3. It is now in 2.4. This means, e.g., if you have olcDatabase={1}bdb,cn=config olcSuffix: dc=example,dc=com and you want to add a new subordinate, now you can: ldapadd olcDatabase={1}bdb,cn=config olcSuffix: dc=foo,dc=example,dc=com this will insert a new BDB database in slot 1 and bump all following databases down one, so the original BDB database will now be named olcDatabase={2}bdb,cn=config olcSuffix: dc=example,dc=com In 2.3 you were only able to add new schema elements, not delete or modify existing elements. In 2.4 you can modify schema at will. (Except for the hardcoded system schema, of course.) More sophisticated syncrepl configurations: the original implementation of syncrepl in OpenLDAP 2.2 was intended to support multiple consumers within the same database, but that feature never worked and was removed from OpenLDAP 2.3. I.e., you could only configure a single consumer in any database. In 2.4 you can configure multiple consumers in a single database. The configuration possibilities here are quite complex and numerous. You can configure consumers over arbitrary subtrees of a database (disjoint or overlapping). Any portion of the database may in turn be provided to other consumers using the syncprov overlay. The syncprov overlay works with any number of consumers over a single database or over arbitrarily many glued databases. As a consequence of the work to support multiple consumer contexts, the syncrepl system now supports full N-way multimaster replication with entry-level conflict resolution. There are some important constraints, of course: In order to maintain consistent results across all servers, you must maintain tightly synchronized clocks across all participating servers (e.g., you must use NTP on all servers). The entryCSNs used for replication now record timestamps with microsecond resolution, instead of just seconds. The delta-syncrepl code has not been updated to support multimaster usage yet, that will come later in the 2.4 cycle. On a related note, syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported in 2.4; you can use syncrepl to replicate an entire server configuration from one server to arbitrarily many other servers. It's possible to clone an entire running slapd using just a small (less than 10 lines) seed configuration, or you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test suite provide working examples of these capabilities. In 2.3 you could configure syncrepl as a full push-mode replicator by using it in conjunction with a back-ldap pointed at the target server. But because the back-ldap database needs to have a suffix corresponding to the target's suffix, you could only configure one instance per slapd. In 2.4 you can define a database to be "hidden" which means that its suffix is ignored when checking for name collisions, and the database will never be used to answer requests received by the frontend. Using this hidden database feature allows you to configure multiple databases with the same suffix, allowing you to set up multiple back-ldap instances for pushing replication of a single database to multiple targets. There may be other uses for hidden databases as well (e.g., using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem). More extensive TLS configuration control: In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came from the system's ldap.conf file. In 2.4 all of these sessions inherit their settings from the main slapd configuration but settings can be individually overridden on a per-config-item basis. This is particularly helpful if you use certificate-based authentication and need to use a different client certificate for different destinations. Various performance enhancements: Too many to list. Some notable changes - ldapadd used to be a couple of orders of magnitude slower than "slapadd -q". It's now at worst only about half the speed of slapadd -q. A few weeks ago I did some comparisons of all the 2.x OpenLDAP releases; the results are in the slides from my SCALE presentation and you can find a copy here: http://www.highlandsun.com/hyc/scale2007.pdf That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD (as of a couple weeks ago). Toward the latter end of the "Cached Search Performance" chart it gets hard to see the difference because the runtimes are so small, but the new code is about 25% faster than 2.3, which was about 20% faster than 2.2, which was about 100% faster than 2.1, which was about 100% faster than 2.0, in that particular search scenario. That test basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand entries per second. The search was on an unindexed attribute using a filter that would not match any entry, forcing slapd to examine every entry in the DB, testing the filter for a match. Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search processing time is almost invisible; the runtime is limited only by the memory bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec; the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.) I think it goes without saying that no other Directory Server in the world is this fast or this efficient. Couple that with the scalability, manageability, flexibility, and just the sheer know-how behind this software, and nothing else is even remotely comparable. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

7 12

slapd cores
by Dmitriy Kirhlarov 14 May '07

14 May '07

Hi, list. I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19). I have reproduceble crash of slapd on this host. But I can't reproduce it on other server (FreeBSD 6.1-STABLE Aug 2). Database is fine (I dump and restore it), changing thread library doesn't help too. Some information from core: (gdb) bt 0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2 0x2836e89a in sigaction () from /lib/libpthread.so.2 0x2836888d in pthread_kill () from /lib/libpthread.so.2 0x28368256 in raise () from /lib/libpthread.so.2 0x28442e34 in abort () from /lib/libc.so.6 0x2841f060 in __assert () from /lib/libc.so.6 0x080aad9e in entry_schema_check () 0x286908a3 in bdb_add (op=0xcecfa0c0, rs=0xcecfa080) at add.c:63 0x080ec0b5 in overlay_init () 0x080db272 in glue_sub_init () 0x08080a75 in slap_req2res () 0x080818ac in slap_send_ldap_result () 0x08113e35 in translucent_initialize () 0x080db309 in overlay_op_walk () 0x080db543 in overlay_op_walk () 0x080db650 in overlay_op_walk () 0x0808b0c6 in fe_op_modify () 0x0808a33e in do_modify () 0x0806fb84 in connection_done () 0x281b36ad in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.3.so.2 0x283703a5 in pthread_create () from /lib/libpthread.so.2 0x2842e3df in _ctx_start () from /lib/libc.so.6 (gdb) info threads 6 Thread 0x818b000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2 5 Thread 0x8267200 (LWP 100039) 0x2837f4f7 in pthread_testcancel () from /lib/libpthread.so.2 4 Thread 0x8267a00 (runnable) 0x2844658b in select () from /lib/libc.so.6 3 Thread 0x8267c00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2 * 2 Thread 0x8267e00 (LWP 100141) 0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2 1 Thread 0x8274000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from /lib/libpthread.so.2 Can somebody help me? WBR Dmitriy

5 7

Slapd crashing again, three different reasons?
by Daniel Henninger 02 May '07

02 May '07

Hi folk, First off, let me say that per our last conversation about this, I have not yet rebuild cyrus-sasl/openldap against a different Kerberos dist. (I was going to build against 1.5.. right now I'm at 1.2.8.. we tend to steer clear of Heimdal) Anyway, on April 28th, at 12:05AM, all three of our slave servers' slapds died. All for apparently different reasons: First slave: #0 0xfed592f0 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfed4e59c in _resetsig () from /usr/lib/libthread.so.1 #2 0xfed4dd3c in _sigon () from /usr/lib/libthread.so.1 #3 0xfed50d98 in _thrp_kill () from /usr/lib/libthread.so.1 #4 0xfedcbdc4 in raise () from /usr/lib/libc.so.1 #5 0xfedb5a5c in abort () from /usr/lib/libc.so.1 #6 0xfedb5d00 in _assert () from /usr/lib/libc.so.1 #7 0xff3188b8 in ber_sockbuf_ctrl (sb=0x18d53b38, opt=1, arg=0xd7c00e6c) at sockbuf.c:89 #8 0x0003071c in connection_get (s=111) at connection.c:312 #9 0x00032ef8 in connection_read (s=111) at connection.c:1307 #10 0x0002f84c in slapd_daemon_task (ptr=0x14d218) at daemon.c:2353 #11 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 #12 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Second slave: #0 0xfee12d38 in fseek () from /usr/lib/libc.so.1 #1 0xfe343680 in krb5_ktfileint_internal_read_entry () from /local/kerberos/lib/libkrb5.so.3 #2 0xfe343ec8 in krb5_ktfileint_read_entry () from /local/kerberos/lib/libkrb5.so.3 #3 0xfe342660 in krb5_ktfile_get_entry () from /local/kerberos/lib/libkrb5.so.3 #4 0xfe35bc44 in krb5_rd_req_decrypt_tkt_part () from /local/kerberos/lib/libkrb5.so.3 #5 0xfe35bdcc in krb5_rd_req_decoded_opt () from /local/kerberos/lib/libkrb5.so.3 #6 0xfe35c594 in krb5_rd_req_decoded () from /local/kerberos/lib/ libkrb5.so.3 #7 0xfe35bb10 in krb5_rd_req () from /local/kerberos/lib/libkrb5.so.3 #8 0xfecd81ec in krb5_gss_accept_sec_context () from /local/kerberos/lib/libgssapi_krb5.so.2 #9 0xfece12c4 in gss_accept_sec_context () from /local/kerberos/lib/libgssapi_krb5.so.2 #10 0xfed02410 in gssapi_server_mech_step () from /local/lib/sasl2/libgssapiv2.so.2 #11 0xff1d95c0 in sasl_server_step () from /local/lib/libsasl2.so.2 #12 0xff1d92b4 in sasl_server_start () from /local/lib/libsasl2.so.2 #13 0x00074998 in slap_sasl_bind (op=0x516fe80, rs=0xd4c01af0) at sasl.c:1393 #14 0x0004c4d4 in fe_op_bind (op=0x516fe80, rs=0xd4c01af0) at bind.c:276 ---Type <return> to continue, or q <return> to quit--- #15 0x0004bddc in do_bind (op=0x516fe80, rs=0xd4c01af0) at bind.c:200 #16 0x00032afc in connection_operation (ctx=0x170948, arg_v=0x516fe80) at connection.c:1132 #17 0xff33cbb4 in ldap_int_thread_pool_wrapper (xpool=0x181b08) at tpool.c:478 #18 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 #19 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Third slave: #0 0xfedc1fe0 in _malloc_unlocked () from /usr/lib/libc.so.1 #1 0xfedc1db0 in malloc () from /usr/lib/libc.so.1 #2 0xff039c48 in default_malloc_ex () from /local/lib/libcrypto.so. 0.9.7 #3 0xff03a638 in CRYPTO_malloc () from /local/lib/libcrypto.so.0.9.7 #4 0xff0a52bc in EVP_DigestInit_ex () from /local/lib/libcrypto.so. 0.9.7 #5 0xff04cb90 in HMAC_Init_ex () from /local/lib/libcrypto.so.0.9.7 #6 0xff18c1dc in tls1_mac () from /local/lib/libssl.so.0.9.7 #7 0xff1877a8 in ssl3_read_bytes () from /local/lib/libssl.so.0.9.7 #8 0xff185608 in ssl3_read () from /local/lib/libssl.so.0.9.7 #9 0xff18d368 in SSL_read () from /local/lib/libssl.so.0.9.7 #10 0xff35e7f4 in sb_tls_read (sbiod=0xff8b7b0, buf=0x175d0d80, len=4) at tls.c:589 #11 0xff319520 in sb_debug_read (sbiod=0xd02fe00, buf=0x175d0d80, len=4) at sockbuf.c:795 #12 0xff3431e8 in sb_sasl_read (sbiod=0xfc0cd08, buf=0xccb14b3, len=8) at cyrus.c:270 #13 0xff319520 in sb_debug_read (sbiod=0xc4f0e50, buf=0xccb14b3, len=8) at sockbuf.c:795 #14 0xff31866c in ber_int_sb_read (sb=0xe03bc80, buf=0xccb14b3, len=8) at sockbuf.c:409 #15 0xff3161e8 in ber_get_next (sb=0xe03bc80, len=0xd7c00ef4, ber=0xccb14a8) at io.c:504 #16 0x000330a8 in connection_read (s=71) at connection.c:1527 ---Type <return> to continue, or q <return> to quit--- #17 0x0002f84c in slapd_daemon_task (ptr=0x14d218) at daemon.c:2353 #18 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 #19 0xfed5b124 in _thread_start () from /usr/lib/libthread.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Now, the second one is most likely the "recompile it against a different Kerberos" issue. However, the last seems to be directly SSL related and the first ... I have no idea about the first. We have openldap built against openssl 0.9.7i. So you might be asking yourself, what occurs at 12:05am in our world? Nothing in particular as far as I can tell from the logs, which is mighty odd. Also this never happens with the master server (but then again it's not getting direct queries) The last request in the logs seems to have been a fairly simple lookup (I X'd out the uid): Apr 28 00:00:05 uni01ds.unity.ncsu.edu slapd[1058]: [ID 469902 local4.debug] con n=2189346 op=115 SRCH base="ou=accounts,dc=ncsu,dc=edu" scope=2 deref=0 filter=" (&(|(objectClass=posixAccount)(objectClass=inetOrgPerson) (objectClass=shadowAcco unt))(|(uidNumber=XXXXX)))" Apr 28 00:00:05 uni01ds.unity.ncsu.edu slapd[1058]: [ID 744844 local4.debug] con n=2189346 op=115 SRCH attr=uid cn cn homeDirectory loginShell uidNumber Looks like they really all crashed at right after midnight and were discovered and fixed 5 minutes later. Any suggestions? =( I know many of you are running this under Solaris. Anyone had any particular problems doing so? Daniel

2 3

Problem when using 'accesslog' and 'refint' overlays in combination
by Alina Dubrovska 02 May '07

02 May '07

Hello dear list, Please try respond to this post, because that's very important for out project to fix described problem! We are trying to configure access logging in my OpenLDAP server (version is 2.3.27) using slapo-accesslog overlay. In slapd.conf I have configured accesslog database according to manual: database bdb suffix "cn=accesslog" rootdn "cn=root,cn=accesslog" rootpw accesslog index reqStart eq database bdb suffix "dc=main_domain,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Administrator,dc=main_domain,dc=com" overlay accesslog logdb "cn=accesslog" logops writes logold (objectclass=person) In previous version of slapd.conf there was also slapo-refint overlay enabled to support 'uniqueMember' attribute update after member entry is renamed or deleted: overlay refint refint_attributes uniqueMember After turning on access logging I inspect the following problem: I create 2 users (objectclass=person) and a group (objectclass=groupOfUniqueNames), then I add both users to that group (add users DN values to uniqueMember attribute). Next I'm trying to rename (or delete) one of the member users and... LDAP hangs up with no response. When I connect once again, then I see that action was performed (user is renamed or deleted, but old member reference is present in group attributes). However, I'm not able to modify directory (that is add some new entry, modify attribute value etc) LDAP hangs up on any attempt and only OpenLDAP restart helps. Last note is that this problem appears only when both accesslog and refint are enabled. Separately they are working as expected. Does anybody have an idea about the reason of such a problem? We tried to find some useful information in logs, but nothing is there (maybe we just looked in wrong place) Maybe it's possbile to configure access-log to use database on different LDAP server? Maybe that could help? Please help! We need to have this working together! Thanks in advance, Alina.

2 1

Syncrepl-Consumer deletes entries
by Joachim Hergeth 01 May '07

01 May '07

Hello list, I have an OpenLDAP provider/consumer installation on two SLES10 systems. One is set up as a provider LDAP, the second is a consumer LDAP using "refreshOnly" synrepl synchronization. The LDAP provides user information for a Samba installation. The initial synchronization of the consumer works as expected. All LDAP entries are copied to the consumer directory. But after some time, usually when users log in into the Samba running with the provider LDAP, nearly 50% of all LDAP entries on the consumer are deleted. This happens without any change on the provider LDAP! Checking the logs I found, that delete-messages can be found in the consumers system log. I do not understand the source of the problem. No entries in the provider LDAP are deleted, so no entries should be deleted in the consumer. To check the installation, I set up a second consumer in a VMWare environment. And also in this system, which had been set up from scratch and only holds the OpenLDAP-consumer, the entries are deleted at the same time when they are deleted in the "real" OpenLDAP consumer system. When I change an attribute of an entry in the provider LDAP which has been deleted from the consumer by this process, like adding a description, this change is forwarded to th consumer and the entry "reappears" in the LDAP of the consumer. Any help or suggestion is appreciated. Thanks in advance Joachim Hergeth The providers slapd.conf is: # # 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/rfc2307bis.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/samba3.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Load dynamic backend modules: modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # 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 to user password # Allow anonymous users to authenticate # Allow read access to everything else # Directives needed to implement policy: ## Yast2 samba hack ACL ## allow the "ldap admin dn" access, but deny everyone else access to attrs=SambaLMPassword,SambaNTPassword by dn="cn=Administrator,dc=master-ldap,dc=gts-systems.de" write by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * none ## Yast2 samba hack ACL done access to dn.base="" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to dn.base="cn=Subschema" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to attrs=userPassword,userPKCS12 by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to attrs=shadowLastChange by self write by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to * by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * 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! ####################################################################### # BDB database definitions ####################################################################### schemacheck on idletimeout 30 loglevel 131 backend bdb database bdb suffix "dc=master-ldap,dc=gts-systems.de" rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de" rootpw <some working password> directory /var/lib/ldap/ checkpoint 1024 5 cachesize 10000 index objectClass,entryCSN,entryUUID,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 1 --------------------------------------------------------------------------- the consumers slapd.conf is: # # 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/rfc2307bis.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/yast.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # Load dynamic backend modules: modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # 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 to user password # Allow anonymous users to authenticate # Allow read access to everything else # Directives needed to implement policy: access to dn.base="" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to dn.base="cn=Subschema" by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by * read access to attrs=userPassword,userPKCS12 by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * auth access to attrs=shadowLastChange by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write by self write by * read access to * by dn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" write # by anonymous auth by * read # 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! ####################################################################### # BDB database definitions ####################################################################### schemackeck on idletimeout 30 loglevel 15288 # TLSCertificateFile /etc/ssl/servercerts/servercert.pem # TLSCACertificatePath /etc/ssl/certs/ # TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem database bdb suffix "dc=master-ldap,dc=gts-systems.de" rootdn "cn=Administrator,dc=master-ldap,dc=gts-systems.de" rootpw "<some working password>" directory /var/lib/ldap checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber,entryCSN,entryUUID eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub syncrepl rid=321 provider=ldap://192.168.1.210:389 type=refreshOnly interval=00:00:00:30 searchbase="dc=master-ldap,dc=gts-systems.de" scope=sub schemachecking=off bindmethod=simple binddn="cn=repladmin,dc=master-ldap,dc=gts-systems.de" credentials=<another nice password> ---------------------------------------------------------------------------

4 5

ppolicy, is a password reset the only way to unlock an account?
by Sam Tran 30 Apr '07

30 Apr '07

Hi All, I am currently testing slapo-ppolicy in OL 2.3.35. I have the following ppolicy: pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxFailure: 3 pwdMustChange: FALSE pwdSafeModify: FALSE My question is the following: Let's say I lock my account after 3 unsuccessful binds. Is a password reset the only way to unlock it? Thanks, Sam

1 0

LDAP Reference Works?
by Yang Sun 30 Apr '07

30 Apr '07

Hi, I am new to LDAP world. And I am trying to design a distribute data structure for storing the user information in our project. I am not sure whether using ldap reference is the right way to do this job. Please give me some suggestion. The detailed situation is: We manage tens of sites. And the sites are orgnized in a tree structure. The requirement is to store the information in the local site (means no central place to store the information for all the sites). It will give the system the maximum flexiblity to expand and when the site is isolated the local site still works well. Sometimes, the local site will need information stored in other sites. I think it is a distribute database architecture. And it reminds me to use the LDAP reference function. So each local site will have a reference to its parent site and some references to its child sites. It gives a logical view of the tree with information for all the sites. I am not sure whether it is possible to do that and whether it has some difficulties to implement it using OpenLDAP. Any suggestion? Thanks, Yang Sun

1 0

rewriting compare ava with overlay rwm
by Jens Grigel 30 Apr '07

30 Apr '07

Hi, we're using openldap 2.3.35 as ldap proxy to support anonymous binds and searches to a restricted ldap server. We're now trying to rewrite existing cn's with old suffix to new cn's with new suffix of the restricted ldap server. So far almost everything is working with rwm-suffixmassage and overlay rwm except rewriting AVA's from ldapcompare. I'm still not sure if this is actually possible with overlay rwm or if i'm misunderstanding the manpage of slapo-rwm. Rewriting the cn's in searches, searchresults, bindDN and compareDN works, but the AVA from the compared attribute (here: cn) is not changed from rewriteContext compareAttrDN. "man slapo-rwm" says that the rewriteContext compareAttrDN rewrites compare AVA, but whatever i try it's not changing anything in the ldapcompare. What format of the rwm-rewriteRules for rewriteContext compareAttrDN is expected for rewriting to succeed? Or is this actually impossible what i'm thinking of? Here my shortened (removed a lot of rewriteRules, but still working) slapd.conf: # slapd.conf loglevel -1 include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload rwm.la overlay rwm rwm-suffixmassage "o=sskm" "ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" database ldap suffix "ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" uri "ldap://5.1.35.254/" network-timeout 3 chase-referrals no idassert-bind bindmethod=simple binddn="cn=q001ldap,ou=dienstkonten,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" credentials="secret" mode=none idassert-authzFrom "dn.regex:.*" overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "cn=99([0-9]{3})" "cn=s001x$1" ":@" rwm-rewriteContext bindDN rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@" rwm-rewriteContext searchEntryDN rwm-rewriteRule "cn=s001x([0-9]{3}),(.+)" "cn=99$1,$2" ":@" rwm-rewriteContext compareDN rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2" ":@" rwm-rewriteContext compareAttrDN rwm-rewriteRule "99([0-9]{3})" "s001x$1" # end slapd.conf The basic idea from this simple setup is to rewrite a cn=99854 to cn=s001x854 and back whereever possible. I'm trying with ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:99854 this fails and produces the following logs slapd[9789]: do_compare slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm> slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm> slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" -> "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: do_compare: dn (cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (99854) slapd[9789]: conn=1 op=1 CMP dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn" slapd[9789]: [rw] compareDN: "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: send_ldap_result: conn=1 op=1 p=3 slapd[9789]: send_ldap_result: err=5 matched="" text="" packet capturing shows that the value is not rewritten when sent to the ldap server. Using the value which i was trying to rewrite to ldapcompare -x -D "" -H ldap://testproxy cn=99854,o=sskm cn:s001x854 succeeds slapd[9789]: do_compare slapd[9789]: >>> dnPrettyNormal: <cn=99854,o=sskm> slapd[9789]: <<< dnPrettyNormal: <cn=99854,o=sskm>, <cn=99854,o=sskm> slapd[9789]: [rw] compareDN: "cn=99854,o=sskm" -> "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: do_compare: dn (cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern) attr (cn) value (s001x854) slapd[9789]: conn=10 op=1 CMP dn="cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" attr="cn" slapd[9789]: [rw] compareDN: "cn=99854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" -> "cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" slapd[9789]: >>> dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: <<< dnPrettyNormal: <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern>, <cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern> slapd[9789]: send_ldap_result: conn=10 op=1 p=3 slapd[9789]: send_ldap_result: err=6 matched="" text="" -- Jens Grigel Citysavingsbank Munich, Germany Dept. of Network/Security

2 3

Replication on RDBMS level?
by Martin Cizek 28 Apr '07

28 Apr '07

Hi all, is it safe to use several slapd servers with slapd-sql backend connected to a replicated database? Are there any drawbacks of using RDBMS-level replication in comparison to slurpd? Thank you, Martin

1 0

How long should replication take?
by Norman Gaywood 27 Apr '07

27 Apr '07

I have a server and slave setup with syncrepl, openldap 2.3.34 Here is my syncrepl stanza on the slave: syncrepl rid=1 provider=ldap://ldap1.sample.edu.au:389 starttls=yes type=refreshAndPersist interval=00:00:01:00 retry=1,2,3,4,5,+ searchbase="dc=sample,dc=edu,dc=au" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off updatedn "cn=Replica,dc=sample,dc=edu,dc=au" bindmethod=simple binddn="cn=SyncUser,dc=sample,dc=edu,dc=au" credentials="secret" If I do only a few updates, the sync seems quite fast. If I run a script to make about 60,000 modifications on the master, this takes about 20 minutes to run. The slave starts updating immediately, however it soon falls behind. It takes over an hour, since the last change to the master, for the slave to be in sync. Is this expected behaviour? -- Norman Gaywood, Systems Administrator University of New England, Armidale, NSW 2351, Australia Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software April 2007