03-19-2008 10:04 AM
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?
03-19-2008 10:13 AM
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) ?
03-19-2008 10:23 AM
03-19-2008 10:26 AM
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?
03-19-2008 10:35 AM
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.
03-19-2008 10:40 AM
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?
03-19-2008 11:06 AM
in the syntax, :: means a Vms node.
The syntax for a file is
if you use Decnet proxies, you can avoid the string "user password"
03-19-2008 11:12 AM
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.
03-19-2008 11:14 AM
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
03-20-2008 01:53 AM
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
_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).
Have one on me.
03-21-2008 12:12 AM
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.
OpenVMS Developer & System Manager