What is a "Service" Account
Service/Daemon Accounts are Organization Specific User Accounts used by scripts or other programs to access data or manipulate things that require authentication.
We need to have auditable practices for handling accounts not under the direct control of a single human being.
This internal document is intended to identify "best practices" for the such accounts created and used by the Microsystems group.
Principal of Least Privilege
Microsoft has coined the term "Principle of Least Privilege" to describe the security model where accounts are assigned the fewest rights possible to perform their intended functions to reduce the exposure should an account become compromised.
Each service (script or application) should have their own individual accounts, so that they can be individually audited and the account can be safely disabled should we believe it compromised.
Service accounts should have only the access rights that they need to perform their function. There's no point in granting "Enterprise Admin" to a daemon responsible for generating pretty web logs (file system access would be all that would be needed in this example).
Naming
As detailed in Unity Domain Naming Conventions, all Microsystems accounts must start with the prefix of "itd" followed by a dot (.), so as not to conflict with private accounts from any other group.
Microsys keeps it's service accounts in the ou=Administrative,ou=Users,ou=MICROSYS,ou=Organizations container.
Service accounts should be associated with one or more human contacts, who are responsible for the use of the account. The "manager" link on an AD object can be used to link the daemon account to a user or group to make it easy to keep track of responsible parties within the directory.
Since by definition the accounts in question are all associated with MICROSYS, you should link to the person (User object) most associated with a paricular service account, and not just link everything to the group.
Optional Security ideas
Service accounts can have a finite lifetime (eg 1 year) after which they expire and have to be renewed.
In the future, a process may be deployed to watch for accounts that are about to expire and warn the responsible parties (as identified by the Manager link) to take action.
If possible, you should not store the clear text password for a service account. Using a Kerberos V keytab file, or an SSL x509 certificate are two ways to avoid clear text. These methods move the security to the file system, as the keytab or certificate becomes a "password equivalent"
Sysnews
Unity Forums
Microsys Blog
Documentation