Re: Local Admin Access

[Clark Gaylord <cgaylord () VT EDU>]

Wait til you read the version I sent Mark.... hehe

On Fri, May 14, 2021 at 11:17 AM Lovaas,Steven <Steven.Lovaas () colostate edu>
wrote:

> 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> 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
> ... autocorrect may have improved this message ...
>
> On Wed, Apr 7, 2021, 13:04 Emilie Kunze <ekunze () austincc edu> wrote:
>
> We are curious how other institutions handle local admin access for
> faculty/staff?
>
> Thank you,
> Emilie
>
>
> <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  | 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://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://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
>
> **********
> 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


-- 
Clark Gaylord
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