Going Google - Authentication - Password Options

Many schools deploy Google Apps for Education as an additional service. Teachers and perhaps students have a system username and password and an additional account and password for the G-Apps access.

Switching to Google Apps for Education for all staff as our primary email and groupware communications presents several challenges.

In our current setup accounts are created in our directory service. Users in a particular group, in our case the Staff group, receive email account as well. The directory username and password are the same for system log-in and email access. So network administrators need only provide one account.

Adding Google Apps for Education creates the need for an additional account. Ideally network administrators would continue to create accounts in the directory service and accounts would be synchronized to Google Apps. This service is available and is called Google Apps Directory Sync.
When network or system administrators create a staff account a corresponding Google Apps account is created. When accounts are suspended or deleted, Google Apps accounts are suspended/deleted in turn.

There is one drawback Google Apps Directory Sync tool, directory passwords are not passed from your local directory service to Google Apps for Education. (Yes, there are APIs and service providers to assist with this.) So users would have one username and two independent passwords, one for system log-in and another for email. The passwords are independent and the staff member controls each one separately.

To minimize password problems and ideally provide one username and password combination we've tried a few things:

Option 1: We set up an open source central authentication system or CAS. (Special thanks to Kris Hagel for his step-by-step directions and his willingness to assist.) The CAS server is tied to our directory services for authentication and then tied to Google Apps with a one-to-one correspondence. When a staff member attempts to log into their email the authentication request is re-routed to your CAS server. The authentication process proceeds locally and is then handed off to Google Apps. VERY SLICK solution. There are a few drawbacks and some VERY compelling benefits to this solution. One of our network administrators invested many hours implementing this solution. Thanks, Brian!
Drawbacks:

• CAS requires a local server (virtual server in our case), 
• The open source solution has informal support only
• If the District has a power failure then even home or mobile users cannot authenticate. The CAS server is a single point of failure. 
• Passwords are never actually transferred to Google Apps

The benefits of a CAS server are that it can be tied to multiple online systems such as your Moodle server, Wikispaces private label, your web-based SIS, Mahara, ... etc.

Option 2: We also are looking at a .dll and registry hack on our directory domain controllers that would take the users password, encrypt it and store it in another contact field. Upon directory sync as discussed above the password would be pushed to Google Apps for Education. I'm rarely a fan of registry hacks and custom .dlls on domain controllers. The drawback here is that the solution seems that it's still being developed. We've read reports that it only syncs passwords after system administrators reset the password and NOT when users initiate the password change. A recipe for problems in my opinion.

Option 3: is to do nothing. Allow staff members have two independent accounts. One for active directory and the other for email. The accounts will have the same username. They may set the passwords differently or the same. It is up to the user. The drawback here is that password management is done in two systems for network administrators.

We're as yet undecided. What would you do?