IvanThanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated.

Jeevan

Date: Tue, 30 Apr 2013 08:51:16 +0200 From: ian@uns.ac.rs To: quanah@zimbra.com CC: jeev_biz@hotmail.com; openldap-technical@openldap.org Subject: Re: Chaining stops working after slapd restart

Quanah Gibson-Mount wrote:

...

--On Monday, April 29, 2013 6:56 PM +0000 jeevan kc jeev_biz@hotmail.com wrote:

...

No, I'm fully using cn=config on Openldap 2.4.30 . I'm working on the chain overlay for the past couple of weeks and when now I finally was able to get it working, I found I could modify the slaves until I restart the server. After I restart the server the chaining doesn't work it says "strong authentication required". So the chaining basically worked only just before I restarted the server.

Please verify whether or not you can reproduce this with OpenLDAP 2.4.35.

This sounds similar to ITS#7381, which was filed against 2.4.32. I've just tested 2.4.35 and can reproduce the bug (using the scripts from the ITS attachment.) -- Ivan Nejgebauer Glavni sistem inženjer CIT-UNS/ARMUNS

Univerzitet u Novom Sadu Trg Dositeja Obradovića 5 21000 Novi Sad +381 21 485 2025 ian@uns.ac.rs www.uns.ac.rs

On 30.04.2013. 17:09, jeevan kc wrote:

Thanks for checking on 2.4.35 . Is there any way to fix the chaining overlay so it works even after restarting the slapd. I need to initiate a password policy for the directory but the chaining needs to be there for it to take effect. Any help / suggestion is appreciated.

I was having the same issue with the chaining overlay and cn=config. It seems that the issue only affects the first olcChainDatabase entry, which is obviously ignored after a server restart. Any further olcChainDatabase entry seems to be working correctly.

As a workaround, I modified the first olcChainDatabase entry with a dummy olcDBURI (e.g. ldap://127.0.0.1) and created a second olcChainDatabase entry with the correct configuration.

As long as ITS#7381 isn't fixed, you could try this workaround.

Best regards, Manuel