Assumptions, Defaults, and Intentional Constraints
Purpose of This Page
This page records the key decisions and assumptions made during initial domain provisioning for the Samba Active Directory Domain Controller (AD DC). The goal is not to document every command used, but to explain why certain choices were made, which defaults were accepted, and which alternatives were intentionally rejected.
Provisioning is the moment where long-term constraints are established. Many operational issues that appear months later trace back to early domain decisions, especially around naming, DNS, and service integration. This page exists to preserve that reasoning.
Domain Role and Scope
The domain was provisioned with the explicit assumption that it would serve a small, tightly controlled environment rather than a large, multi-site enterprise.
Key implications of this scope:
- A single domain controller is sufficient initially
- Simplicity and predictability are prioritized over scalability
- Defaults that favor Windows compatibility are preferred over customization
- Future expansion is possible but not assumed
This framing guided nearly every provisioning choice.
Domain Naming Decisions
Internal Domain Name
The internal domain name was selected to be:
- Stable
- Unambiguous
- Not publicly routable
- Consistent across DNS, Kerberos, and LDAP
Once chosen, a domain name becomes effectively immutable. Renaming a domain is technically possible but operationally risky and rarely worth the effort. For this reason, the name was treated as infrastructure, not branding.
Design principle:
Domain names should be boring, durable, and resistant to future reinterpretation.
NetBIOS Name
The NetBIOS domain name was chosen to be:
- Short
- Uppercase
- Clearly associated with the domain identity
- Unlikely to collide with hostnames or service names
Although NetBIOS is legacy technology, Windows still relies on it in certain contexts. Choosing a clean, predictable NetBIOS name avoids edge-case ambiguity later.
DNS Integration Strategy
The domain controller was provisioned as the authoritative DNS server for the domain.
Reasons for this decision:
- Active Directory depends on DNS for service discovery
- SRV records must be consistent and authoritative
- Client behavior is more predictable when AD controls DNS
- Mixing external DNS servers introduces subtle failure modes
External resolvers may still be used for upstream resolution, but the domain namespace itself is owned and served by the AD DC.
Operational rule:
If identity matters, DNS must be under domain control.
Kerberos Realm Configuration
The Kerberos realm was derived directly from the domain name and treated as a first-class security boundary.
Key considerations:
- Realm naming consistency with DNS
- Strict time synchronization requirements
- Avoidance of manual realm overrides or custom mappings
Kerberos is intolerant of drift and ambiguity. The provisioning process favors defaults that align with Windows expectations rather than creative reinterpretations.
Schema and Feature Set Choices
No custom schema extensions were added during provisioning.
Reasons for deferring schema modification:
- Schema changes are permanent and domain-wide
- Most requirements are satisfied by the default AD schema
- Future needs are easier to evaluate once the domain is operational
- Custom schema increases cognitive and operational load
This decision preserves flexibility by not consuming it prematurely.
Authentication and Access Assumptions
The domain was provisioned with the assumption that:
- Authentication flows will use Kerberos, not LDAP binds
- Windows clients will be first-class domain members
- Administrative access should be centralized and auditable
- Permissions should be granted via groups rather than individuals
These assumptions align with Active Directory’s design and reduce the temptation to implement ad-hoc access controls later.
Single-DC Tradeoffs
Provisioning assumed a single domain controller architecture initially.
Benefits:
- Simpler mental model
- Easier troubleshooting
- Lower operational overhead
Risks:
- Single point of failure
- Greater importance of backups and documentation
- Careful change management required
This tradeoff is considered acceptable for the current environment, with the understanding that additional controllers can be added later if needed.
What Was Explicitly Not Done
Documenting non-decisions is as important as documenting decisions.
The following were intentionally avoided during provisioning:
- Manual LDAP edits
- Schema customization
- External DNS ownership of the domain zone
- Nonstandard Kerberos realm mappings
- Over-optimization for hypothetical future scale
Each of these introduces long-term complexity disproportionate to current needs.
Summary
Domain provisioning establishes the rules of the system long before day-to-day operations begin. The decisions documented here favor predictability, compatibility, and long-term maintainability over customization or cleverness.
By accepting conservative defaults and deferring irreversible changes, the domain remains easier to reason about, easier to troubleshoot, and easier to evolve as operational requirements become clearer.
Status
These provisioning decisions reflect the current understanding and scope of the environment. If the domain expands, integrates additional services, or introduces new trust relationships, this page should be revisited and updated accordingly.