Shift Restrictions

[John Q. Burke]

We currently run VMS in a 'read-only' capacity and none of us in the IT department here know much about VMS. It just works and we only occasionally reset user passwords. Currently one of our users is getting a 'You are not authorized to login at this time' error when attempting to login after a password reset. We have no idea what caused this nor do we know how to correct it. Might anybody be able to help me?

Thanks in advance,
John

[Joseph Huber_1]

Must have been something else than a password reset.
Most probably an access restriction has been done using authorize.
Use MCR AUTHORIZE to show show the users access status:
MCR AUTHORIZE SHOW user
If this show access restricted times, invoke authorize:
MCR AUTHORIZE
then ath the UAF> prompt, HELP MODIFY /[NO]ACCESS , and follow the advice.
The somplest to remove all access time restrictions is
MODIFY user /ACCESS .

[marsh_1]

hi,

you might want to check the users account in the user authorization file, there may be access restrictions around login days/times.
have a read of the system managers manual section on use of the authorize utility here (version v7.3), if you are at all unsure about proceeding with any changes get in some support , a number of the contributors to this forum offer such services.

hth

[marsh_1]

sorry link here :-

http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_73_sysman1.pdf

[Jan van den Ende]

John,

to begin with: WELCOME to the (open)VMS forum!

If you follow Joseph's advise, you _MIGHT_ get a warning: SYSUAF.DAT does not exist. Create it?
If so, answer N ; exit AUTORIZE; do a SET DEFAULT SYS$SYSTEM; and activate AUTORIZE again.
Mind, _IF_ the system was set up with SYSUAF defined (in whatever location is was set uo into) _THEN_ you will NOT get this message, but in an unadapted setup you WILL.

If you already HAVE created a new SYSUAF.DAT, you will also already have found that any changes there have NO effect on other users. And a next try will NOT ask, and may lead to confusion. In that case, log in as the user that made the change, and DIR will show a SYSUAF.DAT. SHOW DEFAULT displays the current directory, and if that is NOT SYS$SYSROOT:[SYSEXE], that remove it, and start again.

And if in anyway in doubt, please _DO_ ask here first BEFORE making the system unusable/inaccessable.
It CAN always be brought to functionality, but tat might require REAL experience!

hth

Proost.

jpe

[Robert Gezelter]

John,

As noted by earlier posters, the AUTHORIZE utility is used to manipulate the system authorization file.

Normally, this file is located in the directory pointed to by the logical name SYS$SYSTEM. The easiest way to get to that file is thus:
$ SET DEFAULT SYS$SYSTEM

Accessing this file will also likely require using an account which has the necessary level of privilege. Generally, the system manager's account has sufficient authorizations.

It is also possible that there is an alternate authorization file. The easiest way to determine if the default authorization file is the correct one is to do something [relatively] innocuous like reset your password (since you know the both the old and new password, one cannot get locked out of the account).

- Bob Gezelter, htttp://www.rlgsc.com

[Joseph Huber_1]

Since the subject is "Shift Restrictions", and nobody in OPs IT group knows about VMSs system management tools, there was either an intruder hijacking the system, or, more seriously, there is a shift schedule application running, somewhere, not necessarily on the VMS system, which has the side effect to put the /access time restriction into VMS sysuaf for all shift personal.
If a transaction of this application failed, the access time of the victim user is incorrect; or the shifter changed shift with a nother person without updating the shift database, or ...

[Wim Van den Wyngaert]

Try
$ delete /intr *
and login again. Should work.

Wim

[Joseph Huber_1]

Wim, don't confuse a non-system manager.
Intruders are told "User authorization failure",
not "...not authorzed to login at this time.",
which indicates an access time restriction.

[Jan van den Ende]

John,

Joseph at 6:51 has a seriously good point. (we had something similar for automatic account creation and expiration, although without shift control).
In that case, the actions given above should help until the next synchronisation with the "shift application".
Should such be the case, then there might be an administrative error in shift registration, and it will be necessary to investigate/correct THAT.

hth

Proost.

Have one on me.

jpe