Purpose
This proposal establishes a naming policy for computers in the NETID domain (i.e. MI). This proposal should address the hostname (netbiosname), name resolution services, and any DNS suffix restrictions. Such a proposal is necessary prior to allowing multiple organizations to join computers to this domain. This proposal addresses C16 on the MI Roadmap Feature list, https://sharepoint.washington.edu/windows/Lists/MI%20Roadmap%20Features/byPriorityUndone.aspx.
Assumptions
Multiple organizations will be joining computers to the NETID domain.
Each of these organization currently has a different computer naming policy (or no policy).
Each of these organization currently has disparate name resolution services and DNS suffixes.
Computer names are often highly visible to clients, should be meaningful and may need to be memorable, especially when the computer is a server.
Computer renames for existing computers are a potentially costly requirement which would likely lessen the chance of organizations adopting MI as their Windows domain of choice.
Windows hostnames must be less than 15 characters. Windows hostnames can contain all alphanumeric characters except the following characters:
- backslash ()
- slash mark (/)
- colon (:)
- asterisk (*)
- question mark (?)
- quotation mark (“)
- less than sign (<)
- greater than sign (>)
- vertical bar (|)
- period (.)
See http://support.microsoft.com/kb/909264 for reference.
Design Considerations
Only one computer within a Windows domain can have a given hostname (netbiosname). The hostname does not collide with any other Active Directory object (a “$” character is automatically appended to the hostname stored in the samAccountName attribute).
Netbios name resolution is still relevant for a variety of Windows-based services, and it is ideal when all computers interacting with those services use a common netbios name resolution source, i.e. the same WINS server.
Kerberos authentication routing for servicePrincipalNames (the Kerberos principal for a computer or service) has a conditional dependency on the DNS suffix of the computer, where if there is an external Kerberos-capable domain trusts in place, authentication resolution first goes to that external Kerberos realm over computer accounts in the local domain. As of today, MI has no external trusts and draft policy prohibits MI from trusting any other authentication source. So this may not be relevant. However, things change over time, and suggestions that address this might be called for.
Discussion
Because of the above stated assumptions, a single naming formula is unlikely to be palatable. A free-for-all, using a first-come first-reserved approach may create unforeseen collision scenarios with computers sharing the same hostname but with a differing DNS suffix (e.g. homer.pottery.washington.edu belonging to MI and homer.u.washington.edu). So a hybrid middle ground must be pursued that allows for flexibility but also tries to limit the potential for collisions.
A practical reason exists to have a different naming algorithm for each organization; it permits others to tell at a glance which organization a given host belongs to. Such ownership recognition can be valuable, saving time in troubleshooting scenarios.
One approach would be to leverage the existing organizational computer naming policies, and allow each of them assuming it does not collide with an existing accepted policy. One pre-requisite for getting a delegated OU in MI would then be to propose a computer naming policy for your delegated OU, and to get that policy ratified as not conflicting with existing accepted policies.
Another approach would be to disallow any hostname found in the campus WINS, by a widely known UW service, or in either the u.washington.edu or washington.edu DNS zones. This, in effect, makes DNS and WINS the authority for MI computer naming, but adds the additional requirement of restricting some existing hostnames already in use on the UW campus.
Another potential approach might be to have different policies based on the class of computer, e.g. a flexible policy for servers and other highly visible computers, and a less flexible policy for workstations, i.e. computers that are only used by a handful of people.
There are certainly other possible approaches.
Proposed Policy
Each organization which requests a delegated OU in MI will receive a default computer namespace based on the algorithm:
<delegated OU name>-<variable>
e.g. pot-barkills might be a computer in the pottery delegated OU used by barkills.
Each organization with a delegated OU CAN request additional computer namespaces.
All computer namespace reservation requests (including default ones) MUST be vetted by MI Engineering for collisions against:
- existing MI computers
- existing computer namespace reservations
prior to being accepted as a reservation. Collisions with existing computers are communicated to the requestor, and the requestor CAN:
- accept those existing computer collisions as exceptions, or
- choose a different namespace, or
- talk with the other delegated OU to work something out
New hostnames that fall under an already accepted computer namespace reservation are considered reserved by the organization with the accepted namespace reservation.
Computer namespace reservations MUST be recorded and published, along with a date of vetting approval to help eliminate confusion and resolve disputes.
Existing computers MAY be migrated into MI with whatever name they currently have, as long as it doesn’t violate an existing approved namespace reservation (or collide with the hostname of an existing MI computer).
New computers (i.e. computers not migrated in) MUST have a name that conforms to a reserved computer namespace belonging to the appropriate delegated OU.
Each organization with a delegated OU MAY challenge a computer name in use in another delegated OU, if it should fail to meet these requirements or cause some other problem. The MI Engineering team, in consultation with the MI Governance team, will resolve any such issues.
MI Engineering MAY revoke any computer name. MI Engineering SHOULD only revoke a name if there is a violation of these computer namespace rules which is not addressed with a mutually agreeable solution in a timely manner.
All computers in MI SHOULD use the campus WINS server to ensure that name resolution of down-level services works. All computers in MI SHOULD use authoritative DNS servers to ensure common DNS name resolution.
Any delegated OU admin MAY make a request for service principal names (SPNs) that differ from a computer’s hostname or fully qualified DNS name. MI Engineering MUST vet these requests against existing computer hostnames and computer namespace reservations prior to assigning the requested non-default SPN.
Example Use Cases
The College of Pottery decides that MI is the best thing since the pottery wheel. It wants a delegated OU. It decides it does not want a computer name policy. This is OK. After researching WINS and DNS, the CoP adds computers with the hostnames of bigguy, big_pot, clay_pot, and mir.
The Redundant Department of Redundancy Department decides (again) to join MI, and proposes that it’s computer name policy will be: red-*-red. This is accepted as unique, and endorsed because it’s easy to equate red with the Redundancy department. After researching WINS and DNS, the RdoRd adds computers with the hostnames of red-jojo-red, red-green-red, red-also-red, repeater, mimeograph, and mirror.
The Department of Clean Metaphysical Entertainment decides to join MI, and proposes a computer naming policy of mir*. This is unique, but collides with two existing hostnames. Neither department is willing to rename their hosts, so this proposed naming policy is rejected. Instead they propose, *_mir. This is accepted as unique, and there are no collisions. CME adds computers with the hostnames of vertigo_mir, phobia_mir, and red-red-red.
The RdoRd cries foul to MI Engineering. Red-red-red falls under their computer naming policy. MI engineering intervenes and red-red-red is renamed.
Outcome
This was implemented as part of the Delegated OU release.