I'd like to flag certain Active Directory accounts to indicate that they represent individual, physical people as opposed to groups, service accounts, built-in accounts, etc. This could be via a custom or built-in attribute, group, etc.
Ideally, the solution would:
Groups are a different kind of object from users, so differentiating them is already possible, even easy. Built-in accounts are usually left in the Users container, while user accounts and service accounts are typically sorted into separate OUs either under the Users container or outside of the Users container. Either way, sorting by OU would be a visual indication in the GUI and also easily searchable and sortable by other applications, powershell commands, searches, etc.
So just sort your users into different OUs by type of user. You might also want to create an OU tree to sort human users more granularly, for example you could sort them by department into separate department OUs. Or you could sort them by office location or whatever makes business sense. That way you have multiple ways to differentiate between users with different needs.
I also like to sort all groups into OUs. Either I make a groups OU and sort all the groups inside that and even create an OU tree structure to differentiate user groups from resource groups from distribution groups, or I include the groups next to the users in the appropriate user OUs.
If you're not intelligently sorting your AD objects into OUs, you're missing out on a major feature of Active Directory.
In addition to using OUs, you could (really should) leverage group membership. Typically there are reasons to create one or more user and distribution groups that include all the human staff of an organization, but not include any built-in or service accounts. You may also want to create a distribution and/or user group for all service accounts (you might be able to assign appropriate rights for service accounts to groups). A distribution group is completely meant to sort users for almost no other purpose (especially if you don't Exchange), so it's an ideal mechanism for grouping accounts for various purposes.
If you do have Exchange, then you've got all kinds of schema extensions added to Active Directory that you can use to differentiate between user mailboxes and shared mailboxes, etc.
Finally, regarding service accounts, you might put some thought into the scope required by your various service accounts. If you have a service that needs a custom account but doesn't need to access any network resources, you could simply create a local account for that service and grant it the necessary rights on the local machine. That's one less service account cluttering up your AD.
In addition to @Todd Wilcox's excellent answer, I'd like to add the idea of a naming convention for the objects in AD.
Certain aspects of the "attributes" you want to create for the users/groups can be inherently applied by having a very strong naming convention for objects and infrastructure, and not deviating from it.
Users
Regular user names should be <FirstName>.<LastName>, or <lastName><FirstInitial>, while their Display Names would be <LastName>, <FirstName> (<Department>). Or whatever works for your company. Either way, they should be reproducible, and formatted in a way such that if you know a certain element for a user, you know how to find out more about them because you know what to look for.
Real Name Department Display name User Name
John Doe IT Doe, John (IT) John.Doe
Jane Doe Finance Doe, Jane (FIN) Jane.Doe
James Doe Human Resources Doe, James (HR) James.Doe
Service accounts should also follow a standard convention, but different than the one for regular users. This also applies to "shared" accounts, but I'd stay away from those anyway. My preferred format is sa.<vendor>.<product>, so that it's fairly easy to group them and find them for later re-use.
Vendor Product Display Name Username
VMware vSphere (SA) VMware - vSphere sa.vmware.vsphere
Microsoft SQL Server (SA) Microsoft - SQL Server sa.microsoft.sqlserver
Microsoft Exchange (SA) Microsoft - Exchange sa.microsoft.exchange
IBM Tivoli Storage Manager (SA) IBM - Tivoli Storage Manager sa.ibm.tsm
Groups
Security groups should be named based on what they're doing and to what they apply, but again following a standard pattern so that similar purposed groups can easily be found.
File shares could be named by the share name, and the permissions they grant, while the server/path for that share is found in the Description (SHR_<ShareName>_R for read, SHR_<ShareName>_M for modify).
Generic Mailbox access groups, could contain the mailbox name, and the rights (GM_<SMTPAddress>_FMR for full access, GM_<SMTPAddress>_SA for Send As).
AD/server Delagation groups could be the name of the team (DLG AD DevOps), DLG SRV BackupAndStorage, etc..)
Distribution lists are the only strange one, in that will likely be named more or less whatever is nedded because people are going to want that. But even then, you can setup standards for them that work for your organization.
Most of the environments I've worked in don't do this with attributes on accounts. They do it via OU organization and/or naming standards. A simplified example might be:
You can sub-divide the different account types if it makes sense. But most of the time, group memberships are all you need to further divide...groups...of people. Adding a standard prefix/suffix to non-human account types can also make this easier to see/manage at a glance. For example, all service accounts might start with "svc.".
