Try

[versions]
zc.buildout = 1.4.1

and then running bin/buildout -n once.

I have not confirmed this, but if I’m right, I think the best solution is to change logged_out to display a link to the login page, rather than the login form. Another option is to leave users in HTTPS mode when logging out.

In my typical use case, I create a Plone OU in AD, put new groups that Plone needs into it, and populate those groups with my AD users. Non-AD users get entered directly into Plone.

You might want to consider a centralized LDAP tool for managing user data, and Plone for all lookups (cached, of course).

In fact, AD is only in the mix because of our campus single sign on system. It forces the users to change their passwords every 3 months, has a good password policy, etc. And it’s ubiquitous. :)

We do definitely want users to be able to update their own info, my concern is for Samba stuff. We deal with Private Health Information so we have to be extra careful.

Thanks!!

And incidentally, it looks like we may be in the same area of study!

I haven’t done a lot with LDAP in the past, but I had a feeling it wouldn’t be ideal for storing application data. Thanks for confirming that.

I will definitely check out GUM, if we end up using it here we’ll be happy to help with that TODO list :)

That said, you do make an excellent point. When I added the requirement for Samba access, it was without any critical discussion. My boss said “we need to add these people to our website” and I said “OK, will they need Samba access too” and he said “yes”… and so a requirement was born :P

I need to talk to him again and clarify exactly what sort of access is really required; I need to get some specific cases out of him. I’ll be surprised if Plone couldn’t handle all of it.

Thanks :)

Often the most cost-effective solution is to rethink the problem and recheck the set of the absolutely critical minimum requirements, rather than jumping into implementation.

In our organization we have Plone sites, other web apps, and all the major os’es (Linux, Windows and Mac). We have LDAP servers and ActiveDirectory servers for auth/auth.

The LDAP for filesystem/server access uses a different set of accounts than we use for logging into web applications. This is because not all the web apps are over https, so we don’t want to comprise network security with user’s who are lax about their web passwords. Since the web-accessed content is less sensitive, we allow user’s to set weaker passwords themselves as well (for better-or-worse, I imagine some user’s just re-use their network password for web).

One set of accounts is chosen to contain additional user data (doesn’t really matter that much if it’s AD, network LDAP or web LDAP, just pick one – we use the web LDAP). Then we point Linux and Mac mail clients to that LDAP source so that user’s can do address autocompletion in their mail client. Then we sync nightly that data using a simple Python script into the corresponding fields in AD so that Windows users can access address information in Outlook (although this app has no autocomplete with networked address books, but it’s no surprise that Outlook is a pretty poor mail client).

For updating the main user and group data, I looked at many of the available LDAP and AD management tools, and didn’t really find them satisfactory. I do use phpLDAPadmin as an internal sysadmin-only tool for exploring/poking-at the different LDAP and AD servers. But all of LDAP and AD management tools are terribly generic, which gives them awful usability. I wanted a tool with the following criteria:

* Only present the fields that we are interested in managing

* Don’t use only the default help text for the LDAP schemas (we use inetOrgPerson as a base). This text is too generic and needs to be made more user-friendly in order to be useable by a project manager or admin secretary.

* Web-based: installing a GUI tool across Windows, Mac and Linux workstations is way to much work. A sngle web apps are much easier to deploy than three different types of clients across 250 workstations.

Since I couldn’t find a tool I liked, I wrote my own :)

http://www.bcgsc.ca/platform/bioinfo/software/gum

It’s actually worked out really well, since user’s really like that they have stable URLs they can reference to see who exactly belong to a specific group or viewing a person’s user account details. And we can delegate updates access to whomever we like. Originally I attemtped to provide fine-grained access to allowing people to only update certain accounts or certain groups, but found that was becoming a big hassle and there were way too many corner cases. So instead I just made a single role for all edits, and then just log all edits performed through GUM into the ZODB. In this way, we can see if anyone is doing any “problematic” edits (which is really super-rare), and having an edit history can be invaluable with employee turn-over and trying to figure out who/why certain accounts got like they did!

Since it’s written in Grok, I’ve also found that the Zope Component Architecture works well for creating a plug-in system, so GUM also makes a good place to hang an assortment of synchronization and assorted management scripts that I’ve written to help push data around to different places, etc.

For dealing with additional user data, that isn’t covered by a common LDAP or AD schema, I’ve tinkered with extending our inetOrgPerson schema objects with an additional custom schema. But I’ve found dealing with LDAP is generally quite a bit of hassle – documentation tends to be poor, writes are non-transactional, and the python-ldap api isn’t as comfortable to use as writing to whatever you’re happiest with for managing ad-hoc data, and finally you need to be more careful about updating LDAP since it sucks to take down *everything* in your organization because you’re just trying to restart the LDAP servers to update the schema for some inconsequintial field. For ad-hoc user data, I use the ZODB, since I’m really comfortable with it, and it’s super easy to use – then just add some custom Views in a seperate distribution installed alongside our GUM app instance. But using a relational db would work just as well if that’s what your comfortable with.

Finally we use the old school, “PasswordResetTool” for Plone to allow external collaborators the chance to change their web-only passwords themselves.

As for our groups, we have a single group source in LDAP, but groups only store Title, Id, and List of User Accounts. So we have a tonne of groups that are still isolated and need to be manually updated and are perpetually out-of-sync (e-mail groups, issue tracker groups, posix groups). Tackling groups in a more one-stop automated fashion is still on the to-do list.

You may not need quite that level of indirection now that Plone has support for multiple authentication sources in PAS, though Samba might necessitate it.

The simplest solution would be to just setup a new LDAP for your non-AD users and groups and use these group memberships for permissions in Samba.

I wouldn’t be overly worried about using Plone to administrate your local users and groups, but you may find an dedicated LDAP admin tool such as phpLDAPadmin or Apache Directory Studio to be more suitable (it probably depends who does the administration). Having local users be able to update their own metadata through Plone can be a great time saver.

You will need to ensure you have a scheme to avoid potential userid conflicts (ldap rewriting might be necessary here), as you have no control over users subsequently added to the Active Directory.