Urgent - Stop shutdown command from shuting down domain stations

  • Thread starter Thread starter Mac
  • Start date Start date
M

Mac

Hello,

In our organization in adition to me one of the managers has the admin
password to 2000 active directory domain.

He has recently learned to restart the stations using "shutdown -i" (he
uses the administrator account and he himself told me that he makes fun
by shutting down some people's computers)

Is there any domain policy that can disable this feature and stop the
administrator from shutting down stations?

This is going to cost my job.

Regards,
Mac
 
For domain computers other than domain controllers, open Local Security
Policy and look under security settings/local policies/user rights there is
a user right for "shut down the system". Only users/groups that have this
user right can shut down a computer. Normally for domain computers that user
right is configured in Local Security Policy, but if you configure it at the
domain level it will override local settings.

Having said that you should go to the powers that be about this. I
understand this is political and maybe you can only do so much. Also no one
should share a administrators account. Each person that needs administrator
access needs their own admin account. The built in administrator account
can be disabled in W2003, otherwise it can be configured with a multi part
password that only one user knows their part and the password is stored in a
sealed envelope in a safe somewhere. Then you can enable account logon,
system events, policy change, and account management events in Domain
Controller Security Policy and logon events, system events, and account
management in Domain Security Policy. That will help track what
administrator does what including shutting down/rebooting a computer [look
in security log of computer restarted] , changing user rights, and resetting
passwords. Note that any administrator can clear security logs but that in
itself will leave an event in the log unless the user uses malicious ways to
delete the security log. Hopefully some of this will help. The link below
give much more detail on auditing. If you enable auditing be sure to
increase the size of the security log quite a bit to say at least 10 MB.
Good luck. --- Steve

http://www.microsoft.com/technet/security/guidance/secmod144.mspx
 
Which aspect of this problem is going to cost you your job --

* that a non-admin person knows the admin password
* that this person gleefully causes denial of service attacks
* that you need a way to stop this behavior

If you report directly to the trouble-causing manager, you have no way to
solve your problem short of leaving before you get fired. It is career
suicide to work for someone who blatantly abuses privileges they (rightly or
wrongly) possess. This person will do everything in his/her power to deflect
all blame toward you.

If you don't work for this manager, what if you just change the admin
password? Will there be any repercussions? Will your manager support your
decision when this abusive manager complains his fun has been taken away?

Steve Riley
(e-mail address removed)
 
Quite the analysis Steve.

I would propose that, even if OP does report to this manager, if you
are right that the OP sooner or later will take heat or leave, it may be
possible for the OP to change all admin passwords and refuse to
disclose them unless//until this manager came to terms with just what
responsible action is (assuming this is within their means).
The manager would not elevate to next higher mgmt, the manager
could not just discipline/releave the OP, . . . That manager would be
between a rock and a hard place and would not want it to be known.

The OP (assuming the bahaviors of the manager could be established)
could certainly make a case for having prevented disruptive activity
that was resulting in productivity loss. It is a matter of whether the
remaining work environment would be breathable .
 
Hello,

Actually he is vice president of a bank with 300 branches and I can
never win if I announce this. I'd rather stop this quietly.

Regards,
Mac
 
That is tough.
Consider that "the Administrator" of the first DC is by the predefined
default recovery agent for EFS
I would suggest that you use this fact, that the (currently shared?)
Administrator account has special properties, and (if you are a US firm)
use the privacy of financial records laws, to motivate defining accounts
for privileged use. Indicate that this is to assure accountability via the
logging. Then, define accounts (not necessarily members of either the
Administrators group or the Domain Admins group) that have delegated
what is needed for the tasks to be done.
Outline that transitioning to the use of personally unique privileged
accounts
is an essential part of a strategy for securing the environment and for
complying with US laws.
 
Good strategic call!

It bridges the gap between technical (almost nothing is impossible) vs what
business really understands or cares about like SOX (or need to be educated
if not).
 
Back
Top