Skip to main content

Client Credential Administration Standard

This standard defines how DTC technicians create, assign, rotate, and document credentials across DTC-managed client environments. It applies to all DTC-managed client infrastructure and supersedes any per-tech or per-client variation.

See also: DTC Company Information Security Policy Section 5.1 Identity Management for DTC's internal authentication doctrine and passwordless requirements.

Scope and Governing Principles

  • MFA is required for all administrative accounts.
  • Break-glass accounts authenticate with one-time token generation or a passkey stored in 1Password. Break-glass access is approved by Code Commanders (T3).
  • All credentials must be related to the organization they belong to. No cross-tenant credential reuse.
  • All client credentials are documented in the client's IT Glue record, or in encrypted custom fields on the relevant HaloPSA, NinjaOne, or IT Glue entity.
  • DTC@user1 and DTC@dental1 client-side accounts are DEPRECATED. Do not create these accounts on new deployments. Existing instances should be removed during the next scheduled maintenance or infrastructure refresh. These legacy accounts were previously used as read-only service/monitoring accounts but are replaced by the dtcadmin and dtcautomate service account standards defined below. If you encounter one in the field, document it in the client's IT Glue and schedule removal.
  • Password baseline: 16+ characters across all systems. No system, application, or account uses a lower threshold.
  • MFA for end users: DTC actively pursues MFA enablement for client end users during onboarding and renewal conversations. Blanket enforcement is not required by this standard, but user MFA SHOULD be prioritized wherever the client's environment, licensing, and workflow allow.

Cloud Identity and SSO for Clients

DTC pursues SSO-first identity architecture for client environments wherever possible, mirroring our own SSO-First Doctrine (see DTC Information Security Policy Section 5.1.2). During client onboarding, renewal, and infrastructure modernization:

  • Prefer Microsoft Entra ID (or the client's existing identity provider) as the authentication source for client applications and services.
  • Identify candidates for federation during technology assessments.
  • Recommend migration off legacy on-premise directory-only patterns where feasible.
  • Document client-specific SSO readiness and gaps in IT Glue.

Legacy on-premise Active Directory environments remain in scope for this standard until they can be federated or replaced.

Active Directory and Directory-Joined Applications

This section applies to client endpoints (local administrator accounts on individual devices) and legacy on-premise Active Directory domains. Modern cloud-first client environments using Microsoft Entra ID should follow the Cloud Identity and SSO guidance below.

  • Administrator accounts (new domains / server setup): Randomly generated 16+ character password. Tech choice or client request.
  • Legacy formula (clientshortname@streetnamelocation#!): DEPRECATED. Do not use the address-based formula for new deployments. Use randomly generated passwords or the staging password DTC@dental{year}! during build, then rotate to production credentials before handoff.
  • REQUIREMENT: Administrator passwords SHALL always follow the client's documented password policy regardless of generation method.
  • End user accounts: clientshortname@user1 or client-requested default. When handing off, remind the client it is best practice for each user to set their own password with no record kept by DTC.
  • DTC users (DTC-owned accounts in client directories): 16+ character password.
  • DSRM (Directory Services Restore Mode) password: Must match the built-in DOMAIN\Administrator credentials.
  • Service user accounts: Randomly generated 32+ characters.

Microsoft 365

  • Tenant administrator accounts (admin@clientdomain.onmicrosoft.com): Randomly generated 32+ character password.
  • End users: clientshortname@user1 or client request.

Servers (Physical Hosts and Hypervisors)

  • Out-of-band management (iDRAC, IPMI, iLO): 32+ character randomly generated password, unique per device.
  • Local admin (dtcadmin): Follows the Workstation Local Admin policy or the AD/Applications Administrator policy defined above ... whichever is applicable to the server's role.
  • STAGING servers... Local Admin (dtcadmin): Password is DTC@dental{year}! during build/staging. Same pattern as staging workstations. This password MUST be changed to production credentials before the server is placed into service.

Network Devices

  • Administrator accounts: Randomly generated 16+ character password.
  • End user accounts on network devices: Unique 16+ character passwords or client-requested password. Must follow the client's password policy.
  • VPN pre-shared keys: Unique 32+ character keys.

Wireless (WiFi)

  • Private SSID PSK: Randomly generated, 16+ characters.
  • Public/Guest SSID PSK: toothbrush default, client phone number (main office line), or client request.

Note: The 16+ baseline applies to all WiFi PSKs despite legacy conventions allowing shorter keys. User-typed PSK friction is an acceptable trade-off for baseline consistency.

Encryption Keys

Randomly generated, 32+ characters.

DTC Leased Devices (QNAPs, BDR appliances, SonicWalls delivered as-a-Service)

DTC leased devices are owned by DTC Inc. They authenticate against Microsoft Entra ID, Active Directory, OR via a distributed local administrative user that uses the same credentials across each leased asset. Distributed local administrative user credentials are stored in IT Glue under a label matching the appliance context... for example BDR admin, SonicWall admin, UniFi admin, or QNAP admin... so the credential's purpose is immediately clear. Do not change these credentials on individual devices without coordinating with the team managing the leased fleet.

DTC Services (Datamotion, Cloud Portals, Managed Services)

  • clientshortname@user1, randomly generated, or client request.
  • If the office is making unique per-staff accounts, users SHALL be forced to set their own password after first login.

Workstations

  • STAGING workstations... Local Admin (dtcadmin): Password is DTC@dental{year}! during build/staging (where {year} is the current calendar year, e.g., DTC@dental2026!).
  • STAGING Security Questions: (1) Street number of the client, (2) Full street name (Rd = Road, Ave = Avenue, etc.), (3) ClientShortName.
  • PRODUCTION workstations... Local Admin (dtcadmin): 16+ character randomly generated, rotated at least monthly via LAPS.
  • All staging and production workstation credentials SHALL be documented in the client's IT Glue.

CRITICAL: All staging credentials SHALL be changed to production credentials before any device (workstation or server) is handed off to the client or placed into production service. No exceptions. Staging passwords are well-known, short-lived, and must never persist into production environments.

Service Account Naming Conventions

DTC uses standardized service account naming so the purpose of every non-human identity is immediately obvious:

Username Purpose
dtcadmin DTC's shared / break-glass administrative account for client environments. Not used for day-to-day work.
dtcautomate Endpoint automation and background app-to-app service automation driven by DTC scripts (NinjaOne, RMM automations, PowerShell jobs)
{org-name}-{tool-name}-automate Dedicated service accounts for a specific tool integrating with a specific organization's environment. Recommended for any new automation ... one identity per tool per org, so credentials can be rotated or revoked granularly.
dtcbackup Dedicated backup service accounts. Used by Veeam, MSP360, NinjaOne Backup, and any other backup platform.

Service Account Access Restrictions

All DTC service accounts (dtcadmin, dtcautomate, dtcbackup, {org}-{tool}-automate) share these restrictions:

  • Shell only. Not permitted to log in via remote console, remote desktop, or the local console interface.
  • Deny Log on locally, deny interactive login.
  • MFA required where the service or API supports it.
  • Credentials for per-client service accounts stored in IT Glue (client record). Credentials for DTC-internal service accounts stored in 1Password. Encrypted custom fields in HaloPSA or NinjaOne are authorized for operationally-scoped storage where the workflow requires it. Never embedded in scripts or source control.
  • Rotated on personnel departure for any human who had access.

Break-Glass Accounts

  • DTC's shared break-glass username for client environments is dtcadmin.
  • Break-glass accounts authenticate via one-time token generation OR a passkey stored in 1Password.
  • Not used for routine work. Access events are logged and reviewed.
  • Break-glass access to client environments is approved by Code Commanders (T3).

Approved Credential Storage

  • IT Glue is the primary documentation vault for all client credentials. See the Approved Credential Storage standard for the full vault map.
  • 1Password is DTC's primary credential vault for DTC-internal credentials only — DTC employee accounts, DTC corporate infrastructure, B2 admin/master keys, and break-glass passkeys. 1Password is not used for client credentials.
  • Operational applications and tools (HaloPSA, NinjaOne) that support encrypted or hashed credential fields may store client credentials inline where the operational workflow requires it.

Passwords SHALL NOT be stored in plaintext documents, spreadsheets, chat messages, email, or scripts.

AI Tool Credential Restrictions

Per DTC Information Security Policy Section 5.9 AI Usage Policy, the following credential tiers SHALL NOT be input into any AI tool, chat interface, or model under any circumstances:

  • Production credentials... any credential for a live client environment, DTC infrastructure, or service account in active production use. Includes tenant admin passwords, AD admin passwords, service account credentials, BDR appliance credentials, network device credentials, VPN PSKs, and encryption keys.
  • Staging credentials... the formulaic staging passwords (DTC@dental{year}!), staging security questions, and any credential for a system being actively built or configured for production handoff. Staging credentials are predictable enough that exposure through AI chat logs represents a real threat to any not-yet-rotated system.

Development credentials are a separate, narrower tier and may be used in AI tools only under the conditions defined in the AI Usage Policy, Section 3.4 Development Credentials in AI Tools. Development credentials are strictly for sandbox/test environments with no real data, no PII, rotatable within minutes, limited scope, and individual ownership. If the environment touches real data of any kind, treat the key as production.

When in doubt: redact first. See DTC Information Security Policy Section 5.9 for the full AI Usage Policy.

Back to top