In this article, we will go over frequently asked questions pertaining to the Aeon 4.1 update.
The 4.1 release has been issued to keep up-to-date with the latest PCI security requirements. For more information on PCI security requirements and recommendations, please see: https://www.pcisecuritystandards.org/. A full Aeon 5.0 release is estimated for June 2019.
- Will there be release notes available for Aeon 4.1?
They are now available here: https://support.atlas-sys.com/hc/en-us/articles/360020761594.
- Will my system automatically update to Aeon 4.1 on release day?
You will need to update your server first. Once your server has been updated you will receive a prompt to update. Right-click on the Aeon client icon and select Run as Administrator to start the automatic client updater. You will need Administrator privileges to run as administrator.
The System Manager will check the Atlas servers for new client releases 10 seconds after startup, after which it will resume the behavior of only checking once every 15 minutes. The default interval at which updates are checked can be customized in the SystemManager.exe.config file by editing the value of the UpdateServiceInterval setting.
To download the installer files, please see the Aeon Downloads page.
- Do I have to update to 4.1?
Due to critical security enhancements contained in this update, if you are using a payment gateway, we highly recommend that you schedule your upgrade as soon as possible. If you are in the Atlas hosted PCI environment, we’ll work with you to get your upgrade scheduled within 90 days. This update contains primarily security enhancements only. Aeon is projected to have a full release in June 2019.
Can you use CyberSource as a payment gateway if your institution uses Shibboleth or CAS?
Yes, the setup procedures will be different than Aeon Auth users since the default directories are set up differently. In CyberSource Configuration, under the Configuring Under Remote Authentication heading, there are instructions on how to modify your CreditCardPayment.html pages so that it works with remote auth. Please note that you will need to download the 4.1 default webpages to obtain the latest version of the CreditCardPayment.html file.
- Where did the Staff, Users, and OpenURL Mapping table go?
These tables were dropped and recreated to support the newly added Staff Passwords table which will record the history of the staff users last 6 passwords.
Why is it necessary for all staff to change their passwords?
To increase security, Aeon's authentication storage hash is updated to a more secure algorithm (default 156,000 iterations). To make sure the passwords are stored in this new format, it is necessary to change them so the new password can be properly hashed and secured in the database. It's also best practice for security purposes to change passwords periodically.
- Do all staff users have to change their passwords upon login after the update? Any way to disable that?
Yes, all staff will have to change their passwords. There is no way to disable that prior to the update.
- If I change my password in a previous version of the Aeon client, can I still login to 4.1?
Due to the change in password hashing, once a staff user has logged in to version 4.1 after the update, they will not be able to login to older client versions. This means that if one staff user plans to update multiple client workstations, they should right-click the 4.1 (or previous version) client to login and start the automatic update on each machine before logging into Aeon 4.1 after the client update completes.
If you experience errors because you have already changed your password in Aeon 4.1 and need to update another client, the workaround is to download and install the 4.1 client to bypass the client automatic updater.
- Is making staff passwords expire an optional setting?
At this time, staff password expiration can NOT be disabled.
- Does the staff password change have to be a different password or can I just keep using the same password?
Yes, it has to be different than your last 4 passwords. After the initial login, the default can be changed. The StaffPreviousPasswordCount Customization Key will allow you to set the default number of unique passwords a user must use before an old password can be reused.
If the value is set to 4, then the user must have 4 unique passwords before an old password can be reused.
If the value is set to 0, the password will not be checked against the user's password history when updating the password.
- Can I change the default number of failed login attempts before a staff account is locked out?
Yes, the StaffLoginAttemptsBeforeLock Customization Key allows you to set the threshold for failed sign-in attempts before an account is locked out. The lower the number, the fewer attempts a user has to login. This reduces the risk of malicious users attempting to login to a staff account. A locked account can't be used until the password is reset by another staff member with access to the Staff Manager.
When set to less than 1, the number of attempts will default to 6.
- How does Aeon track the date the password was changed?
There is a new field called PasswordChangedDate in the Staff table and also in the Users table for patrons.
- Are there default password complexity settings already in place for the initial password change requirement?
Anything will work for current sites. New installations will have base web requirements.
Criteria: (8 characters: 1 uppercase, 1 lowercase, 1 number)
- After the update, do you have to login to the Client before the Customization Manager?
Yes, because the Client will upgrade the Customization and Staff Manager to the latest version.
- Why do my fields no longer prepopulate on default fields?
The autocompletion feature has been disabled on all password fields in the default pages. This prevents the fields from storing and prepopulating secure information such as passwords.
- Will the password changes affect my AtlasBI account?
AtlasBI will lock a staff users account if the user exceeds the max failed login attempts. There are no password change requirements for AtlasBI.
Patron User Accounts
- What if users select forgot/reset password option prior to an attempt to log-in?
If a user selects the forgot/reset password option prior to an attempt to log-in, their new password is created with the new encoding, and they will not be directed to create another new password when logging in. In other words, the forgot/reset password functionality works the same as the change password functionality. For instructions on changing a user password, see Changing User Password on the Web.
- Do all patron users have to change their passwords upon login after Aeon 4.1 update? Any way to disable that?
Yes, all patron users will be required to reset their password upon the first login after Aeon 4.1 update regardless of their authentication type. There is no way to disable that prior to the update.
This does not affect users whose authType is set to Default on their user record and the WebAuthType customization key is either set to LDAP or RemoteAuth.
- Why is it necessary for all patrons to change their passwords?
To increase security, Aeon's storage hash is updated to a more secure algorithm (default 156,000 iterations). To make sure the passwords are stored in this new format, it is necessary to change them so the new password can be properly hashed and secured in the database. It is a best practice for security purposes to change passwords periodically.
- After changing passwords, will patrons still be able to see all of their history and current requests? Will we need to merge accounts?
The account is the same and all history will be there. It's just the password that gets updated.
- What will it look like when patrons are prompted to change their passwords?
Patrons will be directed to the main menu for password changes. See sample image below.
Is making patron passwords expire an optional setting? Where is that set?
Yes making the patron passwords expire is optional. There are new Customization Manager keys called UserPasswordExpirationEnabled and UserPasswordExpirationDays under System | Password Expiration. The defaults are set to yes and 180 days but can be changed after update to Aeon 4.1.
- Can patrons force a reset for their own passwords?
No; however, a staff user can force reset a patron's password for them.
- Will a new FORMSTATE tag need to be added to the ChangePassword.html to avoid losing the session state & information when entering Aeon via the OpenURL?
If your site is new to Aeon and doesn't have any customizations on the ChangePassword.html form, you may use the default ChangePassword.html with the most current FORMSTATE tag.
Existing Aeon Installs/Updates-
For current Aeon institutions who are updating to Aeon 4.1, the ChangePassword form will now display immediately after a user logs into the web when the password change is required. As a result, you will want to enter the <#FORMSTATE> tag on the ChangePassword.html page to avoid losing session state & information transferring from source if entering Aeon via OpenURL.
<form action="aeon.dll" method="post" name="ChangePassword" class="f-wrap-request">
<input type="hidden" name="ILLiadForm" value="ChangePassword">
<input type="hidden" name="Username" value="<#PARAM name='Username'>">
<input type="hidden" name="SessionID" value="<#PARAM name='SessionID'>">
<div class="req"><b>*</b> Indicates required field</div>