Bug 41449

GemStone/S 64 Bit

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.x, 2.3.1.7, 2.3.x, 2.3, 2.2.5.4, 2.2.x, earlier versions

All

Turning on stale account aging may disable accounts

The lastLoginTime of an account is only updated if the repository has stale account aging or password aging enabled.  The update of the lastLoginTime on login requires a commit, which is not always desireable.

As a result, if a stale account age limit is set in a repository that did not previously have either check, the lastLoginTime of accounts that log in frequently may be still set to a date well in the past, which results in the account being disabled immediately.

Accounts created in earlier versions of GemStone may have the lastLoginTime set to nil, which avoids the checks and reduces the risk in cases of repositories that have never had either check enabled.  Accounts created in 2.4 or later have the lastLoginTime set to the time the account was created.

Workaround

Decisions to enable or disabled account and password aging should be done with forethought, in any case.

To turn on account aging safely, an initial period with the stale account age limit set to a large value, or with password age check enabled but not account age limits, will allow accounts time to login in with updates to the lastLoginTime.

Version 2.4.4.7 and 3.0 and later have a method to explicity set the lastLoginTime, which should be used on existing accounts.


                

Last updated: 8/11/11