Why you should not use yourdomain.local domain?

Microsoft recommended use of .local domain when Microsoft released Microsoft Small Business Server. Microsoft also understood that an SBS customer may not have in house expertise to manage Active Directory Domain and Exchange Server. Microsoft understood that SBS user will not have proper firewall. It is obvious that Exchange autodiscovery, single sign on for SharePoint and Lync Server was not in scenario at that time. So Microsoft recommended use of .local domain in Active Directory. Those who worked in SBS environment thought that they could take that concept now and implement .local domain in any organization which is a fundamental design flaw.

You have to understand  that .local domain was a past concept. Moving forward technology has changed a lot since then. You should change yourself when technology changes. But when I visit clients I see that old dog doesn’t learn new trick. Which means their autodiscovery doesn’t work. These clients end up with many issues including blaming Microsoft. You should ask yourself did you design your Active Directory and DNS correctly. Why you expect your autodiscovery to function correctly when your DNS is messy?

When you are promoting a new domain or a new forest, it is highly recommended that you use registered domain name for example yourdomain.com.au. Again those who worked in past SBS era they will raise concern of hacking, TLD etc. I would address their concern by putting the question to them, did you design and configure a correct firewall and security in your corporate infrastructure. If not then you should hire a security professional who will address your concern. Simply promoting a yourdomain.local domain will not secure your domain and you will have a false sense of security that your Active Directory is safe. In realty your corporate network might be open and vulnerable to hacking.

Here are why you should use yourdomain.com.au or registered domain in Active Directory.

  • To implement correct Exchange Autodiscovery
  • To discover correct registered domain for SharePoint and Lync Server
  • To implement single sign on
  • To install correct public certificates for Exchange, SharePoint and Lync. Note that Public Certificate Authority no longer issue certificate using .local domain
  • To use correct UPN of your registered domain
  • To setup correct local and public DNS
  • To design correct Active Directory. You shouldn’t use SBS server as your model. Microsoft retired SBS for many reasons. Brutal truth is Microsoft didn’t want to lose poor customer who couldn’t afford an open license or software assurance so most of SBS users got OEM license through hardware vendor or a reseller.
  • To follow the guidelines of IANA and IEEE when you deal with a domain.

What should you do if you already have a .local domain in SBS server?

If your SBS server is 2008, then create an Active Directory DNS zone using registered domain example: yourdomain.com.au then add HOST (A) record with PTR of webmail or mail and autodiscovery in yourdomain.com.au zone. Create public DNS record for webmail.yourdomain.com.au and autodiscover.yourdomain.com.au.

http://www.yourdomain.com.au (example registered domain) doesn’t resolve after creating yourdomain.com.au?

This happened when http://www.yourdomain.com.au is hosted with third party web hoster not internally. There is an easy fix, create a DNS forwarder or conditional forward for your http://www.yourdomain.com.au. Follow this URL to configure a conditional forwarder. For example: you can forward http://www.yourdomain.com.au to Google DNS server or the DNS server of your ISP or your web hoster who is actually hosting http://www.yourdomain.com.au. To find out who is hosting your website and their DNS record, go to https://www.easywhois.com/ type yourdomain.com.au and hit enter.

Further Study:







Active Directory Certificate Services Best Practices

AD CS is composed of several role services that perform several tasks. One or more of these role services can be installed on a server as required. These role services are as follows:

  • Certification Authority— This role service installs the core CA component, which allows a server to issue, revoke, and manage certificates for clients. This role can be installed on multiple servers within the same root CA chain.
  • Certification Authority Web Enrollment— This role service handles the web-based distribution of certificates to clients. It requires Internet Information Services (IIS) to be installed on the server.
  • Online Responder— The role service responds to individual client requests regarding information about the validity of specific certificates. It is used for complex or large networks, when the network needs to handle large peaks of revocation activity, or when large certificate revocation lists (CRLs) need to be downloaded.
  • Certificate Enrollment Web Service— This new service enables users and computers to enroll for certificates remotely or from non-domain systems via HTTP.
  • Certificate Enrollment Web Policy Service— This service works with the related Certificate Enrollment Web Service but simply provides policy information rather than certificates.
  • Network Device Enrollment Service— This role service streamlines the way that network devices such as routers receive certificates.

Windows Server 2012 Step by Step
Active Directory Certificate Services Hierarchy

Public Key Infrastructure must be deployed in hierarchical order to securely deliver certificates to clients, application and servers. The best way to achieve this is to deploy a Standalone Offline Root CA and Online Enterprise Subordinate CA. Offline Root CA meaning you have to shut down the CA once you obtain the CRL chain for subordinate CA. Subordinate stays powered on and joined to the domain. Offline Root CA works in a workgroup not a domain member.

Standalone offline Root CA:


  • Principal component of PKI infrastructure
  • Provide CRL sign off capacity for subordinate authority
  • Provide Web Enrolment for Sub-ordinate Certificate Authority
  • Maintain CAPolicy.inf to record OID and certificate authority validity period

Online Enterprise Subordinate CA


  • Subordinate Component of PKI infrastructure
  • Present and issue Certificates to clients
  • Sign off Web Certificates for application
  • Management point of Certificate Infrastructure
  • Maintain CAPolicy.inf to record OID and certificate authority validity period

Certificate Services Best practices

  • Analyze and plan necessity of Active Directory Certificates or public key infrastructure (PKI) in your organization before deploying certification authorities (CAs)
  • Place database and transaction log files on separate hard drives possibly SAN
  • Keep the root certification authority offline and secure its signing key by hardware and keep it in a vault to minimize potential for key compromise
  • When changing security permissions for the certification authority (CA), always use the Certification Authority snap-in
  • Do not issue certificates to users or computers directly from the root certification authority
  • Always point client to subordinate certificate any certificates
  • Back up the CA database, the CA certificate, and the CA keys
  • Ensure that key lifetimes are long enough to avoid renewal issues
  • Review the concepts of security permissions and access control, since enterprise certification authorities issue certificates based on the security permissions of the certificate requester
  • Use Secure Sockets Layer (SSL) when using Web-based certificate enrollment

Certificate Provider

You have to select RSA#Microsoft Software Key Storage Provider” with sha1 if there is any Windows XP Client otherwise select RSA#Microsoft Software Key Storage Provider” with sha256 as certificate provider.

Cryptographic Key Length

Use 2048 bit cryptographic length for both offline Root CA and Subordinate CA.


  • Plan certificate templates before deployment
  • Only Publish templates that are necessary
  • Duplicate new templates from existing templates closest in function to the intended template
  • Do not exceed the certificate lifetime of the issuing certification authority
  • Do not delete the Certificate Publishers security group

Validity Period

  • Offline Standalone Root CA- 10 Years
  • Online Enterprise Subordinate CA- 10 Years

Revocation List

The following sections summarize how certificate revocation checking works.

  • Basic chain and certificate validation
  • Validating revocation information
  • Network retrieval and caching

Revocation Best Practice

  • Leave the default revocation checking behavior instead of using CRLs for revocation checking
  • Instead of creating long listings of URLs for OCSP and CRL retrieval, consider limiting the lists to a single OCSP and a single CRL URL
  • Use CryptoAPI 2.0 Diagnostics to Troubleshoot Revocation Settings
  • Use Group Policy to Define Revocation Behavior

Audit Policy

Select the following Audit Policy for both Certificate Authority

  • Backup and restore the CA database
  • Change CA configuration
  • Change CA security settings
  • Issue and manage certificate request
  • Revoke certificates and publish CRL

Backup Certificate Authority

  • Backup Public Key
  • Backup CA database
  • Retention: Daily increment/Monthly Full

Security Permission on Template

The following table summarize certificate security permission in AD CS.

Domain Computers Auto-Enroll Read Only
Domain Users Auto-Enroll Read Only
Wintel Administrator Full Control Full Control

Security Permission on Servers

You must create role separation in Active Directory Certificate Services to provide greater control on Certificate Authority. To enable Role separation, Open Elevated command prompt and type certutil -setreg caRoleSeparationEnabled 1. The following table describe role separation for AD CS.

CA Administrator Full Permission
Certificate Manager Issue and Manage Certificates
Auditor Manage auditing and security logLocal Security Settings/ Security Settings/Local Policies/User Rights Assignments
Backup Operator Back up file and directories

Local Security Settings/ Security Settings/Local Policies/User Rights Assignments

Enrollees Authenticated Users

The Following are the messy configurations you must avoid when installing a Certificate Authority.

  • Do not install Certificate Authority on any Domain Controller or server with other roles unless you are a small business and you have only one or two servers in your organization. In this case, you don’t have any choice.
  • Do not install both certificate authority in two different operating systems such as Windows Server 2003 and Windows Server 2008.
  • Do not keep CAs in different patch and update level.
  • Do not use 1024 bit encryption length.

Relevant Articles:

Microsoft Active Directory Best Practice Part II

Microsoft Active Directory—Best Practice