Naming Convention Standard

The Problem

No naming standard means no automation. Objects named by whoever created them, however they felt like it that day:

User accounts: jsmith, john.smith, smithj, John Smith
Servers: DC1, Exchange-Server, SQL_PROD_01, FileServer
Groups: IT-Admins, VPN Users, Finance_RW, Marketing Group
Service accounts: svc_exchange, ExchangeService, backup

Scripts break. Searches fail. Auditors ask questions you can't answer. Every new hire learns a different pattern from whoever trained them.

Solution Architecture

Pattern Library

Seven object types with defined patterns. Employee accounts, contractors, security groups, application groups, servers, service accounts, gMSAs.

Regex Validation

PowerShell patterns that validate names at creation time. Catches violations before they reach Active Directory.

Framework Alignment

Mapped to ITIL v4, Microsoft AD best practices, CIS Controls, and NIST SP 800-53. Auditors get documentation they recognize.

Governance Process

Exception handling, quarterly audits, annual review cycle. Standards without enforcement are suggestions.

AD Hygiene

Naming conventions only work if the underlying data is clean. Required attributes for every user account:

Manager

Enables org chart generation, approval workflows, and "who reports to whom" queries. Empty manager fields break delegation chains.

Department

Powers dynamic distribution groups, access reviews, and compliance reporting. "Which Finance users have VPN access?"

Location

Office, building, site code. Required for location-based policies, emergency notifications, and asset tracking.

Group Membership

Security groups follow naming convention. Distribution lists, file share access, application permissions—all traceable by pattern.

Quarterly hygiene audits flag accounts missing required attributes. Automation can't route approvals to a manager field that's empty.

Pattern Structure

Validation Pipeline

Validation Code

$NamingPatterns = @{
    Employee    = '^[A-Z]{2}\d{5}$'                     # JN03214
    Contractor  = '^[A-Z]{2}9\d{4}$'                    # JO90107
    SecGroup    = '^(L|G|U|DL|APP|FS)_[\w]+$'          # L_VPN_CJIS
    AppGroup    = '^[A-Za-z]+-[A-Za-z]+(-[A-Za-z]+)?$'  # DocMgmt-Finance
    Server      = '^[A-Z]{2,4}(SRV|VM|CT)[A-Z]{2,4}[DTS]?\d{2}$'
    ServiceAcct = '^svc-[a-z]+-[a-z]+$'                # svc-sql-agent
    gMSA        = '^gmsa-[a-z]+-[a-z]+\$$'             # gmsa-sql-prod$
}

function Test-NamingConvention {
    param(
        [Parameter(Mandatory)]
        [string]$Name,
        [Parameter(Mandatory)]
        [ValidateSet('Employee','Contractor','SecGroup','AppGroup','Server','ServiceAcct','gMSA')]
        [string]$Type
    )
    return $Name -match $NamingPatterns[$Type]
}

Results

Metric	Before	After
Script compatibility	Case-by-case fixes	Predictable parsing
Object identification	Manual inspection	Regex-based type detection
Audit response time	Hours of research	Documented patterns
New hire training	Tribal knowledge	Reference documentation
Contractor identification	Check description field	Username starts with 9

Technologies

Active Directory PowerShell Regex ITIL v4 CIS Controls NIST SP 800-53 gMSA Documentation

Lessons Learned

standards without enforcement are suggestions

Documentation alone doesn't change behavior. Validation scripts that reject non-compliant names do.

encode meaning in structure

The "9" prefix for contractors means any script can identify account type without querying AD attributes.

design for automation first

If a human can't parse the pattern, neither can a script. If a script can parse it, reporting becomes trivial.

map to frameworks auditors know

ITIL, CIS, NIST references mean auditors spend time reviewing, not questioning your approach.