Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Shift Restrictions

 
John Q. Burke
Occasional Visitor

Shift Restrictions

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
10 REPLIES 10
Joseph Huber_1
Honored Contributor

Re: Shift Restrictions

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 .
http://www.mpp.mpg.de/~huber
marsh_1
Honored Contributor

Re: Shift Restrictions

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
Honored Contributor

Re: Shift Restrictions

Jan van den Ende
Honored Contributor

Re: Shift Restrictions

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
Don't rust yours pelled jacker to fine doll missed aches.
Robert Gezelter
Honored Contributor

Re: Shift Restrictions

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
Honored Contributor

Re: Shift Restrictions

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 ...
http://www.mpp.mpg.de/~huber
Wim Van den Wyngaert
Honored Contributor

Re: Shift Restrictions

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

Wim
Wim
Joseph Huber_1
Honored Contributor

Re: Shift Restrictions

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.

http://www.mpp.mpg.de/~huber
Jan van den Ende
Honored Contributor

Re: Shift Restrictions

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
Don't rust yours pelled jacker to fine doll missed aches.
Willem Grooters
Honored Contributor

Re: Shift Restrictions

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
Willem Grooters
OpenVMS Developer & System Manager