Skip to content

Naming and Placeholders

Use structured placeholders in the base blueprint. Replace them only in client overlays or approved customer runbooks.

This page defines the approved naming baseline for:

  • customer overlays
  • site codes
  • hostnames
  • user identities
  • administrative identities
  • service identities
  • reusable placeholder variables

Keep naming predictable. A good naming standard should make objects easy to recognize, easy to automate, and easy to keep stable as the customer grows.

Naming principles

  • Keep names short enough to work across legacy and modern systems.
  • Prefer stable identifiers over clever abbreviations.
  • Separate human-friendly identity from internal immutable identity.
  • Keep customer-specific values in overlays, not hardcoded into the base blueprint.
  • Avoid embedding temporary lab assumptions into long-term naming standards.
  • Use one approved convention per object class. Do not mix multiple patterns for the same type of object.

Required placeholders

Placeholder Meaning Example
CLIENT_CODE Customer short code GEIL
SITE_CODE Site identifier HQ
SITE_NAME Site display name Santo Domingo HQ
ENV_STAGE Deployment stage LAB
DOMAIN_FQDN Internal AD DNS name corp.gntech.me
UPN_SUFFIX User-facing UPN suffix gntech.me
VMID Proxmox VM identifier 4011
HOSTNAME Server or endpoint hostname HQ-DC01
VLAN_ID Network segment ID 20
SUBNET_CIDR IPv4 subnet 172.20.20.0/24
GATEWAY_IP Default gateway 172.20.20.1
DNS_SERVER_IP DNS resolver used by node 172.20.20.11
BACKUP_TARGET Backup repository or share \\HQ-FS01\Backups
USER_EMPLOYEE_ID Internal immutable user identifier GNT-000123
USER_SAM Legacy logon name u000123
USER_UPN User sign-in identity miguel.perez@gntech.me

Customer and site codes

CLIENT_CODE

Use a short, stable uppercase customer code.

Examples:

  • GEIL
  • GNT
  • ACME

Rules:

  • use uppercase letters and digits only
  • avoid spaces
  • avoid punctuation unless a specific external standard requires it
  • keep it stable across the whole customer estate

SITE_CODE

Use a short uppercase code for each operational site.

Examples:

  • HQ
  • BR1
  • BR2
  • NYC
  • MIA

Rules:

  • use uppercase letters and digits only
  • keep it short enough for hostname reuse
  • do not put country or city text into every object unless needed
  • do not change a site code casually after deployment

ENV_STAGE

Use a short environment marker only where the environment itself must be distinguished.

Examples:

  • LAB
  • TEST
  • PROD

Do not overload every hostname with ENV_STAGE unless the customer actually runs parallel environments that share the same management plane.

Hostname standard

Core pattern

For infrastructure systems, use:

SITE-ROLE##

Examples:

  • HQ-CHR01
  • HQ-DC01
  • HQ-FS01
  • HQ-CL01
  • HQ-PRN01

This is the approved baseline for the pilot and should remain the default pattern unless a customer has a stronger enterprise standard already in place.

Approved role codes

Role Pattern Example
Router SITE-CHR## HQ-CHR01
Domain controller SITE-DC## HQ-DC01
File server SITE-FS## HQ-FS01
Application server SITE-APP## HQ-APP01
SQL server SITE-SQL## HQ-SQL01
Backup server SITE-BKP## HQ-BKP01
Management workstation SITE-MGMT## HQ-MGMT01
Workstation SITE-CL## HQ-CL01
Printer SITE-PRN## HQ-PRN01
Hypervisor SITE-HV## HQ-HV01

Hostname rules

  • Use uppercase in documentation for consistency.
  • Keep hostnames concise.
  • Use two-digit numeric sequences where practical: 01, 02, 03.
  • Do not use spaces.
  • Do not use accents or locale-specific characters.
  • Do not encode OU, VLAN, or operating system edition into the hostname unless the customer requires it.

Templates and build VMs

Use explicit names for image objects.

Examples:

  • TPL-WS2025
  • TPL-WS2025-CORE
  • TPL-W11E
  • TPL-W11-IOT-LTSC
  • TPL-W11E-BUILD

Rules:

  • TPL- is reserved for reusable templates
  • -BUILD is reserved for transient image source VMs
  • do not use production server naming on a build image

Domain naming guidance

  • Prefer an internal namespace approved for the customer.
  • For Microsoft 365 and future Entra integration, prefer an AD domain that is neutral and stable, while keeping the public verified namespace as the user-facing UPN suffix.
  • For GNTECH, the recommended pattern is:
  • AD domain: corp.gntech.me
  • User UPN suffix: gntech.me
  • Avoid location-bound forest root names such as hq.gntech.me if the company is expected to grow beyond a single headquarters.
  • In the base blueprint, use corp.example.com or corp.example.corp as documentation placeholders only when customer naming is not yet approved.

User naming baseline

The full identity rationale is defined in Identity and Namespace Strategy. The approved naming baseline is:

Property Standard
User UPN nombre.apellido@gntech.me
Duplicate UPN nombre.apellido2@gntech.me
Legacy logon name u######
Internal immutable identifier GNT-######
Display name Nombre Apellido

Examples:

  • miguel.perez@gntech.me
  • miguel.perez2@gntech.me
  • u000123
  • GNT-000123

Administrative account naming

Administrative accounts must be visibly distinct from standard user identities.

Approved baseline:

Property Standard
Admin UPN adm.nombre.apellido@gntech.me
Admin legacy logon name a###### or another approved dedicated admin sequence
Admin immutable identifier separate from the standard user identifier

Examples:

  • adm.miguel.perez@gntech.me
  • adm.ana.garcia@gntech.me

Rules:

  • do not reuse the standard user account as an admin account
  • do not hide privileged identity behind ambiguous names
  • keep admin identities in the approved Admins OU

Service account naming

Service accounts must not follow the same pattern as human identities.

Recommended baseline:

svc.<function>.<system>

Examples:

  • svc.sql.hqfs01
  • svc.backup.hq
  • svc.sync.entra

Rules:

  • prefix service identities consistently with svc
  • keep the function visible
  • keep the target system or scope visible where useful
  • if a service account needs a mail-like UPN, document that explicitly instead of improvising

Group naming baseline

The approved baseline should distinguish groups by purpose first, then by scope, then by permission level.

The repository already uses descriptive access-group names such as:

  • DL-HQ-FS01-Public-RW
  • DL-HQ-FS01-Departments-IT-RW
  • DL-HQ-FS01-Departments-Finance-RW

Group type prefixes

Prefix Meaning Typical scope
DL Domain local security group Resource permissions
GG Global security group User or computer role membership
UG Universal security group Cross-domain or future multi-domain use only when justified

For the current single-domain baseline:

  • use DL for resource access groups
  • use GG for role or population groups
  • do not introduce UG unless the environment has a real need for it

Resource access groups

Recommended interpretation for the current access-group pattern:

  • DL = domain local
  • HQ-FS01 = resource scope
  • Public or Departments-IT = business target
  • RW = permission level

Recommended pattern:

DL-RESOURCE-TARGET-PERM

Examples:

  • DL-HQ-FS01-Public-RW
  • DL-HQ-FS01-Departments-IT-RW
  • DL-HQ-FS01-Departments-Finance-RW
  • DL-HQ-FS01-Backups-RW

Recommended permission suffixes:

Suffix Meaning
RO Read only
RW Read and write or modify
FC Full control
RX Read and execute

Role and population groups

Use GG groups for user populations, operational roles, or delegated access populations that are not tied directly to one ACL target.

Recommended pattern:

GG-SCOPE-ROLE

Examples:

  • GG-HQ-Helpdesk
  • GG-HQ-Server-Admins
  • GG-HQ-Workstation-Admins
  • GG-HQ-Finance-Users
  • GG-HQ-IT-Users

Keep these groups readable. They are often what administrators, auditors, and scripts will search for first.

Administrative groups

For privileged access groups, keep the same GG baseline but make the role explicit:

GG-SCOPE-ADMINROLE

Examples:

  • GG-HQ-Domain-Admins-Delegated
  • GG-HQ-Server-Admins
  • GG-HQ-Backup-Operators

Do not hide administrative power behind generic group names such as:

  • IT Team
  • Support Access
  • Admins 2

Naming rules for groups

Rules:

  • keep the group type visible at the beginning
  • keep the resource visible in the group name
  • keep the site or scope visible where it matters
  • keep the access level visible in the group name
  • prefer consistent abbreviations over free-form names
  • do not create generic names that hide what the group actually controls
  • do not encode OU paths into the group name
  • do not use spaces
  • use hyphens consistently as separators
  • keep names short enough to stay readable in tools and scripts

Placement in the OU structure

For the current OU baseline:

  • create managed security groups under OU=Security Groups,OU=Groups,OU=GNTECH,...
  • do not assume separate RoleBased, ResourceBased, or Delegation OUs at day zero
  • if future scale justifies sub-OUs below Security Groups, keep the naming standard unchanged

Group membership model

For the current single-domain design, use the classic AGDLP model:

  • A = accounts
  • G = global groups
  • DL = domain local groups
  • P = permissions

Practical meaning in this guide:

  • user accounts go into GG population or role groups
  • GG groups become members of DL resource-access groups
  • DL groups are assigned directly to the file share, folder, or delegated resource ACL

Do not assign large numbers of individual users directly to resource ACLs unless it is a deliberate exception.

User account
  -> GG-HQ-Finance-Users
  -> DL-HQ-FS01-Departments-Finance-RW
  -> NTFS or share permission on HQ-FS01

User account
  -> GG-HQ-IT-Users
  -> DL-HQ-FS01-Departments-IT-RW
  -> NTFS or share permission on HQ-FS01

Approved examples

User population group Resource access group Permission target
GG-HQ-Finance-Users DL-HQ-FS01-Departments-Finance-RW \\HQ-FS01\Departments\Finance
GG-HQ-IT-Users DL-HQ-FS01-Departments-IT-RW \\HQ-FS01\Departments\IT
GG-HQ-All-Staff DL-HQ-FS01-Public-RW \\HQ-FS01\Public

Administrative membership examples

Use the same discipline for delegated or privileged access where it fits:

Population or role group Access or admin target group Scope
GG-HQ-Helpdesk GG-HQ-Workstation-Admins Workstation support administration
GG-HQ-Server-Ops GG-HQ-Server-Admins Member server administration
GG-HQ-Backup-Team GG-HQ-Backup-Operators Backup operations

For highly privileged built-in groups such as Domain Admins, do not assume automatic nesting strategy without a separately validated privilege model. Keep those cases deliberate and tightly controlled.

Membership rules

  • Put users into GG groups.
  • Put GG groups into DL groups for resource access.
  • Assign DL groups to ACLs.
  • Keep direct user-to-resource assignment as the exception, not the norm.
  • Keep role groups readable and business-aligned.
  • Keep resource groups readable and ACL-aligned.
  • Do not create duplicate groups that express the same intent with different names.

Naming rules for documentation

  • Use placeholders in the base blueprint.
  • Replace them in overlays or approved customer-specific runbooks.
  • Keep examples realistic and consistent with the approved baseline.
  • Do not mix placeholder examples from one customer with production values from another.
  • If a customer deviates from the base convention, document that deviation explicitly in the overlay.

Final recommendation

Use this baseline unless a customer already has an approved enterprise convention:

  • CLIENT_CODE = short uppercase customer code
  • SITE_CODE = short uppercase site code
  • infrastructure hostnames = SITE-ROLE##
  • templates = TPL-*
  • user UPN = nombre.apellido@verified-domain
  • duplicate user UPN = numeric suffix
  • standard user legacy logon = stable unique sequence such as u######
  • admin UPN = adm.nombre.apellido@verified-domain
  • service accounts = svc.<function>.<system>

Keep the naming simple, explicit, and stable. Reusability matters more than inventiveness.