I’ve done a couple of other posts on using AD credentials with AWS API. You setup AWS IAM to trust AD Federation Services (ADFS) for authentication. You get temporary access keys to use with the AWS API. This is safer than making lots of IAM accounts with long term passwords (Secret Access Keys) that end up embedded in code and stored who knows where. See previous posts for an overview of AD authentication to AWS.
Hey there Enterprise Administrator! Avoid storing AWS API keys by using Windows authentication instead[/caption] Are you an Enterprise investigating AWS? Don’t want to become a security news story like these guys? https://www.google.co.uk/search?q=news+aws+secret+access+key+hack Are you used to multiple levels of physical and logical security for access to your equipment? https://www.youtube.com/watch?v=_qc5TG2ulx8 Is access to your VPC config shielded by nothing but some AWS API credentials? (which are probably stored in plain text.
When you get started with Amazon Web Services (AWS) one thing to do early is secure access to the web console. Rather than manage another set of user accounts you can reuse your corporate directory (Microsoft Active Directory) to login to the AWS console. You use AD Federation Services to do this. Also, if you keep your ADFS server internal, then your AWS console is not accessible from the public Internet.
If you’re accessing intranet websites using Blackberries and other mobile platforms like Good for Enterprise you can get Kerberos working to provide single sign-on/passthough authentication. Staff can then browse intranet pages that are secured by Windows authentication, URL filtering or NTFS without having to type in their (probably complex) Windows password on a teeny tiny phone keypad. I use the Active Server Page (ASP) below on IIS to test if Kerberos is working.