In a recent engagement, there was a need to build an Amazon Web Services (AWS) hosted, Microsoft .NET application, using Active Directory for authentication and AutoScale to provide scale out capacity. AutoScale, for those of you who don’t know what it is, is a mechanism that automatically deploys or destroys EC2 instances to ensure you have the appropriate capacity available for your deployed application. It can undertake this task based on a number of policies (CPU load, network load, scheduled time etc.), with integration into other AWS services like ELB and CloudWatch.
Back on topic, most web applications tend to be multi-tier but rely on internal authentication mechanisms such as usernames/hashed passwords within databases. Think of your typical forum, the users and passwords are stored in a database and are referenced when users login. This is typically the case where you’re dealing with publicly facing stand-alone open source web applications based on PHP, Ruby On Rails or the like. It’s not uncommon to see .NET applications deployed in this manner either, connecting to an SQL back-end using SQL authentication, as opposed to AD authentication. In this instance though, the application utilised Active Directory for certain aspects of its functionality and as such this necessitated the server to be joined to the Active Directory domain prior to it serving out requests. Given that AutoScale simply clones machines and starts them up, this meant that there would be some problems with Active Directory. For the more experienced amongst us, the answer to fixing this is pretty obvious – sysprep.
Sysprep has 2 ways to join machines to a domain:
- Secure Join – Through the use of putting in credentials in the sysprep answer file, the machine will automatically join domain
- Unsecure Join – A little more advanced, it uses a shared computer password to join the domain and does not require plain text credentials in a file