I would like to get a feel for suggestions on the local admin account.
Do your field techs know what the password is? Do you change it when one
of them leave? Are there any standards posted on the Internet?

Re: Local Workstation Admin by Shenan

Shenan
Fri Feb 04 09:26:16 CST 2005

Al Wilson wrote:
> I would like to get a feel for suggestions on the local admin account.
> Do your field techs know what the password is? Do you change it
> when one of them leave? Are there any standards posted on the
> Internet?

Standards for passwords depend on your situation and policies.

I would say that field techs might know local PC administrative level
passwords - but unless they are involved with management of the Domain -
they should not know the domain level admin password(s).

You should always change your passwords when anyone you have given it to
leaves the company. That's just common sense.

I have no idea if there are any "standards" posted on the internet for
company policies such as this. Perhaps Google can help you there?

--
<- Shenan ->
--
The information is provided "as is", it is suggested you research for
yourself before you take any advice - you are the one ultimately
responsible for your actions/problems/solutions. Know what you are
getting into before you jump in with both feet.



Re: Local Workstation Admin by Al

Al
Fri Feb 04 15:16:23 CST 2005

Thanks for taking the time to reply.

I guess the questions boils down to -
"Is there an easy way to change the local admin password via the domain when
it is viewed as compromised?"
"Do companies regular give out this type of access, or do they just rely on
the ability to authenticate to the Domain for techs?"





Re: Local Workstation Admin by Torgeir

Torgeir
Fri Feb 04 15:22:40 CST 2005

Al Wilson wrote:

> Thanks for taking the time to reply.
>
> I guess the questions boils down to -
> "Is there an easy way to change the local admin password via the
> domain when it is viewed as compromised?"
Hi

Yes, if this is an Active Directory domain:

You could do it in a computer startup script (with a GPO) that runs
as part of the boot up process (before the user logs in). It runs
under the system context and has admin rights.

To avoid users being able to read the script where the password is
stored, grant read access only for the AD group "Domain Computers"
to the script file.


As long as the Administrator account name is "Administrator", this
batch file will set the password on the account:

'--------------------8<----------------------
@echo off
net.exe user administrator newpassword
'--------------------8<----------------------


As long as the Administrator account name is "Administrator", this
vbscript will set the password on the account:

'--------------------8<----------------------
sNewPassword = "testpassword"
Set oWshNet = CreateObject("WScript.Network")
sComputer = oWshNet.ComputerName

On Error Resume Next
Set oUser = GetObject("WinNT://" & sComputer & "/Administrator,user")
oUser.SetPassword sNewPassword
oUser.SetInfo
On Error Goto 0
'--------------------8<----------------------


If there is a chance that the name of the administrator is not
"Administrator" (e.g. the account is renamed, or you have some
non-English OS versions), you could use this version instead:

'--------------------8<----------------------
sNewPassword = "testpassword"
Set oWshNet = CreateObject("WScript.Network")
sComputer = oWshNet.ComputerName
sAdminName = GetAdministratorName

On Error Resume Next
Set oUser = GetObject("WinNT://" & sComputer & "/" & sAdminName & ",user")
oUser.SetPassword sNewPassword
oUser.SetInfo
On Error Goto 0


Function GetAdministratorName()

Dim sUserSID, oWshNetwork, oUserAccount

Set oWshNetwork = CreateObject("WScript.Network")
Set oUserAccounts = GetObject( _
"winmgmts://" & oWshNetwork.ComputerName & "/root/cimv2") _
.ExecQuery("Select Name, SID from Win32_UserAccount" _
& " WHERE Domain = '" & oWshNetwork.ComputerName & "'")

On Error Resume Next
For Each oUserAccount In oUserAccounts
If Left(oUserAccount.SID, 9) = "S-1-5-21-" And _
Right(oUserAccount.SID, 4) = "-500" Then
GetAdministratorName = oUserAccount.Name
Exit For
End if
Next
End Function
'--------------------8<----------------------




--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx

Re: Local Workstation Admin by Shenan

Shenan
Fri Feb 04 15:50:09 CST 2005

Al Wilson wrote:
> Thanks for taking the time to reply.
>
> I guess the questions boils down to -
> "Is there an easy way to change the local admin password via the
> domain when it is viewed as compromised?"

Torgeir Bakken (MVP) wrote:
> Yes, if this is an Active Directory domain:
>
> You could do it in a computer startup script (with a GPO) that runs
> as part of the boot up process (before the user logs in). It runs
> under the system context and has admin rights.
>
> To avoid users being able to read the script where the password is
> stored, grant read access only for the AD group "Domain Computers"
> to the script file.
>
>
> As long as the Administrator account name is "Administrator", this
> batch file will set the password on the account:
>
> '--------------------8<----------------------
> @echo off
> net.exe user administrator newpassword
> '--------------------8<----------------------
>
>
> As long as the Administrator account name is "Administrator", this
> vbscript will set the password on the account:
>
> '--------------------8<----------------------
> sNewPassword = "testpassword"
> Set oWshNet = CreateObject("WScript.Network")
> sComputer = oWshNet.ComputerName
>
> On Error Resume Next
> Set oUser = GetObject("WinNT://" & sComputer & "/Administrator,user")
> oUser.SetPassword sNewPassword
> oUser.SetInfo
> On Error Goto 0
> '--------------------8<----------------------
>
>
> If there is a chance that the name of the administrator is not
> "Administrator" (e.g. the account is renamed, or you have some
> non-English OS versions), you could use this version instead:
>
> '--------------------8<----------------------
> sNewPassword = "testpassword"
> Set oWshNet = CreateObject("WScript.Network")
> sComputer = oWshNet.ComputerName
> sAdminName = GetAdministratorName
>
> On Error Resume Next
> Set oUser = GetObject("WinNT://" & sComputer & "/" & sAdminName &
> ",user") oUser.SetPassword sNewPassword
> oUser.SetInfo
> On Error Goto 0
>
>
> Function GetAdministratorName()
>
> Dim sUserSID, oWshNetwork, oUserAccount
>
> Set oWshNetwork = CreateObject("WScript.Network")
> Set oUserAccounts = GetObject( _
> "winmgmts://" & oWshNetwork.ComputerName & "/root/cimv2") _
> .ExecQuery("Select Name, SID from Win32_UserAccount" _
> & " WHERE Domain = '" & oWshNetwork.ComputerName & "'")
>
> On Error Resume Next
> For Each oUserAccount In oUserAccounts
> If Left(oUserAccount.SID, 9) = "S-1-5-21-" And _
> Right(oUserAccount.SID, 4) = "-500" Then
> GetAdministratorName = oUserAccount.Name
> Exit For
> End if
> Next
> End Function
> '--------------------8<----------------------

Adding to what Torgeir Bakken already put (following the logic really) - I
would also rename the administrator account on all the PCs and rename the
guest account to administrator.

Although in some ways this is practicing 'security by obscurity' - which is
not something I would usually press - in this case it is an effective
measure against the "weekend warrior" hacker - who gets the laptop home and
notices they cannot install "xxxxx" piece of software, but knows they
probably could if they were administrator and they know (from hearing people
talk) the username is usually "administrator" - blah blah blah.

It can also stop some simple kiddie-scripting attacks, because they might
break the "administrator" password, but since that is now the guest account
renamed (and it is disabled) - more power to them.

It does not stop more sophisticated attacks or people, however, who would
look for (using something like Torgeir Bakken's "GetAdministratorName"
function above) the actual administrative users. However, it is something
simple to do when pushing out the new password via scripts anyway. =)

--
<- Shenan ->
--
The information is provided "as is", it is suggested you research for
yourself before you take any advice - you are the one ultimately
responsible for your actions/problems/solutions. Know what you are
getting into before you jump in with both feet.



Re: Local Workstation Admin by SuperTech

SuperTech
Fri Feb 04 17:50:08 CST 2005

"Al Wilson" <wilsona12@yahoo.com> wrote in
news:ekGdnGsCFHA.3596@TK2MSFTNGP12.phx.gbl:

> I would like to get a feel for suggestions on the local admin
> account. Do your field techs know what the password is? Do you
> change it when one of them leave? Are there any standards posted
> on the Internet?

Yes, field techs have this where I am.

No, we don't change it when someone leaves.

Standards on the Internet? Sure, probably somewhere.

However, changing a local administrator password is laughably easy by
someone that does not know it so I would not be too worried about that.
Be worried about domain administrator and enterprise accounts much more
than local accounts!

SuperTech

Re: Local Workstation Admin by Roger

Roger
Sat Feb 05 00:28:42 CST 2005

My preferred solution is, roughly, composed with elements from:
1. Machine local (desktop) administrator account is renamed
and has a extremely long/complex, uncrackable password.
If the OS allows, the machine local admin is restricted to
local console login only.
2. The machine local admin account password is changed
periodically, but not extremely so, either by a remote
script run in a Domain Admin context or by a machine
startup script (make sure that it is only readable by the
Domain Computers group).
3. Techs obtain administrative power on the desktop via a
domain group that is in the machine local administrators grp
and so use a minimally privileged domain account to service
the desktops. The desktops are ideally grouped such that
the workstation admin groups (those from the domain that
are in the workstations' administrators groups) each only
cover a smaller, logical set of machines. These domain
workstation administrative groups may, ideally, be normally
empty, with Tech accounts placed in them when/as needed,
perhaps by the Techs themselves - but if so there is nightly
reporting on content of these groups. Senior Techs of tenure
might have normal membership in such groups, and/or might
be the ones controlling memberships of these groups.
4. The Techs do not know the machine local admin password,
and change may be called for after its use has been needed
(This all goes back to the sensitivity of info that may be
on or passing through the dsktp machines and the degree
of trust in the Techs).
5. Techs are expected to use a plain user account at their
own desktop for day-to-day. Accounts that are empowered,
for servicing dsktp machines or via AD delegations, are not
for use as their office, day-to-day login.
6. Depending on the category of Tech, their accounts (that is,
the domain's dsktp admin groups for that category of Tech)
may be specifically denied network login on the dsktp
machines, i.e. local login only allowed.

The machine local admin account is only needed when the
machine is not able to speak with domain control. Having
a crackable password that is everywhere the same is a large
risk. Anyone grabbing the SAM of one will be able to due
large-scale damage to dsktp machines across the enterprise.
Having a machine local admin account that does not have an
everywhere the same password becomes complicated when
the account is needed, hence the compromise, everywhere
the same (or one of a very few sets based on factors more
like dsktp sensitivity than simply OU structure). but extremely
long/complex, etc. = uncrackable.

The extent to which one moves in the above directions is
something one must judge based on the environment.
Is this a healthcare org and its offices, or is this a trucking
company tracking its shipments and routing schedules? etc.
What are the risks and types of costs from having unauthorized
access to potentially all desktops with administrative rights?

As always, security has costs and inconveniences. Where one
sets the dial is a unique decision for each environment.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Al Wilson" <wilsona12@yahoo.com> wrote in message
news:ekGdnGsCFHA.3596@TK2MSFTNGP12.phx.gbl...
> I would like to get a feel for suggestions on the local admin account.
> Do your field techs know what the password is? Do you change it when one
> of them leave? Are there any standards posted on the Internet?
>
>



Re: Local Workstation Admin by Roger

Roger
Sat Feb 05 00:31:56 CST 2005

Let me rephrase that:
Assume that something will penetrate your network,
virus, worm, bot, disgruntled fireling, whatever, and
it is sufficiently smart to assume that it can crack the
built-in admin account pwd and then try this account
name and password with every machine it can see on
your network.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Al Wilson" <wilsona12@yahoo.com> wrote in message
news:ekGdnGsCFHA.3596@TK2MSFTNGP12.phx.gbl...
> I would like to get a feel for suggestions on the local admin account.
> Do your field techs know what the password is? Do you change it when one
> of them leave? Are there any standards posted on the Internet?
>
>



Re: Local Workstation Admin by Aaron

Aaron
Fri Feb 18 13:30:31 CST 2005

Shenan Stanley wrote:
> Al Wilson wrote:
>
>>I would like to get a feel for suggestions on the local admin account.
>>Do your field techs know what the password is? Do you change it
>>when one of them leave? Are there any standards posted on the
>>Internet?
>
>
> Standards for passwords depend on your situation and policies.
>
> I would say that field techs might know local PC administrative level
> passwords - but unless they are involved with management of the Domain -
> they should not know the domain level admin password(s).
>
> You should always change your passwords when anyone you have given it to
> leaves the company. That's just common sense.
>
> I have no idea if there are any "standards" posted on the internet for
> company policies such as this. Perhaps Google can help you there?
>

At the place I work we have each local Admin password set to a randomly
generated 10 digit code. The code for each pc is stored in a database
for retrieval when we need it. This makes logging on as a local admin a
bit more work but we no longer have a problem with having to change 2000
desktops' admin passwords when someone leaves on bad terms. A technician
that needs the local admin password can call any of our full time
employees and get the password. All our technicians are in a domain
group that is added to each pc in the administrators groups. This makes
the need for the local admin password only when the domain isn't
available to authenticate.