At Peninsula IT a common engagement for field consultants in our Sydney based Amazon Consulting Partner Cloud practice is the setup or remediation of an Amazon Web Services (AWS) environment that involves a Microsoft Active Directory hosted within a VPC and managed by the customer. What is also common, is that the subnetting of the Virtual Private Cloud (VPC) network within the AWS account needs fixing – perhaps there is not enough available addresses (subnets too small), or perhaps there is too many addresses in each subnet but not enough subnets available in the VPC network.
To fix this problem and modify the subnet details, we need to follow the AWS community advice and:
- Shut down the all the EC2 instances on the affected subnet
- Create Amazon Machine Images (AMI’s) of the EC2 instances and verify success. Make sure all the AMI’s are completed.
- Delete the original instances on the subnet
- Record the details of the affected subnet such as routing table assignment, network ACL’s and tags
- Delete the subnet
- Create a new subnet (s) with more or less available IP’s, depending on the problem you are trying to fix. Typically we use subnet CIDR addresses with /27 or /28 bit subnet masks.
- Specify the details that were recorded in step 4 for the new subnet (s) as appropriate – routing table assignment, network ACL’s and tags
- Launch new instances using the AMI’s you created in Step 2, selecting the correct new subnet that was created in Step 6.
Now we have our instances back, and running on the new subnets that give us the address spacing we need. At this point, everything should be fine – right? In most cases, the answer is yes. However, when the steps 1-8 above involve the recreating of a Domain Controller, the change in IP address due to the new subnet (AWS IP addresses are automatically allocated) will mean that the member servers can probably no longer contact the domain controller. This also means that you probably won’t be able to log onto the AD member instances using your domain credentials and you will receive the the Windows Network Level Authentication (NLA) error shown below:
The workaround for this is simple if you know the username and password for a local administrator account for the affected member instances. You simply login to the instances and change the DNS setting to point at the new IP address of the domain controller.
However, on many engagements we often see that customers do not know the local administrator username and password (as best practice is generally considered to disable the default local administrator account and create a new one with a new name). At this point, you might be think, uh-oh, what have I done! Well, this is also fixed quite easily by adding a new local administrator account via the Windows Computer Management MMC snapin for the remote computer from the console of the domain controller as below.
From here, it’s just a case of adding a new local administrator
and using that account to log onto the member servers console using RDP to change the DNS network address to the new domain controller IP address. At this point, the NLA error should be gone, and your AWS instances should be working just like they were before the subnet was recreated.