Main Nav

All,

At Green Mountain College, we are about to recommend a move from onsite Exchange to Google Apps for Edu and are beginning work on our roll out plan.  As part of that plan, we would like to make it so that all of our systems (Moodle, Jenzabar EX, JICS, Active Directory) have the same usernames and passwords.  All of those systems currently have their own username and passwords.

What are other colleges/universities doing to handle this?  Integrating into our onsite AD has been discouraged because our power and telecom services are less that reliable enough to achieve > 96% uptime (let alone 99%). 

--
Jesse Safran
Sr. Desktop Supervisor/Assist. Network Admin
Green Mountain College
1 Brennan Circle
Poultney, VT 05764
802-287-0105 (Cell)
802-287-8264 (IT Computer Support Line)
safranj@greenmtn.edu
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

We use NETIQ (used to be Novell) Identity Manager with the Google module/driver for provisioning and syncing passwords to Google.  For other pieces such as Moodle we use LDAP.


Message from gibson_brian@wheatoncollege.edu

We use Active Directory to authenticate as many applications as we can (Moodle, Equitrac Print/Copy management and Luminis's CAS server to name a few) and we have a PHP web front end where users can change their AD password and it replicates the password out to Google using the APIs.


On 3/29/2013 10:56 AM, Alan Nord wrote:
We use NETIQ (used to be Novell) Identity Manager with the Google module/driver for provisioning and syncing passwords to Google.  For other pieces such as Moodle we use LDAP.


We have a mixed approach. Reset password is a PHP app that changes the password in AD. Then the SSO code has a hook that actually resets the password on Google. Upon every login, it checks to see if the user's recent password change in AD is more recent than the last time it reset the password on Google successfully (it consults a MySQL table). 

We did this because until recently the reset password app was tied at the hip to Oracle Identity Manager and we didn't want to touch it. We just implemented a home grown identity management and the reset code will do the changes in both AD and Google to avoid the overhead of having to check every time someone logs in (though it tends to be more failsafe - for eg. if somehow reset succeeded in AD reset, but failed in Google reset, you need to find a way to solve this problem).


-- Ravi
CIO & Associate Dean for WellesleyX, Wellesley College
Google Voice - 860-631-RAVI


At USC, we use Kerberos as the underlying password repository,
driving by a Sun SJES LDAP 5 to control access (both authentication and authorization).
All our infrastructure, Active Directory, NIS domain, VPN, Google Apps, etc. integrate with Kerberos/LDAP

For the Google Apps component, we developed modules (written in Java/JSP/Spring) to provision accounts and maintain/sync passwords between our system and Google.

With the above set up, we have implemented a SSO strategy for both web and non-web systems.

Here's a 2008 Internet 2 presentation from our Identity Services Architect, Brendan Bellina.
    http://goo.gl/RzD4o

Linh Pham
Systems Analyst
University of Southern California
213-821-3118


On 3/29/13 8:32 AM, Ravi Ravishanker wrote:
We have a mixed approach. Reset password is a PHP app that changes the password in AD. Then the SSO code has a hook that actually resets the password on Google. Upon every login, it checks to see if the user's recent password change in AD is more recent than the last time it reset the password on Google successfully (it consults a MySQL table). 

We did this because until recently the reset password app was tied at the hip to Oracle Identity Manager and we didn't want to touch it. We just implemented a home grown identity management and the reset code will do the changes in both AD and Google to avoid the overhead of having to check every time someone logs in (though it tends to be more failsafe - for eg. if somehow reset succeeded in AD reset, but failed in Google reset, you need to find a way to solve this problem).


-- Ravi
CIO & Associate Dean for WellesleyX, Wellesley College
Google Voice - 860-631-RAVI


We use a custom web page which sets our AD and Google passwords at the same time. The page returns whether the password was set successfully, or if it failed in AD or Google Apps. Users can set their AD and Google passwords to be separate, but most use the same one. 

Rurik


That you all for your responses!  In reply to a couple of the comments:

  1. "If local uptime is a concern, you should consider hosting a backup AD server elsewhere" - Agreed and this is something we are beginning to explore as part of this process.  Where and how much $ will be large concerns.  Until this year, we only had about 20MB of bandwidth available for use, so hosting anything offsite was a concern.  Fiber finally made it to our campus and 400MB changes this conversation pretty quickly.
  2. For those of you using home built software, have any of you open sourced it or made it available at all?  If so, can you let me (and the list) know where we can take a look at it?

Thank you, again!

-Jesse



All,

At Green Mountain College, we are about to recommend a move from onsite Exchange to Google Apps for Edu and are beginning work on our roll out plan.  As part of that plan, we would like to make it so that all of our systems (Moodle, Jenzabar EX, JICS, Active Directory) have the same usernames and passwords.  All of those systems currently have their own username and passwords.

What are other colleges/universities doing to handle this?  Integrating into our onsite AD has been discouraged because our power and telecom services are less that reliable enough to achieve > 96% uptime (let alone 99%). 

--
Jesse Safran
Sr. Desktop Supervisor/Assist. Network Admin
Green Mountain College
1 Brennan Circle
Poultney, VT 05764
802-287-0105 (Cell)
802-287-8264 (IT Computer Support Line)
safranj@greenmtn.edu
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

We use NETIQ (used to be Novell) Identity Manager with the Google module/driver for provisioning and syncing passwords to Google.  For other pieces such as Moodle we use LDAP.


Message from gibson_brian@wheatoncollege.edu

We use Active Directory to authenticate as many applications as we can (Moodle, Equitrac Print/Copy management and Luminis's CAS server to name a few) and we have a PHP web front end where users can change their AD password and it replicates the password out to Google using the APIs.


On 3/29/2013 10:56 AM, Alan Nord wrote:
We use NETIQ (used to be Novell) Identity Manager with the Google module/driver for provisioning and syncing passwords to Google.  For other pieces such as Moodle we use LDAP.


We have a mixed approach. Reset password is a PHP app that changes the password in AD. Then the SSO code has a hook that actually resets the password on Google. Upon every login, it checks to see if the user's recent password change in AD is more recent than the last time it reset the password on Google successfully (it consults a MySQL table). 

We did this because until recently the reset password app was tied at the hip to Oracle Identity Manager and we didn't want to touch it. We just implemented a home grown identity management and the reset code will do the changes in both AD and Google to avoid the overhead of having to check every time someone logs in (though it tends to be more failsafe - for eg. if somehow reset succeeded in AD reset, but failed in Google reset, you need to find a way to solve this problem).


-- Ravi
CIO & Associate Dean for WellesleyX, Wellesley College
Google Voice - 860-631-RAVI


At USC, we use Kerberos as the underlying password repository,
driving by a Sun SJES LDAP 5 to control access (both authentication and authorization).
All our infrastructure, Active Directory, NIS domain, VPN, Google Apps, etc. integrate with Kerberos/LDAP

For the Google Apps component, we developed modules (written in Java/JSP/Spring) to provision accounts and maintain/sync passwords between our system and Google.

With the above set up, we have implemented a SSO strategy for both web and non-web systems.

Here's a 2008 Internet 2 presentation from our Identity Services Architect, Brendan Bellina.
    http://goo.gl/RzD4o

Linh Pham
Systems Analyst
University of Southern California
213-821-3118


On 3/29/13 8:32 AM, Ravi Ravishanker wrote:
We have a mixed approach. Reset password is a PHP app that changes the password in AD. Then the SSO code has a hook that actually resets the password on Google. Upon every login, it checks to see if the user's recent password change in AD is more recent than the last time it reset the password on Google successfully (it consults a MySQL table). 

We did this because until recently the reset password app was tied at the hip to Oracle Identity Manager and we didn't want to touch it. We just implemented a home grown identity management and the reset code will do the changes in both AD and Google to avoid the overhead of having to check every time someone logs in (though it tends to be more failsafe - for eg. if somehow reset succeeded in AD reset, but failed in Google reset, you need to find a way to solve this problem).


-- Ravi
CIO & Associate Dean for WellesleyX, Wellesley College
Google Voice - 860-631-RAVI


We use a custom web page which sets our AD and Google passwords at the same time. The page returns whether the password was set successfully, or if it failed in AD or Google Apps. Users can set their AD and Google passwords to be separate, but most use the same one. 

Rurik


We use Shibboleth for authentication for most of our web services with AD as the directory source/password repository.  If local uptime is a concern, you should consider hosting a backup AD server elsewhere, whether that's with a cloud service provider like Amazon or find another college who would exchange some rackspace.  

--
Brad Christ
Chief Information Officer
Southern Oregon University



********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.