-1

We've successfully extended our on-premises active directory to AWS, creating domain controllers as EC2 micro instances, we loosely based our setup on the Amazon White Paper: Implementing Active Directory Domain Services in the AWS Cloud

We are in the process of implementing a system of stopping all of our EC2 instances outside of business hours and starting them inside of business hours. However, I can't seem to find any documentation regarding the effects (if any) of stopping and starting these DCs along with other EC2 instances.

SatanicPuppy gave a very vague warning on this topic in his answer on Can Amazon VMs be used as Active Directory domain controllers?:

There are all kinds of problems that you can have when you lose access to a domain controller, so any network interruption will have huge business consequences

Jesper Mortensen outlines detailed reasons not to put a DC in AWS in Running Windows domain on Amazon EC2 but this might be several years out of date at this stage

Finally, my question is: If these DCs were powered off for a whole weekend, would this cause problems with the other EC2 instances?

EDIT 1: I'm well aware this might be a difficult question to answer but I won't accept a 'why would you want to do this' or 'just don't do this' type answer. The question is pertaining to the specific problems this would cause, not whether or not it's a good idea

13
  • 4
    Just. Don't.Do.This. - Domain Controllers aren't meant to be turned off and on like a light switch. If you're approaching this from a cost standpoint then you should rethink your strategy. If leaving these EC2 based Domain Controllers on is cost prohibitive then you probably shouldn't be using EC2 based Domain Controllers.
    – joeqwerty
    Oct 6, 2015 at 15:50
  • 2
    Because nobody does that. It's not best practice and can only lead to less than reliable AD DS functionality and potential problems. Domain Controllers are meant to be on. If they need to be shut down for periodic maintenance then that's one thing, but nobody powers them down "for the weekend" as a part of SOP.
    – joeqwerty
    Oct 6, 2015 at 16:19
  • 6
    This is a weird idea. And you aren't even explaining the driver for it. If you showed up for a meeting and said everyone should wear three socks, would you expect everyone to 'just know' what you are talking about? What is the business value? Are you saving $3/day by turning off the domain controllers? Do you have a business goal to save .001% on your carbon footprint.
    – Greg Askew
    Oct 6, 2015 at 16:46
  • 3
    @ShaneC joeqwerty and Greg Askew are in the right here. Very frequently here we have people posting things like this, devoid of context, proposing that they do something that goes against all sane systems administration practices. In these cases, the correct answer is clearly: don't do that. If you provide context and information on why you're looking to do this, or information on what problem you're trying to solve, you'll get a much better answer.
    – EEAA
    Oct 6, 2015 at 16:56
  • 3
    Also, see What is the XY problem.
    – EEAA
    Oct 6, 2015 at 16:57

4 Answers 4

5

Rather than discuss whether or not this is a great idea, which you've already stated you don't want to do, let's instead discuss what you lose when you don't have access to a domain controller.

  1. AD Logins. Cached credentials would work, if the user had logged on before, but new domain logins would fail.
  2. Network shares. Your Kerberos ticket duration and enforcement are set by domain policy, but accessing network shares would begin to fail across your network. (The default is 10 hours for users and 600 minutes for services, or was when the article I just found was published.)
  3. DNS. Your desktops would still have connectivity, but they won't be able to resolve domains, inside or out.
  4. Any other service that uses AD credentials (VPN, Network Access Control, websites with integrated security, etc.).

If you turn off your DCs every night and over the weekend, I'd be afraid of clock drift as well. Clock drift can cause issues with AD logins (because Kerberos uses timestamps). I honestly don't know how much clock drift there would be because I've never tried it, but it would make me nervous. Especially since virtual machines have a reputation for drifting clocks anyway.

I'm also concerned that, well. Outside of business hours is the traditional time to do disruptive maintenance. I also don't know what kind of scheduled jobs you're running at your location, and what kind of credentials they use, but it's possible that you have tasks running that would disrupt user experience if run during the business day.

1
  • 1
    To add to point number 1: Any remote logins to domain members via RDP would fail. It's not possible to log on via RDP with cached credentials. The domain member needs to authenticate the user against AD in order to log the user on via RDP. Local/console logins would continue to work, so long as the user credentials have been previously cached on said domain members.
    – joeqwerty
    Oct 6, 2015 at 19:13
5

I understand that you're looking for specific reasons why this isn't a good idea, and as your own research has shown, Domain Controllers can be turned off for short periods of time with little or no risk, but my entire point is that this isn't something that anybody does as a normal practice and contradicts best practice. You're free to do anything you want with your infrastructure, but nobody I know would ever do this nor would they allow it to be done.

If you were shutting them down occasionally for maintenance or other purposes I wouldn't be worried about it, but if you're shutting them down every weekend then I'd be thinking about things like Group Policy synchronization issues, lingering objects, USN rollbacks, etc., etc. Not that those are likely to happen, but I sure would be thinking about those issues if this were the SOP.

2

This isn't really a designed use case for AD. There is a design assumption in Windows in general that domain controllers run constantly until they go away forever. Turning them off a lot for long periods of time will create replication errors, and maybe even tombstone problems if they come back after a long period of inactivity.

Tombstones are records which are flagged as deleted for a holding period to keep the directory consistent over replication.

For more of the various considerations introduced by disconnected domain controllers, check out the documentation: https://technet.microsoft.com/en-us/library/cc782557(v=ws.10).aspx

But, not only this. This plan won't save you any money, and will probably cost more! EC2 instance reservation gets you a very steep discount on instances on the assumption of 100% usage. The best discount comes from the all up-front option, where you pay in advance for the instance to be running constantly for the next 1 or 3 years. If the discount is more than 28%, as it often is, shutting them off two days a week won't save you any money.

Also, sometimes people do use the domain on the weekend and in the night.

Even more than this, best practice usually dictates using your domain controllers as DNS servers. Updates and background tasks tend to require this.

In any event, if you are using three micro instances for your DCs, your EC2 charges (for reserved instances) are likely somewhere in the neighbourhood of $300 a year. You might be able to cut this down by $100 or so by foregoing the reservations and running them only 8 hours a day. This savings is not even remotely worth the amount of extra work this will cause you.

Even one replication issue a year caused by this will wipe out the EC2 savings in extra labour.

0

Amazon's response to my question was very helpful, they understood the need to do this and outlined specific potential problems with this approach.

The main point they highlighted was that the only way this kind of setup could work is by ensuring that all the machines that rely on the EC2 DCs are switched off alongside them, which is exactly what we plan on doing.

Along with this, three other considerations should be taken into account

  1. If you have FSMO roles on this DC, turning the DC's off would not be the best practice
  2. These DC's would not be available for authentication for the time they are turned off and the instances or services will resume authentication when the DC's are resumed
  3. You would need to allow sufficient time to ensure they have enough time to complete replication after they come back up.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .