Domain Service Accounts are STUPID

I've covered this before, but apparently, amazingly, there are people on this planet who do not read my stupid blog.  As if there is anything more important or interesting out there.  Geez.

(Imagine this for just a moment: Rioting in Cairo comes to a halt, as one guy over on the side yells out "Hey!  Check this American idiot blog out!" and the crowds quietly converge around this guy's laptop to read this right now.  Yeah.  It could happen.  Right after the monkeys fly out of my butt).

I've mentioned this topic several times in the past, like here http://skatterbrainz.blogspot.com/2009/02/windows-7-2008-r2-managed-service.html and here http://skatterbrainz.blogspot.com/2008/11/can-you-roll-your-own-management.html and here, but most importantly here http://skatterbrainz.blogspot.com/2008/08/using-system-account-instead-of-domain.html

I feel like a traveling minstrel everytime I have to explain this to someone.  Even more amazing when I have to explain it to a SCCM administrator.  As if they didn't already use this when granting permissions to the MP and SLP role hosts on the System Management OU in Active Directory.

It goes like this:

The local SYSTEM account only has rights to the local machine, by default.  But, what happens when you attempt to access a remote resource using the local SYSTEM account, is that the remote resource sees the incoming authentication request coming from DOMAIN\COMPUTERNAME$ (where "DOMAIN" is your NetBIOS domain name, and "COMPUTERNAME$" is the name of the computer where the SYSTEM account process was initiated).  The "$" suffix is Windows' way of identifying a computer account (as if it doesn't already have enough other ways to know this).

All computers which have been joined to a domain become members of the default group "Domain Computers".  This group is not a member of any other groups by default.  It is not granted any resource accesses either, by default.  It's just sitting there, in case you need it.  Well - YOU NEED IT.

You can go about this in one of three ways:

1. For resources that need to grant access to all domain computers, just grant the "Domain Computers" group the appropriate access.
2. For resources that need to grant access to one specific computer, just grant the Computer$ account explicit access (although, this technically breaks the AGUDLP or ADLGUP methodology, or whatever.  I live by it, but don't ask me to say it right)
3. For resources that need to grant access to a specific collection of computers, create a security group (Global or Universal, whatever) and grant access to the group

Sounds easy - Right?   That's because IT IS EASY.  EASY as taking a dump after eating a pound of Chinese food and a box of laxatives.  You'll wonder why you EVER bothered making stupid domain accounts to run scheduled tasks, backups, launch services, etc.  Then you'll smack yourself in the face realizing you don't need to manage passwords anymore either.

Please.  Give it a try.