topic Shift Restrictions in Operating System - OpenVMS

Shift Restrictions

John Q. Burke — Wed, 06 May 2009 12:59:22 GMT

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

Re: Shift Restrictions

Joseph Huber_1 — Wed, 06 May 2009 13:17:50 GMT

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 .

Re: Shift Restrictions

marsh_1 — Wed, 06 May 2009 13:23:00 GMT

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

Re: Shift Restrictions

marsh_1 — Wed, 06 May 2009 13:24:53 GMT

sorry link here :-

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

Re: Shift Restrictions

Jan van den Ende — Wed, 06 May 2009 15:25:16 GMT

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

Re: Shift Restrictions

Robert Gezelter — Wed, 06 May 2009 19:09:00 GMT

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

Re: Shift Restrictions

Joseph Huber_1 — Thu, 07 May 2009 05:51:00 GMT

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 ...

Re: Shift Restrictions

Wim Van den Wyngaert — Thu, 07 May 2009 06:37:28 GMT

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

Wim

Re: Shift Restrictions

Joseph Huber_1 — Thu, 07 May 2009 06:54:13 GMT

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.

Re: Shift Restrictions

Jan van den Ende — Thu, 07 May 2009 07:19:54 GMT

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

Re: Shift Restrictions

Willem Grooters — Thu, 07 May 2009 08:21:08 GMT

Just a thought:
Have you checked the system time against "real time"? Though your watch may indicate you have access, if the systenm clock runs too fast or too slow, this may cause problems like this.

Willem