how to break password for the username.

[Amit Phadnis]

Hi,
I have open VMS 8.3 server, which has only one user yet now.

Now that user has forgot the password, so unable to login into the system.

It is the only username we have. so what is the solution on this. I want to login into the system and then change the password.

But now how can I login into the system.

Pls let me know the solution on this.

Thnks & Regards

Amit Phadnis.

[Karl Rohwedder]

Beside a useraccount there should also be a SYSTEM account for management. Login into this account (or ask your admin to do that) you may change the password with:
$ set def sys$System
$ mcr authorize
UAF> MOD username/password=newpasswd
UAF>exit

If you've lost your SYSTEM password, pls. read the OpenVMS FAQ (e.g. http://hoffmanlabs.org/vmsfaq/index.shtml) on how to break into a system.

regards Kalle

[Jon Pinkley]

Amit,

Your question is similar to:

I had only a single key for my house, and I have lost that key. How can I make a key that will unlock the door?

There are no "master keys" for VMS and the locks are pick/bump resistant. If you have access to the console (you are already in the house), you can force a crash, and boot the machine in conversational mode and if you follow the instructions in the VMS FAQ, you will be able to change the password. That is different than determining what the current password is. And you won't be able to do this without rebooting the machine, so it will be detectable.

So the analogy is that you can break a window, enter your house through the window, and from the inside of your house, you can unlock the door, remove the lock and replace it with a new one for which the old key would not work.

If there were a trivial way to break in, what would be the purpose of VMS security?

Jon

[Hoff]

Here's the short version of the requisite sequence for resetting a forgotten SYSTEM password:

http://64.223.189.234/node/204

Yes, the OpenVMS Frequently Asked Questions (FAQ) has a break-in sequence.

Or you can skim the OpenVMS manuals and specifically the OpenVMS System Manager's Essentions manual, as a sequence is documented there. (Using its site keyword, Google can be restricted to searching the HP OpenVMS web site to make finding this detail within the piles and piles of OpenVMS documentation easier and faster, or you can choose to run a broader search for the password sequence.)

[Pradeep Nair_1]

Hello Amit,

As Kalle comments you can get the information from hoffmanlabs vmsfaq website. For your easiness,
I'm including the steps here. Have fun.


>>> b -fl 0,1

Once you have triggered a conversational bootstrap and have reached the SYSBOOT prompt, you will
want to request that OpenVMS read the system startup commands directly from the system console. This
in place of reading the startup commands from the default OpenVMS system startup procedure,
SYS$SYSTEM:STARTUP.COM. You will also want to disable the windowing system, if any, and you
will want to request that the parameter changes not be recorded.
SYSBOOT> SET/STARTUP OPA0:
SYSBOOT> SET WINDOW_SYSTEM 0
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE
Though the following is not specifically required here, you will have to perform an additional step if you
wish to completely disable the DECwindows startup procedures. In particular, you will have to define the
following logical name within SYLOGICALS.COM:
$ DEFINE/SYSTEM/EXEC DECW$IGNORE_WORKSTATION TRUE
The CONTINUE command shown above will cause OpenVMS to continue the bootstrap. Eventually,
OpenVMS will issue a $ prompt on the console terminal. You must type the following two commands,
exactly as shown:
$ SPAWN
$ @SYS$SYSTEM:STARTUP
The result of these two commands will be the invocation of normal system startup, but you will be left
logged in on the console, running under a privileged username. Without the use of the SPAWN
command, you would be logged out when the startup completes.
If necessary, you can skip the invocation of the system startup temporarily, and perform tasks such as
registering license PAKs or various other "single-user" maintenance operations.
Best of "Ask the Wizard" (3 of 4) [1/13/2003 4:05:12 PM]
Use the following commands to reset the SYSTEM password:
$ SET DEFAULT SYS$SYSTEM: ! or wherever SYSUAF.DAT resides
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY SYSTEM /PASSWORD=newpassword
UAF> EXIT
$


Regards, Pradeep

[p.balamurugan]

Hi Amit

Use the following process to reset your password.

>>> boot 0,1

SYSBOOT> SET UAFALTERNATE 1
SYSBOOT> SET WINDOW_SYSTEM 0
SYSBOOT> CONTINUE
Username: [Return]
Password: [Return]
Password: [Return]
$ DEFINE/SYSTEM/EXECUTIVE_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
AUTHORIZE> MODIFY SYSTEM/PASSWORD=FGLFTUTU
AUTHORIZE> EXIT
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET WINDOW_SYSTEM 1
SYSMAN> PARAMETERS SET UAFALTERNATE 0
SYSMAN> PARAMETERS WRITE CURRENT
SYSMAN> EXIT
$ @SYS$SYSTEM:SHUTDOWN

[Duncan Morris]

p.balamurugan

be aware that your sequence assumes that the site has never set up SYSUAFALT.

If there is an existing SYSUAFALT, then you would need to know the password for the account(s) defined in there.

Follow the references quoted earlier for a safe route into the system.

Regards,

Duncan

[Jan van den Ende]

Adding to Duncans warning:

In case the location of SYSUAF.DAT has been changed (essintial on multi-site and on multi-architecture clusters, advised on others if there is system disk contention), then
$ DEFINE/SYSTEM/EXECUTIVE_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
will be VERY counter-productive,
And, if you did the DEFINE, the SET DEF SYS$SYSTEM is totally superfluous.
OTOH, if you leave out the DEFINE, then you NEED the SET DEF if SYSUAF location has not been set up.
If it HAS been moved, then the SET DEF is superfluous but harmless.

Totalling: the balamurugan solution is the correct sequence, IF YOU LEAVE OUT the DEFINE SYSUAF.


Oh, and the
>>> boot 0,1
is a pretty good catch-all, BUT

- it only works on Alpha; the Vax and Itanium instructions are quite different.
- it assumes that the console variable BOOTDEF_DEV has been set, and set correctly (not unlikely, but not guaranteed!)
- it assumes that SYS0 is the boot root. (standard for non-clustered systems, but unlikely in a cluster)

hth

Proost.

Have one on me.

jpe

[Willem Grooters]

A different approach, if you have installation media (CD, installation disk) at hand - without having to do anything with conversational boot. However, you'll need to know what is your normnal systemdisk and SYStem root are. Assuming you boot:

>>> B -flags 0,0 DKA0

that would be DKA0 and [SYS0], respectively.

* Boot the system from the installation media
* Choose "Execute DCL commands" (IIRC, choice #7)
* $ MOUNT/OVERRIDE=ID DKA0
* CD DKA0:[SYS0.SYSEXE]
* MC AUTHORIZE MOD /PASS=
* $ DISMOUNT DKA0.
* $ LOGOUT
* Choose option 8 to shutdown
* boot normally.

By the way: if that single user acount happens to be SYSTEM, I STRONGLY suggest to:
* Create a user account for regular system management tasks, with ALL (but BYPASS) privileges as authorized, not default. Normally, you can do most with TMPMBX and NETMBX , probably OPER. If you need more privs, you can always enable / disable them on the fly.
This user account could (Should?) be outside the SYSTEM account range (typically (00 - 10)
* Create an account for this single user with TMPMBX and NETMBX privilege only, and if more are REALLY needed, add these as Authorized privileges unless this user really needs them at login.
* If this user needs to eprform specific tasks now and than, that require elevated privileges, consider creating a captive account with no more than the required privileges, using a command procedure that will allow nothing more than what is required.

[Jan van den Ende]

Amit,

Willem gave some gave suggestions!
I would like to add one item to his list:
Give the user with the authorized privs also OPER as /DEFPRV (default priv).
Accounts with default OPER priv CAN login (for maintenamce tasks, that why this is) if the system is closed for 'ordinary' users by $ SET LOGINS/INTERACTIVE=0

hth

Proost.

Have one on me.

jpe