[dijichi2]

I have an SVN service that I could make available without using my internal VPN. I could either open it with Cisco VPN client access or use https externally with authentication. (There is some security behind watching and checking). If that would help others I would consider that for the project.

svn tree must come from zimbra themselves. starting a new svn tree is like forking the code - the opposite to what we need. we want the official svn tree reopened so we can develop against a tracked tree. 3rd-party development of zimbra is extremely difficult/time consuming without this, which is why I keep banging on about it in the vain hope zimbra might fix it, and probably why there is very little community development at the moment.

To reiterate - The goal should be to make ZCS directory service agnostic and thus allow the customer to chose whether to integrate (leverage) the existing user data within an existing repository or to use a repository of choice (that suits the customers identity management goals) without the need for messy meta or sychroniziation tools. Do you agree with that statement?

You're confusing two seperate issues here. The first issue is making Zimbra directory agnostic. The second issue is allowing non-zimbra use of the zimbra directory server, either in the zimbra controlled DIT or outside of it on a seperate DIT. The two issues do not have to be dependent of each other and are valid, and indeed important seperate goals.

Making Zimbra directory agnostic shouldn't be a big deal - most LDAP is done inband through standard protocols, the difficult bit will be making the OpenLDAP-specific script stuff generic, and possibly handling the implementation differences in how LDAPv3 protocol is interpreted.

Allowing non-zimbra use of zimbra DIT is a much bigger issue, if you think about it how do you deal with schema changes, nonstandard class and attribute design etc? This has always put people off using zimbra to control other systems, eg. Samba. Currently I use an entire FDS instance just for Samba and have zimbra do external auth against that - a messy kludge. Recently Greg from Zimbra has pointed us in the right direction with his Samba zimlets and setup. It's worth analyzing and discussing how this has been implemented and how this method can be extended to other systems.

After the install I went into use slapcat to spit the database out to ldif (everything not just what someone wants you to see) and I started to find funny (VERY NOT FUNNY) changes to the core schema. Haven't worked out how tragic this is but I get a bad feeling here as userPasswd and uid are two of them. I have spent most of my professional life working in directories and identity related fields. Directory design for scale and performance, identity management, security, user store sychronization. Fixing the crap from some bonehead who has adjusted the core LDAP schema for his purpose whatever and now can't make it work well across the empire. ####heads who have decided to create their own schema becaue they could.

Well no, core schema should never be altered but are you sure it has been? I haven't looked at the zimbra alterations, but make sure it's not just differences in OpenLDAP versions. OpenLDAP has a long history of point-release schema fixes that makes life fun. It's entirely possible zimbra places old schemas against updated versions of OpenLDAP without tracking them correctly (pure conjecture, just guessing).

Another nasty is the Zimbra requirment to search the directory as an anomymous user. I have never met a medium or large company yet who would allow anonymous access to user data no matter how inoxious it may seem such as mail, cn, sn, givenName or title.

To the outside, absolutely, in fact I remember whining very early on in these forums about the same issue. However, because the main zimbra LDAP runs on standard port 389, it restricts certain attributes through ACLs and allows the rest through for GAL access. Personally I don't feel this is a very good way of doing this, it would be much nicer for instance to move main LDAP tree to a nonstandard port as is done with SQL, and then expose the GAL and personal addressbooks on the standard port on a much restricted LDAP tree.

Any company should block 389 to the outside world. Internally as long as ACLs are reasonable it is often considered acceptable to allow anon binds - I have seen some large companies do this.