Hi,
This is weird - quite possible a config problem, I'm hoping someone can spot it :)
I have a minimal slapd server which works fine with either an rwm/relay section or a ppolicy section - but not both at once.
I'm happy to explain *why* I need to do this if asked, but for now it would just clutter this message. I do have a Really Good(TM) reason.
============ Actual problem ===================
We load slapd up with actual entries for the dc=new,dc=example,dc=com domain.
slapd is configured to map all records with rwm/relay to dc=old,dc=example,dc=com so clients with the old config still work.
ie
we load a real record:
1) dn: uid=testuser,ou=people,dc=new,dc=example,dc=com
and we want clients asking about
2) dn: uid=testuser,ou=people,dc=old,dc=example,dc=com
will be served from (1)
======== OK here's an example ================
=== Server ====
Running debian 6 server with debian slapd 2.4.23-7.2
/usr/sbin/slapd -d 4 -h "ldap:/// ldaps:/// ldapi:///" -g openldap -u openldap -f /etc/ldap/slapd.conf
=== Test client ===
Running test against the "old" realm:
ldapwhoami -x -W -D uid=testuser,ou=people,dc=old,dc=example,dc=com
# Enter the wrong password and it fails correctly and server runs OK.
# Enter the right password and the client says:
ldap_result: Can't contact LDAP server (-1)
Server says (last few lines from slapd): [rw] bindDN: "uid=testuser,ou=people,dc=old,dc=example,dc=com" -> "uid=testuser,ou=people,dc=old,dc=example,dc=com" [rw] bindDN: "uid=testuser,ou=people,dc=old,dc=example,dc=com" -> "uid=testuser,ou=people,dc=new,dc=example,dc=com" => ldap_bv2dn(uid=testuser,ou=people,dc=new,dc=example,dc=com,0) <= ldap_bv2dn(uid=testuser,ou=people,dc=new,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=testuser,ou=people,dc=new,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=testuser,ou=people,dc=new,dc=example,dc=com)=0 => bdb_entry_get: ndn: "uid=testuser,ou=people,dc=new,dc=example,dc=com" => bdb_entry_get: oc: "(null)", at: "(null)" => bdb_entry_get: ndn: "cn=default,ou=pwpolicies,dc=new,dc=example,dc=com" => bdb_entry_get: oc: "(null)", at: "(null)" ==> hdb_bind: dn: uid=testuser,ou=people,dc=new,dc=example,dc=com send_ldap_result: err=0 matched="" text="" => bdb_entry_get: ndn: "uid=testuser,ou=people,dc=new,dc=example,dc=com" => bdb_entry_get: oc: "(null)", at: "(null)" Segmentation fault
However, queries against the "new" domain work:
ldapwhoami -x -W -D uid=testuser,ou=people,dc=new,dc=example,dc=com Enter LDAP Password: dn:uid=testuser,ou=people,dc=new,dc=example,dc=com
If I disable ppolicy in slapd.conf, queries agains the "old" domain work:
root@ldaptest1:/etc# ldapwhoami -x -W -D uid=testuser,ou=people,dc=old,dc=example,dc=com Enter LDAP Password: dn:uid=testuser,ou=people,dc=new,dc=example,dc=com
(the rewrite is not perfect - but that may not matter for my clients).
Almost certainly I have done something stupid - and it seems clear that ppolicy is being upset by the relay mappings. Any ideas how to fix would be *very* welcome - I have been all over Google and the man pages.
All the best!
Tim
OK - boring stuff:
slapd.conf ########################################### ####################################################################### # Global Directives:
# Features to permit allow bind_anon_cred bind_anon_dn update_anon
# Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel sync stats
sizelimit 5000 tool-threads 1
modulepath /usr/lib/ldap moduleload back_hdb moduleload back_relay moduleload rwm moduleload ppolicy
overlay rwm rwm-rewriteEngine on
backend hdb
####################################################################### # Global ACLs #
# Ensure read access to the base for things like # supportedSASLMechanisms. access to dn.base="" by * read
# The userPassword by default can be changed # by the entry owning it if they are authenticated. # This ACL must be first or password leakage will happen!!! access to attrs=userPassword,shadowLastChange by peername.path="/var/run/slapd/ldapi" manage by dn="cn=admin,dc=new,dc=example,dc=com" manage by set="user/uid & [cn=sysadmin,ou=groups,dc=new,dc=example,dc=com]/memberUid" write by self write by * auth
# The admin dn has full write access, everyone else # can read everything. Local unix domain socket (root only) # Can do everything access to * by peername.path="/var/run/slapd/ldapi" manage by dn="cn=admin,dc=new,dc=example,dc=com" manage by set="user/uid & [cn=sysadmin,ou=groups,dc=new,dc=example,dc=com]/memberUid" write by * read
####################################################################### # Main new.example.com authoritative database #
database hdb suffix dc=new,dc=example,dc=com
rootdn "cn=admin,dc=new,dc=example,dc=com" rootpw "{SSHA}NoNoNooo..."
directory "/var/lib/ldap" dbconfig set_cachesize 0 134217728 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on checkpoint 512 30
####################################################################### # # Password Policy # # overlay ppolicy ppolicy_default "cn=default,ou=pwpolicies,dc=new,dc=example,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext
####################################################################### # Virtual maps - compatibility with old.example.com only # # map dc=old to dc=new # database relay suffix "dc=old,dc=example,dc=com" relay "dc=new,dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=new,dc=example,dc=com" ###########################################
Initial database loaded with slapadd from this ldif: ########################################### dn: dc=new,dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: new.example.com dc: new
dn: cn=admin,dc=new,dc=example,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: NoNoNoooo...
dn: ou=people,dc=new,dc=example,dc=com objectClass: organizationalUnit ou: people
dn: ou=groups,dc=new,dc=example,dc=com objectClass: organizationalUnit ou: groups
dn: ou=pwpolicies,dc=new,dc=example,dc=com objectClass: organizationalUnit ou: pwpolicies
# # # Standard policy for normal people #
dn: cn=default,ou=pwpolicies,dc=new,dc=example,dc=com objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdMinAge: 0 pwdMaxAge: 15811200 pwdExpireWarning: 1814400 pwdGraceAuthnLimit: 3 pwdInHistory: 6 pwdCheckQuality: 2 pwdMaxFailure: 5 pwdMinLength: 8 pwdLockout: TRUE pwdLockoutDuration: 300 pwdFailureCountInterval: 300 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE
dn: uid=testuser,ou=people,dc=new,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: Test User employeeType: Staff gecos: Test User gidNumber: 1000 givenName: Test homeDirectory: /homes/testuser loginShell: /bin/bash mail: testuser@new.example.com sn: User uid: testuser uidNumber: 1000 userPassword: {SSHA}NoNoNoooo...
dn: cn=ddh-staff,ou=groups,dc=new,dc=example,dc=com objectClass: top objectClass: posixGroup cn: ddh-staff description: Test Group gidNumber: 1000 memberUid: testuser
dn: cn=sysadmin,ou=groups,dc=new,dc=example,dc=com objectClass: top objectClass: posixGroup cn: sysadmin description: Staff: System Admin Group gidNumber: 1001 memberUid: testuser
########################################### ########################################### ########################################### ########################################### ########################################### ###########################################
In my base, it was back-relay. back-ldap fixed the back-relay problem (with a performance degradation), but then I encountered oodles of problems with back-ldap, followed by back-meta, after which I was forced to scrap any hope of maintaining my legacy naming context without synchronization.
I started a bug report on one of them, but I was in the middle of a roll-out of the new directory infrastructure, and I never got back to all three problems.
Greg
On Tue, Dec 4, 2012 at 1:39 PM, Tim Watts tw@dionic.net wrote:
This is weird - quite possible a config problem, I'm hoping someone can spot it :)
I have a minimal slapd server which works fine with either an rwm/relay section or a ppolicy section - but not both at once.
I'm happy to explain *why* I need to do this if asked, but for now it would just clutter this message. I do have a Really Good(TM) reason.
On 04/12/12 22:02, Gregory Haverkamp wrote:
In my base, it was back-relay. back-ldap fixed the back-relay problem (with a performance degradation), but then I encountered oodles of problems with back-ldap, followed by back-meta, after which I was forced to scrap any hope of maintaining my legacy naming context without synchronization.
I started a bug report on one of them, but I was in the middle of a roll-out of the new directory infrastructure, and I never got back to all three problems.
Hi Greg,
Hmm..
In my case I would have to shelve ppolicy until all my clients had been converted - I have over 150 clients and 600 user accounts (under my control) but LDAP is not just used by PAM/NSS (if it were it would be easy) - there are undocumented usages in apache configs, Confluence, possibly webapps written in all manner of languages etc etc.
It's a real mess...
Cheers,
Tim
On Tue, Dec 4, 2012 at 2:08 PM, Tim Watts tw@dionic.net wrote:
In my case I would have to shelve ppolicy until all my clients had been converted - I have over 150 clients and 600 user accounts (under my control) but LDAP is not just used by PAM/NSS (if it were it would be easy)
- there are undocumented usages in apache configs, Confluence, possibly
webapps written in all manner of languages etc etc.
It's a real mess...
I agree. It was a real mess for me.
I can give you a quick rundown of what I encountered. I feel a bit guilty that I never submitted complete ITS reports, but I was too busy trying to recover from software that was suddenly crashing repeatedly and predictably once put into production.
back-relay and slapo-ppolicy, as you mentioned, crashed the server.
back-ldap and slapo-rwm would cause the server to crash if a certain malformed search filters were used (as a developer working on some code here discovered within the first day we were up and running.)
back-meta would cause the server to hang if there were an additional space in a search base (our old primary naming context was "o=lawrence berkeley laboratory,c=us" and a mail client user had "o=lawrence[space][space]berkeley lab,c=us" in his configuration.
Given some of the explanation I received after posting the first bug, I couldn't help but come to the conclusion that using any of the rewriting infrastructure in the wild was a bad idea. And that's where I ended up. So, we shortened the lifetime of our legacy naming context, wrote some additional synchronization tools, and just cranked up a new database with that content.
If you find a solution that works reliably, I'm all ears.
Greg
On 04/12/12 22:19, Gregory Haverkamp wrote:
back-ldap and slapo-rwm would cause the server to crash if a certain malformed search filters were used (as a developer working on some code here discovered within the first day we were up and running.)
Is back-ldap a proxy to another LDAP service?
I am wondering if I could make my new LDAP server just serve the new namespace and have a translating legacy proxy on another server.
ppolicy would only need to be on the new namespace server.
I could bulk update nss and pam configs so the legacy proxy would only need to serve edge cases until I hunt them down.
Does this sound possible? Cheers
Tim
On 12/04/2012 11:19 PM, Gregory Haverkamp wrote:
On Tue, Dec 4, 2012 at 2:08 PM, Tim Watts tw@dionic.net wrote:
In my case I would have to shelve ppolicy until all my clients had been converted - I have over 150 clients and 600 user accounts (under my control) but LDAP is not just used by PAM/NSS (if it were it would be easy)
- there are undocumented usages in apache configs, Confluence, possibly
webapps written in all manner of languages etc etc.
It's a real mess...
I agree. It was a real mess for me.
I can give you a quick rundown of what I encountered. I feel a bit guilty that I never submitted complete ITS reports, but I was too busy trying to recover from software that was suddenly crashing repeatedly and predictably once put into production.
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
If you consider more productive fix symptoms rather than fix the root cause, that's your problem.
back-relay and slapo-ppolicy, as you mentioned, crashed the server.
back-ldap and slapo-rwm would cause the server to crash if a certain malformed search filters were used (as a developer working on some code here discovered within the first day we were up and running.)
You seem to be one of the few complaining about that. If instead of whining you filed a report, it would have been fixed ages ago.
back-meta would cause the server to hang if there were an additional space in a search base (our old primary naming context was "o=lawrence berkeley laboratory,c=us" and a mail client user had "o=lawrence[space][space]berkeley lab,c=us" in his configuration.
Back meta rewrites the way you ask it to do. If you configure it to rewrite "o=lawrence[space]berkeley lab,c=us" don't whine if it fails to rewrite "o=lawrence[space][space]berkeley lab,c=us". Tell it to rewrite "o=lawrence[space]+berkeley lab,c=us" instead, and it'll do what you want. Machines tend to be as clever as users, seldom cleverer.
Given some of the explanation I received after posting the first bug, I couldn't help but come to the conclusion that using any of the rewriting infrastructure in the wild was a bad idea.
That's correct. It should be one's last resort to deal with poorly designed systems.
And that's where I ended up. So, we shortened the lifetime of our legacy naming context, wrote some additional synchronization tools, and just cranked up a new database with that content.
That's exactly what one is expected to do.
If you find a solution that works reliably, I'm all ears.
RTFM? p.
On 05/12/12 16:10, Pierangelo Masarati wrote:
You seem to be one of the few complaining about that. If instead of whining you filed a report, it would have been fixed ages ago.
That's rather uncalled for.
However, if you can tell me roughly what *useful* data would be required for a bug report, I will file one. But I do not have huge amounts of time and like Greg, I have the pressure to "get the job done".
back-meta would cause the server to hang if there were an additional space in a search base (our old primary naming context was "o=lawrence berkeley laboratory,c=us" and a mail client user had "o=lawrence[space][space]berkeley lab,c=us" in his configuration.
Back meta rewrites the way you ask it to do. If you configure it to rewrite "o=lawrence[space]berkeley lab,c=us" don't whine if it fails to rewrite "o=lawrence[space][space]berkeley lab,c=us". Tell it to rewrite "o=lawrence[space]+berkeley lab,c=us" instead, and it'll do what you want. Machines tend to be as clever as users, seldom cleverer.
Given some of the explanation I received after posting the first bug, I couldn't help but come to the conclusion that using any of the rewriting infrastructure in the wild was a bad idea.
That's correct. It should be one's last resort to deal with poorly designed systems.
In an ideal world my predecessors would not have left me such ****ed up systems. But there you go. Personally I need a translation layer to give me a phase-over period of some months to track down and remove all dependencies on the old schema - after that, I can "go clean" with a saner system :)
And that's where I ended up. So, we shortened the lifetime of our legacy naming context, wrote some additional synchronization tools, and just cranked up a new database with that content.
That's exactly what one is expected to do.
If you find a solution that works reliably, I'm all ears.
RTFM? p.
I did and it oddly enough does not really deal with random segfaults. As far as I can see, *I* am doing it pretty much by the book - and I think we are all agreed that daemons should not segfault even on bad config.
Again - happy to try to get to the root cause, but I am not fully confident that my config is 100% sane anyway, because of the way it combines two overlays, which are clearly unhappy with each other.
Cheers
Tim
--On Wednesday, December 05, 2012 6:22 PM +0000 Tim Watts tw@dionic.net wrote:
On 05/12/12 16:10, Pierangelo Masarati wrote:
You seem to be one of the few complaining about that. If instead of whining you filed a report, it would have been fixed ages ago.
That's rather uncalled for.
However, if you can tell me roughly what *useful* data would be required for a bug report, I will file one. But I do not have huge amounts of time and like Greg, I have the pressure to "get the job done".
http://www.openldap.org/faq/data/cache/59.html
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 05/12/12 18:42, Quanah Gibson-Mount wrote:
--On Wednesday, December 05, 2012 6:22 PM +0000 Tim Watts tw@dionic.net wrote:
On 05/12/12 16:10, Pierangelo Masarati wrote:
You seem to be one of the few complaining about that. If instead of whining you filed a report, it would have been fixed ages ago.
That's rather uncalled for.
However, if you can tell me roughly what *useful* data would be required for a bug report, I will file one. But I do not have huge amounts of time and like Greg, I have the pressure to "get the job done".
http://www.openldap.org/faq/data/cache/59.html
--Quanah
Thanks Quanah,
I have raised a ticket.
Now I will have to go and look for a workaround, which is either going to be:
Test ppolicy, then disable it for the interim until I get the clients using the new domain.
or
Try having the main server running a mint copy of the new domain/tree and have a second separate server acting as a translation gateway. The second server can go and die when the clients are fixed. The logs on the second server can be used to help nail down which clients are still using the old namespace.
Cheers
Tim
And the practical way to have a legacy namespace translation working together with a nice new LDAP server seems to be:
ldapmaster.example.com <- This is shiney, new namespace, ppolicy and anything else. It has no legacy crap on it at all.
ldaplegacy.example.com <- Translation server on different machine with a config roughly like:
slapd.conf ####################################################################### # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options.
####################################################################### # Global Directives:
# Features to permit allow bind_anon_cred bind_anon_dn update_anon
# Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args #loglevel config sync stats ACL parse loglevel sync stats
# The maximum number of entries that is returned for a search operation sizelimit 5000 tool-threads 1
# Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_ldap moduleload back_relay moduleload rwm
# TLS TLSCipherSuite SECURE256:!AES-128-CBC TLSCACertificateFile /etc/ssl/certs/CA-example.com.pem TLSCertificateFile /etc/ldap/ssl/ldaplegacy.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/ldaplegacy.example.com.key
# Overlays overlay rwm rwm-rewriteEngine on
backend ldap
####################################################################### # Global ACLs #
# Note - we are read only as we are a legacy translation proxy. by * auth
# The admin dn has full write access, everyone else # can read everything. Local unix domain socket (root only) # Can do everything access to * by * read
####################################################################### # Main example.com relay #
database ldap suffix dc=new,dc=example,dc=com uri ldap://ldapmaster.example.com/
####################################################################### # Virtual maps - compatibility with cch.kcl.a.cuk only #
# # These are all used by old apache + mod_ldap configs #
# # map ou=staff,dc=old to dc=new # database relay suffix "ou=staff,dc=old,dc=example,dc=com" relay "dc=new,dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=new,dc=example,dc=com" # # map ou=external,dc=old to dc=new # database relay suffix "ou=external,dc=old,dc=example,dc=com" relay "dc=new,dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=new,dc=example,dc=com"
# Ensure read access to the base for things like # supportedSASLMechanisms. access to dn.base="" by * read
# The userPassword by default can be changed # by the entry owning it if they are authenticated. # This ACL must be first or password leakage will happen!!! access to attrs=userPassword,shadowLastChange
######################################################################
It's limited - no write passthough - but that's not a problem for me. I can switch NSS and PAM linux clients over to the new schema and server fairly easily. This is a catchall for the misc crap - and once I have enough logging enabled I will be able to locate what is asking for what LDAP records and hunt down the remaining bad config.
Then when the legacy stuff is gone, ldaplegacy gets turned off - no changes to ldapmaster - simples :)
--On Thursday, December 13, 2012 5:30 PM +0000 Tim Watts tw@dionic.net wrote:
And the practical way to have a legacy namespace translation working together with a nice new LDAP server seems to be:
ldapmaster.example.com <- This is shiney, new namespace, ppolicy and anything else. It has no legacy crap on it at all.
ldaplegacy.example.com <- Translation server on different machine with a config roughly like:
Seems like a good solution. I had to run two environments in parallel once, that was a pain. ;)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Gregory Haverkamp -
Pierangelo Masarati -
Quanah Gibson-Mount -
Tim Watts