What is the difference between the "Authenticated User" and "user" groups in windows server 2008 (or 2003)?

I'm going to say what Sam said a slightly different way because I think it might be clearer, and then I'll give you a couple "bloopers" related to permissions to think about.

"Authenticated Users" isn't a group that you can alter the membership of. Rather, any user who is authenticated by any means the server is aware of (its "Local Users and Groups" database, a domain controller in the domain the server is joined to, a domain controller in a domain that is trusted by the domain the server is joined to, etc) that user has "Authenticated Users" added to their security token.

Typically, the "Guest" account is not enabled on servers, so all users are members of "Authenticated Users". If you were to enable the "Guest" account on a server (or in the domain the server is joined to, or in a domain trusted by the domain the server is joined to, etc) you could then access that server using "Guest" credentials (i.e. any credential that doesn't authenticate). If you were to examine the security token created by such an access you'd find that it doesn't contain "Authenticated Users". (It's easiest to demonstrate this by enabling the "Guest" account on a temporary basis and playing around with permissions on temporary shares. It's rather difficult to see the security token that a guest connection has created for it, but easy to observe the behaviour.)

"Users" is a plain old group that you can add and remove members from. It just happens that it's a "well-known security identifier" group-- that is, a group that's created when the OS is installed and has a known relative security identifier. Think of it is a "stock" group in the operating system. By default, users who are added to a server's "Local Users and Groups" are made members of "Users", but they can be removed from that group if you so desired.

When you join a server to a domain the "DOMAIN\Domain Users" group is nested into the server's "Users" group, thereby granting the same permissions to members of "DOMAIN\Domain Users" as would be granted to "Users".

In many cases where you're setting permisions that you believe should apply to "everyone on the organization" you need to think about whether you mean "Everyone who will ever be authenticated by this server's 'Local Users and Groups', any domain controller in this domain, or in any trusted domain" or "Everyone in this server's 'Local Users and Groups' or anyone in this domain". That's your decision point between "Authenticated Users" and "Users" / "DOMAIN\Domain Users".

I've seen one organization (a hospital) that had to launch a massive permissions re-engineering on all their file server computers because they initially used "Users" and "DOMAIN\Domain Users" in permissions everywhere, then later joined a larger "Hospital Association" and created trust-relationships to other hospitals' domains. No one in the "TRUSTED_DOMAIN\Domain Users" group could access resources that were available to "Users" or "DOMAIN\Domain Users" because no nesting of "TRUSTEDDOMAIN" groups into "DOMAIN" groups occurs automatically, nor can you nest groups or users from other domains into "DOMAIN\Domain Users" (being that it's a glocal security group). Had the first hospital used "Authenticated Users" where they used "Users" or "DOMAIN\Domain Users" they wouldn't have had any problems when they added the trust-relationship.

One other common issue I've seen relating to using both "Users" / "DOMAIN\Domain Users" and "Authenticated Users" in permissions is that, potentially, they might be overbroad for future applications. Several times I've had to go back and re-engineer permissions when a Customer decided to give some contractor a user account, but didn't want that contractor to be able to access any resources on servers except some particular project-related items.

If the Customer used "Users" and/or "DOMAIN\Domain Users" in many permissions this contractor scenario would be fairly easy-- remove their account from the "Users" (or, if it's a domain account, "DOMAIN\Domain Users") group and put them into some other group (because a user must be a member of a single "primary" group, at minimum, for POSIX compatibility).

If the Customer used "Authenticated Users" in many permissions, though, this contractor scenario becomes a mess. There's no group I can take the contractor out of that will make them NOT a member of "Authenticated Users". I'm stuck either re-engineering all the permissions where "Authenticated Users" is used, or enabling the "Guest" account and not creating an account for the contractor, but rather letting them just use "Guest" credentials. This would make me uncomfortable, both as the contractor and as the sysadmin, since the actions of the contractor become un-auditable in a "Guest"-enabled configuration.

In the contractor's case, it would've been better for the Customer to have been using, say, a "DOMAIN\Company Employee Users" group everywhere they'd been using "Authenticated Users", such that the contractor could just not be made a member of "DOMAIN\Company Employee Users". That's a situation that takes some up-front thinking during the design phase of all your permission hierarchies, but it's one that I've tried to think about more and more after having this "contractor" issue occur at multiple Customer sites.

Think about what you mean when you're naming "Authenticated Users", "Users", and "DOMAIN\Domain Users" in permissions and you'll be in good shape. If you use them blindly there's a chance that, down the road, you'll find yourself in a horrible permission re-engineering swamp.

(Now, who's gonna ask about the "Everyone" group? Heh heh...)

The Authenticated users group is a computed group, anyone who authenticates correctly to the computer, or domain is added to this group automatically, you cannot manually add users to it.

The users group is a group by which you can control membership, and decide which users you wish to be a member of it. By default the Authenticated Users group is a member of this group, but it doesn't have to be. Users in this group can perform tasks such as running applications, using local and network printers, shutting down the computer, and locking the computer.