Re: User Activities

I think I understand the situation a bit better now, but...

When you refer to "the system administrator ID", is that the domain
administrator account, or the administrator account local to the machine
that was attacked?

Also, the perpetrator is said to have logged on to the victim's PC "through
their workstation": how did they do that, using remote desktop?

As I see it, then, the perpetrator logged into workstation "A" using account
"B", then ran MSTSC.exe to connect to XP system "C", where he then "logged
in" as the administrator. In order to determine the actual identity of the
person, you would first need to know that there would be a one-to-one
relationship between the personal accounts used and the owners of those
accounts. In other words, if you could determine that which actual account
is what I have referred to as account "B", then its owner would be the bad
guy.

If you could determine the originating PC, I would suspect you have already
been looking at the event log entries most likely to contain this
information. It might not give a workstation name, but perhaps some
identification of the connection that could be traced back somehow. Sorry,
but I don't know much about that.

If you could do that, then you would still need to figure out which account
was the last one to logon to workstation "A" before the time of the event.
Again, that should be found in the event viewer, this time of the bad guy's
workstation.

But you asked about finding out from the domain controller which computer
"this person logged in from". As I understand it, the domain controller may
not actually keep such records. Even if it did, I don't think it would keep
a perpetual log of who logged in where and when - perhaps just some stats on
the last workstation a person logged in from. Someone in my organization has
stated that there is a way to do this by enabling some AD feature, but
nobody has been able to give me any actual details. And anyway, in this
case, I don't think you know who the person is in the first place, so it
would be difficult to find out where he logged in from.

I would think that you might need to use other, perhaps less technical,
methods to determine who did what, and how, and why. For example, do you
have security cameras...


As to how to prevent this kind of thing from happening, I believe one of the
best things is to stop allowing accounts (especially privileged ones) from
being shared. The actual administrator account, whether a domain admin or a
local admin on a server or workstation, should almost never be used. Those
individuals whose roles require administrative access to some resource
should each be given their own administrative account (separate from the
personal account they use for email and etc) that is added to whatever
groups required, whether the administrators group local to a workstation or
server, or the "domain admins" group in the domain. The structure of these
permissions should be such that you can readily ensure that the admin users
have admin access only to those resources they have a responsibility for.

Passwords to actual administrator accounts should not generally be known by
anyone, and perhaps left locked up somewhere in case they are ever needed. I
am an administrator on one server, but I have absolutely no idea what the
password for the administrator account is, and only knew it when it was
created at install time. Since then it has been managed and secured
remotely.

This will not prevent the rogue admin syndrome from happening. But since
they will have to use an account whose password should be known only to
them, your list of suspects will be much shorter. And perhaps this
additional accountability will dissuade some from even going rogue in the
first place.


/Al

"tslu" <tslu69@xxxxxxxxx> wrote in message
news:u$K%23N2OoHHA.3264@xxxxxxxxxxxxxxxxxxxxxxx
Hi Al,

okay, let me elaborate on the network setup. We have a MS 2003 Server as
the domain controller. I suspect an employee who used the system
administrator ID and password to logged into a PC through their
workstation and deleted files and folders. This person is one of 3
persons who has the password and ID to the administrator password.

From victim's PC, we are able to view from the event viewer that the
administrator had logged in and deleted something. How we come to know of
the incident was that the user complained of missing folders.

What I am concerned with, am I able to view MS 2003 server log to know
which PC this person logged in from. Or maybe tools available.

Maybe you can give me some guidelines to prevent this type of incidents
happening.

Al Dunbar wrote:
"tslu" <tslu69@xxxxxxxxx> wrote in message
news:ubAdcNmnHHA.3512@xxxxxxxxxxxxxxxxxxxxxxx
Hi, I have a situation where an employee had logged into the domain
network as an administrator and got into a PC to delete certain folders
in that PC.

Can I obtain information such as :
1. Which PC the administrator logged in from
2. Which PC the administrator got into
3. Time and date the incident happen

You don't give much to go on. For example, do you know the administrator
account that was used? Do you know who it was that did this? Is that
person authorized to use the administrator account.

And, if you do not know on which PC this happened, how did you become
aware that any folders went missing?

As to the specifics:

1. I don't know of a standard way to determine this. we do it by
examining logs created by our logon scripts, but even then, a rogue
administrator would be able to cover his tracks. I have been told that
ad2003 may have a way of doing this, but the feature needs to be enbaled,
as it is off by default.

2. you could search the hard drives of all workstations to see which one
has these particular folders missing. Not much good if it was unique
information and you want it back.

3. if you are not already doing extensive auditing, this may not be
possible. That said, it might be worth having a close look at event
viewer to see what kinds of events are being recorded there.


/Al





.

Relevant Pages

  • Re: Keep admins off of client machines
    ... the sharepoint admin is simple, just create a standard user account for them ... The 'Domain Administrator' account is ... Domain Administrator password. ... takes a thorough understanding of such priveleges to do so. ...
    (microsoft.public.windows.server.sbs)
  • Re: firewall on budget ?
    ... 1)Work in Admin mode, and through 'run as', browse ... If working in admin mode and doing runas to browse in a guest account. ... Installing a program, getting an error, then doing the run as, can be ... running as administrator all the time. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: XP (SP2) user passwords
    ... Safe Mode requires an administrator to log on the machine. ... I always suggest checking who has Admin accounts, ... administrator account, which normally does not appear, and in SP2, I don't ...
    (microsoft.public.windows.mediacenter)
  • Re: User Activities
    ... The only logs I mentioned were the event logs (they can be found in the ... When you refer to "the system administrator ID", ... administrator account, or the administrator account local to the machine ... "through their workstation": how did they do that, ...
    (microsoft.public.windows.server.security)
  • Re: Could this be an XP problem?
    ... >> This means you have admin access under jlunis login. ... This is one way to get in as admin in XP home. ... >> tab) then type in administrator as username and blank password. ... administrator account. ...
    (microsoft.public.windowsxp.general)