Index syndication
comment syndication

Launch Windows Server 2016 Nano in AWS with Powershell

Amazon Web Services yesterday announced they now have Amazon Machine images available for Windows Server 2016. This includes Nano Server, a perfect solution for a roll your own IaaS server to host your .NET Core APIs.

Windows Server 2016 Nano Server -A cloud-native, minimal install that takes up a modest amount of disk space and boots more swiftly than the Datacenter version, while leaving more system resources (memory, storage, and CPU) available to run apps and services.

One of the interesting things about Nano for existing Windows server users, is you can only access it via PowerShell/WinRM for managment of the server. You can quickly spin up a new instance of nano in your PowerShell console (already configured for AWS):

Once the instance has started up, you can get the Admin credentials using your EC2 Key, and establish a remote PowerShell session:

This leaves you with an established PowerShell session to the remote server, which can be shown as follows:

C:\> $session
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
2 Session2 172.19.1.67 RemoteMachine Opened Microsoft.PowerShell Available

 

You are now able to invoke remote commands on your Nano server:

C:\> Invoke-Command -Session $session -ScriptBlock { Get-Process | Select ProcessName, Id |ft }
ProcessName Id
----------- --
amazon-ssm-agent 1792
csrss 496
EMT 1088
Idle 0
LiteAgent 828
lsass 556
services 544
smss 360
svchost 648
svchost 692
svchost 768
System 4
wininit 520
WmiPrvSE 1236
wsmprovhost 1468

 

If you just want to jump onto the remote server, you can Enter the Session:

C:\> Enter-PSSession -Session $session
[172.19.1.67]: PS C:\Users\Administrator\Documents> $StartTime = (Get-Date) - (New-TimeSpan -Day 1)
[172.19.1.67]: PS C:\Users\Administrator\Documents> Get-WinEvent -FilterHashTable @{LogName='System'; Level=2; StartTime=$StartTime}
| select TimeCreated, Message
TimeCreated Message
----------- -------
10/21/2016 2:36:36 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/21/2016 2:36:15 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:18:55 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:18:48 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 4:14:42 AM Task Scheduler service failed to start Task Compatibility module. Tasks m...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 4:14:11 AM The Virtualization Based Security enablement policy check at phase 0 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 6 fail...
10/20/2016 11:12:05 AM The Virtualization Based Security enablement policy check at phase 0 fail...

[172.19.1.67]: PS C:\Users\Administrator\Documents> Exit-PSSession

 

Don’t forget once you are finished to remove the session:
Remove-PSSession -Session $session
 

Given that this instance has no local console, you will have to maintain and access it fully using PowerShell. Time to skill up on your PowerShell skills. If you would like to read more on remotely managing the instance, Microsoft have documented how to manage Nano Server. It’s a good next step to read.

ADFS2 is not always SAML 2.0 standards compliant

Now the madness with ADFS2 SAML assertions via WS-Trust 1.3 – and how they are not valid for use with Amazon Web Services (AWS).

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Responses must contain SubjectConfirmatonData with a Recipient and NotOnOrAfter

This failed due to a missing Recipient attribute on the SubjectConfirmationData element. Of course; I can’t modify the assertion to add the missing Recipient; as the SAML token is signed:

lexx:saml$ aws sts assume-role-with-saml --role-arn $role --principal-arn $principal --saml-assertion $assertion
A client error (InvalidIdentityToken) occurred when calling the AssumeRoleWithSAML operation: Response signature invalid

Second fail is because I’ve modified the assertion to add the missing attribute; but now the signature is invalid.

When you get an assertion from the ADFS Identity Provider via the IdP Web Landing Page, for AWS, the assertion includes a “recipient”:

<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
  <subjectconfirmationdata NotOnOrAfter="2015-02-08T22:48:18.520Z" Recipient="https://signin.aws.amazon.com/saml"></subjectconfirmationdata>
</subjectconfirmation>

When you ask for an assertion from the WS-Trust 1.3 endpoint; it is missing:

<subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
  <subjectconfirmationdata NotOnOrAfter="2015-02-09T05:03:10.517Z"></subjectconfirmationdata>
</subjectconfirmation>

Seems to be a common problem with ADFS2 whereby ADFS1 did it correctly. It’s not just me

In the original SAML 2.0 Core spec – Line 725 – Recipient is an optional attribute in the SubjectConfirmationData element. However in subsequent errata for the specification, Errata 02 in May 2007, made it mandatory. Errata 05 still includes this requirement.

At lease one bearer element MUST contain a element that itself MUST contain a Recipient attribute containing the service provider’s assertion consumer service URL

Of course; Amazon adhere to the Standard:

The value of the Recipient attribute inside the SubjectConfirmationData element must match the AWS endpoint (https://signin.aws.amazon.com/saml)

It seems that ADFS2 doesn’t provide valid SAML 2.0 assertions issued via the WS-Trust 1.3 endpoint. Since this has been a standard since for almost 8 years, how does ADFS2 even claim to be standards based.

SAML assertion from ADFS2 via SOAP endpoint

According to Wikipedia, Microsoft Active Directory Federation Services (ADFS) is:

… a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and implement federated identity.

ADFS can provide Single sign as an identity provider to users, but what if a developer needs the same sign on outside of “browser land”? One option is to scrape webpage responses, but a better option is receiving a SAML Assertion using SOAP endpoints exposed via Microsoft ADFS, as long as they are enabled. You can use SOAP 1.2 with WS-A Addressing and mixed message security with the username/password in the SOAP headers secured over HTTPS, and get a valid SAML assertion.

There is Mex Endpoint (Anonymous by default) provided by ADFS2 or greater (if not disabled) at
https://youradfsserver.com.au/adfs/services/trust/mex
If you want to play with SOAP based claim requests, use a tool like SoapUI and consume the Mex endpoint as the WSDL. You can then construct Soap messages, and see if you get a valid response – which would contain an assertion.

The SOAP Endpoint for requesting a SAML token using WS-Trust 1.3 and mixed security would be
https://youradfsserver.com.au/adfs/services/trust/13/usernamemixed

The client credentials are included in the header of a SOAP message. Confidentiality is preserved at the transport layer (SSL/TLS); hence a usernamemixed endpoint.

Here is an example SOAP request for usernamemixed:

You can also use curl to post the soap request as shown:

Given all that; this actually won’t work for AWS; given ADFS2 actually breaks the SAML2.0 standards updated in 2012. Next post will detail this.

Powershell: AWS and IAM policy retrieval

I’ve recently been working more day to day on Amazon Web Services, and I found it a little unwieldy to navigate around policy documents assigned to IAM groups.

Sometimes you just want to have a local copy of the policies to edit/play with/look at.

Therefore, I came up with a quick script to solve this. Enjoy…
Of course, the AWS SDK for Powershell is required.