Hey guys, I currently have a multi-master system setup with a back_ldap proxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it. It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature." If I remove ppolicy overlay I don't see any of the values.
I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong?
Thanks for any help, Tyler
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
I currently have a multi-master system setup with a back_ldapproxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it.
olcUpdateRef only makes sense when the database is shadow - i.e. it also contains a olcSyncrepl directive. The indications above make sense when slapo-ppolicy is on a shadow database; you're trying to use them on a proxy, which is usually not a shadow.
It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature."
This indication makes sense: slapo-chain uses libldap calls, which can be configured to automatically handle referrals. However, in general, slapo-chain can be used instead of the built-in referral chase capabilities, because it allows finer grain control on what identity is used/propagated during referral chasing. But this should be outside the scope of your issue.
If I remove ppolicy overlay I don't see any of the values.
Please clarify: what do you mean by "I don't see any of the values"? I0ve checked with HEAD code, and I've noticed that indeed ppolicy control responses don't get propagated from a remote DSA through the proxy. Is this what you mean? I'm filing an ITS about this. Actually, I think the reason is related to ITS#6166 (Followup 1); however, we need to fix it now rather than wait for that fix.
I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong?
I know I didn't answer your question, but I need a clearer description of what you're trying to accomplish. And there seems to be an issue related to slapd-ldap behavior when control responses are to be returned during a bind.
p.
On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
2.4.18 I have ppolicy setup on both masters as well as the proxy (as an overlay to back_ldap) because it was the only way I could see the values from the masters when queries where made to proxy (which I need to be able to do).
I currently have a multi-master system setup with a back_ldapproxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it.
olcUpdateRef only makes sense when the database is shadow - i.e. it also contains a olcSyncrepl directive. The indications above make sense when slapo-ppolicy is on a shadow database; you're trying to use them on a proxy, which is usually not a shadow.
It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature."
This indication makes sense: slapo-chain uses libldap calls, which can be configured to automatically handle referrals. However, in general, slapo-chain can be used instead of the built-in referral chase capabilities, because it allows finer grain control on what identity is used/propagated during referral chasing. But this should be outside the scope of your issue.
If I remove ppolicy overlay I don't see any of the values.
Please clarify: what do you mean by "I don't see any of the values"? I0ve checked with HEAD code, and I've noticed that indeed ppolicy control responses don't get propagated from a remote DSA through the proxy. Is this what you mean? I'm filing an ITS about this. Actually, I think the reason is related to ITS#6166 (Followup 1); however, we need to fix it now rather than wait for that fix.
That is exactly what I mean - pwd* and friends attributes from ppolicy do not get propegated to the proxy utilitzing back_ldap. The only way I could get them was by adding the overlay to back_ldap on the proxy itself but as I explained earlier its not processing pwdExpireWarning times correctly. Thank you for filing the ITS. Would you mind letting us know the number on that once you create it? I cannot find anything currently. Also, I cannot find ITS#6166 either. Can you double check that number?
I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong?
I know I didn't answer your question, but I need a clearer description of what you're trying to accomplish. And there seems to be an issue related to slapd-ldap behavior when control responses are to be returned during a bind.
p.
Hopefully my previous responses above clarified that. Thank you for filing the ITS. Tyler
On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
2.4.18 I have ppolicy setup on both masters as well as the proxy (as an overlay to back_ldap) because it was the only way I could see the values from the masters when queries where made to proxy (which I need to be able to do).
Not sure what you mean by "see"; do you mean they be returned in search requests? This, from a proxy standpoint, should not be an issue, as they are treated much like any other attribute. Did you load ppolicy.schema on the proxy server? Do ACLs allow to return them? Are you explicitly requesting operational attributes?
I currently have a multi-master system setup with a back_ldapproxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it.
olcUpdateRef only makes sense when the database is shadow - i.e. it also contains a olcSyncrepl directive. The indications above make sense when slapo-ppolicy is on a shadow database; you're trying to use them on a proxy, which is usually not a shadow.
It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature."
This indication makes sense: slapo-chain uses libldap calls, which can be configured to automatically handle referrals. However, in general, slapo-chain can be used instead of the built-in referral chase capabilities, because it allows finer grain control on what identity is used/propagated during referral chasing. But this should be outside the scope of your issue.
If I remove ppolicy overlay I don't see any of the values.
Please clarify: what do you mean by "I don't see any of the values"? I0ve checked with HEAD code, and I've noticed that indeed ppolicy control responses don't get propagated from a remote DSA through the proxy. Is this what you mean? I'm filing an ITS about this. Actually, I think the reason is related to ITS#6166 (Followup 1); however, we need to fix it now rather than wait for that fix.
That is exactly what I mean - pwd* and friends attributes from ppolicy do not get propegated to the proxy utilitzing back_ldap. The only way I could get them was by adding the overlay to back_ldap on the proxy itself but as I explained earlier its not processing pwdExpireWarning times correctly. Thank you for filing the ITS. Would you mind letting us know the number on that once you create it?
http://www.openldap.org/its/?findid=6530; fixed in HEAD; you should be able to pull out back-ldap/bind.c 1.258 -> 1.259; I'm not sure it applies straightforward to 2.4.18, though.
I cannot find anything currently. Also, I cannot find ITS#6166 either. Can you double check that number?
http://www.openldap.org/its/?findid=6166
I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong?
I know I didn't answer your question, but I need a clearer description of what you're trying to accomplish. And there seems to be an issue related to slapd-ldap behavior when control responses are to be returned during a bind.
p.
Hopefully my previous responses above clarified that. Thank you for filing the ITS.
p.
On 04/22/2010 12:26 PM, masarati@aero.polimi.it wrote:
On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
2.4.18 I have ppolicy setup on both masters as well as the proxy (as an overlay to back_ldap) because it was the only way I could see the values from the masters when queries where made to proxy (which I need to be able to do).
Not sure what you mean by "see"; do you mean they be returned in search requests? This, from a proxy standpoint, should not be an issue, as they are treated much like any other attribute. Did you load ppolicy.schema on the proxy server? Do ACLs allow to return them? Are you explicitly requesting operational attributes?
By 'see' I do mean search requests directed at the proxy. If the ACL's are fine when searching on the masters then it should be fine on the proxy, right (proxy relies on the masters for ACL's)? The schema is loading and yes I am requesting operational attributes but this is through phpldapamin's "show internal attributes" button. Maybe I'll try through ldapsearch tool next time I am ready to try a few more things. I've noticed the following in the logs though which confuses me even more:
PROXIED attributeDescription "PWDHISTORY" inserted. PROXIED attributeDescription "PWDPOLICYSUBENTRY" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted.
Confused..
I currently have a multi-master system setup with a back_ldapproxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it.
olcUpdateRef only makes sense when the database is shadow - i.e. it also contains a olcSyncrepl directive. The indications above make sense when slapo-ppolicy is on a shadow database; you're trying to use them on a proxy, which is usually not a shadow.
It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature."
This indication makes sense: slapo-chain uses libldap calls, which can be configured to automatically handle referrals. However, in general, slapo-chain can be used instead of the built-in referral chase capabilities, because it allows finer grain control on what identity is used/propagated during referral chasing. But this should be outside the scope of your issue.
If I remove ppolicy overlay I don't see any of the values.
Please clarify: what do you mean by "I don't see any of the values"? I0ve checked with HEAD code, and I've noticed that indeed ppolicy control responses don't get propagated from a remote DSA through the proxy. Is this what you mean? I'm filing an ITS about this. Actually, I think the reason is related to ITS#6166 (Followup 1); however, we need to fix it now rather than wait for that fix.
That is exactly what I mean - pwd* and friends attributes from ppolicy do not get propegated to the proxy utilitzing back_ldap. The only way I could get them was by adding the overlay to back_ldap on the proxy itself but as I explained earlier its not processing pwdExpireWarning times correctly. Thank you for filing the ITS. Would you mind letting us know the number on that once you create it?
http://www.openldap.org/its/?findid=6530; fixed in HEAD; you should be able to pull out back-ldap/bind.c 1.258 -> 1.259; I'm not sure it applies straightforward to 2.4.18, though.
I cannot find anything currently. Also, I cannot find ITS#6166 either. Can you double check that number?
http://www.openldap.org/its/?findid=6166
I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong?
I know I didn't answer your question, but I need a clearer description of what you're trying to accomplish. And there seems to be an issue related to slapd-ldap behavior when control responses are to be returned during a bind.
p.
Hopefully my previous responses above clarified that. Thank you for filing the ITS.
p.
On 04/22/2010 12:26 PM, masarati@aero.polimi.it wrote:
On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
2.4.18 I have ppolicy setup on both masters as well as the proxy (as an overlay to back_ldap) because it was the only way I could see the values from the masters when queries where made to proxy (which I need to be able to do).
Not sure what you mean by "see"; do you mean they be returned in search requests? This, from a proxy standpoint, should not be an issue, as they are treated much like any other attribute. Did you load ppolicy.schema on the proxy server? Do ACLs allow to return them? Are you explicitly requesting operational attributes?
By 'see' I do mean search requests directed at the proxy. If the ACL's are fine when searching on the masters then it should be fine on the proxy, right (proxy relies on the masters for ACL's)?
It depends on how you configure things, that's why I'm asking. If the proxy has no ACLs, then anything the remote host returns is passed to the client. Otherwise, the proxy performs its own checking (which, obviously, can only further restrict). I'm asking because you are hiding essential information on how your system is configured, and that doesn't help helping.
The schema is loading and yes I am requesting operational attributes
How are you requesting operational attributes? Did you add '+' to the requested attrs?
but this is through phpldapamin's "show internal attributes" button. Maybe I'll try through ldapsearch tool next time I am ready to try a few more things.
Yes, I was assuming (since you didn't tell) that you were using ldapsearch. Please make sure what's being requested (by looking at both the proxy and the remote host's logs. Check, don't assume.
I've noticed the following in the logs though which confuses me even more:
PROXIED attributeDescription "PWDHISTORY" inserted. PROXIED attributeDescription "PWDPOLICYSUBENTRY" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted.
This is a clear indication the schema is ***not*** loaded. That's why I asked. The ppolicy schema is loaded by default when slapo-ppolicy is built statically in slapd. Otherwise you need to either load ppolicy.schema, or load the ppolicy.la module. In any case, the schema must be present also on the proxy, even though the proxy does not need to have the overlay instantiated. It would be waaaaaay easier if you posted your remote host & proxy configuration, and detailed how OpenLDAP was built (namely, static or dynamic modules).
p.
On 04/22/2010 02:35 PM, masarati@aero.polimi.it wrote:
On 04/22/2010 12:26 PM, masarati@aero.polimi.it wrote:
On 04/22/2010 11:38 AM, masarati@aero.polimi.it wrote:
Hey guys,
Hi. What version? Also, I's not clear (to me) whether you're configuring slapo-ppolicy also on the proxy. If this is the case, I think you're not doing the right thing.
2.4.18 I have ppolicy setup on both masters as well as the proxy (as an overlay to back_ldap) because it was the only way I could see the values from the masters when queries where made to proxy (which I need to be able to do).
Not sure what you mean by "see"; do you mean they be returned in search requests? This, from a proxy standpoint, should not be an issue, as they are treated much like any other attribute. Did you load ppolicy.schema on the proxy server? Do ACLs allow to return them? Are you explicitly requesting operational attributes?
By 'see' I do mean search requests directed at the proxy. If the ACL's are fine when searching on the masters then it should be fine on the proxy, right (proxy relies on the masters for ACL's)?
It depends on how you configure things, that's why I'm asking. If the proxy has no ACLs, then anything the remote host returns is passed to the client. Otherwise, the proxy performs its own checking (which, obviously, can only further restrict). I'm asking because you are hiding essential information on how your system is configured, and that doesn't help helping.
The schema is loading and yes I am requesting operational attributes
How are you requesting operational attributes? Did you add '+' to the requested attrs?
but this is through phpldapamin's "show internal attributes" button. Maybe I'll try through ldapsearch tool next time I am ready to try a few more things.
Yes, I was assuming (since you didn't tell) that you were using ldapsearch. Please make sure what's being requested (by looking at both the proxy and the remote host's logs. Check, don't assume.
I've noticed the following in the logs though which confuses me even more:
PROXIED attributeDescription "PWDHISTORY" inserted. PROXIED attributeDescription "PWDPOLICYSUBENTRY" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted.
This is a clear indication the schema is ***not*** loaded. That's why I asked. The ppolicy schema is loaded by default when slapo-ppolicy is built statically in slapd. Otherwise you need to either load ppolicy.schema, or load the ppolicy.la module. In any case, the schema must be present also on the proxy, even though the proxy does not need to have the overlay instantiated. It would be waaaaaay easier if you posted your remote host & proxy configuration, and detailed how OpenLDAP was built (namely, static or dynamic modules).
p.
I failed to mention the above messages where after I removed ppolicy. I'm using third party rpms from Buchan, it is built dynamic modules: #####################################################3 Name : openldap2.4-servers Relocations: (not relocatable) Version : 2.4.18 Vendor: TelkomInternet Release : 1.rhel5 Build Date: Fri 18 Sep 2009 05:43:56 AM EDT Install Date: Mon 21 Sep 2009 05:47:01 PM EDT Build Host: build.telkomsa.net Group : System/Servers Source RPM: openldap2.4-2.4.18-1.rhel5.src.rpm Size : 4774420 License: Artistic Signature : DSA/SHA1, Fri 18 Sep 2009 05:52:27 AM EDT, Key ID ac92ba5060d204a7 Packager : Buchan Milne bgmilne@staff.telkomsa.net URL : http://www.openldap.org Summary : OpenLDAP servers and related files Description : OpenLDAP Servers
This package contains the OpenLDAP server, slapd (LDAP server), additional backends, configuration files, schema definitions required for operation, and database maintenance tools
This server package was compiled with support for the berkeley database library. ########################################################### Below are my configs (database config was added so I could convert over to cn=config which I can assure has not changed since I converted it):
PROXY:
include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/evolutionperson.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dnszone.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/qmail.schema include /etc/openldap2.4/schema/puppet.schema pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib/openldap2.4 moduleload back_ldap.la moduleload ppolicy.la TLSCertificateFile /etc/ssl/openldap2.4/directory-proxy.crt TLSCertificateKeyFile /etc/ssl/openldap2.4/directory-proxy.key TLSCACertificateFile /etc/ssl/openldap2.4/directory-proxy.crt loglevel config stats 4096 allow bind_anon_dn database config rootdn "cn=admin,cn=config" rootpw <secret> database ldap suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw <secret> uri "ldaps://directory1.example.com ldaps://directory2.example.com" idletimeout 600 overlay ppolicy ppolicy_default "cn=Password,ou=Policies,dc=example,dc=com" ppolicy_use_lockout
DIRECTORY1:
include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/evolutionperson.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dnszone.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/qmail.schema include /etc/openldap2.4/schema/puppet.schema include /etc/openldap2.4/example.access.conf pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib/openldap2.4 moduleload ppolicy.la moduleload syncprov.la TLSCertificateFile /etc/ssl/openldap2.4/directory1.crt TLSCertificateKeyFile /etc/ssl/openldap2.4/directory1.key TLSCACertificateFile /etc/ssl/openldap2.4/directory1.crt loglevel config sync allow bind_anon_dn database config rootdn "cn=admin,cn=config" rootpw <secrect> database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw <secret> directory /var/lib/ldap2.4 cachesize 1000 idlcachesize 1000 idletimeout 600 checkpoint 256 5 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index automountInformation eq index sudoUser eq index entryCSN,entryUUID eq index manager eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 1 syncrepl rid=001 provider=ldaps://directory2.example.com bindmethod=simple binddn="cn=Mirrormode,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on overlay ppolicy ppolicy_default "cn=Password,ou=Policies,dc=example,dc=com" ppolicy_use_lockout limits dn.exact="cn=Mirrormode,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
DIRECTORY2:
Exactly the same as DIRECTORY1 except syncrepl entry has directory1 in place of directory2.
I've noticed the following in the logs though which confuses me even more:
PROXIED attributeDescription "PWDHISTORY" inserted. PROXIED attributeDescription "PWDPOLICYSUBENTRY" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted.
This is a clear indication the schema is ***not*** loaded. That's why I asked. The ppolicy schema is loaded by default when slapo-ppolicy is built statically in slapd. Otherwise you need to either load ppolicy.schema, or load the ppolicy.la module. In any case, the schema must be present also on the proxy, even though the proxy does not need to have the overlay instantiated. It would be waaaaaay easier if you posted your remote host & proxy configuration, and detailed how OpenLDAP was built (namely, static or dynamic modules).
p.
I failed to mention the above messages where after I removed ppolicy. I'm using third party rpms from Buchan, it is built dynamic modules: #####################################################3 Name : openldap2.4-servers Relocations: (not relocatable) Version : 2.4.18 Vendor: TelkomInternet Release : 1.rhel5 Build Date: Fri 18 Sep 2009 05:43:56 AM EDT Install Date: Mon 21 Sep 2009 05:47:01 PM EDT Build Host: build.telkomsa.net Group : System/Servers Source RPM: openldap2.4-2.4.18-1.rhel5.src.rpm Size : 4774420 License: Artistic Signature : DSA/SHA1, Fri 18 Sep 2009 05:52:27 AM EDT, Key ID ac92ba5060d204a7 Packager : Buchan Milne bgmilne@staff.telkomsa.net URL : http://www.openldap.org Summary : OpenLDAP servers and related files Description : OpenLDAP Servers
This package contains the OpenLDAP server, slapd (LDAP server), additional backends, configuration files, schema definitions required for operation, and database maintenance tools
This server package was compiled with support for the berkeley database library. ########################################################### Below are my configs (database config was added so I could convert over to cn=config which I can assure has not changed since I converted it):
PROXY:
include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/evolutionperson.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dnszone.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ppolicy.schema
I see. What I note is that some of the schema elements are only defined by the overlay itself, they are not specified in the schema file. This makes sense, because they are operational, and slapd does not allow to specify operational attributes in the configuration. For this purpose, you need to
moduleload ppolicy.la
in your proxy configuration, *without* configuring the ppolicy overlay on the proxy database. This should make all attributes related to ppolicy known to the proxy. Does this solve all your issue, or is there anything left? I mean, apart from the fix to ITS#6530, that allows to proxy control responses on successful binds.
p.
On Apr 22, 2010, at 4:54 PM, masarati@aero.polimi.it wrote:
I've noticed the following in the logs though which confuses me even more:
PROXIED attributeDescription "PWDHISTORY" inserted. PROXIED attributeDescription "PWDPOLICYSUBENTRY" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted. PROXIED attributeDescription "PWDCHANGEDTIME" inserted.
This is a clear indication the schema is ***not*** loaded. That's why I asked. The ppolicy schema is loaded by default when slapo-ppolicy is built statically in slapd. Otherwise you need to either load ppolicy.schema, or load the ppolicy.la module. In any case, the schema must be present also on the proxy, even though the proxy does not need to have the overlay instantiated. It would be waaaaaay easier if you posted your remote host & proxy configuration, and detailed how OpenLDAP was built (namely, static or dynamic modules).
p.
I failed to mention the above messages where after I removed ppolicy. I'm using third party rpms from Buchan, it is built dynamic modules: #####################################################3 Name : openldap2.4-servers Relocations: (not relocatable) Version : 2.4.18 Vendor: TelkomInternet Release : 1.rhel5 Build Date: Fri 18 Sep 2009 05:43:56 AM EDT Install Date: Mon 21 Sep 2009 05:47:01 PM EDT Build Host: build.telkomsa.net Group : System/Servers Source RPM: openldap2.4-2.4.18-1.rhel5.src.rpm Size : 4774420 License: Artistic Signature : DSA/SHA1, Fri 18 Sep 2009 05:52:27 AM EDT, Key ID ac92ba5060d204a7 Packager : Buchan Milne bgmilne@staff.telkomsa.net URL : http://www.openldap.org Summary : OpenLDAP servers and related files Description : OpenLDAP Servers
This package contains the OpenLDAP server, slapd (LDAP server), additional backends, configuration files, schema definitions required for operation, and database maintenance tools
This server package was compiled with support for the berkeley database library. ########################################################### Below are my configs (database config was added so I could convert over to cn=config which I can assure has not changed since I converted it):
PROXY:
include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/evolutionperson.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dnszone.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ppolicy.schema
I see. What I note is that some of the schema elements are only defined by the overlay itself, they are not specified in the schema file. This makes sense, because they are operational, and slapd does not allow to specify operational attributes in the configuration. For this purpose, you need to
moduleload ppolicy.la
in your proxy configuration, *without* configuring the ppolicy overlay on the proxy database. This should make all attributes related to ppolicy known to the proxy. Does this solve all your issue, or is there anything left? I mean, apart from the fix to ITS#6530, that allows to proxy control responses on successful binds.
p.
Yes! Your solution of loading the module but not configuring it on the proxy solved the false alarms on the proxy and did allow searches for the attributes to be recognized. My only problem now as you pointed out is in the ITS where password policy controls are not being sent back to the proxy.
Thanks for you help :)
openldap-technical@openldap.org
-
masarati＠aero.polimi.it -
Tyler Gates