You definitely want all of your validation and authentication to occur at the lowest common denominator point. You don't want to put heavy authentication on one front-end only to have a hole or weak authentication on another front-end. Better to use a common scheme on the back-end (LDAP) and allow the front-ends to just use what's there. It greatly reduces complexity (usually) and is significantly more robust.

I'm a bit unclear why you can't use ACL's (ACI's) in LDAP to do this. Generally you would have the user authenticate against the LDAP database (e.g. by binding to it using their distinguished name) first, and then when they're authenticated, try to do operations as that user (e.g. changing their password). I've only had a small amount of experience with ACI's with a couple of LDAP platforms, but they seemed similar enough for me to think they were the same syntax, but I may not have been looking close enough.

So basically, it seems to me that you should be able to do this by putting all of your access control and authentication in LDAP. Not sure though..

Note that
1. There is no problem with auth. It works quite well. The real problem is autz.
2. When I'm generating 'modify user preferences' dialog on front-end I want to include 'Change passoword' button if and only if a user can change that password. And how can I know if user 'foo' can change password for user 'bar'? User foo is maybe an admin, and he can. But application does not know this and does not know whether to display 'change password' button or not. The only how to resolve it is to change a password, and I definitely do not want to do this in dialog generation (not dialog processing) phase.
3. Overhead. Imagine Customer object in LDAP. There are billing information, sales information, and admin information in this single object. I want different users to have access to different parts of this object. I want to display changable fields as real inputs and read-only fields as normal non-editable text. If I would try to change every possible attribute in LDAP prior to displaying a simple HTML INPUT, it will take years to complete a single request. (Remember, LDAP is read optimized, writes are sloooow).

So let me get this straight: you want users to be able to modify LDAP data directly and you want a nice easy web interface to do the same, with consistent validation and access requirements?

So right off the bat, you have to implement ACI's in LDAP. There's no way around that if you want direct LDAP access. The trick is exploring those ACI's to provide a meaningful user interface, right? I don't know of any way to do this in LDAP, but others might. This was probably your original question, so I apologize for not picking up on that.

With respects to overhead, there are certain optimizations you can do, such as checking to see if the value given differs from the value stored before attempting to change it, etc. Do you expect to be doing a lot of updates such that time is a factor? If so, perhaps LDAP isn't the best choice here. A real relational database might be acceptable, but practicality may require you to push your access control into your application (though I think most if not everything can be done in a decent database package, even if it's cumbersome), which means you don't want users to directly update their stuff. If you wanted to keep a read-only LDAP copy, you could do that and update it at intervals.

I believe that ACI's can be fetched from the LDAP server, and though I alluded to it in my previous post, I believe ACI's are also standard across most LDAP platforms. So in theory, you should be able to fetch them and parse them locally and use that information to determine whether or not the user can edit that piece of entry. Sounds daunting, I know. It would be great if LDAP has a "can a user do this" operation, and maybe it does; I don't know.