Implications in changing the Administrator password

[Guest]

Ok, I've seen the billions of posts on how to do it, but its all basic stuff. I went through this process on NT4, but Windows 2000 with AD is not as familiar to me.

Ok, so we will be having IT staff leaving soon, so we need to change the domain administrator's password. We have the following Microsoft server products running in our domain:
- Windows Server 2000
- Exchange Server 2000
- ISA Server (2000?)
- SQL Server 2000

Servers are set up as follows:
- File server (domain controller, secondary DNS, DHCP)
- Exchange server (domain controller, primary DNS)
- ISA server (member server)
- SQL server (member server)

What are the implications of changing our domain administrator account, if nearly all of the services on each server is set to "logon as system"

 

[SaltPeter]

Ok, I've seen the billions of posts on how to do it, but its all basic

stuff. I went through this process on NT4, but Windows 2000 with AD is not
as familiar to me.

Ok, so we will be having IT staff leaving soon, so we need to change the

domain administrator's password. We have the following Microsoft server
products running in our domain:

- Windows Server 2000
- Exchange Server 2000
- ISA Server (2000?)
- SQL Server 2000

Servers are set up as follows:
- File server (domain controller, secondary DNS, DHCP)
- Exchange server (domain controller, primary DNS)
- ISA server (member server)
- SQL server (member server)

What are the implications of changing our domain administrator account, if nearly all of
the services on each server is set to "logon as system"

If i understand you correctly, you are letting IT staff share a single
administrator account. This is a critically dangerous policy from both a
security and accountability point of view. Lets face it, should you decide
to audit a given resource, how do you know who was the admin at the time the
audit triggerred?

Each IT staff member should be provided with both a normal account and an
administration account where the later inherits its administrative rights
through domain group inheritence. The original administrator account can
then be renamed, secured with a serious password, and carefully audited for
intrusion detection.

If that staff member leaves, you disable his/her accounts (the original
administrator account is never involved). Also, operating a domain of that
size on a single administrative account is suicide.

Suggestion: re-evaluate your company policy when it comes to
administrator(s).

 

[Guest]

Ah, I can see how you came to that conclusion!!!

Ok, the account Administrator for our domain is know by all in our IT dept, but is only used for server functions - each IT staff member has their own logon with domain admin rights for normal use

 

[SaltPeter]

Ah, I can see how you came to that conclusion!!!

Ok, the account Administrator for our domain is know by all in our IT

dept, but is only used >for server functions - each IT staff member has
their own logon with domain admin rights >for normal use

Your original admin should not be distributed. I'm not refering to a local
administrator, but rather the original domain administrator account.

OK, perhaps i'll counter with detailing how we work here. IT department each
have a normal domain user account(whether that account is a local admin to
that station is irrelevent). If i walk up to an unlocked, unmanned system
with an active user login thats a normal domain user, thats accepted. Again,
if that domain user is admin locally, its irrelevent.

Each appropriate IT user also has a domain-wide or OU-delegated
administrative account. Only used to perform administrative tasks on the
domain. Example: IT user logs on as normal user, executes "run as..." to run
an administrative tool with alternative administrative credentials.

If i walk up to an unlocked, unmanned desktop and the active logon is a
domain or OU administrative logon, he or she gets fired on the spot. Even if
he or she went for a pee. This way, the only time the user's domain admin
account is ever used is with the run as... command. And there is no such
thing as an unmanned and unlocked server here. This policy is strictly
enforced.

Do this: log on as a normal domain-user at a client. Find a shortcut or MMC
console, press and hold Shift + right-click. See the previously hidden "run
as..." entry? So there is no excuse.

HOW TO: Enable and Use the "Run As" Command When Running Programs in Windows
http://support.microsoft.com/default.aspx?scid=kb;en-us;294676&sd=tech