Re: Local Admin Access

["Lovaas,Steven" <Steven.Lovaas () COLOSTATE EDU>]

Clark, this is the best thing I've read all week!

Steve Lovaas
Colorado State University


Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> on behalf of Clark Gaylord 
<cgaylord () VT EDU>
Sent: Friday, May 14, 2021 8:44:48 AM
To: SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Local Admin Access

Mark Herron asked that I follow up on one of my points: that NULL is the Correct password for local administrative 
accounts, to wit, why?

As some may know -- though as Mark pointed out to me, if you Google for recommendations it seems that our professional 
is (unsurprisingly) woefully ignorant of -- there has been since Windows XP/2003 a default local security policy to 
prohibit network connections for accounts with null passwords.

When coupled with the use of RunAs/Secondary Login, this removes the dominant component of the threat model: that 
remote access with administrator accounts is a serious threat -- we saw a *lot* of this with Windows 2000! [Btw, that 
was 20 years ago.] The next threat model would be exploiting an active administrator session, for example using drive 
by client attacks -- which Secondary Login mitigates. The final component to allowing users to have administrative 
access is that they might install "unauthorized" software, which is mostly a paper tiger in the first place.

Which speaks to the real reason we don't want to allow users to have administrative access: because we don't want users 
to have administrative access ... which further speaks to the biggest threat of all ....

--ckg


On Mon, May 10, 2021 at 12:30 AM Clark Gaylord <cgaylord () vt edu<mailto:cgaylord () vt edu>> wrote:
> From previous environment, though lessons learned continue to inform and apply:

All users have a separate local admin account on their computer and are shown how to use "RunAs/secondary login"; admin 
rights are removed from the user's normal account. This latter policy is exempted in very rare cases where applications 
require it (it happens but it's rare; sometimes custom filesystem permissions etc can avoid it).

This policy began applied to portable systems only, several years ago. After a few years of zero incidents and user 
contentment, plus 2/3 were laptops anyway, this was broadened to fixed systems (outside true "shared" systems like 
labs). We still would offer support for installing software, etc, but this cuts down on needless help desk costs for a 
policy that accomplishes effectively nothing except exacerbating security hostility. This also helps greatly when 
trying to help users over the phone when they live in the middle of a forest 1,000 miles away.

This policy was universally derided by support staff and sysadmins who failed to recognize that they are a far bigger 
security threat than users who occasionally have the temerity to install Notepad++ (*) or a home printer. After several 
years of zero "user admin" related incidents, the point was conceded. Note that we *had* seen occasional incidents with 
the previous "some users are granted admin rights" policy -- by using secondary login, incidents effectively 
disappeared. But the big win is the improved user/IT relationship, which has huge security benefits.

On rare occasions, we'd find users, always developers/engineers, who thought they knew better than IT, who would abuse 
this and use their local admin as their daily driver. This never created large security issues (it's still just local 
admin after all, and these people are not very common) but periodically they'd shoot their foot off. The biggest 
problem with these users is not security per se but support; they tend to let very legitimate system issues persist 
(like a busted GPU that causes their system to blue screen a few times each month) because they don't want the support 
desk to see that they abuse the policy.

An interesting nit is that probably null password is the ideal choice for Windows systems, but we were always 
(irrationally) nervous of this policy. With that said, it is harder to enforce strong passwords on local accounts; our 
help desk would create with a good random password and get the user to record in their password safe (typically 
LastPass). We drove weak domain passwords to *zero* by regularly cracking user passwords and aggressively pursuing 
crackables. This is harder for local accounts. Ideally, we'd harvest all local SAMs and crack those but this never 
proved to be worth the effort. Users actually became pretty good at choosing passwords and using LastPass, and most 
just kept the password we assigned (IIRC 16 random lowers with dashes between each four was the common approach -- 
that's more than 64 bits of entropy, so not bad, and certainly better than anything you see in the wild).

Now, a much bigger threat was the help desk staff shared password(s), also a local account. Sysadmins had domain admin, 
but help desk had shared local admin accounts. These had been terrible passwords (and the same everywhere), and it is 
here that LAPS proved invaluable. We found we had to remain vigilant or the staff would frequently revert to poor 
practices where they could. You can also use domain accounts for this, but we found local admin with LAPS more usable.

One other nit is that this practice is a problem for homebrew on Mac. Brew assumes the account running has sudo, but 
you'll find things that don't work right if they're installed by the admin account. This is a serious homebrew 
deficiency and requires regular permission tweaking. For most Mac users who are homebrew-savvy, it's manageable, but 
it's a PITA for sure.

--ckg


(*) Yes Notepad++ is one of the few applications that can install successfully in the user's profile.... But you get 
the point.

--
Clark Gaylord
cgaylord () vt edu<mailto:cgaylord () vt edu>
... autocorrect may have improved this message ...

On Wed, Apr 7, 2021, 13:04 Emilie Kunze <ekunze () austincc edu<mailto:ekunze () austincc edu>> wrote:
We are curious how other institutions handle local admin access for faculty/staff?

Thank you,
Emilie


[https://lh5.googleusercontent.com/8TGVFPsiEyy3_TXFjMAe-lCBkyXwyGevnGxIvGdvcCw3hjOZXmPHYbmZT0pi_gZG5RkwAY-Hr0A_XFdoepzZEFuNDmYnRMqD-9ud3Hyk-fMTIXJpmQ2qt5M1SGUDHcrQ6M_D9CrN]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Faustincc.edu%2F&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063483837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AOr%2FVgxdn8V%2FodiV7RmLgAjW4IurHK9ifGDxOXdfk4E%3D&reserved=0>

Emilie Kunze

IT Security Analyst Sr.

Acting Information Security Officer

Office of Information Technology

ekunze () austincc edu<mailto:ekunze () austincc edu>  | o 512-223-1157

ACC Information 
Security<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fit.austincc.edu%2Fdepartments%2Finformation-security%2F&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063493830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h4cYugvQwuyRSdXyXRJdWUBWXFLfhvA%2FEMsuOT2RVcA%3D&reserved=0>

      
[https://lh3.googleusercontent.com/3i9G30Fg3ZAiC3mZdiMpvQRradC3TjjCk-pdmKCGV_fzPcMSzNSQE7rf9y9DqgXUxJxxl35vf4rLx4n1kM_DpBsJJjbxv9EcmSmUwSHZdlZxsP2Dc_UngTyQv3pHCl6VhsG5Lfio]
 
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Faccinfosec%2F&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063493830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5u5DvVyw%2Fe9ljDAMGXGyF7eClEx0nzZFU6Bv4I62ZKg%3D&reserved=0>
     
[https://lh5.googleusercontent.com/-i9vIi5rgXE71dcrX6-3bGqGXXd0B3y8YE4Q25USF9da5jZ2Slz-TeACb7E26aea5om8HOq35WMxxecKyIBRBaAEAipDnYr8hice3MMzGl1G-l7r9tpbmZ8S_SCmCRsTJ8yWtK3l]
 
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FACCInfoSec&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063503826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gBoLrR%2FCgVGldjyOEMc1QdGjBFh3%2BG3k4AITVLmh0DU%3D&reserved=0>


                                                  CONFIDENTIAL NOTICE
This communication, including any attachments, may contain confidential information and is intended only for the 
individual or entity to which it is addressed. Any review, dissemination, or copying of this communication by anyone 
other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply e-mail, delete and destroy all copies of the original message.



**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063513822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bANvHtlCR4z9Mm8hiRGP28h5mBXscs6yCIMIezNU5GQ%3D&reserved=0>


--
Clark Gaylord
cgaylord () vt edu<mailto:cgaylord () vt edu>

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=04%7C01%7Csteven.lovaas%40COLOSTATE.EDU%7C64acaa9213b1451c045908d916e6db55%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637566003063513822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bANvHtlCR4z9Mm8hiRGP28h5mBXscs6yCIMIezNU5GQ%3D&reserved=0>

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community