2

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:

  • Make it easy to add the attribute to multiple accounts at once
  • Not have to be added to every account
  • Provide some indication (visual, etc.) that it may need to be set at account creation
  • 2
    Most organisations solve that by a naming convention if not already grouping accounts in relevant OU's. – HBruijn May 11 '16 at 16:32
5

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.

3

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.

2

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:

  • (domain root)
    • All Accounts
      • Humans
      • Shared Accounts
      • Service Accounts

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.".

  • Group membership is also a handy tool for sorting users. Note that users can only be in one OU, but can be in all kinds of combinations of different types of groups, so for the most granular sorting, groups have some advantages over OUs. An intelligent design for both group membership and OU structure is of course the ideal. Also, there are technical reasons not to move some built-in accounts from the Users container into the OU structure like the one in your answer, so some care should be taken before sorting all accounts that way. – Todd Wilcox May 11 '16 at 16:40
  • Indeed. I didn't meant to imply that built-in accounts should be moved. Generally speaking, our practice is to not modify anything built-in including the default group policy objects. – Ryan Bolger May 11 '16 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.