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
