Hmmm going completely off on a tangent here, does this mean that if you
run a MSTSC console session to a DC you are exempt from the lockout
policies set by passprop? Interesting (almost anyway!!!) I wouldn't be
too bothered about the log on locally thing otherwise cos if you aint
got your DC's site secure you're kinda asking for trouble anyway :)

Kind regards
Drew

-----Original Message-----
From: Laura A. Robinson [mailto:[EMAIL PROTECTED] 
Sent: 16 November 2005 17:10
To: Dubber, Drew B; 'Derick Anderson'; [email protected]
Subject: RE: Renaming Administrator account

I was going to mention passprop, as well, but it does have some issues
such as a bit of flakiness if you use the NT4 version of it on a post-NT
system, and the Win2K version is buried in a .cab file in the reskit for
Win2K.
Also, of course, passprop only allows for over-the-network Administrator
account lockout; the account can still log on locally to DCs regardless.

Of course, this all leads me to want to discuss the pros and cons of
account lockout policies themselves, but I don't have enough time right
now to be all locquacious and brilliant and starting big long
philosophical discussions. :-)

Laura

> -----Original Message-----
> From: Dubber, Drew B [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 16, 2005 11:07 AM
> To: Derick Anderson; [email protected]
> Subject: RE: Renaming Administrator account
> 
> Have a look at passprop, that allows you to make the admin account 
> subject to lockout. Whether you want to or not is another matter...
> 
> In my opinion, I like icing on cakes! :) At the very least someone has

> to make a conscious effort to find the admin account first.
> 
> Kind regards
> Drew
> 
> -----Original Message-----
> From: Depp, Dennis M. [mailto:[EMAIL PROTECTED]
> Sent: 16 November 2005 03:02
> To: Derick Anderson; [email protected]
> Subject: RE: Renaming Administrator account
> 
> If you rename the domain administrator account, it is still the 
> "administrator" account and is not subject to account lockout 
> policies.
> This policy utilizes the administrator well known sid to determine the

> administrator account, not the name of the account.  While it is 
> security through obscurity, it will protect you against most worms 
> that are in the wild that target the administrator account.
> 
> Dennis
> 
> -----Original Message-----
> From: Derick Anderson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 15, 2005 4:21 PM
> To: [email protected]
> Subject: Renaming Administrator account
> 
> A question for the list, inspired by the server hardening/break in
> threads:
> 
> Is changing the Administrator account name really worthwhile or not? 
> My largely unfounded, sparsely researched opinion is this:
> 
> So far I haven't read a convincing argument for changing the name of 
> the administrator account, and there's one reason I've chosen not to -

> account lockout policy. Only the domain Administrator account is 
> exempt from lockout unless there's a special dispensation for 
> Domain/Enterprise admins I don't know about. So choosing another 
> account (and thus changing the SID) would take away the protection(?) 
> against a DoS attack on the Administrator account.
> 
> As for providing extra security, I believe it's security by obscurity.
> In order to access password-based systems, you have a set of public 
> knowledge (username) and private knowledge (password):
> known * unknown = unknown, or in a (non)mathematical sense for brute 
> force attacks, 1 * ?
> = ?. Now let's say you change the Administrator password, what have 
> you gotten? Unknown * unknown = unknown, or ? * ? = ?. You've changed 
> the equation but not the outcome. I realize that changing the name 
> prevents automated attacks but can't this be defeated by not allowing 
> direct remote Administrator access? (no VPN account, no OWA account, 
> servers locked up in a datacenter...)
> 
> Basically what I'm asking is whether changing the account name is a 
> fundamental princple or just icing on the cake.
> 
> Derick Anderson
> 
> 
> 
> --------------------------------------------------------------
> ----------
> ---
> --------------------------------------------------------------
> ----------
> ---
> 
> 
> --------------------------------------------------------------
> ----------
> ---
> --------------------------------------------------------------
> ----------
> ---
> 
> 
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------
> 


---------------------------------------------------------------------------
---------------------------------------------------------------------------

Reply via email to