| Prev | Installation | Next |
|---|
ToDo:�Add/verify information on on-demand sync, account registration, and batch synchronization. Add section on ldapsearch.
Overview.�You do not want to make users remember yet another password and username. If you can avoid it you do not want to store their passwords either. This document should help you set your system up so your users can seamlessly log in to your OpenACS instance using the password they are accustomed to using for other things at your institution.
Background.�The original OpenACS LDAP implementation (which has been depreciated by this package) treated the LDAP server as another data store similar to Oracle or Postgresql. It opened a connection using a priveleged account and read or stored an encrypted password for the user in question. This password was independent of the user's operating system or network account, and had to be synchronized if you wanted the same password for OpenACS.Save their passwords? Sync passwords? Deal with forgotten password requests? No Thanks. Using ldap bind, you can delegate authentication completely to LDAP. This way you can let the IT department (if you are lucky) worry about password storage/synchronization/etc. The bind operation takes a username and password and returns a true of false depending on whether they match up. This document takes the 'bind' approach so that your users LDAP/AD password (or whatever else you use) can be used to login to OpenACS.
Note on Account Creation.�On the authentication driver configure screens, you will also see lots of options for synchronizing users between your directory and OpenACS. This document takes the approach of provisioning users on demand instead of ahead-of-time. This means that when they attempt to login to OpenACS, if they have a valid Windows account, we'll create an account for them in OpenACS and log them in.
ToDo: Add/verify information on on-demand sync, account registration, and batch synchronization. Add section on ldapsearch.
Overview. You do not want to make users remember yet another password and username. If you can avoid it you do not want to store their passwords either. This document should help you set your system up so your users can seamlessly log in to your OpenACS instance using the password they are accustomed to using for other things at your institution.
Background. The original OpenACS LDAP implementation (which has been depreciated by this package) treated the LDAP server as another data store similar to Oracle or Postgresql. It opened a connection using a privileged account and read or stored an encrypted password for the user in question. This password was independent of the user's operating system or network account, and had to be synchronized if you wanted the same password for OpenACS.Save their passwords? Sync passwords? Deal with forgotten password requests? No Thanks. Using ldap bind, you can delegate authentication completely to LDAP. This way you can let the IT department (if you are lucky) worry about password storage/synchronization/etc. The bind operation takes a username and password and returns a true of false depending on whether they match up. This document takes the 'bind' approach so that your users LDAP/AD password (or whatever else you use) can be used to login to OpenACS.
Note on Account Creation. On the authentication driver configure screens, you will also see lots of options for synchronizing users between your directory and OpenACS. This document takes the approach of provisioning users on demand instead of ahead-of-time. This means that when they attempt to login to OpenACS, if they have a valid Windows account, we'll create an account for them in OpenACS and log them in.
Installing AOLserver LDAP support (openldap and nsldap). Install openldap and nsldap using the document Malte created Next, modify your config.tcl file as directed in the nsldap README. Here's what the relevant additions should look like:
# LDAP authentication
@@ -30,9 +30,9 @@
[10/Jan/2006:11:11:08][22553.3076437088][-main-] Debug: nsldap: adding pool ldap to the list of allowed pools
[10/Jan/2006:11:11:08][22553.3076437088][-main-] Debug: nsldap: Registering LDAPCheckPools (600)
- auth-ldap + driver installation.�Next, visit the software installation page in acs-admin and install the auth-ldap package. Your OpenACS installation now has all the code required to authenticate using nsldap, so now you need to configure your site's authentication to take advantage of it. To add the authentication driver to your OpenACS instance, go to: Main Site, Site-Wide Administration, and then AuthenticationHere's some sample Authentication Driver values:Name=Active Directory, Short Name=AD, Enabled=Yes, Authentication=LDAP, Password Management=LDAPYou may wish to push this new authority to the top of the list so it will become the default for users on the login screen.Next, you have to configure the authentication driver parameters by going to: Main Site, Site-Wide Administration, Authentication, Active Directory, and then ConfigureParameters that match our example will look like:UsernameAttribute=sAMAccountNMame, BaseDN= cn=Users,dc=mydomain,dc=com, +
auth-ldap + driver installation. Next, visit the software installation page in acs-admin and install the auth-ldap package. Your OpenACS installation now has all the code required to authenticate using nsldap, so now you need to configure your site's authentication to take advantage of it. To add the authentication driver to your OpenACS instance, go to: Main Site, Site-Wide Administration, and then AuthenticationHere's some sample Authentication Driver values:Name=Active Directory, Short Name=AD, Enabled=Yes, Authentication=LDAP, Password Management=LDAPYou may wish to push this new authority to the top of the list so it will become the default for users on the login screen.Next, you have to configure the authentication driver parameters by going to: Main Site, Site-Wide Administration, Authentication, Active Directory, and then ConfigureParameters that match our example will look like:UsernameAttribute=sAMAccountNMame, BaseDN= cn=Users,dc=mydomain,dc=com, InfoAttributeMap=first_names=givenName;last_name=sn;email=mail, -PasswordHash=N/A
Code Tweaks for Bind.�Bind-style authentication is not supported via configuration parameters, so we will have to modify the tcl authentication routine to provide this behavior.You'll have to modify the existing ./packages/auth-ldap/tcl/auth-ldap-procs.tcl file to support bind authentication.First toggle ldap bind support.Change this:
+PasswordHash=N/A
Code Tweaks for Bind. Bind-style authentication is not supported via configuration parameters, so we will have to modify the tcl authentication routine to provide this behavior.You'll have to modify the existing ./packages/auth-ldap/tcl/auth-ldap-procs.tcl file to support bind authentication.First toggle ldap bind support.Change this:
# LDAP bind based authentication ?
set ldap_bind_p 0
@@ -65,4 +65,4 @@
set result(auth_status) ok
}
- Troubleshooting.�If you're having trouble figuring out some the values for the ldapm, see this useful page on setting up Active Directory integration with Bugzilla. It explains how distinguished names are defined in Active Directory, and how to test that you have the correct values for connectivity and base DN using the OpenLDAP command-line utility ldapsearch.John had an issue where nsldap was not loading because AOLServer couldn't find the openldap client libraries, but he was able to fix it by adding the openldap libraries to his LD_LIBRARY_PATH (e.g. /usr/local/openldap/lib)
Credits.�Thanks to Malte Sussdorf for his help and the Laboratory of Computer Science at Massachusetts General Hospital for underwriting this work.
Troubleshooting. If you're having trouble figuring out some the values for the ldapm, see this useful page on setting up Active Directory integration with Bugzilla. It explains how distinguished names are defined in Active Directory, and how to test that you have the correct values for connectivity and base DN using the OpenLDAP command-line utility ldapsearch.John had an issue where nsldap was not loading because AOLServer couldn't find the openldap client libraries, but he was able to fix it by adding the openldap libraries to his LD_LIBRARY_PATH (e.g. /usr/local/openldap/lib)
Credits. Thanks to Malte Sussdorf for his help and the Laboratory of Computer Science at Massachusetts General Hospital for underwriting this work.