- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: password changes not taking effect
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 11:12 AM
тАО03-19-2008 11:12 AM
Re: password changes not taking effect
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-19-2008 11:14 AM
тАО03-19-2008 11:14 AM
Re: password changes not taking effect
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-20-2008 01:53 AM
тАО03-20-2008 01:53 AM
Re: password changes not taking effect
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-20-2008 05:57 PM
тАО03-20-2008 05:57 PM
Re: password changes not taking effect
Verne Britton
WVNET
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-21-2008 12:12 AM
тАО03-21-2008 12:12 AM
Re: password changes not taking effect
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
- « Previous
-
- 1
- 2
- Next »