Re: password changes not taking effect (342 Views)
Reply
Regular Advisor
David G. Douthitt
Posts: 105
Registered: ‎10-23-2007
Message 1 of 15 (342 Views)

password changes not taking effect

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!
Please use plain text.
Honored Contributor
labadie_1
Posts: 1,221
Registered: ‎08-07-2003
Message 2 of 15 (342 Views)

Re: password changes not taking effect

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) ?
Please use plain text.
Regular Advisor
David G. Douthitt
Posts: 105
Registered: ‎10-23-2007
Message 3 of 15 (342 Views)

Re: password changes not taking effect

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.
Please use plain text.
Esteemed Contributor
Phillip Thayer
Posts: 403
Registered: ‎02-20-2004
Message 4 of 15 (342 Views)

Re: password changes not taking effect

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
Once it's in production it's all bugs after that.
Please use plain text.
Regular Advisor
David G. Douthitt
Posts: 105
Registered: ‎10-23-2007
Message 5 of 15 (342 Views)

Re: password changes not taking effect

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?
Please use plain text.
Esteemed Contributor
Phillip Thayer
Posts: 403
Registered: ‎02-20-2004
Message 6 of 15 (342 Views)

Re: password changes not taking effect

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
Once it's in production it's all bugs after that.
Please use plain text.
Regular Advisor
David G. Douthitt
Posts: 105
Registered: ‎10-23-2007
Message 7 of 15 (342 Views)

Re: password changes not taking effect

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?
Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,204
Registered: ‎04-26-2004
Message 8 of 15 (342 Views)

Re: password changes not taking effect

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

Volker.
Please use plain text.
Honored Contributor
labadie_1
Posts: 1,221
Registered: ‎08-07-2003
Message 9 of 15 (342 Views)

Re: password changes not taking effect

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"
Please use plain text.
Esteemed Contributor
Phillip Thayer
Posts: 403
Registered: ‎02-20-2004
Message 10 of 15 (342 Views)

Re: password changes not taking effect

You got it!

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

Phil
Once it's in production it's all bugs after that.
Please use plain text.
Honored Contributor
Volker Halle
Posts: 5,204
Registered: ‎04-26-2004
Message 11 of 15 (342 Views)

Re: password changes not taking effect

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.
Please use plain text.
Honored Contributor
Robert Gezelter
Posts: 2,367
Registered: ‎10-30-2003
Message 12 of 15 (342 Views)

Re: password changes not taking effect

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
Please use plain text.
Honored Contributor
Jan van den Ende
Posts: 4,537
Registered: ‎12-17-2003
Message 13 of 15 (342 Views)

Re: password changes not taking effect

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
Don't rust yours pelled jacker to fine doll missed aches.
Please use plain text.
Regular Advisor
Verne Britton
Posts: 100
Registered: ‎06-01-2005
Message 14 of 15 (342 Views)

Re: password changes not taking effect

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


Verne Britton
WVNET
Please use plain text.
Honored Contributor
Willem Grooters
Posts: 2,038
Registered: ‎05-21-2003
Message 15 of 15 (342 Views)

Re: password changes not taking effect

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.
Willem Grooters
OpenVMS Developer & System Manager
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation