openldap-technical October 2014

openldap-technical@openldap.org

69 participants
76 discussions

Re: OpenLDAP, SASL and TLS
by Kristof Takacs 08 Oct '14

08 Oct '14

I use the following version: - OpenLDAP (2.4.35), but I have tried 2.4.39 as well - Cyrus SASL (2.1.26) - OpenSSL (1.0.1h) - Heimdal ( I beleive 1.5.2) Thanks, Kris On Mon, Oct 6, 2014 at 1:30 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, October 06, 2014 2:27 PM -0400 Kristof Takacs < > kristof.takacs(a)gmail.com> wrote: > > > I use the following open source libraries: >> - OpenLDAP >> - Cyrus SASL >> - OpenSSL >> - Heimdal >> > > It is always critical to list the versions of software you are using. > Please do so. > > --Quanah > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

3 8

Re: Problem adding olcModuleLoad
by Daniel Jung 07 Oct '14

07 Oct '14

sorry isnt module name memberof? On Mon, Oct 6, 2014 at 7:45 PM, Daniel Jung <mimianddaniel(a)gmail.com> wrote: > sorry isnt module name memberof? > > On Mon, Oct 6, 2014 at 6:39 PM, Howard Chu <hyc(a)symas.com> wrote: > >> Daniel Jung wrote: >> >>> running 2.4.39 >>> >>> # module{0}, config >>> dn: cn=module{0},cn=config >>> objectClass: olcModuleList >>> cn: module{0} >>> olcModuleLoad: {0}syncprov.la <http://syncprov.la> >>> olcModuleLoad: {1}auditlog.la <http://auditlog.la> >>> >>> ldif: >>> dn: cn=module{0},cn=config >>> changetype: modify >>> add: olcModuleLoad >>> olcModuleLoad: memberof >>> >>> using ldapmodify >>> modifying entry "cn=module{0},cn=config" >>> ldap_modify: Other (e.g., implementation specific) error (80) >>> additional info: <olcModuleLoad> handler exited with 1 >>> >>> What am i missing here? >>> >> >> You're missing a valid module name. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > >

3 4

Problem with Index creation
by Joaquin Estrada 07 Oct '14

07 Oct '14

Hi folks. I am having a problem with index creation and am wondering if anyone here has seen this or knows what may be happening. We recently deployed a new proxy server product in our environment and have been working with the vendor to resolve some problems. This device connects to our existing LDAP server environment though a new database we added, per the vendor¹s requirements. One of the problems I am seeing is that, since the addition of this device, we are getting a lot of of the ³<= bdb_equality_cadidates: (uniqueMember) not indexed² messages showing up in the slapd log files. In order to resolve this, I¹ve attempted to create a new equality index on this attribute however no matter what I do, slapindex will not create an index! The following steps were done: 1. Shut down Slapd 2. Modify the slapd.conf file and add the ³index uniqueMember eq² entry to the current list of indexes. 3. Save the slapd.conf file. 4. Navigate to the current path for the database files and delete all existing index ³bdb² files. 5. Run a slapindex f (location of slapd) -b (suffix of database to reindex) I¹ve done this several times, once without deleting the current index files and then a few others after I¹ve deleted the current index files. The slapindex tool will recreate all of the indexes except the ³uniqueMember² index. I do not see an index file for this, and of course starting slapd back up results in the same messages in the log. So, what could be causing this? Is it possible that the vendor is using a filter improperly? If there is no data in the uniqueMember attribute for any of the records would it prevent slapindex from creating an index file? Any help would be appreciated!

1 0

Problem adding olcModuleLoad
by Daniel Jung 06 Oct '14

06 Oct '14

running 2.4.39 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}auditlog.la ldif: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: memberof using ldapmodify modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 What am i missing here? Thanks

2 1

Re: Issues with Master / Slave and ppolicy
by Raul Hernandez 06 Oct '14

06 Oct '14

Hello Quanah, You are right. Here is my slave configuration: dn: cn=module,cn=config changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: syncprov olcModuleLoad: back_ldap dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://example.com binddn="cn=syncReplUser,dc=example,dc=com" bindmethod=simple credentials=PASSWD searchbase="dc=example,dc=com" type=refreshAndPersist scope=sub retry="5 10 10 +" timeout=1 sizelimit=unlimited schemachecking=on - add: olcUpdateRef olcUpdateRef: ldap://example.com dn: olcOverlay=chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: chain olcChainReturnError: TRUE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: ldap://example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=syncReplUser,dc=example,dc=com" credentials=123456. mode=self flags=prescriptive,proxy-authz-non-critical dn: cn=module,cn=config changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: ppolicy dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=Policies,dc=example,dc=com olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: TRUE On Mon, Oct 6, 2014 at 1:20 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, October 06, 2014 2:12 PM -0430 Raul Hernandez < > hernandezr(a)gmail.com> wrote: > > > I've been searching on the Internet how to solve this issue without any >> luck. Can someone point me to the right direction? >> > > You've left out the sync replication configuration for the slave. > > --Quanah > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

LMDB Crash-consistency
by Howard Chu 06 Oct '14

06 Oct '14

Just an fyi... As you would know from reading the LMDB design papers ( http://symas.com/mdb/#pubs ) LMDB is crash-proof by design. A Symas client already confirmed this in their own crash testing last year https://symas.com/carrier-grade-stability-and-performance/ and it has again been verified by a research group at the University of Wisconsin. Their findings are being presented at the Usenix OSDI conference this week, and you can read the paper here https://www.usenix.org/conference/osdi14/technical-sessions/presentation/pi… They report on a single "vulnerability" in LMDB, in which LMDB depends on the atomicity of a single sector 106-byte write for its transaction commit semantics. Their claim is that not all storage devices may guarantee the atomicity of such a write. While I myself filed an ITS on this very topic a year ago, http://www.openldap.org/its/index.cgi/Incoming?id=7668 the reality is that all storage devices made in the past 20+ years actually do guarantee atomicity of single-sector writes. You would have to rewind back to 30 years at least, to find a HDD where this is not true. The UWisc researchers' point is that we cannot say what behaviors will be exported by up--and-coming nonvolatile RAM mechanisms (e.g. MRAM or PCRAM); if they offer byte-addressability instead of sector-addressability then there's a potential for these writes to become non-atomic in the future. At any rate, this issue has zero relevance today, and we are monitoring all of the upcoming NVRAM technologies closely for future developments. The other takeaway from these reports is how critically unreliable many other popular systems are. If you use any of the other projects that were included in this research, you owe it to yourself to rethink that usage, or raise discussions with their developers on how they plan to address their many weaknesses. As an interesting footnote, BerkeleyDB was included in the original testing, and while it was in their preliminary results http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf it is now conspicuously absent from the final paper. Regardless, the OpenLDAP Project is deprecating use of BerkeleyDB for multiple reasons. Again, if you're still using BDB you need to take a moment to re-evaluate your project. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Issues with Master / Slave and ppolicy
by Raul Hernandez 06 Oct '14

06 Oct '14

Hello! I've implemented in our testing lab, 2 openldap master servers (both configured as mirror mode); 1 HA server with HAproxy (to grant load balancing and tcp proxying to both masters), and 1 openldap slave which synchronizes its data from the masters through the HA server. All writes sent to the slave (add/edit ous and users), are forwarded to the masters. It work as is supposed to. I've also implemented the ppolicy overlay on this architecture, with "olcPPolicyForwardUpdates" set to TRUE on the slave. All authentication failures made on the slave, are sent to the masters so they can manage the policy. Here is the issue: On the slave, after a few write operations, its database misses its base (objectClass: dcObject). On the master, after an ldapsearch to its base I get the following: # example.com dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Example dc: example # admin, example.com dn: cn=admin,dc=example,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9V1poc1UwK3VIV0FtMXRMMm1XdE9xU0Y4M3NHY05Qd28= # Test, example.com dn: ou=Test,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: Test On the slave, after an ldapsearch to its base, I get the following: # Test, example.com dn: ou=Test,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: Test I can still fetch objects, and make modifications to them from the slave; but tools like PHPLDAPADMIN, which constructs the tree from "dcObject", shows the following message: "This base cannot be created with PLA." All this servers are Debian SID, with slapd 2.4.39. I've been searching on the Internet how to solve this issue without any luck. Can someone point me to the right direction?

2 1

OpenLDAP, SASL and TLS
by Kristof Takacs 06 Oct '14

06 Oct '14

Hello, I have been working on extending an application that searches LDAP server with Kerberos support. I can now bind and then search using the following mechanism: - Simple Bind - Simple Bind with TLS - Kerberos Bind I am having issues when I have Kerberos bind and TLS turned on. I can see the the Kerberos ticket established, the SASL bind to the LDAP server complete, but the LDAP search failing as the message cannot be parsed by the server. I use the following open source libraries: - OpenLDAP - Cyrus SASL - OpenSSL - Heimdal In my debugging, I noticed that there are different writers that are installed in the chain. I turned on debugging, and hence I see these writers called in the order listed: - simple with TLS: sb_debug_write() -> tlso_sb_write() -> sb_debug_write() -> sb_stream_write() - Kerberos Bind: sb_debug_write() -> sb_sasl_generic_write() -> sb_debug_write() -> sb_stream_write() - Kerberos + TLS: sb_debug_write() -> sb_sasl_generic_write() -> sb_debug_write() -> tlso_sb_write() -> sb_debug_write() -> sb_stream_write() Is this a use case that is supposed to work? What could I be missing? Thanks! Kris

2 1

Syncrepl question
by Бажал Дмитрий 06 Oct '14

06 Oct '14

Hey guys. We have syncrepl working and recently got next problem: when trying to rename object, operation succeeds, but syncrepl gets no events for renaming children objects of renamed first one. How do you fix this? Is it ldap server configuration, or am I doing smth wrong with syncrepl client? Fast look into google gave no information. Thanks for your attention (talk is about OpenLDAP 2.4.31)

3 2

MMR with MirrorMode problem..
by Bill Brigden 06 Oct '14

06 Oct '14

Hi all, I'm running 2.4.39 with Mirrormode replication. I've noticed that occasionally when making schema changes, a change will hang indefinitely without reason. Though (possibly as a cause), also I've found that if I try and restart one of the three servers in this replica set, it will occasionally get the following with causes it to hang indefinitely: Oct 1 08:55:37 ldap-03 slapd[19608]: daemon: shutdown requested and initiated. Oct 1 08:55:37 ldap-03 slapd[19608]: slapd shutdown: waiting for 2 operations/tasks to finish The other hosts show the disconnection and try and reconnect - the only way to fix it seems to be either force killing this server or restarting all the other hosts. Any ideas? It's a fairly standard setup with mirrormode as per the doc's. I've seen there is 2.4.40 released however haven't scheduled in an upgrade yet as there wasn't anything on the changelog that appeared to be linked. Cheers

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2014