Naming standards play a bigger role in your IT enterprise than you may think. No matter what your role is within your IT organization, you will see naming standards in place everywhere you look. User IDs, network domains, computer names and databases are all examples of where naming standards are used. Installation of new IT equipment usually requires a name be created for identification purposes.
How is the name chosen? Is the convention documented where people can easily find it? Who decided this convention and has it ever been revisited? If you don’t know the answers to these questions, you may want to do some research. Having poor standards, or not following them, can be more costly than you think.
Properly constructed naming standards should identify a number of characteristics embedded in the name itself. Computer names should identify information such as the owner, department and physical location. The name should categorize the sensitivity of the equipment and dictate if the machine operates in the test or production environment. For example, let’s assume the hostname NYDNSVL1.
The name may look cryptic, but if all hostnames follow the same standard, you will be able to read key information from the name. For example:
• The hostname is broken up as NY-DNS-V-L-1.
• The first field tells you the location, so we know the server is located in New York.
• The second field tells you the function or owner of the server; this is a DNS server.
• The next field tells you if the host name is physical or virtual.
• The fourth field shows the operating system running, which in this example is Linux.
• The final field is an incremental field that allows for multiple versions of the server to exist.
Let’s say we also control the length, case and character usage in this standard as well and we’ve decided the name will be in all capitals. The name won’t contain any special characters (i.e., @, &, $, etc.) and it will be a maximum length of 15 characters. We’ve chosen these standards for maximum computability between multiple operating systems and different network standards (more on that later). To better understand naming limitations with Active Directory and NETBIOS,
you may wish to read Microsoft’s Knowledge Base at http://support.microsoft.com/kb/909264.
Tips for Creating User IDs
User IDs should be unique and not easily guessed. Avoid using generic names such as OPS, ADMIN, SUPER or anything involving the company’s name. User IDs with privileged access should have a name that identifies this isn’t a normal user account. Users in operations, engineering, administration and audit should all be identifiable from the name of their user ID.
The length of the user IDs you create will be dictated by the different types of operating systems you have in place. Taking all vendors’ standards into consideration is important when creating your own naming standards. User ID and password standards enforce the strength of a password by controlling length, case sensitivity and special character usage. Interoperability issues can arise if one platform doesn’t support the standards of another. For example, companies with IBM mainframes must limit user IDs to eight characters. Windows sets the default limit to 20 characters to ensure compatibility with Windows 2000 Server. Linux supports user IDs up to 32 characters. If you have a policy in place that dictates all user IDs must be the same across all platforms, then you would need a standard in place catering to the most restrictive platform. However, you may wish to create a naming standard that limits you to 10 characters if all your systems support the length, as you don’t want to give your users IDs that are too long to type, and limiting your user ID to 10 characters should also ensure compatibility across the applications in your IT environment.
Key Factors to Consider When Defining Naming Standards
Compatibility. One of the biggest problems with incompatible names was encountered at a client site when trying to use Kerberos for single sign-on. Kerberos is a secure network authentication protocol supported by z/OS, Windows and UNIX. All three existed in the client’s environment, but the UNIX Kerberos deployment was the oldest. It was also the most incompatible due to one factor—the name. While industry standards for Kerberos exist, the various vendors that use it choose whether or not to enforce them. On the UNIX system, the vendor chose not to enforce any of the naming standards. This became a problem as the name chosen for the Kerberos setup was lowercase. Other vendors choose to enforce the naming standards that dictate the name should be uppercase. That caused the existing UNIX setup to be incompatible with the other vendors. That made the project impossible to complete without re-implementing the UNIX setup from scratch.
Scalability. Room for growth may seem like a common sense detail, but getting it wrong can have catastrophic consequences down the road. The names you define should never need to be changed, no matter how big your enterprise grows. One policy many companies have is to never reassign user IDs. They keep them unique like social security numbers. Your company may only have 10,000 employees currently working, but it may have employed 50,000 people since it was founded. These are the details that need to be considered when defining naming standards. The consequences of having to redefine user IDs or server names, for example, could come at significant cost and risk to your company.
Security. Your enterprise’s security relies heavily on good naming standards being in place. Security administrators rely on naming standards to help them categorize the entitlements being requested. Details such as sensitivity, ownership and environment (QA, development and production) can all be identifiable through a properly constructed name. Masking rules are useful for granting entitlements for large amounts of resources that will be accessed by the same group of users. Masking rules couldn’t be put in place unless ownership of resources is controlled through naming convention.
No exceptions. The only thing worse than not having good naming standards in place is not following the standards currently documented. Doing so can undermine the intended goal of the convention. Breaking standards can affect such things as automated reporting, environment segregation, ownership and security. This is why exceptions to current naming standards shouldn’t be allowed under any circumstance. In situations where newly acquired software or hardware can’t follow currently defined standards, the affected owners should meet to discuss modifications to the standards to avoid conflicts.
This article has just scratched the surface of why naming standards shouldn’t be treated lightly in your IT environment. Although these examples aren’t meant to be followed strictly, they’re meant to open your mind to different factors you should consider before creating any name. Your company’s needs will dictate the standards you define. This may seem like a lot of work, and depending on how big your company is, it may be. However, this work should be embraced, as it will pay dividends long-term as your IT environment grows.