Um, it's *my* workstation. I maintain it. I send the security logs to
my syslog server, same as my servers. Nobody else logs into it without
me knowing about it. If I can't trust that, well, I'm screwed. I think
I'm just fine with this setup, but I have some refinements, both in
place and contemplated.
I have put together a VM on which I've installed a number of critical
applications, such as the firewall management app, the various SAN
management apps, the RSAT tools, and others. I trust that one as well,
but only log into it with my DA account, and it's in a separate OU for
management purposes.
And, while I currently only have two accounts - my standard user
account, and my DA account, I'm contemplating three more personal
accounts, in order of priority:
o- An account with which I log into other users' workstations
(and terminal servers), which will be a member of a "workstation
administrators" group that already exists and also applies to our
Terminal Server machine
o- An account with which I log into other servers, such as
file/print, SQL, or other application servers, which other IT staff
(who are not DAs) might log into for administrative purposes
o- An Exchange Admin account to log into Exchange servers (and
which is not the Exchange Service account)
My standard user account is a member of the "workstation
administrators" group, and I don't log into users' machines with my DA
account.
In a small (three person) infrastructure team which is part of a small
IT staff (7, including manager, dba/crm guy, web app guy and ERP guy),
I think we're doing fairly well. It's a struggle to get my
infrastructure team to understand some of the security details, but
they're slowing getting there.
Kurt
On Fri, Feb 24, 2012 at 19:40, Crawford, Scott <[email protected]> wrote:
> The bottom line rule should be only enter DA credentials into trusted
> machines. I'd much rather interactively log into a DC than use DA creds on an
> untrusted machine. You might want to investigate how much you *really* need
> to use DA credentials.
>
> -----Original Message-----
> From: Kurt Buff [mailto:[email protected]]
> Sent: Friday, February 24, 2012 5:21 PM
> To: NT System Admin Issues
> Subject: Re: Log on to DC directly
>
> Well, let's see.
>
> If you're not supposed to log into the DC interactively with your DA account,
> and you not supposed to use your workstation to use the RSAT tools in a
> non-interactive fashion with your DA account (that is, so that it doesn't
> create a local DA account profile), and you can't login interactively into
> your workstation with your DA account, what are you left with?
>
> Kurt
>
> On Fri, Feb 24, 2012 at 14:16, Crawford, Scott <[email protected]> wrote:
>> Unfortunately, doing this violates "shouldn't log into a workstation with
>> your DA account." Granted, it's better than logging in interactively.
>>
>> -----Original Message-----
>> From: Kurt Buff [mailto:[email protected]]
>> Sent: Friday, February 24, 2012 1:56 PM
>> To: NT System Admin Issues
>> Subject: Re: Log on to DC directly
>>
>> On Fri, Feb 24, 2012 at 11:19, David Lum <[email protected]> wrote:
>>> Barring being an SBS domain, is there really any reason someone needs
>>> to log in to a DC directly unless installing an app?
>>>
>>> David Lum
>>> Systems Engineer // NWEATM
>>> Office 503.548.5229 // Cell (voice/text) 503.267.9764
>>
>> Some network diagnostics will only work from there, for sure (ping, etc.).
>>
>> But for daily operations, not so much.
>>
>> Below is a set of command lines that I use from an elevated prompt to start
>> the RSAT and other tools on my Win7 workstation. I log in as a standard
>> user, open cmd.exe as administrator, then copy/paste these into the command
>> prompt, each of which uses my Domain Admin account to do what I need to do.
>>
>> The nice thing is that opening these apps in this fashion doesn't put a
>> profile for my DA account on the local machine, and we all know that you
>> shouldn't log into a workstation with your DA account.
>>
>> I keep a notepad with the commands open at all times.
>>
>> Kurt
>>
>>
>>
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\dsa.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\dssite.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\domain.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\gpmc.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\dhcpmgmt.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\dnsmgmt.msc /s"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\eventvwr.msc /s runas /netonly
>> /user:[email protected] "C:\windows\system32\mmc.exe \"C:\Program
>> Files\Update Services\administrationsnapin\wsus.msc"\"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\tsadmin.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\compmgmt.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\cmd.exe"
>> runas /netonly /user:[email protected]
>> "C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe"
>> runas /netonly /user:[email protected]
>> "C:\windows\system32\explorer.exe"
>> runas /netonly /user:[email protected] "C:\windows\system32\msra.exe
>> /offerra"
>> runas /netonly /user:[email protected]
>> "C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe"
>> runas /netonly /user:[email protected]
>> "C:\windows\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe"
>> runas /netonly /user:[email protected] "C:\utils\procexp.exe"
>> runas /netonly /user:[email protected] "C:\Program Files (x86)\Sunbelt
>> Software\Enterprise\EnterpriseConsole.exe"
>> runas /netonly /user:[email protected] "C:\Program Files
>> (x86)\Microsoft\Exchange Server\V14\ExPDA\ExPDA.exe"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\adsiedit.msc"
>> runas /netonly /user:[email protected] "C:\windows\system32\mmc.exe
>> C:\windows\system32\pkiview.msc"
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>>
>> ---
>> To manage subscriptions click here:
>> http://lyris.sunbelt-software.com/read/my_forums/
>> or send an email to [email protected]
>> with the body: unsubscribe ntsysadmin
>>
>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>>
>> ---
>> To manage subscriptions click here:
>> http://lyris.sunbelt-software.com/read/my_forums/
>> or send an email to [email protected]
>> with the body: unsubscribe ntsysadmin
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to [email protected]
> with the body: unsubscribe ntsysadmin
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to [email protected]
> with the body: unsubscribe ntsysadmin
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin
