Over the weekend of the 6th and 7th of February 2010, work in development will be conducted on allowing SSO to interface with Cascade Web Forms. This will cause intermittent report outages for all applications.
Mike Carroll installed new certificates for cascade.ups.edu and chinook.ups.edu (sso and dip).
The new cascade certificate will expire 10/13/2011.
Changes to the provisioning system housed in the Cascade database will be installed on 8/20 starting at 5:30 a.m., and it shouldn’t take more than half an hour to finish.
These changes are to support Moodle integration to AD.
Problems with provisioning should be reported to Carol White immediately.
The Groups container was accidentally deleted in the OID test database today and had to be re-created based on priv data in the Summit database.
Here are the steps we had to do to recover everything:
1. Recreate the Groups container.
Export the Groups container definition (as an LDIF command) from the OID production instance, and import it into OID test. You’ll need an LDAP browser tool to do this, like JXplorer.
2. Recreate all the AD groups.
Set the status of all the pugetsound domain groups in the privilege table to PA and run
privcmd.resolve_pending_privdef on each one.
3. Recreate the members in the AD groups.
Set the status of all AD person_privilege records to PA and run privcmd.resolve_pending_privs.
4. Recreate the portal group container.
Export the portal.070109.134036.113589000 container definition (as an LDIF command) from the OID production instance, and import it into OID test. You’ll need an LDAP browser tool to do this, like JXplorer.
5. Recreate all the portal groups.
Set the status of all the portal groups in the privilege table to PA and run
privcmd.resolve_pending_privdef on each one.
6. Recreate the members in the portal groups.
Set the status of all portal person_privilege records to PA and run privcmd.resolve_pending_privs.
7. Address any unusual configuration issues.
ViewsFlash groups have a special setup, the administrator group is a member of the creator group, so that has to be done manually.
We set the debug level back to 63 to troubleshoot the password sync errors due to AD password policy problem. Here are the commands, executed as oracle on whidbey:
oidctl connect=AS1012P server=odisrv instance=1 configset=1 flags=”port=3636 sslauth=2″ stop
oidctl connect=AS1012P server=odisrv instance=1 configset=1 flags=”port=3636 sslauth=2 debug=63″ start
The Active Directory password policy was inadvertently set to reject passwords that did not contain any special (non-alphanumeric) character, such as *#$% etc.
The problem began about 3/21/2009 and was corrected at 3:15pm on 3/26/2009. During this period, anyone changing a password using Windows was instructed to include a special character.
Passwords changed using Cascade Web during this period were not synchronized to Active Directory, so the new password did not work for Webmail, Windows, etc. This can now be corrected by changing either the AD or OID password.
The problem was corrected by deselecting the special character requirement in the AD password policy.
Here is an example of the error in the ActiveExportUsers_Groups.trc log:
Error in executing mapping DIP_LDAPWRITER_ERROR_MODIFY
javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 0000052D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0
The login page for Banner Forms was changed early on 5/15/2009 (see Cascade middle tier http server restarted), so Banner Forms users are prompted for Puget Sound username and password instead of Banner Database username, password, and database name.
Initially, this did not work correctly for Macintosh users, who were required to enter their username and password twice.
This problem was resolved Saturday morning, so Macintosh users should now be able to log in to Banner Forms (and create purchase orders), entering their Puget Sound credentials only one time per session.
To fix the problem, Ed changed parameter baseHTML to point to our modified basejpisso_webutil.htm file.
As part of implementing Banner Password Synchronization, the Cascade middle tier http server was restarted so that the following change in the httpd.conf file would take effect:
#Redirect /banner https://psforms.ups.edu/forms/frmservlet?config=banner
Redirect /banner https://psforms.ups.edu/banner_sso/gokssso.p_login
This directs cascade.ups.edu/banner to the new Banner login page that authenticates against OID.
The recently released Mac OS X 10.5.7 and Safari 3.2.3 fix the problem where users received “Too many redirects” error when logging in to Cascade Web.
The Technical Help page has been updated to show which versions of Mac OS X and Safari are compatible with Cascade. Browser/OS combinations that are not compatible still receive a message that includes a link to this Technical Help page.
Password synchronization and network/domain password resetting are currently disabled. Technology Services is currently working on restoring this service and we expect it to be restored shortly. We will update you as soon as possible.
UPDATE: Password Synchronization has been re-enabled as of 4:10pm on 5/12.
AD must have sole control of its “mail” attribute to properly provision e-mail accounts. OID –> AD synchronization had included this, and the provisioning system (privcmd) had been filling this with any known e-mail address. This prevented new pugetsound domain accounts from being enabled when the e-mail address was not in the ups.edu domain, as is the case for most new students.
The mapping file was changed to no longer update the “mail” attribute when synchronizing from OID to AD.
The following minor changes were installed 3/25/2009 10:30am, with no disruption:
- Cascade Home page now includes “Technical Problems” link
- Password Change page now includes buttons when using tab key to navigate
- Typo in error message was fixed
- Format of initial password was changed so it includes mixed case instead of symbol
The value of mod_osso_url in the production application server was changed from “https://cascade.ups.edu:443” to “https://cascade.ups.edu”.
This fixes the problem where ViewsFlash or Discoverer could not be accessed via Firefox. (A space appeared at the end of the url.)
We tested the new configuration, using Firefox to directly access ViewsFlash, Discoverer, Portal, Cascade Web, and oiddas.
The maximum SSO session duration value (not the inactivity timeout) had previously been set incorrectly to 0.5 hours, which was treated as 0, preventing the SSO cookie from maintaining a session.
This value was set to the normal value of 8 hours.