|
Nope – I merely left out the chain directives. Given the choice between “forward ppolicy updates” or “allow users to change their passwords anywhere”, we went with the former. We never identified how to get them to /both/ work and require actual user authentication. This is ok in our environment – and as it turns out we kind of like this limitation. Our corp environment authenticates off the master servers and we simply tell people to use a corp servers to change their password.
We don’t have any users (besides myself) whose desktop’s authenticate from our OpenLDAP infrastructure – it’s only our servers. Here’s the bits we simply removed from the conf (from the thread you’re quoting, the rest is largely the same): chain-uri ldaps://ldap-vip.corp.example.net/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=root,dc=example,dc=net" credentials="secret" mode="self" chain-tls ldaps chain-return-error TRUE Someone else hopped onto the thread indicating they had the same problems – but no one ever chimed in with “this is what’s going on” or “this is what you’re doing wrong”. Such is free community support.
J We’re now using the RHEL6/CentOS6 2.4.23 supplied packages (nearly a sin in this mailing list, but everything is working fine for us) but haven’t approached attempting this again as we’re used to this limitation.
Of course, that wouldn’t be the case if user desktops authenticated from local slave ldap servers, but we’re not in that situation and really, we’ve a lot of other fish in the frying pan. Good luck! - chris From: Limb, Jong (VDSS) [mailto:Jong.Limb@dss.virginia.gov]
Were you ever able to figure out why the authentication against a slave works regardless of the password as you describe below? I am having the exact same problem. Thanks. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 Hello again, I'm having an odd issue with ppolicy and my master/slave config. First, my goals General use: Slave handles all reads locally. Writes get forwarded to the master by the slave. Password policy: When password failures happen on clients using slave ldap servers, the failures, etc, get passed to the master to get replicated to the slaves. I understand this would be done using the ppolicy option: ppolicy_forward_updates Authentication: Actually authenticate (more later). To the problem: --------------- When I leave the section in the chain bit of SLAVE slapd.conf below marked by lines intact (which bind as root): * ppolicy_forward_updates seems to work great - the master shows matching "pwdFailureTime" attributes. * Regardless of password entered, you get a shell. User/bad password = get a shell! This being a problem should be obvious. I suspect that's due to the chain overlay section... This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. |