That's the risk you take logging in *anywhere* with elevated
credentials, even a DC.

By your logic, I can't actually use a DA account anywhere.

On Sat, Feb 25, 2012 at 06:03, Crawford, Scott <[email protected]> wrote:
> I can see that there is a difference between there, but the bottom line is
> that malware can doesn't need to leverage stored credentials if it can just
> wait for you to type them in.
>
> Sent from my Windows Phone
> ________________________________
> From: Kurt Buff
> Sent: 2/25/2012 1:27 AM
>
> To: NT System Admin Issues
> Subject: Re: Log on to DC directly
>
> What I want is to avoid leaving my DA credentials in the local cache,
> because to my mind, and from what I've read about and seen, that's the
> biggest risk to the infrastructure.
>
> The "runas /netonly" incantations absolutely avoid that. Quitting the
> apps running under those incantations when not actively being used
> certainly helps, but the major thing is to not leave those credentials
> on disk, in whatever form, to be attacked by malefactors.
>
> Kurt
>
> On Fri, Feb 24, 2012 at 23:13, Crawford, Scott <[email protected]>
> wrote:
>> Sounds like you're on the right track. I didn't mean to imply that you
>> absolutely shouldn't log into your workstation. Simply that what you
>> described contradicted your desire to avoid logging into your workstation
>> with DA creds.
>>
>> -----Original Message-----
>> From: Kurt Buff [mailto:[email protected]]
>> Sent: Saturday, February 25, 2012 12:33 AM
>> To: NT System Admin Issues
>> Subject: Re: Log on to DC directly
>>
>> 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
>>
>>
>> ~ 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

Reply via email to