<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Disable OPEN VMS  User Account Automatically in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093111#M30265</link>
    <description>CA1467620,&lt;BR /&gt;&lt;BR /&gt;It really boils down to the old main question: "What are you trying to achieve?"&lt;BR /&gt;&lt;BR /&gt;If this is some application, that several applic managers must be able to stop and start, then there exist tricks to have this done from their own accounts (without ever logging in to this "application super user").&lt;BR /&gt;&lt;BR /&gt;In general, LOTS of things CAN be done in controlled ways in VMS, but most of those DO require advanced skills and experience.&lt;BR /&gt;&lt;BR /&gt;And, after a certain treshold, some people just HAVE to have full access to the system(s). In those cases, TRUST is all that is left.&lt;BR /&gt;And then, all that is left is to "trust, but verify".&lt;BR /&gt;(alas in many cases, the skills to verify are badly missing!)&lt;BR /&gt;&lt;BR /&gt;hth&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;jpe</description>
    <pubDate>Mon, 18 Feb 2008 13:17:17 GMT</pubDate>
    <dc:creator>Jan van den Ende</dc:creator>
    <dc:date>2008-02-18T13:17:17Z</dc:date>
    <item>
      <title>Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093104#M30258</link>
      <description>I have requirement to disable the privilege user account (ABCUSER) after every successful login.&lt;BR /&gt;Could any one please help me find out? How to disable the user account automatically?&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;This implementation is for security purpose. Normally this powerful Application account should always be disabled. Once the user required using this ABCUSER account, he needs approval for it.&lt;BR /&gt;After performing the task, once he logout. The user account will automatically disable after 1 or 2 hrs.&lt;BR /&gt;User again needs approval to unlock this account and login.&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Feb 2008 11:15:05 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093104#M30258</guid>
      <dc:creator>Kumar_Sanjay</dc:creator>
      <dc:date>2008-02-18T11:15:05Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093105#M30259</link>
      <description>You may set a very short lifetime or disable the account in its LOGIN.COM or SYLOGIN.&lt;BR /&gt;But note: since the account is privileged, the user has all he needs to circumvent your mesasures, except it is tied into a captive account.&lt;BR /&gt;&lt;BR /&gt;regards Kalle</description>
      <pubDate>Mon, 18 Feb 2008 11:32:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093105#M30259</guid>
      <dc:creator>Karl Rohwedder</dc:creator>
      <dc:date>2008-02-18T11:32:37Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093106#M30260</link>
      <description>This Account is equivalents to system account added some special identifiers for applications. I couldnâ  t make this as captive account.</description>
      <pubDate>Mon, 18 Feb 2008 11:35:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093106#M30260</guid>
      <dc:creator>Kumar_Sanjay</dc:creator>
      <dc:date>2008-02-18T11:35:38Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093107#M30261</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;&amp;gt;&lt;BR /&gt;This Account is equivalents to system account &lt;BR /&gt;&amp;lt;&amp;lt;&amp;lt;&lt;BR /&gt;&lt;BR /&gt;- A. Let the account have expiration in the past.&lt;BR /&gt;When enabling it, do so by setting short expiration.&lt;BR /&gt;&lt;BR /&gt;(from other prive'd account):&lt;BR /&gt;$ MC authorize mod &lt;ACCOUNT&gt; /EXPI="+2:0:0"&lt;BR /&gt;will allow two hours. of login window.&lt;BR /&gt;&lt;BR /&gt;Mind. this will also block NETWORK and BATCH logins!&lt;BR /&gt;&lt;BR /&gt;- B. Always allow just ONE login:&lt;BR /&gt;in the LOGIN.COM of the account, do&lt;BR /&gt;# MCR AUTHORIZE MOD &lt;ACCOUNT&gt;/NOINTERACTIVE.&lt;BR /&gt;&lt;BR /&gt;Befoe use, another priv'd account will need to set /INTERACTIVE.&lt;BR /&gt;&lt;BR /&gt;Caveat: any user logged in into this account will always be able to change his own account at will!&lt;BR /&gt;There exists NO way to avoid that, once a priv'd user has command line access.&lt;BR /&gt;&lt;BR /&gt;hth&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;jpe&lt;/ACCOUNT&gt;&lt;/ACCOUNT&gt;</description>
      <pubDate>Mon, 18 Feb 2008 12:14:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093107#M30261</guid>
      <dc:creator>Jan van den Ende</dc:creator>
      <dc:date>2008-02-18T12:14:27Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093108#M30262</link>
      <description>I think what you try to do is nonsense.&lt;BR /&gt;&lt;BR /&gt;How do you know that this privileged account has not started a detached or batch process that will re-enable this account, or create another privileged account, or anything else, like what some guys did long ago, patch loginout.exe, while still having a correct checksum ?&lt;BR /&gt;Are you suspicious if you have usually about 100 symbiont processes, if you have one more, that in fact does something completely different ?&lt;BR /&gt;&lt;BR /&gt;I do not believe you can reliably do what you want.</description>
      <pubDate>Mon, 18 Feb 2008 12:46:11 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093108#M30262</guid>
      <dc:creator>labadie_1</dc:creator>
      <dc:date>2008-02-18T12:46:11Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093109#M30263</link>
      <description>CA1467620,&lt;BR /&gt;&lt;BR /&gt;Since the account has full privileges, and is not captive, it is straightforward to neutralize such restrictions, as Karl and Labadie have observed.&lt;BR /&gt;&lt;BR /&gt;The obvious way to attempt this is to pre-expire the account. However, the expiration can simply be reset by using AUTHORIZE or another program. Resetting the LOGIN.COM file (e.g., to something that automatically logs off) can be similarly defeated.&lt;BR /&gt;&lt;BR /&gt;Automatic emails to multiple persons can act as a discouragement to improper use, but they do not prevent the use.&lt;BR /&gt;&lt;BR /&gt;It may be appropriate to reduce the privilege level of this account, in which case something can be done. Consulting with someone with extensive experience in OpenVMS security would be a sound idea [Disclosure: We provide services in this area, as do several other frequent participants in this forum].&lt;BR /&gt;&lt;BR /&gt;- Bob Gezelter, &lt;A href="http://www.rlgsc.com" target="_blank"&gt;http://www.rlgsc.com&lt;/A&gt;</description>
      <pubDate>Mon, 18 Feb 2008 12:59:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093109#M30263</guid>
      <dc:creator>Robert Gezelter</dc:creator>
      <dc:date>2008-02-18T12:59:08Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093110#M30264</link>
      <description>In my own experience, it is almost always possible to use a CAPTIVE account for this kind of issue, i.e. accounts used to access an application.    In your case, you specify a user called ABCUSER (I don't know if this is just coincidental, or if the user is actually accessing Archive Backup Client (ABC)), however is is relatively simple to limit the input command strings at the DCL Level, to some predefined sub-set.   Once inside the application/utility, then the DCL restrictions no longer apply so the user has full access to the application/utility commands.   This solution does however require some skill at DCL scripting.&lt;BR /&gt;    Alternatively, while the problems with privileged accounts being able to modify their own account while logged in, are certainly valid, if the user/application does not actually require BYPASS or SECURITY, then an identifier on the AUTHORIZE exe or the SYSUAF.DAT of the form,&lt;BR /&gt;(IDENTIFIER=ABCUSER, ACCESS=NONE) will stop them modifying their own account.   However, if the account does require either of those privileges then there is little you can do.&lt;BR /&gt;&lt;BR /&gt;Dave&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Feb 2008 13:17:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093110#M30264</guid>
      <dc:creator>The Brit</dc:creator>
      <dc:date>2008-02-18T13:17:07Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093111#M30265</link>
      <description>CA1467620,&lt;BR /&gt;&lt;BR /&gt;It really boils down to the old main question: "What are you trying to achieve?"&lt;BR /&gt;&lt;BR /&gt;If this is some application, that several applic managers must be able to stop and start, then there exist tricks to have this done from their own accounts (without ever logging in to this "application super user").&lt;BR /&gt;&lt;BR /&gt;In general, LOTS of things CAN be done in controlled ways in VMS, but most of those DO require advanced skills and experience.&lt;BR /&gt;&lt;BR /&gt;And, after a certain treshold, some people just HAVE to have full access to the system(s). In those cases, TRUST is all that is left.&lt;BR /&gt;And then, all that is left is to "trust, but verify".&lt;BR /&gt;(alas in many cases, the skills to verify are badly missing!)&lt;BR /&gt;&lt;BR /&gt;hth&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;jpe</description>
      <pubDate>Mon, 18 Feb 2008 13:17:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093111#M30265</guid>
      <dc:creator>Jan van den Ende</dc:creator>
      <dc:date>2008-02-18T13:17:17Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093112#M30266</link>
      <description>I would try the following:&lt;BR /&gt;&lt;BR /&gt;Create the account to be a captive, normal user (that is: non-SYSTEM) account, with normal default privileges and only those that are required in some actions, as authorized.   &lt;BR /&gt;The procedure (actually a menu) would do a SET PRIV to elevated levels before the required action (no more than really needed) and revoke these privileges afterwards - no matter the outcome.&lt;BR /&gt;On exit (whatever way) the procedure would need to set the /DISUSER flag of the account. Another approach is keeping the first login time of the script, and set the expiration date accordingly. You could do so in a (SYSTEM or GROUP) logical, that is deleted on logout after expiration.&lt;BR /&gt;&lt;BR /&gt;Be sure this user has NO DCL access; all he does should be under full control of the procedure, and any escape should result in logout (that's what a captive account is meant for).&lt;BR /&gt;&lt;BR /&gt;To reuse the account, someone that is able to chnage UAF records (using a similar captive account?) could allow him access for the next period.&lt;BR /&gt;&lt;BR /&gt;Any file, touched by this account, should be secured for write access for any non-privileged user. You can do so by an ACL on identifier, and no access for non-holders.&lt;BR /&gt;&lt;BR /&gt;If you require DCL access, it's a no-go. You cannot do without to prevent activities you do NOT want to be executed. Otherwise, this account should have no access to ANY file or resource unless explicitly allowed. Writing a DCL procedure that limits activities to the bare minimum required is less time consuming (and earier to maintain).&lt;BR /&gt;&lt;BR /&gt;I have used such an approach in a development area to allow the (non-system) developers do some limietd system tasks they otherwise couldn't execute (except for the time limitation)</description>
      <pubDate>Mon, 18 Feb 2008 14:52:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093112#M30266</guid>
      <dc:creator>Willem Grooters</dc:creator>
      <dc:date>2008-02-18T14:52:55Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093113#M30267</link>
      <description>Here's a configuration approach that should lead to a single-use password:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://64.223.189.234/node/682" target="_blank"&gt;http://64.223.189.234/node/682&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Alternatively, some sites use the two-password login mechanism for cases such as this, where two folks each have one of the two passwords needed to log into the (privileged) username for the target system.  Both folks must be present to log in.&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Feb 2008 15:51:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093113#M30267</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2008-02-18T15:51:06Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093114#M30268</link>
      <description>Hi Willem Grooters&lt;BR /&gt;&lt;BR /&gt;Thanks for your reply. We have two different accounts for this application.&lt;BR /&gt;&lt;BR /&gt;1. User id -ABCLOWPRV - This is regular user account for application startup and shutdown.&lt;BR /&gt;2. User id -ABCUSER - this account has all the privilege and use rarely for application maintained or trouble shooting application problems. Since this has all the privileges we want to protect this account.&lt;BR /&gt;&lt;BR /&gt;You suggested procedure is suitable to this environment and want to implement the same.&lt;BR /&gt;I want to add the /DISUSER Flag on the exit/logout of the ABCUSER. This will prevent users login if he know the last password.. &lt;BR /&gt;&lt;BR /&gt;How do I implement the same; &lt;BR /&gt;Is there any options in authorize to do this ?&lt;BR /&gt;or do i need to write a command procedure for this?</description>
      <pubDate>Mon, 18 Feb 2008 16:12:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093114#M30268</guid>
      <dc:creator>Kumar_Sanjay</dc:creator>
      <dc:date>2008-02-18T16:12:27Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093115#M30269</link>
      <description>CA1467620 ,&lt;BR /&gt;&lt;BR /&gt;&amp;gt;&amp;gt;&amp;gt;&lt;BR /&gt;I want to add the /DISUSER Flag on the exit/logout of the ABCUSER. This will prevent users login if he know the last password.. &lt;BR /&gt;&lt;BR /&gt;How do I implement the same; &lt;BR /&gt;Is there any options in authorize to do this ?&lt;BR /&gt;&amp;lt;&amp;lt;&amp;lt;&lt;BR /&gt;&lt;BR /&gt;$ MCR AUTHORIZE MODIFY ABCUSER /FLAG=DISUSER&lt;BR /&gt;&lt;BR /&gt;(undo with /FLAG=NODISUSER)&lt;BR /&gt;&lt;BR /&gt;Before using AUTHORIZE in this way, you should have defined&lt;BR /&gt;$ DEFINE /SYSTEM/EXECUTIVE SYSUAF &lt;WHEREVER sysuaf.dat="" is=""&gt;  (by default: SYS$SYSTEM:SYSUAF.DAT) &lt;BR /&gt;Be aware that the logical might already be defined, in that case LEAVE it!&lt;BR /&gt;&lt;BR /&gt;hth&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;jpe&lt;BR /&gt;&lt;/WHEREVER&gt;</description>
      <pubDate>Mon, 18 Feb 2008 16:29:52 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093115#M30269</guid>
      <dc:creator>Jan van den Ende</dc:creator>
      <dc:date>2008-02-18T16:29:52Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093116#M30270</link>
      <description>CA1467620,&lt;BR /&gt;&lt;BR /&gt;AUTHORIZE is used to set the DISUSER flag (see HELP MOD /FLAGS within AUTHORIZE).&lt;BR /&gt;&lt;BR /&gt;As Willem noted, unless the user has NO ACCESS to DCL, this is not an effective measure. If the user has access to DCL, they can undo (or fail to do) this measure as they please.&lt;BR /&gt;&lt;BR /&gt;- Bob Gezelter, &lt;A href="http://www.rlgsc.com" target="_blank"&gt;http://www.rlgsc.com&lt;/A&gt;</description>
      <pubDate>Mon, 18 Feb 2008 16:51:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093116#M30270</guid>
      <dc:creator>Robert Gezelter</dc:creator>
      <dc:date>2008-02-18T16:51:34Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093117#M30271</link>
      <description>CA1467620,&lt;BR /&gt;&lt;BR /&gt;In the spirit of "trust but verify", giving this account TWO different passwords  (see AUTHORIZE HELP /SECONDARY ), where each person to use the account has only ONE of those, then the account can only ever be used if TWO people are available to log in.&lt;BR /&gt;Now, (as long as they do not conspire :-) ), you can be reasonably sure that they will only do legitimate things.&lt;BR /&gt;&lt;BR /&gt;This will get you much closer to what you want than any other OS. If this does not satidfy the auditors, then let THEM show how it has to be done!&lt;BR /&gt;&lt;BR /&gt;hth&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;jpe</description>
      <pubDate>Mon, 18 Feb 2008 17:42:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093117#M30271</guid>
      <dc:creator>Jan van den Ende</dc:creator>
      <dc:date>2008-02-18T17:42:09Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093118#M30272</link>
      <description>Hmm, I don't know why the first reply by Karl did not get the full 10 points for a perfect reply and closed the question.&lt;BR /&gt;&lt;BR /&gt;It solves the problem and as bonus points out legitimate and serious concerns.&lt;BR /&gt;&lt;BR /&gt;As Karl indicates, in the login.com for the account issue MCR AUTHOURIZE &lt;USER&gt; /DISUER.&lt;BR /&gt;&lt;BR /&gt;Anything more is just window dressing / fluff.&lt;BR /&gt;&lt;BR /&gt;You may want to describe the real problem better. That is, what is the task to be 'protected' and why is the user not trusted the rest of the time.&lt;BR /&gt;&lt;BR /&gt;One of my customs uses a 'careful' mode where specially flagged users can login with full privs, but with all input and output logged. I'm sure that also can be hacked around, but any person caught attempting that is 'questionable'.&lt;BR /&gt;Just enough of a hurdle and clear demarkation imho.&lt;BR /&gt;&lt;BR /&gt;fwiw,&lt;BR /&gt;Hein.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/USER&gt;</description>
      <pubDate>Mon, 18 Feb 2008 17:45:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093118#M30272</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2008-02-18T17:45:37Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093119#M30273</link>
      <description>No user should have ALL privileges unless they need access to ALL resources on the system, and those *few* users should be very knowledgeable and very trusted. &lt;BR /&gt;&lt;BR /&gt;Any Application-level manager should only have full access to the resources needed to manage that application. It's better to look at the system's security from the bottom-up rather than top-down.&lt;BR /&gt;&lt;BR /&gt;To use AUTHORIZE, a user needs W access to the SYSUAF, NET($)PROXY and RIGHTSLIST files (SYSTEM uic or SYSPRV) so you shouldn't give them that, and don't give them BYPASS or any such elevated priv's (which they *really* shouldn't need to do what you describe.) Application resources should be protected/isolated at the Group level, and/or via ACL's.&lt;BR /&gt;&lt;BR /&gt;Following the other advice on ways to limit their access times should work fine for you if your system and application's security is properly configured.&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Feb 2008 18:58:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093119#M30273</guid>
      <dc:creator>Doug Phillips</dc:creator>
      <dc:date>2008-02-18T18:58:32Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093120#M30274</link>
      <description>&amp;gt;I want to add the /DISUSER Flag on the &lt;BR /&gt;&amp;gt;exit/logout of the ABCUSER. This will &lt;BR /&gt;&amp;gt;prevent users login if he know the last &lt;BR /&gt;&amp;gt;password.. &lt;BR /&gt;&lt;BR /&gt;  If I'm understanding your objective, I'd suggest adding the DISUSER it to the *LOGIN* rather than the LOGOUT. DISUSER doesn't affect an existing process, it just prevents new processes from starting. You definitely have control over LOGIN, but may not get to the LOGOUT (process disconnection, bug in application, power fail, system crash, etc...). This also prevents your user from connecting a second session before finishing with the first.&lt;BR /&gt;&lt;BR /&gt;  Assuming your user has a high level of privileges, just add these lines to LOGIN.COM&lt;BR /&gt;&lt;BR /&gt;$ IF F$TRNLNM("SYSUAF").EQS."" THEN DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF&lt;BR /&gt;$ MCR AUTHORIZE MODIFY 'F$GETJPI("","USERNAME")' /FLAG=DISUSER&lt;BR /&gt;&lt;BR /&gt;This will use the system defined SYSUAF, or set a logical name to use the default one if there's no system defined one.&lt;BR /&gt;(note to Jan, for AUTHORIZE use, the SYSUAF logical name may be in any mode, or in any table visible to the process)&lt;BR /&gt;&lt;BR /&gt;If the user doesn't have SYSPRV (and doesn't need it for the other processing), you can set it as a "trapdoor" privilege:&lt;BR /&gt;&lt;BR /&gt;(permanent setting for account:&lt;BR /&gt;$ MCR AUTHORIZE user/DEFPRIVILEGE=SYSUAF/PRIVILEGE=NOSYSUAF&lt;BR /&gt;&lt;BR /&gt; Once you've done the AUTHORIZE command in LOGIN.COM, issue:&lt;BR /&gt;&lt;BR /&gt;$ SET PROCESS/PRIVILEGE=NOSYSPRV&lt;BR /&gt;&lt;BR /&gt;Once SYSPRV has gone from the default mask, it can't be reinstated because it's not in the authorized mask.&lt;BR /&gt;&lt;BR /&gt;All that said, as others have already mentioned, but it's worth stressing... if the privileged user has ANY access to DCL, or, in some cases even a prompt for data, it really doesn't matter how many tricks and traps you set, if they know what they're doing they WILL be able to get past them. &lt;BR /&gt;&lt;BR /&gt;It comes down to a very simple test - If you don't trust the person, don't give them privilege.</description>
      <pubDate>Mon, 18 Feb 2008 21:12:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093120#M30274</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2008-02-18T21:12:25Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093121#M30275</link>
      <description>&amp;gt;I want to add the /DISUSER Flag on the &lt;BR /&gt;&amp;gt;exit/logout of the ABCUSER. This will &lt;BR /&gt;&amp;gt;prevent users login if he know the last &lt;BR /&gt;&amp;gt;password.. &lt;BR /&gt;&lt;BR /&gt;  If I'm understanding your objective, I'd suggest adding the DISUSER it to the *LOGIN* rather than the LOGOUT. DISUSER doesn't affect an existing process, it just prevents new processes from starting. You definitely have control over LOGIN, but may not get to the LOGOUT (process disconnection, bug in application, power fail, system crash, etc...). This also prevents your user from connecting a second session before finishing with the first.&lt;BR /&gt;&lt;BR /&gt;  Assuming your user has a high level of privileges, just add these lines to LOGIN.COM&lt;BR /&gt;&lt;BR /&gt;$ IF F$TRNLNM("SYSUAF").EQS."" THEN DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF&lt;BR /&gt;$ MCR AUTHORIZE MODIFY 'F$GETJPI("","USERNAME")' /FLAG=DISUSER/NOACCESS&lt;BR /&gt;&lt;BR /&gt;This will use the system defined SYSUAF, or set a logical name to use the default one if there's no system defined one.&lt;BR /&gt;(note to Jan, for AUTHORIZE use, the SYSUAF logical name may be in any mode, or in any table visible to the process)&lt;BR /&gt;&lt;BR /&gt;If the user doesn't have SYSPRV (and doesn't need it for the other processing), you can set it as a "trapdoor" privilege:&lt;BR /&gt;&lt;BR /&gt;(permanent setting for account:&lt;BR /&gt;$ MCR AUTHORIZE user/DEFPRIVILEGE=SYSUAF/PRIVILEGE=NOSYSUAF&lt;BR /&gt;&lt;BR /&gt; Once you've done the AUTHORIZE command in LOGIN.COM, issue:&lt;BR /&gt;&lt;BR /&gt;$ SET PROCESS/PRIVILEGE=NOSYSPRV&lt;BR /&gt;&lt;BR /&gt;Once SYSPRV has gone from the default mask, it can't be reinstated because it's not in the authorized mask.&lt;BR /&gt;&lt;BR /&gt;All that said, as others have already mentioned, but it's worth stressing... if the privileged user has ANY access to DCL, or, in some cases even a prompt for data, it really doesn't matter how many tricks and traps you set, if they know what they're doing they WILL be able to get past them. &lt;BR /&gt;&lt;BR /&gt;It comes down to a very simple test - If you don't trust the person, don't give them privilege.</description>
      <pubDate>Mon, 18 Feb 2008 21:13:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093121#M30275</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2008-02-18T21:13:41Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093122#M30276</link>
      <description>CA1467620, if you want the account disusered as the user logs off then bad news. No direct way of doing it. &lt;BR /&gt;We use a nightly job which disables and changes  password for a number of selected accounts. One being FIELD. We also produce reports on when specific accounts were used. This seems to please the auditors. &lt;BR /&gt;&lt;BR /&gt;Maybe an internals specialist can hook in some code to disable accounts at logout ?&lt;BR /&gt;&lt;BR /&gt;My 2 cents.</description>
      <pubDate>Mon, 18 Feb 2008 22:58:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093122#M30276</guid>
      <dc:creator>Thomas Ritter</dc:creator>
      <dc:date>2008-02-18T22:58:54Z</dc:date>
    </item>
    <item>
      <title>Re: Disable OPEN VMS  User Account Automatically</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093123#M30277</link>
      <description>If you decide to DISUSER the account during login, I'd also add the RESTRICTED flag to the account, to ensure that LOGIN.COM is executed.&lt;BR /&gt;&lt;BR /&gt;  Another tool that I use is a daily job to analyse accounting records and report on what I deem to be suspect modifications to SYSUAF. This approach is not bullet proof, but I find it adequate for keeping an eye on privileged users (typically application managers).</description>
      <pubDate>Mon, 18 Feb 2008 23:35:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/disable-open-vms-user-account-automatically/m-p/5093123#M30277</guid>
      <dc:creator>Martin Hughes</dc:creator>
      <dc:date>2008-02-18T23:35:02Z</dc:date>
    </item>
  </channel>
</rss>

