Skip to content

Identity and Namespace Strategy

This guide assumes the organization will grow from a single-site company into a multinational identity estate that eventually integrates tightly with Microsoft 365 and Microsoft Entra ID.

Recommendation

Use:

  • Forest: single forest
  • AD domain: corp.gntech.me
  • User sign-in UPN suffix: gntech.me

Do not use hq.gntech.me as the forest root domain if the long-term vision is multinational growth.

Why corp.gntech.me instead of hq.gntech.me

hq.gntech.me is location-bound. It encodes headquarters into the identity namespace, which becomes awkward once the company grows into:

  • multiple countries
  • multiple regions
  • more than one major office
  • mergers or legal entities that do not map cleanly to "HQ"

corp.gntech.me is better because it is:

  • organization-wide rather than site-specific
  • neutral for future branches, subsidiaries, and regional operations
  • easier to keep stable for decades
  • consistent with the idea that the AD domain is an enterprise identity namespace, not a site label

User sign-in model

Users should sign in with:

nombre.apellido@gntech.me

not with the AD DNS name as their user-facing identity.

The on-prem AD domain can remain corp.gntech.me while the user UPN suffix is set to gntech.me. This is the future-proof model for Microsoft 365 because users can keep the same business identity in:

  • on-prem Active Directory
  • Microsoft Entra ID
  • Microsoft 365
  • Exchange Online
  • Teams
  • future SaaS integrations

User naming standard

Standard user identity

The approved default user pattern is:

  • UPN: nombre.apellido@gntech.me
  • primary mail address: nombre.apellido@gntech.me
  • display name: Nombre Apellido

Examples:

  • miguel.perez@gntech.me
  • ana.garcia@gntech.me
  • laura.rodriguez@gntech.me

This keeps the user-facing identity simple, professional, and aligned with future Microsoft Entra ID synchronization.

Duplicate-name handling

If the natural nombre.apellido@gntech.me value is already in use, append a numeric suffix to the alias portion only:

  • miguel.perez@gntech.me
  • miguel.perez2@gntech.me
  • miguel.perez3@gntech.me

Do not invent alternate spellings or inconsistent abbreviations unless a documented exception is required.

The standard should stay predictable so helpdesk, HR, and identity operations can resolve collisions quickly.

Immutable internal identifier

Readable names are not enough for long-term identity administration. Every user should also receive an internal unique identifier that never depends on the person’s name.

Recommended pattern:

  • employeeID = GNT-000123

This identifier should remain stable even if:

  • the user changes legal name
  • the user is rehired later
  • another person has the same first and last name
  • the business later integrates with other systems

If the environment uses Exchange schema extensions or operational attributes, the same identifier can also be copied into a tracking attribute such as extensionAttribute1, but employeeID should remain the primary human-readable internal key.

sAMAccountName standard

Do not base sAMAccountName on the full user name as the long-term standard.

Recommended pattern:

  • sAMAccountName = u######

Examples:

  • u000123
  • u000124
  • u000125

Why this is recommended:

  • sAMAccountName has legacy length constraints
  • name-based sAMAccountName values become messy with duplicates
  • stable numeric-style values are easier to keep unique
  • the user signs in with UPN, not with the legacy logon name, so sAMAccountName can be optimized for administration rather than memorability

Administrative accounts

Administrative identities should not reuse the same naming pattern as standard user accounts.

Recommended pattern:

  • standard user: miguel.perez@gntech.me
  • admin user: adm.miguel.perez@gntech.me

Examples:

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

This keeps privileged identities visibly separate from day-to-day user identities and helps later policy, monitoring, and delegated administration.

Administrative accounts should also receive their own unique internal identifiers and should live in the approved Admins OU, not under standard Users.

Service accounts

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

Recommended examples:

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

If a service identity needs a mail-like UPN for application compatibility, use a separately documented service naming standard rather than mixing service accounts into the human naming convention.

Why this is aligned with Microsoft guidance

Microsoft states that:

  • UserPrincipalName is the Microsoft Entra username for user accounts
  • a UPN must be unique within a directory forest
  • if the on-prem UPN suffix is verified in the Microsoft Entra tenant, the synchronized Microsoft Entra UPN remains the same
  • OUs are for administrative purposes such as Group Policy application and delegation of authority

That leads to the design principle used here:

  • keep the AD domain name stable and neutral
  • keep the user-facing UPN aligned with the verified public business domain
  • use OUs and sites, not extra domains, for geography and operations whenever possible
  • use a single enterprise management root OU such as OU=GNTECH for clean long-term structure
  • use an object-first OU model for standard users, workstations, and servers, while keeping privileged administration in separate admin-tier containers

Domain and forest recommendation

Default enterprise recommendation

Use:

  • 1 forest
  • 1 domain
  • many sites
  • many OUs

This should be the default for GNTECH unless a later requirement proves otherwise.

Why not create multiple domains early

A new domain is not just a naming preference. Microsoft’s logical model shows that domains are directory partitions with their own replicated domain data and administrative implications. The SID guidance also matters: if a user moves between domains, they receive a new SID and rely on SIDHistory for continuity.

That means multiple domains add:

  • more complexity
  • more replication and operational overhead
  • more migration complexity for users and resources
  • more identity lifecycle friction for a company that mainly needs one global identity plane

When a new domain is justified

Only introduce additional domains if there is a real requirement such as:

  • separate replication boundaries that cannot be solved with sites
  • unique password/account policy requirements that justify a new domain
  • large-scale autonomy requirements that cannot be handled with delegation
  • legacy application constraints

Even then, remember that the forest remains the top shared identity structure. If you truly need a hard security or administrative separation, the discussion should often be about separate forests, not simply child domains.

GNTECH future-proof naming standard

AD and cloud

  • AD forest root domain: corp.gntech.me
  • User UPN suffix: gntech.me
  • Microsoft 365 primary identity suffix: gntech.me

Examples

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

Computer naming examples

  • HQ-DC01
  • HQ-FS01
  • BR1-DC01
  • US-NYC-CL0231

Site codes

Keep site identity out of the AD domain name and put it into:

  • site codes
  • OU hierarchy
  • AD Sites and Services
  • hostname conventions

Final recommendation for GNTECH

If the public business namespace is gntech.me, the documentation standard should be:

  • Forest/domain DNS: corp.gntech.me
  • User UPN suffix: gntech.me
  • Standard user UPN/mail: nombre.apellido@gntech.me
  • Duplicate user handling: append a numeric suffix such as nombre.apellido2@gntech.me
  • Legacy logon name: use a unique stable value such as u######
  • Internal immutable identifier: use employeeID such as GNT-######
  • Administrative account pattern: use a visibly separate prefix such as adm.nombre.apellido@gntech.me
  • Enterprise management root OU: OU=GNTECH
  • Primary production object OUs: Accounts, Computers, Groups
  • Primary child OUs: Users, Admins, Service Accounts, Servers, Workstations, Security Groups
  • Do not use: hq.gntech.me as forest root
  • Use OUs and AD Sites: for geography, branches, countries, and administrative delegation

Sources

  • Microsoft Learn: Understanding the Active Directory Logical Model
  • https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/understanding-the-active-directory-logical-model
  • Microsoft Learn: Microsoft Entra UserPrincipalName population
  • https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname
  • Microsoft Learn: Security identifiers
  • https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers