Account is disabled -- See Account Administrtator

[Tarek]

Hi all,
i'm trying to telnet to a ws, but while i'm putting the password i have the error:
Account is disabled -- See Account Administrtator
Is it possibile to enter again remotely without going to the ws personally??
Thanks

[Stefan Farrelly]

If the account is disabled the only way to fix is to log into the workstation or onto its console and reset the account which is disabled. If its root then you will need to reboot it in single user mode to reset.

[eran maor]

Hi

there is 2 option for thisd problem .

1. if you system is a trusted system then

If the user doesn't login and the Maximum Period of Inactivity
is set back to the default, then the account remains locked.
SAM will not reactivate an account that has been deactivated due
to the Maximum Period of Inactivity being exceeded. SAM indicates
the account is being reactivated for the last login time has expired,
but the reactivate/deactivate action always stays at reactivate.

When this problem occurs it may be due to the user never logging
in since the system was trusted. After using SAM or
/usr/lbin/modprpw -k to reactivate the account, executing getprpw
to determine the lockout reason will always reflect lockout=0100000.
For example:

/usr/lbin/getprpw -m lockout username
lockout=0100000

The user may not have a field named u_suclog in their tcb database
file (/tcb/files/auth/*/username) which contains the system
time of the last successful login to the account.

SAM and /usr/lbin/modprpw seem to only update this field to
reactivate an account if the field already exists. Normally when
the system is trusted the u_suclog entry should be included in
the users database file. But when it isn't and the user doesn't
login before the period of inactivity is exceeded, this problem
occurs.

To resolve this problem, do the following:

1. In SAM, under General User Account Policies, disable the
user's security policy referred to as: Maximum Period of
Inactivity on Account (days).

2. Reactivate the account and have the user login.

This will add the u_suclog entry to the user's database file.

3. Enable the user's Maximum Period of Inactivity on Account
(days) security policy.



if your system are not a trusted system i will check to see if the password is more then 8 char or you never login with the user to the system .

[Tarek]

Thanks both. I hadn't specified before,
but i'm root user. So i will boot in single user and change the password. I thought that maybe there was another way without going personally to the place where the WS is.
Thanks for your help.
Tarek

[Mark Vollmers]

tarek-

while you're in there, take a look at why the account was disabled (password expire, etc). you might want to change this at the same time so that you don't have to do it again later (since it's a bit of a pain to deal with root being disabled). Just a thought.

Mark

[Tarek]

Thanks Mark.
How can i know how was the password disabled??
If there something to check??

[Mark Vollmers]

tarek-

There are a number of things that could cause root to be disabled. It could be a security thing that disables accounts that are inactive for x amount of time (this is set in SAM). It could also be that root lockup up after a number of failed attempts. It could also be that the password expired. I'd go into SAM (once you set the password) and check the aging and security. Also, the last and lastb commands will show who is logging in and failed logins (lastb for this one). If root shows up a lot in the failed log, then someone is trying to log in using that account. Good luck!

Mark

[Tarek]

The fault of the account disabled was because of 3 bad logins. I booted in single user and changed the password, but it still didn't allow me to enter. How can i do?

[Michael Tully]

Hi,

Is your system trusted??

What you have done is actually changed
the root password but the account remains
locked. If the system is trusted you can
try and unlock the account using the
'modprpw' command

# /usr/lbin/modprpw -k root

Suggest you invest some time and install
a product called 'sudo'. It can be found
at the following link. This product can be used to be the root user without directly using the 'root' account and not knowing the password.

http://www.courtesan.com/sudo/


HTH
Michael

[Tarek]

How can i know if my system is trusted or not???

[Mark Vollmers]

tarek-

You should be able to tell if it is in SAM (under auditing and security, I think). Of course, you need to be able to get in first. I'd try the command that Michael gave; if it is a trusted system, it should work. If not, it will probably do nothing. You can't get at the account right now, so it's not like you can screw it up. :) Also, since you now know that it locked up on bad logins, make sure that you were the one attempting to login and not one of your users who's doing stuff they shouldn't be doing. Good luck.

Mark

[Michael Tully]

Hi Tarek,

The easiest way to tell if your system is
trusted or not is tee if the password
encryptions in the password file. If there
are then your system is not trusted. If
there is an '*' in the second field then
the system is trusted. As Mark has pointed
out the 'modprpw' program will only work
on a trusted system.

Hope this clarifies things

Regards
Michael

[G.Kumar]

To find you are in a trusted system; see any files are there in /tcb directory.If the directory is not empty the system is trusted.