Ellipse Password Problem 1

[bernief]

I have come across a problem with a specific userID that cannot log on with a password set in MSO020. If I remove the password, then Ellipse allows the user to log in, any password added to the signon profile causes the "INVALID USERID/PASSWORD" error.

This does not happen if the signon profile is copied to a new profile in MSO020 using a different signon ID, eg, "TEST" copied to "TEST1".

Any ideas out there?

 

[Glen]

There are a couple of "hard-coded" user IDs in the system. These IDs have special rules about passwords that are outside of the normal authentication process. Which user ID are you having problems with?

Glen Colbert
gcolbert@rag-american.com

 

[bernief]

Hi Glen,
Thanks for this but, this is not one of those "hard coded" ID's. It is a normal user signon that was created by the System Administrator.
Everything points to this being a hardware (disk sector) or data corruption problem.
I have been implementing MIMS and Ellipse (from 3.13 to 5.3.2) security for many years and have never seen this before, therefore think that this is not really a functional problem.

Regards
bernief

 

[rogggers]

I have had the same type of problem, and it was with a user who only had a four letter userID, and we had to make his password 7 characters long, and this got over / around the problem

john

 

[bernief]

Hi John,

Thanks for this but I discovered that the problem is related to a new encryption algorithm for version 5.2.3.4.

On conversion a new record is created for each new userID in MSF012 that stores a Key Value. On first sign on into Ellipse a password change screen makes the user change their initial password, writes a MSF020 records and blows away the MSF012 record. This works perfectly for most users, but if the user has not changed his password (ever) in the previous version, the MSF012 record is not blown away and there is a mismatch between that and the MSF020 record. There is a fix being worked on by Mincom. In the meantime there is an SQL to MSF012 and a sequence of events that must be gone through to fix it for affected users.

 

[jridgway]

Request the fix for MI12856
Components involved are:
The following components are contained in the distribution
msc020.cbl el5.2.3.2_dst 1
mso000.cbl el5.2.3.2_dst 8
mstparam.tbl
msk000.cbl el5.2.3.2_dst 9
msssec.cbl el5.2.3.2_dst 2
mso022.cbl el5.2.3.2_dst 6

It will solve the problem - Jridgway

 

[bernief]

Thanks Jridgway. Do you have any idea when this fix was developed? Would have been useful to have it in the final distribution for go-live!

bernief

 

[jridgway]

bernief:
The fix was very recent, within the last month.

 

[blakej]

I believe this fix is included with Ellipse 5.2.3.5 service pack.

 

[dpes1]

We had this exact problem the day we went live on Ellipse 5.2.3.4. We did not experience the problem in our TEST region. We got an emergency distribution the day we went live after users could not access the system unless we blanked out passwords.

NW773 NW188DP4 MSO020 EMERGENCY DIST MSO022.CBL 1 1 18-Aug-03

Other fixes we received for MSO022:
1. CANNOT USE SPECIAL CHARACTERS IN PASSWORDS, e.g. #$%^&* - Fixed NW772

If you use WebView, watch out for these:
1. USER PASSWORD IS DISPLAYED ON THE SCREEN WHEN APPROVING
VIA MSO877 IN WEBVIEW - Fixed NW770

2. POSITION SELECTION ON LOGIN CAUSE PASSWORD TO BLANK OUT
AND MUST REENTER IN WEBVIEW - Open NW771

3. PASSWORD IS NEEDED REPETITIVELY WHEN APPROVING VIA MSO877 IN WEBVIEW (IS BLANKED OUT EACH TIME USER CHANGES SCREENS - Open - Newmont # NW06BDP1

4. CANNOT CHG PASSWORD WEBVIEW. SCREEN NOT AVAILABLE - Fixed NW765

5. POSITION OF PREVIOUS USER LOCKED IN POSITION FIELD OF NEW USER UPON PASSWORD CHANGE AND CANNOT BE CHANGED IN WEBVIEW. Open - Newmont # NW248DP1

Rgds
Donna