SSL Certificate and Sysprep

SSL connections will fail to an IIS server that has been sysprep'd. Windows sysprep will change the SIDs on all the existing accounts. This will effectively remove access to the private key for the IIS account i.e. Network Service. In order to restore it, you'll need to remove the certificate from IIS, delete the certificate from the certificate store, and import the certificate again.

Wireshark and Capturing Local Traffic

Wireshark cannot be used to capture local traffic because the packets never make it to the network interface. They are routed internally, inside of the TCP/IP stack. There are few workarounds listed in the link below.

 

Loopback capture setup

http://wiki.wireshark.org/CaptureSetup/Loopback

Security Assertion Markup Language (SAML) – Simple Assertion Example (v1.1)

For the detailed version, read the SAML assertion section of the SAML specification: http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf.

 

Below is a simple example of a SAML assertion (v1.1) that contains the following:

• Assertion – The container item.
• Conditions – Conditions that restrict or qualify the usage of the assertion.
• Attribute Statement – The identity and claim information.
• Signature – An XML digital signature that cryptographically identifies who issued the token as well as provides assertion integrity

The parts highlighted in yellow are particularly useful from a claims based identity model perspective.

• MajorVersion and MinorVersion – Identifies the version of SAML being used.
• NotBefore and NotOnOrAfter – Defines a lifetime for the token.
• Subject's NameIdentifier – The identity being represented.
• Subject's Confirmation Method – Used by applications for further confirmation of the subject. Bearer is used when possession of the token is sufficient for authentication purposes. Holder-of-key uses an advanced verification method that encrypts a secret key in the assertion. This key can be used as extra verification that the person sending the token can legitimately use it. For example, during a request to a Secure Token Service (STS), a user is authenticated, given a token, and also given (or negotiates) a proof of possession key. The user may then send a SOAP message to a web service, provide the token as authentication, and sign the message with the proof of possession key. The receiving service decrypts the holder-of-key (because it was encrypted only for the intended web service) and can validate the message signature was generated with the proof key.
• Attribute Name, Namespace, and Value – This is the representation of a claim in the SAML structure. The claim type is a combination of the Namespace and Name and the claim resource is the value. All attributes represent themselves as a right of PossessProperty.

 

<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_4311722f-8e78-4ae2-8fbe-e24b1b3b9675" Issuer="Issuing STS" IssueInstant="2009-03-05T16:57:06.013Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Conditions NotBefore="2009-03-05T16:52:05.419Z" NotOnOrAfter="2009-03-06T16:57:05.419Z"></saml:Conditions>

<saml:AttributeStatement>

<saml:Subject>

<saml:NameIdentifier>AccountName</saml:NameIdentifier>

<saml:SubjectConfirmation>

<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">

<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>

</e:EncryptionMethod>

<KeyInfo>

<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">gThFQ32F9Eu+Jv+0qvZEuBnjthM=</o:KeyIdentifier>

</o:SecurityTokenReference>

</KeyInfo>

<e:CipherData>

<e:CipherValue>q+72FhXYpZTYy50ACugWCth3cJ1/NyHUg0...</e:CipherValue>

</e:CipherData>

</e:EncryptedKey>

</KeyInfo>

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Attribute AttributeName="name" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">

<saml:AttributeValue>AccountName</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="lastActivityDate" AttributeNamespace="http://host.name.com/ws/2009/05/claims/token">

<saml:AttributeValue>2009-03-05T16:57:06.013Z</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>

<Reference URI="#_4311722f-8e78-4ae2-8fbe-e24b1b3b9675">

<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>

<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>

<DigestValue>fJDD/+Reo2gQOPQ+dKCfrSbPkhw=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>L2n4ZYUleQSqgHVFHU5IOF023Ilind...</SignatureValue>

<KeyInfo>

<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">gThFQ32F9Eu+Jv+0qvZEuBnjthM=</o:KeyIdentifier>

</o:SecurityTokenReference>

</KeyInfo>

</Signature>

</saml:Assertion>

.NET COM Interop and Binary Contract Compatibility

When manually creating COM interfaces and classes in .NET, it's critical that the declared order of the .NET operations matches the order in the COM interface. For example, the following IUniformResourceLocator .NET interface matches the layout of the actual COM interface.

using System.Runtime.InteropServices;

 

[

ComImport(),

InterfaceType(ComInterfaceType.InterfaceIsIUnknown),

Guid("CABB0DA0-DA57-11CF-9974-0020AFD79762")

]

public interface IUniformResourceLocator

{

void SetURL(

[In, MarshalAs(UnmanagedType.LPWStr)] string pszURL,

[In, MarshalAs(UnmanagedType.U4)] IURL_SETURL_FLAGS dwInFlags);

 

void GetURL(

[Out, MarshalAs(UnmanagedType.LPWStr)] out string pszURL);

 

void InvokeCommand(

[In] URLINVOKECOMMANDINFO pURLCommandInfo);

}

 

If the methods are declared in alphabetical order (which is what I mistakenly did), then a fairly generic, "Value does not fall within the expected range" error is thrown when calling SetURL.