password changes not taking effect

[Volker Halle]

David,

the $ DIR 0"":: command (without specifying username and/or password) prevents the username to be sent with the outgoing connect request. This prevents DECnet proxies for this user to be used. This command only works, if there is a 'default DECnet account' or a 'default FAL' account on the local system, which provides a valid user name for the DECnet file access listener (FAL) to run.

Volker.

[Robert Gezelter]

David,

Just a small note: The DIR 0"user password":: will only function if:

- DECnet is running
- the user has the NETMBX and TMPMBX privileges

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

[Jan van den Ende]

David,

correct me if I am wrong, but

>>>
Given that a user is already on the system, and asks for password change.
<<<

To formulate more precise, do you mean the user is at that time LOGGED IN to the system, or that the userNAME already exists?

I read is as the first of these, but that DOES raise some questions:

-WHY does the user not change his/her password him/her self?
-WHERE do the Login Fails come from (any successfull interactive login RESETS this to zero!)

>>>
The user was listed as having 16 login-fails; now (hour or two later) there are no login-fails.
<<<

So, the user HAS logged in again successfully!


>>>
DELETE/INTR and/or change password with AUTHORIZE in the right order or at the right time
<<<

Not exactly.
_IF_ there exists an "intruder" intrusion record, the user (or the used terminal, or terminal server, or remote system, whatever is the source of the login attempt) cannot login. Period.
If the intrusion record is of type "suspect", then a correct username/password CAN log in; an incorrect try increases the number of attemps.
If that number reaches (SYSGEN PARAM) LGI_RETRY_LIM, then the type changes to intruder.
Each try has a timestamp, and after a timeout it is removed from the intrusion database. This might step down the intrusion level. Each failed login attempt for "intruder" records increases the timeout period.
A suitibly priv'd security officer (or system manager) CAN delete intusion records.
Changing SUSUAF in itself does have no influence (although is frequently desired, since obviously the user does not know or remember the correct password).

hth

Proost.

Have one on me.

jpe

[Verne Britton]

ANAL/AUDIT may also shed some light on what is going on.


Verne Britton
WVNET

[Willem Grooters]

One more cause:
If a user tries to login using TELNET and uses a bad password, the offending system will be flagged as intrusion. ANY user trying to login from that system will now be denied access - since the _system_ is blocked.
If it happens to be a Citrix server, ALL new connections from this machine will now be denied access. Not just telnet sessions. Once authenticated HTTP sessions can be blocked as well (I've seen that happen)

Changing the user password will of course have no effect in these cases since the _system_ is denied access. Not the user.

Cause behind the behaviour: the TCP protocol (as used by telnet) does not hold a username that VMS can check to be valid. Just an IP address.