[dev] Active Directory Development

[Ben Klang]

Please see my comments inline below:


On Jan 18, 2008, at 11:40 AM, Mike Peachey wrote:

> I am looking for some advice.
>
> I am attempting to put get horde-webmail-1.0.4 going in a production
> environment with Authentication and Grouping based on Active Directory
> from a Win2003 AD server. The problem is there are a lot of changes I
> need to make to make it properly compatible.
>
> For example, in Groups/ldap.php, the function getGroupMemberships
> searches LDAP groups for member=username when in AD this is served  
> up as
> member=User's full DN. My temporary solution to this is to add a third
> parameter that is false by default in getGroupMemberships, and then  
> when
> the group memberships are requested in services/shares/edit.php, I  
> pass
> the third parameter $auth->_findDN(Auth::getAuth()) to correctly  
> search
> for groups.
You should have a checkbox option on the Group configuration tab  
named "attrisdn".  This switch makes the Group_ldap driver use DNs  
instead of usernames for gorup membership.

>
> The problem with this one is that I don't yet know where else in the
> code I am going to have to make changes to allow for this, and once I
> do, I am going to have to document every single change and then re- 
> make
> them when the system is upgraded.
>
> There is another one that I haven't started on yet which is nested
> groups in Active Directory. Currently, Horde will search for group
> memberships only at one level, but I need it to check for group  
> members
> that are groups, and then recursively search through them too. But
> before I start on this task, I'd rather ensure that my changes have a
> chance of making it into the Horde source, or at least make the  
> changes
> AROUND the current source, so that when I upgrade at a later date, the
> changes will remain or will be easy to replace.
>
I have a patch written in my environment which will enable this  
functionality.  I would be happy to speak with you offline about this  
patch as it was rejected from mainstream Horde for architectural  
reasons.  We hope to revisit it in Horde 4.0.

> I have two problems with this:
>
> 1. Because I'm not totally familiar with the design structure of  
> Horde,
> it is going to take me a while to actually work out HOW I should be
> doing things and how certain modules are extending each other and what
> public functions I should be aware of. For example, in creating a new
> section of code or making specific changes to functions to take  
> account
> of AD compatibility, I don't know whether I should be adding a  
> whole new
> authentication module called AD as a selectable option instead of ldap
> and pam and the rest, or whether I should be adding a true/false
> condition within the current LDAP structure that says "this LDAP
> is/isn't an AD server".
>
You should actually not need to make such large-scale changes.  I  
have a couple working environments that meet your stated goals  
exactly.  The only difference is that my environments are "regular"  
LDAP as opposed to AD, but functionally, other than small  
workarounds, they work the same.

> 2. I'm currently working on the source of horde-webmail-1.0.4 which is
> already out of date, if I'm going to develop new code for the project
> (assuming I'm even allowed to) then I should be working out of the
> current CVS HEAD. The problem with this is that, at the same time, I'm
> still trying to run Horde in a production environment and I don't know
> how likely I am to come across really serious bugs within the current
> source that are going to adversely affect users.
If you intend on writing code for the Horde 3.x branch (sometimes  
called FRAMEWORK_3) then you can develop against the lowest version  
for which you wish to be compatible.  Code written against FW_3 will  
always be forward compatible with the FW_3 branch.  That is to say,  
if an application was written against Horde 3.0.0 it will still  
function correctly with Horde 3.2.0.  This is subject to change with  
Horde 4.0, but that isn't even into the alpha stage yet.  However if  
you choose to write against Horde 3.1, the application is not  
guaranteed to be compatible with Horde 3.0.  If you develop against  
CVS HEAD, you are not guaranteed compatibility with any release  
except possibly future ones.

And yes, not only are you "allowed" to develop new code, but we  
encourage it :)

Please note that the Horde Webmail edition is based on FRAMEWORK_3.
>
> I could really do with some advice here - I'm not used to contributing
> to projects, usually I'm just making subtle changes to integrate  
> things
> into our environment (such as the hell I had with customising RT) -  
> but
> the number of changes that I need to make for Horde AD integration  
> means
> it's really worth my while trying to properly help out with the  
> project
> as a whole for my benefit and everyone else's.

If you are considering stepping up your contributions I would suggest  
to you that you might find the conversation in #horde-dev of  
Freenode's IRC network to be helpful.  In that channel you can speak  
with some of the Horde developers directly.  Alternatively you can  
post here to reach a wider potential audience.  Finally there is good  
documentation in the Horde Wiki (http://wiki.horde.org), in the API  
documentation (http://dev.horde.org), and in the comments of the  
source code itself.

>
> My mind is hanging by a thread now thanks to that large section of
> verbal diarrhoea, so I shall stop now - but if someone could get  
> back to
> me about this I'd really appreciate it.
> -- 
> Kind Regards,
>
>
Good luck and I look forward to working with you.

/BAK/
-- 
Ben Klang
Alkaloid Networks LLC
ben at alkaloid.net
404.475.4850
http://projects.alkaloid.net