Which is why you only use them on trusted machines because they're less likely to have malware.
Sent from my Windows Phone ________________________________ From: Kurt Buff Sent: 2/25/2012 2:41 PM To: NT System Admin Issues Subject: Re: Log on to DC directly 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 ~ 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
