Setting Authorize PwdMix flag

[Jim Geier_1]

We are deploying a new password policy that will involve shifting from case-insensitive to case-sensitive passwords on the OpenVMS systems. This policy requires that passwords be chosen with at least one character from three of the fours sets of characters: (1) uppercase, (2) lowercase, (3) numeric, and (4) special characters. I have written a program, built a VMS$PASSWORD_POLICY shareable image, and set LOAD_PWD_POLICY to 1 to enforce this new policy, and it is working fine on our test system.

My question is about how to deploy the change to having the PwdMix flag added to all usernames (about 5000 total) on our production systems. If we set the flag on a given date for all usernames, then all users will have to enter their password as uppercase until they change their password. Since 99+% of our users are captive, and most do not know about the /NEW_PASSWORD qualifier that can be added when entering one's username, most users do not change their password until they are forced to after the password has actually expired. So adding the flag all at one time may cause a revolt among our users, or at least add a level of frustration that would not make for happy "customers."

I was considering running a script daily that would get the last password date and add to that the password lifetime, and if the password was to expire in 5 days, set the username to have case-sensitive passwords and be immediately expired. This would force that user to change their password that day, and there would be only the one signon where they had to enter an uppercase password to match the encrypted value of their old password. Does this seem like a reasonable approach?

How have others migrated from case-insentive to case sensitive passwords on their OpenVMS systems? Are there any "gotchas" that I might be missing?

[Phillip Thayer]

Why not add a hook in you VMS Password policy program to look up usernamed in a secondary file that you maintain. If the username is there then force the user to uppercas. If the user is not there then allow mixed case. Use the authorize list file to generate a starting list of usernames. Then you can convert one user at a time by simply editing the file and removing a username from the list. When the file is empty all users are converted over to mixed case.

Phil

[Jim Geier_1]

The password policy is only called when someone changes their password. It is not called whenever someone logs in. If I understand your suggestion, it would work if the password policy was called from LOGINOUT, but it is only called from the program that sets passwords (SETP0, I think).

[Phillip Thayer]

Oh Yeah. Your right. Last time I used this was in 1996 so it's a bit rusty.

Phil

[John Gillings]

Jim,

I'd suggest you modify the users as:

UAF> MODIFY user/FLAG=PWDMIX/PWDEXP

This will change the user to mixed case, and expire the password, thus forcing them to change the password on next login.

You could also add something to the SYS$ANNOUNCE string explaining the change in policy and that any old password will need to be entered in upper case. Remember that SYS$ANNOUNCE can point to a file using an "@" in the definition.

From a people management perspective, I'd say phasing in would be a mistake, and more likely to cause a revolt. Treat everyone the same, and eliminate the "why me?" issue. It's more comforting to find that everyone has the same "problem". You also maximise your users helping each other, rather than "it's working for me..."

On the other hand, perhaps giving a few days prior warning via SYS$ANNOUNCE and/or a mail message would reduce confusion and complaints. You might also want to blame HP for the change, "OpenVMS has been changed to conform with Windows" (which is, in a sense, true ;-)

[John Gillings]

Jim,

Just thought of another approach...

Write a program which checks if the current users UAF entry has PWDMIX set. If not, it sets PWDMIX and PWDEXP, and returns an appropriate status code. INSTALL it with SYSPRV and execute it from SYLOGIN:

$ RUN FIXPWD
$ IF $STATUS.EQS.changed THEN SET PASSWORD

So, your user can login with the old upper case password, but then has to change it (the only problem is the old password prompt will need to be entered in upper case... a nice big message perhaps?). I suppose you could implement your own SET PASSWORD code in the FIXPWD program...

[Ian Miller.]

I would go for the big bang approach John G described. Give them a few days warning first.

Ensure the appropriate helpdesk has been warned as this will generate more calls (any change always does).

It may help to blame some external agency for the policy change rather than just saying you are aligning to industry best practice (or some such phrase). Communication is the key for this sort of thing. The technical part has been done.

[Jim Geier_1]

Thanks for the ideas. The "big bang" approach is completely out of the question for this organization; the disruption to the business would be substantial. (I wonder how many of you suggesting the "big bang" have managed a system with 5000 users, much less 5000 users who are not computer people -- many of these users have to have training to use a mouse.)

This password policy is being phased in on all platforms in the organization, and there has been notification to the end-users that when their password expires after July 10, the new password will have to comply with the new rules. The challenge is that on the OpenVMS systems there is the problem with the setting PwdMix and then the old password having to be in uppercase. I want to minimize the impact of that insofar as it is possible.

[Phillip Thayer]

Jim,

I think the idea that John G. had with the program that looks at the PWDMIX flag from an installed program with privileges at login is probably the best idea. Then control who gets migrated by using a simple data file with usernames that are to be migrated that day/week/month it would work. Once the use has changed the password then you delete them from the control file.

Phil

[Dave Lennon]

Hi,

I forsee this conversion to using mixed case passwords being a big problem for us, too.

Does anyone know the internals of when the vms$password_policy module is called??

For instance, when exactly is the PWDMIX flag checked??

Is the new password available to vms$password_policy already upcased if no PWDMIX is specified?

Could one modify the values of the new password in vms$password_policy?

Is the old password already checked by the time vms$password_policy is called?

What I am thinking is to modify the user's UAF record to set PWDMIX inside of vms$password_policy and, if necessary, call sys$hash_password to rehash the mixed case password, (provided the plaintext password was not also uppercased)...

Anyone know if there is any hope of this working?

Thanks,
Dave

[Jim Geier_1]

Dave,
I have been working with vms$password_policy quite a bit lately. I do not know exactly when it is called, but it is after the new password and verification password are compared.

The password passed to vms$password_policy (specifically the routine policy_plaintext) is already uppercase if the PwdMix flag is not set. When the PwdMix flag is set, the password passed to policy_plaintext is mixed-case.

The routine policy_plaintext returns a status code indicating whether the password was acceptable or not. I do not see a means of modifying the actual password in that routine.

If by "old password already checked by the time vms$password_policy is called" you mean that the old password was validated against the stored value, then yes, it has been. The error indicating that the old password did not match comes before policy_plaintext is called.

You could use $SETUAI to set the user's UAF record to set the PwdMix flag in policy_plaintext, but at that point, it is too late to have the effect you are hoping for.

We are going to have a DCL script run at login time that does the following:
1. check for the existence of PwdMix and if set, exit
2. check to see if the password is expiring in 6 days (one day before the 5-day notice the system displays), and if it is not, exit. If the password is expiring in 6 days, do the following:
a. run a program to set PwdMix
b. display text telling the user of the new password rules, and that for the next entry only, they must enter their old password in all uppercase
c. issue the command SET PASSWORD

This is the best I have come up with to minimize impact on the business and give the best information to the end-users. There will be other communication to the whole company, and the password policy is changing on all platforms. The deployment on OpenVMS is a little more challenging because of the migration to mixed-case passwords.

[David R. Lennon]

Jim,

I was afraid of that. Well, I guess we can't get real fancy and handle going right into changing a password in loginout (such as logging in with username/NEW_PASS or when a /pwdexpired is set).

I like the scheme you describe but one can do a bit better by front-ending the $set password command in DCL and simply uppercase what they give as the old password before passing it on.

I've attached a command procedure I just cobbled together that was tested on v8.2 and shows what I mean and implements most of your scheme (except for checking when the password is due to expire). Note that it still implements any new password checking that is done in a vms$password_policy module.

Let me know what you think or if anyone has improvements or objections to this...

By the way, are you at liberty to share your code for your password policy module?

Thanks,
Dave

[Galen Tackett]

Jim,

I'm another who might find this password policy module useful, if it can be made available.

Thanks,

Galen

[Jan van den Ende]

Jim,

another vote of interest here.

Proost.

Have one on me.

jpe

[Jim Geier_1]

Dave, your DCL to manage the SET PASSWORD is going to enhance my plan very well, reducing dramatically the end-user frustration. Thank-you!

There are three programs I will gladly share. Two are done, and one will be done later this week:
1. UAF_SYMBOL converts interesting UAF values to DCL symbols...not rocket science, but useful. I may change this to use the current username if the logical name username is not defined.
2. SET_PWDMIX sets the PwdMix flag (not done yet)
3. VMS$PASSWORD_POLICY enforces the password policy. Our policy is to require at least one character from 3 of the following 4 sets: lowercase alphabetic, uppercase alphabetic, numeric, and special characters, where "special" is defined as the ASCII characters greater than 32 and less than 127 not upper, lower, or numeric (basically what you see on a normal keyboard in the U.S.) Currently includes debugging code. Two modules, a .FOR and a .MSG

Note: my code is in Fortran...hope you can stand it.

[Jim Geier_1]

Attached is the VMS$PASSWORD_POLICY.FOR. The .MSG file is simply (but the formatting gets a little weird here...):

.TITLE PASSWORD Error and Warning messages
.FACILITY PASSWORD 06 /PREFIX=PASSWORD_
.IDENT 'Version V1.0'

.SEVERITY INFORMATIONAL
UPPER /FAO_COUNT=1
LOWER /FAO_COUNT=1
NUMERIC /FAO_COUNT=1
SPECIAL /FAO_COUNT=1


.SEVERITY WARNING
RULE1 /FAO_COUNT=0
RULE2 /FAO_COUNT=0

.SEVERITY ERROR
NOPRIV /FAO_COUNT=0

.END

[Jim Geier_1]

Found some major bonehead flaws in the UAF_SYMBOLS program -- forgot that $FAO requires call-by-value when passing integer arguments. Also added last non-interactive login time.

[John Gillings]

Jim,
In case it helps...

Attached is a fairly generic VMS$PASSWORD_POLICY routine in MACRO32. It uses a character table to categorise the type of character in the password string, producing existence flags and counts of each type.

This makes it very simple to test different policies involving requirements for combinations and/or counts of different character classes.

MACRO32 is universal, no PAKs or products installed for the compiler, and full control over what RTLs are linked.

[John Gillings]

(let's try that again, this time with the attachment!)

[Jim Geier_1]

The migration to mixed-case passwords with the strict rules mandated was a struggle. The code I wrote did help, but in reality, the users are struggling with the password policy.

Lesson learned -- communication is a key to success, and even though we really tried to communicate, we failed there, and there was undue frustration experienced by the users.

Four months later, if I had to do it over, I would probably vote for the "big bang" method, even though it would guarantee some temporary disruption.