Name Resolution in 'the cloud' using Active Directory

When running DNS to support an Active Directory domain within Amazon's EC2 and MS Azure I've observed some subtle differences with the set-up of the forwarders for resolution of external name spaces.

To add context to the above, I'm running AD domains within the Azure and AWS domains and therefore domain joined servers are configured to use the DNS server on the Active Directory Domain Controller for DNS in order to support normal domain membership capabilities. Should the member server or client require name resolution for external namespaces then additional configuration is required in some cases, as the client only makes DNS queries to Domain Controller and therefore can't leverage the inbuilt functionality provided by the platform.

In Azure, standalone machines using the out of the box configuration, will rely on the Azure DNS option on the VNET which will resolve any external name queries by via the Azure infrastructure as defined by the option illustrated below for when viewing the VNET >> DNS Servers.

The same is true for VPCs in AWS, their default DHCP option set will be configured with 'AmazonProvidedDNS' which will provide a reserved IP address at the base of the VPC address space (the last octet incrememted by 2) and will be enabled to service name resolution for external DNS names.

When considering the scenario of configuring forwarding for name queries from a Domain Controller or other hosted DNS server and also assuming that it is undesirable for the servers to have direct access to the Internet via the VNET default routing or public IP address assignment. Therefore I have configured the forwarders on the DNS Server with the Azure/AWS supplied recursive resolvers and remove the Root Hints ensuring that there is a single defined path for name resolution. This approach ensures that any name resolution queries are answered by the Domain Controllers for the name space for which it is authoritative and any external name space queries are forwarded within the VPC/VNET and answered by the platform and sent back to the DC. This ensures that no DNS traffic directly originating or destined for an internal server is exposed to the outside world.

The recursive resolvers that can be used in as forwarders are listed below;

• Azure DNS - 168.63.129.16

• AWS DNS - 169.254.169.253

List FSMO Roles via Command Line

To list FSMO via the command line, use the following command

netdom query fsmo 

It's much easier than using the MMC GUI

Security Accounts Manager Failed

This morning we received errors from a remote site 2003 based Domain Controller which was sharing the hardware with a File Server, with the following message being logged in the Directory Services Log.

NTDS (460) NTDSA: Corruption was detected during soft recovery in logfile C:\WINDOWS\NTDS\edb.log. The failing checksum record is located at position END. Data not matching the log-file fill pattern first appeared in sector 14418 (0x00003852). This logfile has been damaged and is unusable.

 When restarting the server, the following message was appearing and when clicking 'OK', the DC would then reboot.

 

By entering Directory Services Restore Mode, several checks were preformed using NTDSUTIL from the Command Prompt.

NTDSUTIL > FILES > INFO showed that all files were present and the correct size.

NTDSUTIL > FILES > INTEGRITY showed that the Database was corrupt.

NTDSUTIL > FILES > RECOVER would not recover the database.

Finally I tried,

esentutl /p “C:\Windows\NTDS\ntds.dit” /!10240 /8 /o

Deleted all log files present in the NTDS folder, in this case C:\Windows\NTDS

Then a DB analysis which completed successfully.

NTDSUTIL > Semantic Database Analysis > Go

Upon rebooting the server, no more error messages and I was now in a point where I could gracefully Demote the server and replace it with a dedicated Domain Controller.

Troubleshooting AD Replication & Lingering Objects

Some handy links for better understanding the troubleshooting of AD replication, Lingering objects and their removal, with a guide coming soon.

Removing Lingering Objects

Information about Lingering Objects in an AD Forest
 https://support.microsoft.com/en-us/kb/910205

Removing Lingering Objects
http://blogs.technet.com/b/askds/archive/2014/09/15/remove-lingering-objects-that-cause-ad-replication-error-8606-and-friends.aspx

Fixing Lingering Object Problems
https://technet.microsoft.com/en-us/library/cc738018%28v=ws.10%29.aspx

Strict Replication Consistency 

Contrary to popular belief, Strict Replication Consistency isn't enabled by default on DCs that reside in forests upgraded from 2000 functional levels
http://blogs.technet.com/b/askds/archive/2010/02/15/strict-replication-consistency-myth-versus-reality.aspx

Troubleshooting Replication

AD Replication Status Tool
A very useful tool for troubleshooting replication, think of repladmin but in a GUI and more.
http://blogs.technet.com/b/askds/archive/2012/08/23/ad-replication-status-tool-is-live.aspx

ReplDiag
http://activedirectoryutils.codeplex.com/releases/view/13664

My take on Stub Zones vs Conditional Forwarders

I'm lucky/unfortunate enough (delete depending on the day) to architect and manage a geographically distributed Active Directory environment consisting of multiple domains and forests. The forests are connected using a variety of AD trusts and they all hinge on our DNS infrastructure.

I've typically been a big advocate for AD integrated stub zones rather than Conditional Forwarders due to the ability to centrally manage them by virtue of their AD integration whether it be Domain or Forest wide scope and also their ability to update the name servers belonging to the DNS zone.

To be clear, stub zones contain three record types (SOA, NS and A) which reference the name servers responsible for the source DNS zone. Periodically the SOA, NS and A records are updated from the Master Server list for the particular zone. When a query is performed against the server hosting and matching the Stub Zone, the server references the NS and then A records contained in the zone to direct the query to a suitable name server for an answer. This is perfectly acceptable when the source zone is located on a number of Domain Controllers in a central location such as a data centre but may add complications when the Domain Controllers are geographically distributed, such as in Hub/Spoke topologies where the spokes consist of DCs in remote offices connected to small/slow links. While answers to name queries are cached by the server hosting the stub zone, attempting to perform name lookups across such links may introduce delays or add to the traffic on the links. Microsoft indirectly acknowledge this eventuality by virtue of the behaviour of stub zones in the Technet - Contrasting stub zones and conditional forwarders but in the context of security and not being able to directly influence server to server connections when compared to the static configuration of Conditional Forwarders.

Stub zones do not provide the same server-to-server benefit because a DNS server hosting a stub zone in one network will reply to queries for names in the other network with a list of all authoritative DNS servers for the zone with that name, instead of the specific DNS servers you have designated to handle this traffic.

Based on the above statements, interpretation and my experience, my recommendations are as follows..

Conditional Forwarders - Great for server to server connections for name resolution such as specifically defining server A will always forward to server X,Y,Z for contoso.com when contoso.com is a hosted on a geographically heavy distributed AD infrastructure or where not all sites are routable from server A. The obvious downside with all Conditional Forwarders is maintaining the list of forwarders on a per server basis.

Stub Zones - Ideal when referencing DNS zones hosted on resource forests/infrastructures which are hosted centrally, fully routable/reachable from the server hosting the stub zone. Obvious benefits are that the name server list is maintained as part of the stub and the zone can be AD integrated to ensure that it is available throughout the Domain or Forest. Be careful when creating a stub zone which references a zone which is hosted on geographically distributed infrastructure.

MS KMS and publishing to additional Domains

MS KMS automatically publishes a SRV record to the DNS of it's local domain, which is ideal if there is a single AD forest/single domain configuration, but if instead there's a single AD forest with multiple domains then straight out of the box, a single KMS deployment isn't going to cut it.

Obviously, one or more KMS servers can be deployed in each domain in the forest but even with virtualisation that approach can become expensive, time consuming, complicated from a licensing compliancy perspective. Therefore I propose the following, configure the one (or two) KMS servers located in (maybe the forest root) to service the other domains too.

Once the KMS is configured and working, open Regedit.exe and navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform

Create a new Multi-key Value and name it DnsDomainPublishList. Edit this new registry value and enter a list of the domains which the KMS is to publish to, one per line. (see below)



Once the entries have been made, restart the 'Software Protection' service.

In order for KMS aware clients to 'find' the KMS, it registers SRV records in DNS _VLMCS._TCP., confirmation that this has occurred can be found in the Application Event log on the KMS server with an Event ID of 12294, with the message;

Publishing the Key Management Service (KMS) to DNS in the fake.company.com' domain is successful.

If any 12293 Event IDs exist with

'Publishing the Key Management Service (KMS) to DNS in the 'fake.company.com' domain failed.
Info:
0x80072338

Check  the _tcp. for an existing _VLMCS SRV record, as a KMS may have already been unwittingly introduced to the environment.

Converting Integer8 to Time and Date

I recently discovered a quick way of converting an Integer8 number which is used for the pwdLastSet attribute among others in Active Directory. The Integer8 is often used to represent time in 100-nanosecond intervals since 12:00 AM January 1, 1600 and there appears as a long integer like value such as 129148817107011564

To convert this value to a meaningful date, the w32tm command can be used from a command line with the ntte argument..

w32tm /ntte

Associate the employeeID attributed with the user class in AD

In preparation for our new HR system, I linked the existing employeeID attributed in our AD Schema to the user class. This allows the storing of employee IDs in Active Directory for each user. A quick guide can be found here