password changes not taking effect

[David G. Douthitt]

I've a question about changing passwords for users (as SYSTEM).

Given that a user is already on the system, and asks for password change. I go into SYS$SYSTEM:AUTHORIZE and change the password (with MODI USER/PASSWORD= ). No problem there.

The problem comes up when they try to login. Even with the correct password, they still get rejected. Looking at SHO INTR shows their attempt. Clearing attempts with DELETE/INTR doesn't seem to help - or at least not right away.

This problem seems to go away if you DELETE/INTR and/or change password with AUTHORIZE in the right order or at the right time.

What am I missing here?

Thanks!

[labadie_1]

If you do
$ reply/ena=secu
before they log, what messages do you get when they log ?

before telling them to log in, try yourself with
$ dir 0"user newpassword"::
and see if you get an error message or a listing of the files in sys$login of the user.

Do you have special code in sylogin.com (or the name this procedure has on your site) ?

[David G. Douthitt]

More information: this is on a system running OpenVMS 8.3. The user was listed as having 16 login-fails; now (hour or two later) there are no login-fails.

[Phillip Thayer]

There may already have been an intruder record before you changed the password. That means the user would not be allowed to login to the system at all, even with the new password. You should always check and delete any intruder records that may be hanging around for any user that you change a password for. Of course that would be done ONLY after checking to see if the actual person that the account belongs to confirms that they truly are wanting to change their password.

Phil

[David G. Douthitt]

In the specific case that prompted this question, the user has now been able to login (which probably explains the 0 login-fails).

This problem, however, has happened before and probably will again. It only happens occasionally. I keep thinking that there must be another audit "record" or "event" stored somewhere for a particular user, which is not cleared by DELETE/INTR and which causes them to be placed in an INTR record instead of being let in as security warrants.

How does the DIR 0"" command work?

[Phillip Thayer]

From the DCL manual explaining DELETE/INTRUSION_RECORD:

--------------------------------------------

Description
Use the DELETE/INTRUSION_RECORD command to remove an entry from the break-in database. For example, if the user Hammer repeatedly attempted to log in to terminal TTA24 with an expired password, the SHOW INTRUSION command would display the following entry:


Intrusion Type Count Expiration Source

TERM_USER INTRUDER 9 10:29:39.16 TTA24:HAMMER



The terminal is locked out of the system because the login failure limit has been reached. When Hammer approaches you and you identify the problem as an expired password, you can then use the DELETE/INTRUSION command to remove the record from the break-in database.

-------------------------------------------

You need to delete all intrusion records before the account will be able to log in again. Also, remember that intrusion records will have the source of the intrusion which can include terminal server named, IP addresses/domains or node names. You need to make sure you delete ALL intrusion records for the user.

Phil

[David G. Douthitt]

If I understand this correctly - what is happening is:

1. User pwd changed
2. User says can't login
3. Delete Intruder Records
4. User says can't login
5. User pwd changed
6. User says Finally - it works!

The right way is to:

1. Check Intr Records and Delete if needed
2. Change password
3. User says You're Wonderful!

Did I get that right?

[Volker Halle]

... and don't forget to check that the user is the user she/he claims to be !

Volker.

[labadie_1]

The dir 0"user password":: does a dir on the same node (0 means itself) withe the user user :-)
in the syntax, :: means a Vms node.

The syntax for a file is
node::disk:file.ext;version
or
node"user password"::disk:file.ext;version

if you use Decnet proxies, you can avoid the string "user password"

[Phillip Thayer]

You got it!

And Volker is also right, check that the user is actually the user they claim to be.

Phil

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