none
Why is "Authenticated Users" in the local Users group by default? RRS feed

  • Question

  • This has been bugging me for as long as I can remember:

    By default, "Authenticated Users" is a member of the local Users group on all Windows Servers (2003/2008/2012).

    My colleagues, and I, agree that this is a security hole.  This default allows any domain user/computer to be granted user rights on the server.  This results in "Domain Guests" group members being granted write access to the %systemroot% and public libraries, in addition to all other rights normally granted to users.  This default effectively neuters the Domain Guests group.  I'm referring to the Domain Guests group, not the built-in Guest account.

    Let's review what is in the Authenticated Users group:

    • All domain user accounts (Windows 2000)
    • All domain user accounts except built-in Guest (Windows 2003+)
    • All domain computer accounts
    • All computer and user accounts in trusted domains except built-in Guest as noted above.

    Security Concerns:

    • Anyone (with any domain account) can logon to any system
    • Everyone is granted at least user-level access to each system they access

    On most servers, you don't want users to have any permissions.  For example, why does anyone (other than the people who manage the server) need permission on a DHCP server?  They don't, but with the default permissions, any domain user or domain joined computer connecting to the DHCP server would effectively be given user level rights.  Unacceptable, right?  Of course.

    As networking professionals, our job is to plug/prevent these kinds of security holes/threats. So...

    Workaround:

    For years, we have been removing Domain Users, Authenticated Users, and INTERACTIVE from our server's local Users group, and adding Domain Admins instead.  For systems where users need access, such as file/print, we simply re-add Domain Users.

    We've been doing this for years on Windows Server without problems (mostly).

    Another Example:

    Many companies for which I've consult want to implement different levels of access for different people.  This is simple:  Visitors/Consultants are members of Domain Guests, Employees are members of Domain Users, and IT Staff are members of Domain Admins.

    This works great when you implement the workaround above.  But, with the default settings, visitors are granted the same permissions as employees.  So, you cannot use the built-in groups, and instead you must create custom groups and implement elaborate GPO & ACL to treat the Users group as an un-trusted group and deploy a non-well known SID "Employee" group.

    One more Example:

    We have a network scanner that queries AD to obtain a list of user's email addresses so that it can email the scanned image.  In our domain, anonymous LDAP is disabled, so the scanner must use a domain account to query the directory.  We don't want to create a regular user account because the scanner doesn't need that access and it would give a hacker a "normal user account" if they breached the password.  So, we placed the account in, and only in, the Doman Guests group.  Now, this account has no access to our Windows servers, and can only query AD.  (Of course, the "hacker" can query AD for admins and target them for hacking, but that's different issue).

    With "Authenticated Users" in the local users group, someone using the scanner account, would have User level rights on every server in the domain.  Scary!

    You see how the default group membership neuters the Domain Guests group?

    Problem with the Workaround:

    Starting with Windows 2008, I've found situations where Windows doesn't operate properly if the Authenticated Users group has been removed from Users.  There have been numerous scenarios where I encountered a problem for which I couldn't find any help on the Internet.  When this happens, I think "let me add Authenticated Users in the users groups and test again".  Voila!  It usually fixes the problem.  For example, a failover cluster cannot bring the network name online if authenticated users is not in the users group.

    Summary:

    Windows supports 4 core access levels: Guest, User, Power User (server operator), Administrator

    But, the default permissions eliminates the usefulness of the Guest level.  Essentially, EVERYBODY in the domain (including computers) are at least users!

    Removing Domain Users, Authenticated Users, and INTERACTIVE from the server's local Users group, and adding Domain Admins, is a valid workaround (albeit with some one-off problems).

    So why is this not the default?! At least for servers.  Seriously!  12 years after the "Trustworthy Computing" program, this seems like a overlooked design flaw.

    Someone please explain to me why EVERY user in the domain(s) should be able to logon to EVERY server in the domain(s), and create files/folders on the system drive - BY DEFAULT.

    Thank you

    • Edited by Tony MCP Friday, January 17, 2014 1:00 AM
    • Changed type Amy Wang_Moderator Monday, January 27, 2014 3:06 AM Security Discussion
    • Changed type Tony MCP Thursday, January 30, 2014 12:13 AM It's a question
    Friday, January 17, 2014 12:54 AM

All replies

  • Wow you must be tired in typing that... hope someone from MS will care a little bit for your concern :)

    Every second counts..make use of it. Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Friday, January 17, 2014 9:28 AM
  • Someone please explain to me why EVERY user in the domain(s) should be able to logon to EVERY server in the domain(s), and create files/folders on the system drive - BY DEFAULT.

    The snarky part of me would wonder why EVERY user in the domain can walk into your data center and do that in the first place.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, January 17, 2014 6:41 PM
  • On Fri, 17 Jan 2014 00:54:39 +0000, Tony MCP wrote:

    This has been bugging me for as long as I can remember:

    By default, "Authenticated Users" is a member of the local Users group on all Windows Servers (2003/2008/2012).

    If this was truly a security problem, it would have been exploited and
    identified as a true security hole by any number of security reporting
    bodies. It has not.

    Someone rants about this a couple of times every year, and it really is not
    a problem.


    Paul Adare - FIM CM MVP
    Computers save time like kudzu prevents soil erosion.

    Friday, January 17, 2014 7:13 PM
  • The snarky part of me would wonder why EVERY user in the domain can walk into your data center and do that in the first place.

    Of course!  Most companies keep their servers behind locked doors; it's a best practice.  However, I've worked with some clients who cannot (or won't) physically secure their servers (but that's a different security problem).

    I purposely did not address physical security in my original post because it is not a "solution" to the core problem.  Similarly, installing a firewall doesn't fix a security vulnerability in the firewalled system.

    Besides, what's wrong with having another security layer?  I doubt anyone here believes that one layer of security (no matter how strong it may be) is enough.  If so, then no-one would install firewalls, right?  Properly configured access control lists and up-to-date Windows Updates would be enough, right?  Of course not.

    So, to restate my concern, IF someone happens to gain physical access into the data center, why do I want them to be able to logon to every server in there (by default)?  Aren't we failing as security professionals if we don't anticipate and plan for this?


    -Tony

    Friday, January 17, 2014 7:53 PM
  • If this was truly a security problem, it would have been exploited and
    identified as a true security hole by any number of security reporting
    bodies. It has not.

    You have a good point.  However, just because it hasn't been exploited yet doesn't mean the vulnerability doesn't exist.  Certainly, you can recall patches Microsoft released for security holes discovered years ago; there was no rush to produce a patch because no one had exploited it yet.

    Remember the SQL injection hacks?  That wasn't a "security threat" until someone exploited it big time.  I wonder how many years hackers were compromising SQL systems before the industry took notice.

    As for Authenticated Users issue, when it is "exploited" it is done by someone with an account in AD, not someone in a far away country (usually).  So, it is usually considered a lower risk, but it IS still a security risk.

    Someone rants about this a couple of times every year, and it really is not
    a problem.

    Really?  So I'm not alone in my opinion.  Maybe someone at Microsoft should investigate this.

    As for it being a "problem":  I suspect that people probably "just deal with it", but I disagree that it's not a problem.

    Regardless, this doesn't answer my question: Someone please explain to me why EVERY user in the domain(s) should be able to logon to EVERY server in the domain(s), and create files/folders on the system drive - BY DEFAULT.

    As a security professional, I believe this to be a design flaw for any operating system.


    -Tony

    Friday, January 17, 2014 8:28 PM
  • On Fri, 17 Jan 2014 20:28:14 +0000, Tony MCP wrote:

    You have a good point.  However, just because it hasn't been exploited yet doesn't mean the vulnerability doesn't exist.  Certainly, you can recall patches Microsoft released for security holes discovered years ago; there was no rush to produce a patch because no one had exploited it yet.

    It simply is not a vulnerability, nor is it a design flaw. If you don't
    like the defaults, then change them. Make sure you document your changes so
    that you can reverse them if things break.


    Paul Adare - FIM CM MVP
    Only two things are infinite, the universe and human stupidity,
    and I'm not sure about the former. -- Albert Einstein

    Friday, January 17, 2014 9:37 PM
  • I purposely did not address physical security in my original post because it is not a "solution" to the core problem.  Similarly, installing a firewall doesn't fix a security vulnerability in the firewalled system.

    Any other worries about security in the absence of proper PHYSICAL security is an absolute waste of time and an expenditure of grossly misdirected energies.

    If an organization isn't willing to do the simple things, like put business critical resources behind a locked door, any expectation that they'll do the difficult things (like use proper procedures, configuration, etc.) is just a pipe dream.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, January 17, 2014 10:14 PM
  • Any other worries about security in the absence of proper PHYSICAL security is an absolute waste of time and an expenditure of grossly misdirected energies.

    If an organization isn't willing to do the simple things, like put business critical resources behind a locked door, any expectation that they'll do the difficult things (like use proper procedures, configuration, etc.) is just a pipe dream.

    I agree -- completely.

    My point is that relying on one layer of security is not enough.  The default security settings provide inadequate protection for when the wrong person enters the data center (it can happen).

    The Authenticated Users in the users group seems like a throwback to the 1990s when Microsoft didn't prioritize security.  Other parts of the operating system have been scrutinized and secured over the years, but this appears to have been "overlooked".  I'm simply trying to understand why it hasn't been changed.

    I keep asking, "If someone happens to gain physical access into the data center, why do I want them to be able to logon to every server in there (by default)?"  This is the core concern, and I'd like someone authoritative (from Microsoft preferably) to explain to me why this is the default.  It's simply not the most secure way to configure the OS.  Please someone explain to me why I am wrong.


    -Tony

    Saturday, January 18, 2014 5:51 AM
  • If you don't like the defaults, then change them. Make sure you document your changes so
    that you can reverse them if things break.

    As I mentioned, that's exactly what I do.  But I shouldn't have to!  Shouldn't Windows be secure out-of-the-box?  If it is not, then don't we have a duty to inform Microsoft and other users of the holes?

    Unfortunately, it's not always as simple as just changing the default permissions. We all know that changing default permissions is risky and often causes problems.

    Example: If Authenticated Users is removed from the Users group on cluster nodes (Windows 2008+), you'll encounter strange Kerberos problems.  I posted about this previously.

    It simply is not a vulnerability, nor is it a design flaw.

    Ok, maybe.  Let's just call it an oversight by Microsoft.  Security is our business, and with the Target credit card data breach fresh on my mind, I have to ask:

    Someone please explain to me why EVERY user in the domain should be able to logon to EVERY server in the domain, and create files/folders on the system drive - BY DEFAULT.  Don't forget that "Users" also have read permission to the majority of the file system by default as well.


    -Tony

    Saturday, January 18, 2014 6:27 AM
  • I want to thank everyone for your responses so far.  But, bear in mind that the question I am trying to get answered is, Why is "Authenticated Users" in the local Users group by default?

    Clearly, removing Authenticated Users from the local users group and replacing it with Domain Admins is more secure.  Systems configured this way would only be accessible by Administrators until they explicitly loosed security.

    Is this not better?  Why isn't this the default?

    I am seeking someone authoritative to explain why Authenticated Users being in the local users groups is the default.  It's simply not the most secure way to configure the OS.  Someone please explain to me why I am wrong.

    Or, at least explain to me why the defaults are better than my suggestion above.


    -Tony

    Saturday, January 18, 2014 6:53 AM
  • Hi Tony,

    Aside from the valid physical v logical comments made earlier, these are "canned" user types carried over from NT... the adjunct that you're looking for is simply not there..

    Regards,

    Mylo


    http://blog.auth360.net

    Saturday, January 18, 2014 11:45 PM
  • Wait.... so you now thing that Domain Admins is a local user, not a local Administrator on the box????

    sigh

    Sunday, January 19, 2014 5:42 AM
  • Make long story short this is you concern right?

    Why is "Authenticated Users" in the local Users group by default?

    Security is .... -it never exist by default---


    Every second counts..make use of it. Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Monday, January 20, 2014 4:06 AM
  • Hi Tony,

    Aside from the valid physical v logical comments made earlier, these are "canned" user types carried over from NT... the adjunct that you're looking for is simply not there..

    Regards,

    Mylo


    http://blog.auth360.net

    I expect you're right, but I hope someone can explain why this was never changed.  So many other security changes have occurred over the years.

    I expect that no one will ever be able to explain this to me, unfortunately.


    -Tony

    Monday, January 20, 2014 6:50 AM
  • You have a good point.  However, just because it hasn't been exploited yet doesn't mean the vulnerability doesn't exist.  Certainly, you can recall patches Microsoft released for security holes discovered years ago; there was no rush to produce a patch because no one had exploited it yet.

    If you look at the enormous  amounts of effort that malware writers go through to exploit something (read a book on rootkits) I can safely conclude that if something completely trivial like group membership of authenticated users would be exploitable, it would have long been done.


    Monday, January 20, 2014 7:10 AM
  • Wait.... so you now thing that Domain Admins is a local user, not a local Administrator on the box????

    sigh

    Uh, I'm not sure that I understand your comment.  "Domain Admins" is not a local user or a local security principal at all.  It's a domain global security group in an Active Directory domain.

    Maybe you are referring to my comment of adding Domain Admins to the local Users group?  This is necessary for the workaround I described.  This is related to UAC and is beyond the scope of the problem described in this thread.  If you need more information on this, just let me know.


    -Tony

    Monday, January 20, 2014 7:35 AM
  • If you look at the enormous  amounts of effort that malware writers go through to exploit something (read a book on rootkits) I can safely conclude that if something completely trivial like group membership of authenticated users would be exploitable, it would have long been done.


    I understand your point, but I disagree that it's not exploitable.  Create a user account in your domain, make it a member of the Domain Guests group (and only that group), give me the user/pass, and let me in your server room.  I can do as much damage as if you gave me a domain admin user/pass.

    BUT, that's not the issue.  The default configuration is simply not as secure as it should be.  I simply want to know why!


    -Tony

    Monday, January 20, 2014 8:11 AM
  • Why is "Authenticated Users" in the local Users group by default?

    Security is .... -it never exist by default---

    Sure.  If we look at the history of Windows, we see that security didn't exist in early versions.  It's been added and enhanced over the years.  A good operating system should be secure out-of-the box with minimal attack surface.  As-is Windows isn't as secure as it could be.

    I simply want to know why -- This is the point of this thread.  Why hasn't Microsoft made this simple change?  If it's an oversight, so be it.  If there's a good reason, explain it.

    Thanks


    -Tony

    Monday, January 20, 2014 8:24 AM
  • On Mon, 20 Jan 2014 08:11:48 +0000, Tony MCP wrote:

    I understand your point, but I disagree that it's not exploitable.  Create a user account in your domain, make it a member of the Domain Guests group (and only that group), give me the user/pass, and let me in your server room.  I can do as much damage as if you gave me a domain admin user/pass.

    BUT, that's not the issue.  The default configuration is simply not as secure as it should be.  I simply want to know why!

    On Mon, 20 Jan 2014 08:11:48 +0000, Tony MCP wrote:

    I understand your point, but I disagree that it's not exploitable.  Create a user account in your domain, make it a member of the Domain Guests group (and only that group), give me the user/pass, and let me in your server room.  I can do as much damage as if you gave me a domain admin user/pass.

    That is simply not true. Being a member of local Users on a server is not
    the equivalent of being given the password of a member of Domain Admins.
    Also from the 10 Immutable Laws of Computer Security:

    Law #3: If a bad guy has unrestricted physical access to your computer,
    it's not your computer anymore


    BUT, that's not the issue.  The default configuration is simply not as secure as it should be.  I simply want to know why!

    There needs to be a balance between security and usability. This is simply
    one of those balances, and it really isn't the issue that you make it out
    to be. There are a lot of great minds in security out there, greater than
    mine or yours, and not one of them has identified this as a security risk
    and this is nothing new, this has been the default Windows configuration
    for many, many years.

    As far as demanding to know why it is this way, you'll find that Microsoft
    doesn't comment on design decisions and those MSFT staff that support these
    forums are support engineers, not product designers.

    The only truly secure computer is the one that is never actually turned on.


    Paul Adare - FIM CM MVP
    RedHat Adventure: "You're in a maze of twisted little packages, all
    dependent.
    There's a threatening little Gnome in the room with you."
    -- Peter Dalgaard

    Monday, January 20, 2014 8:38 AM
  • Being a member of local Users on a server is not
    the equivalent of being given the password of a member of Domain Admins.

    I never said it was.  I was only implying that with Windows default security settings, "guests" have enough permissions to bring down servers.

    Also from the 10 Immutable Laws of Computer Security:

    Law #3: If a bad guy has unrestricted physical access to your computer,
    it's not your computer anymore

    You aren't the first person to mention this, and many people seem to think it reduces the validity of my problem.

    Of course, physical security is important, very important.  But, locks can be picked, keycards can be hacked, and guards can be bribed.  I don't understand why we don't make it as difficult as possible for the bad guy once they get in.  I'm starting to think my pro-Linux colleagues are right -- maybe Windows people aren't really serious about security.

    Physical security is an important layer of security, but not the only one the matters.

    Consider this scenario:  Someone obtains a domain user/pass combination (even a domain guest) and hacks the password to your datacenter's KVM over IP.  Now they can shutdown (at least) your entire datacenter, and physical security was never compromised!!!

    We should do everything, EVERYTHING to increase security on our systems.  As long as it doesn't affect usability too much...

    There needs to be a balance between security and usability. This is simply
    one of those balances, and it really isn't the issue that you make it out
    to be. There are a lot of great minds in security out there, greater than
    mine or yours, and not one of them has identified this as a security risk
    and this is nothing new, this has been the default Windows configuration
    for many, many years.

    There is a balance, and security professionals struggle with it every day.  The "Authenticated Users" group issue is a simple change that doesn't affect the balance -- it's easy to undo on systems that require user access.

    Just because "that's the way it has always been" doesn't equate to a lack of a security risk.

    For 17 years, Windows did not include a firewall. The designers didn't see it as a security risk.  They were wrong, and it was added.  Now, it's considered a security risk not to use it.

    Maybe this is the same situation.

    As far as demanding to know why it is this way, you'll find that Microsoft
    doesn't comment on design decisions and those MSFT staff that support these
    forums are support engineers, not product designers.

    Microsoft has a history of modifying their products to fix security flaws.  Support engineers have a mechanism to report problems to the designers.  So, this thread can serve that purpose.

    But, you might be right.  Maybe I need to open a support ticket with Microsoft.


    -Tony

    Monday, January 20, 2014 10:09 AM
  • The only truly secure computer is the one that is never actually turned on.

    Or don't connect to the internet.

    Just plug in USB drive, plug it out, plug it again.. just what OBL did... :)


    Every second counts..make use of it. Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Monday, January 20, 2014 10:11 AM
  • On Mon, 20 Jan 2014 10:09:12 +0000, Tony MCP wrote:

    I never said it was

    You did, but I'm not about to continue to argue this point with you.

    You're demanding an explanation for something that in your opinion is a
    security hole and it simply is not, nor is it recognized as such in the
    computer security community.
    There is no compelling reason for Microsoft to change this behaviour as it
    is not the horrible problem you make it out to be.
    Show me a concrete, real world example where this has been the cause of an
    exploit and I may change my mind.
    I have done enterprise security work for organizations that require
    facilities and systems that meet or exceed Top Secret ratings and this is
    just not an issue. You, are not about to convince the community that this
    is a real problem that needs to be corrected.


    Paul Adare - FIM CM MVP
    "Quoted-Printable: a standard for mangling Internet messages
    Quoted-Unreadable: the result of applying said standard
    Unquoted-Unprintable: the comments from the recipients of the above" -- bf8

    Monday, January 20, 2014 11:07 AM
  • If you look at the enormous  amounts of effort that malware writers go through to exploit something (read a book on rootkits) I can safely conclude that if something completely trivial like group membership of authenticated users would be exploitable, it would have long been done.


    I understand your point, but I disagree that it's not exploitable.  Create a user account in your domain, make it a member of the Domain Guests group (and only that group), give me the user/pass, and let me in your server room.  I can do as much damage as if you gave me a domain admin user/pass.

    BUT, that's not the issue.  The default configuration is simply not as secure as it should be.  I simply want to know why!


    -Tony

    First of all, Guests are disabled. You should not have guests to begin with.

    Second, as authenticated user you are still just a user, not an admin.

    Third, Only a handful of users should get physical access. Basically, only the ones doing server installs and hardware troubleshooting. Not even all our admins have data center access.

    Monday, January 20, 2014 11:38 AM
  • First of all, Guests are disabled. You should not have guests to begin with.

    The built-in Guest account is disabled by default.  I was referring to adding user accounts to the "Domain Guests" group.

    Second, as authenticated user you are still just a user, not an admin.

    True.  But, an authenticated user can logon to console of every Windows system and has read/write access to the system drive (by default).

    Third, Only a handful of users should get physical access. Basically, only the ones doing server installs and hardware troubleshooting. Not even all our admins have data center access.

    Of course.  But, I don't think one layer of security is enough.  I strongly believe that using additional access controls is a best practice, just in case someone unexpected gains physical access to the server.

    -Tony

    Wednesday, January 22, 2014 6:25 AM
  • Make long story short this is you concern right?

    Why is "Authenticated Users" in the local Users group by default?

    Yes.  I find it frustrating that no one as even attempted to answer the question. It's just been a whole lot of tangential discussion.

    :(


    -Tony

    Wednesday, January 22, 2014 6:30 AM
  • It seems that I may have selected the wrong place to express my concern and ask my question.

    I hoped to start an intellectual discussion on the pros vs cons of including the "Authenticated Users" group in the Users group.  Instead, I've received responses basically saying, 1) "It's not a problem because no one has exploited it", or 2) "It's not a problem because your servers should be physically secure".

    1) I can't believe any security professional would say such thing.  Every massive security attack started as something unexploited.  Additionally, I've listed several scenarios in this thread where the default configuration poses a threat.  Do we really need to wait for an attack before discussing this setting?

    2) Maybe everyone here keeps their servers in a citadel with roaming armed military guards.  But for most companies, it's usually nothing more than a locked door or two.  Unwanted people can, and do, find themselves in the server room.  Physical security is very important, but it's not everything.  This should be common sense.  For example: placing a Windows XP system (without any service packs or security patches) behind a locked door doesn't eliminate its security holes.

    I admit, this may only be a minor security concern, but...

    Clearly, removing "Authenticated Users", "Interactive", and "Domain Users" from the local Users group results in a system that is more secure.  Think about it, a system that only "Domain Admins" can access is more secure than a system that any user account can access.  It may only be a little more secure, but IT IS more secure.

    The fix is a simple change with minimal risks, and I wanted to spawn a discussion on whether or not this should be the default configuration.  Don't we all want our systems to be as secure as possible?

    Here are some talking points I was hoping to hit upon during the non-existent discussion:

    Guests Group usage:

    • I am referring to the Guest group, not the disabled guest account.
    • The intended usage of the Guest group is to provide a container for accounts that aren't as trusted as Users.
    • The description on the local Guests group is "Guests have the same access as members of the Users group by default, except for the Guest account which is further restricted".
    • They have the same access because Authenticated Users is in the Users group.
    • The result is that Guests == Users
    • The default settings render the intent of the Guests group mute.
    • Maybe Microsoft is trying to eliminate the use of the Guest privilege level. If so, why not delete the group, or change its description to discourage its use?
    • If the Guest security level is not used, then sysadmins need to reinvent the wheel to implement a mechanism to reduce the access level of people who are not as trusted as regular "Domain Users".  e.g., contactors, service accounts, visitors, network devices, outside employees.

    System Drive NTFS permissions:

    • Compare the default permissions on the C:\ between desktops and servers, and you'll discover they are basically the same except for:
    • On Desktops, Authenticated Users can create folders (and sub-files/folders) on the system drive.  Users are granted read-only permissions.
    • On Servers, Users can create folders (and sub-files/folders) on the system drive.  Authenticated Users are not explicitly granted any permissions.
    • Why the difference?
    • Is it because servers are supposed to be more secure than desktops?
    • If so, someone at Microsoft realizes that "Authenticated Users" is less secure than "Users", right?
    • With the defaults, server permissions are effectively the same as desktops.  This doesn't seem to be the intent.

    Since a discussion to iron out "best practices" for this situation doesn't appear to be forthcoming, here are my recommendations for securing Windows with regard to "Authenticated Users":

    • Remove "Authenticated Users" and "Interactive" from the local Users group on all domain joined computers (servers and desktops).
    • Remove "Domain Users" from the local Users group on all domain joined servers.
    • Add "Domain Admins" to the local Users group on all domain joined computers. (Otherwise, the desktop will never appear when an admin logs on to a server with UAC enabled.)
    • Leave "Authenticated Users" and "Domain Users" in the Domain Local Users group on domain controllers.
    • Leave "Authenticated Users" in the local Users group on failover cluster nodes.
    • On servers that users access (file servers, Exchange, etc.) add "Domain Users" to the local Users group.

    I've been implementing the above changes for all my clients on every version of Windows since Windows 2000, up to and including Windows 2012 R2.  It works well.

    However, these changes are not without their risks.  Occasionally, we experience weird problems when testing new server applications.  For example, our new, just-installed, backup solution wasn't working properly.  After hours of fruitless troubleshooting, we re-added "Authenticated Users" on the backup server and the problems disappeared.

    So, if you experience weird problems that you can't seem to fix (and nobody has even heard of), the first thing to try is re-adding "Authenticated Users" back into the Users group.

    Thanks and good luck.

    P.S., It still bugs me that I have to make these changes.  Windows should be as secure as possible out-of-the-box.


    -Tony

    • Edited by Tony MCP Wednesday, January 22, 2014 9:30 AM
    Wednesday, January 22, 2014 9:25 AM
  • I hoped to start an intellectual discussion on the pros vs cons of including the "Authenticated Users" group in the Users group.  Instead, I've received responses basically saying, 1) "It's not a problem because no one has exploited it", or 2) "It's not a problem because your servers should be physically secure".

    Okay.. let's modify the two rules and I'll be blunt about your desire to start "an intellectual discussion" on the topic.

    First, the simple statement is this: "It's not a problem." PERIOD. Reasons are irrelevant, and I now see they were pointless to have been wasted on this conversation.

    Second, as regards the "intellectual discussion"... I'm all for having intellectual discussions, but let's pick something worth talking about! Authenticated Users has ALWAYS been in the local Users group. There are GAZILLIONS of reasons why that MUST be the case.

    Bottom line: It's not going to change. There's no reason to change it.

    End of discussion. :-)

    Pick something to discuss that needs to be changed, can actually BE changed.

    Btw.. if you really don't want Authenticated Users in the local Users group of your servers by default, it's TRIVIAL to customize an image with that change and then deploy from the customized image. Make the image and be done with it. Or just configure a Group Policy template and remove it.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, January 23, 2014 8:05 PM
  • First, the simple statement is this: "It's not a problem." PERIOD. Reasons are irrelevant, and I now see they were pointless to have been wasted on this conversation.

    I never said it was a "problem".  I only said that security could be tighter with this change.

    Btw.. if you really don't want Authenticated Users in the local Users group of your servers by default, it's TRIVIAL to customize an image with that change and then deploy from the customized image. Make the image and be done with it. Or just configure a Group Policy template and remove it.

    Of course, that's what I am doing.

    Authenticated Users has ALWAYS been in the local Users group. There are GAZILLIONS of reasons why that MUST be the case.

    YES, yes, ... finally! Please list some of those reasons.  That is the why this thread exists.


    -Tony

    Thursday, January 30, 2014 1:12 AM
  • Why is "Authenticated Users" in the local Users group by default?

    I honestly don't understand the feedback this thread has received.  I simply pointed out a minor configuration change that results in a more secure system with little or no added risk.  Instead of answering my question, everyone has defended the status quo and belittled any benefits of this security change.

    As security professionals, we should consider ANY change that increases security.  It shouldn't matter how small the benefits are.  Linux admins understand this.

    If these people worked for me, we'd have a serious conversation about their attitude toward security.

    But, I agree with Lawrence, this is irrelevant to this thread's purpose.

    So, please no more discussion about security concerns with "Authenticated Users".  Both sides of the debate have been covered well.  Let's get this thread back to its original purpose:

    Why is "Authenticated Users" in the local Users group by default?

    In summary, let us concentrate on why "Authenticated Users" is in the users group and why it shouldn't be removed.  Let's not debate why someone would want to remove it.

    Thank you.

    • Edited by Tony MCP Thursday, January 30, 2014 3:57 AM
    Thursday, January 30, 2014 1:57 AM
  • Authenticated Users has ALWAYS been in the local Users group. There are GAZILLIONS of reasons why that MUST be the case.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Lawrence, I'm still waiting for you to list some of the "GAZILLIONS of reasons" why I shouldn't remove Authenticated Users from the local users group.

    Thank you.


    -Tony

    Thursday, February 13, 2014 10:00 PM
  • Differences between Authenticated Users, Domain Users, and Everyone groups

    http://networkadminkb.com/KB/a41/differences-between-authenticated-users-domain-users.aspx


    Regards~Biswajit

    Disclaimer: This posting is provided & with no warranties or guarantees and confers no rights.

    MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin

    MY BLOG

    Domain Controllers inventory-Quest Powershell

    Generate Report for Bulk Servers-LastBootUpTime,SerialNumber,InstallDate

    Generate a Report for installed Hotfix for Bulk Servers

    Friday, February 14, 2014 2:53 AM
  • Looking at your scenario...  isn't what you really want is to restrict local logon for Users on your servers completely?

    Meaning... 

    1. Run GPEdit.msc
    2. Navigate to:  Configure Computer / Windows Settings / Security Settings / Local Policies / User Rights Assignment / Allow Log on Locally
    3. Remove "Users"

    I'm not sure why you would want any old authenticated user to be able to log on to your servers... and I think blocking logon abilities completely is a better mechanism than trying to restrict what they can do post-logon.

    Thanks!
    Elden

    Friday, April 18, 2014 10:17 PM
  • This is still a problem with Windows 10. In my space I am concerned with workstations that need to have limited access for regulatory reasons. . It’s great to use global groups to limit who can login but if authenticated users or interactive are added to users than any domain user can login. Has there been any development on this?
    Wednesday, December 13, 2017 7:50 PM
  • Has there been any development on this?

    Unfortunately, no.  I've been asking this question for years on various blogs.  The typical responses I receive are:

    • You are stupid for changing Microsoft's default security settings
    • It's not a security flaw or Microsoft would have fixed it
    • If you keep your computers behind locked doors, then it's not problem
    • If you don't like it, just change it

    Nobody ever attempts to answer the actual question: "Why can EVERY user in the domain logon to EVERY server/workstation in the domain, and create files/folders on the system drive, by default?"

    In general, most people get argumentative and trivialize my concerns.  It doesn't help when I explain why it's a security issue.  They just insist that it's not a real problem.  Just look at the posts on this thread for examples.

    In all the years, on all the blogs, I've never received a proper answer to my question.

    In my opinion, this confirms the common belief that Windows admins are less concerned about security than Linux admins.

    For me, I remove "Authenticated Users", "Interactive", and "Domain Users" from the local Users group on all domain-joined systems that I manage.  I've been doing this since February 2004 with almost no problems.  You learn where you NEED Authenticated Users in the local group, and grant that permission, but only where it's needed (fail-over cluster member nodes are one example).

    Note:  If you remove those three accounts [as I do], you need to add "Domain Admins" to the local Users group, otherwise blank desktop on logon.


    -Tony

    Thursday, December 14, 2017 1:29 AM
  • You've been given lots of answers that's not the problem. The problem is that you haven't been given the answer you want to hear.
    Thursday, December 14, 2017 5:57 AM
  • You've been given lots of answers that's not the problem. The problem is that you haven't been given the answer you want to hear.

    Based on this post, I reread the entire discussion just now.  I was hoping to find an answer that I missed previously.  I did not.

    The closest this thread came to getting an answer was when Lawrence said, "Authenticated Users has ALWAYS been in the local Users group. There are GAZILLIONS of reasons why that MUST be the case."  I begged him to post some of those reasons, but he never did.

    Thank you for taking the time to follow/post on this thread, but I respectfully disagree that an answer has been posted.


    -Tony

    Thursday, December 14, 2017 6:42 AM
  • I just stumbled on this thread and thought I would comment.

    TL;DR summary:  You aren't wrong that Authenticated Users shouldn't be in the Local Users group.  Nobody knows *why* it was done (long ago), and MS has bigger fish to fry than to fix a "low risk" issue.

    Longer version: 

    Why questions are tricky and -- as you probably know if you have kids -- the answer is often just "because".  I think some of the answers have mostly hit your question, but I'm not sure you are asking the right question. 

    You are asking, Why is...?  The answer to that is because a long time ago, some developer or department made a decision to put Authenticated Users in the local Users group.  Almost certainly, that person or department has changed so much that nobody today knows who made the decision or why they did.  You are very likely correct that it was because they were not as concerned about security as they should have been.  Nevertheless, that is the state of things.

    Your real question should be why has that situation persisted to this day?  The likely answer to that is because it is complicated.  As you acknowledge, there are some situations that present issues when removing Authenticated Users, and there are almost certainly others that you have not encountered.  While I am by no means defending MS (because I agree that it was a boneheaded decision in the first place), there is some risk-analysis, bean-counter at MS who has decided that thus far, because it is mostly mitigated by the "zeroeth law of computer security" (I.e. physical security), the risk of leaving it the way it is does not out-weigh the cost to hunt down and resolve all the implications of removing it.  Either that or they are so busy trying to resolve other, currently active exploits, that they don't even have this on the list of security risks.  It's the squeaky wheels that get the grease!

    In an ideal universe, should it be changed?  Sure.  Is insisting on an answer on a "social" discussion board to why it is the way it is going to accomplish much?  Unlikely.  Providing a suggestion via official feedback is probably a more effective route to change here.  You could always threaten to vote with your wallet and not purchase MS products until they fix the problem.  ;-)

    My $.02.

    Monday, April 16, 2018 6:12 PM