| > 1 ) Password for root and DEMO account for DKA200 (MLS+ Server) had
> expired...
You could always set the date to the last known time it was run?
and then go from there (change expiration time, etc.)
> Hopefully, there was no Console Password mounted, if not we would have
> to return the entire system to US...
Comment? No sense of adventure?
Field service would have been able to clear the console NVRAM
(or you might yourself if you have the processor user's manual).
> 2 ) I observed a curious problem (seem to be a bug or a lock of license for
> the encrypting algorithm) for password picking from any Window, Xterm,..
> whatever the account is used. A soon as you try to change the password
>
> system crash as soon as you enter the password
This is a mismatch in OSF V2.1 and the firmware loaded on the
hardware (see note 363.2). [ Hmm, I might have to put a special
patch out for this, if V3.1A hangs around for much longer...]
For demo's, we really should running V4.0A. I think.
Anyway...
> This is very difficult to maintain as is, because obliges us to have
> some accounts with "cryptic account names... without passwords !", or
> no to change passwords at all.
You will not be able to change passwords (i.e., run the change
password utility) if you run a recent revision of the firmware.
I don't know who gave you the system, but the problem can
be fixed if you upgrade to MLS+ V4, or load an older
version of the firmware for this hardware.
If for any reason you can do neither, then you can get around
the problem by changing the account's ppde (protected password
database entry, see man 4 prpwd) manually.
All you need is an account whose password you do know, and be
good at line editing.*
Step 1:
Save a copy of the u_pwd field (i.e., the encrypted string) in
the /tcb/files/auth file for an account whose password you do know.
Write it down or whatever.
Step 2:
In that account ppde, or any other account to which you can login,
change the u_pwd field to empty and the u_nullpw field to
nothing, e.g.,:
:u_pwd=:\
:u_nullpw:\
(u_pwd is the null string, and the binary field u_nullpw
does not have the @ in it, meaning null passwords are okay.)
Step 3:
Login as that user. It does not now require a password (the
password is nothing).
Step 4:
Go back and re-examine the ppde (/tcb/files/auth/[az]/) file for that
account. It will now have a new value in the u_suclog field, e.g,
u_suclog=863458272. Write down or save that value somewhere.
Step 5:
In the pdde for the account to which you want to log in,
change the values of the u_pwd field to the encrypted
string you saved in step 1, and change the value of the
u_suclog *and* u_succhg fields to the value you saved in
Step 4. You should now be able to login as the user.
_________
*Note that the format for the protected password database is
very strict. You cannot make typing mistakes, you are not
forgiven. Every line in the file except the first one
must begin with a tab. Every line in the file must end with
a continuation character (\), except the last line. The last
field on the last line must be "chkent:".
Fields must be separated by the colons, two if they are
also separated by the continuation character/newline. Fields
are either binary types, in which case the field name is
followed by an at sign (@) equals "ON" or nothing (just
the : field separator), meaning "OFF"; or fields take string
arguments, in which case the field name is always terminated
with an equal sign.
|