Security

Creating a Self-Signed Code Signing Certificate for AD FS Signing and Decrypting

Some times we don’t want to use automatic rollover for the certificates in AD FS, simply because we want even more granular control on what’s going on. To solve this we can either buy an public signed certificate from an CA we trust, or we can create a self-signed certificate our self using makecert.exe. Note that I would recommend a publically signed certificate for production use, but if you’re not as paranoid as me, self-signed works just as fine. A tool we can use for certificate creation in the Microsoft world, is makecert.exe. makecert.exe is a part of the Windows SDK. It’s also included when you install Visual Studio. The path for Makecert should be something like this on our computer

  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x64\
  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x86\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x64\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x86\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\x64\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\

The syntax for makecert is as follow

makecert [options] outputCertificateFile

To make a certificate that can be used with AD FS signing, our command should be like this (All in one line)

makecert -r -pe -n “CN=MySigningCert” -b 12/28/2014 -e 01/01/2020 -eku 1.3.6.1.5.5.7.3.3 -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 “MySigningCert.cer” -len 2048

This should be successful. We can now export the key form our computer, and use it in the AD FS service.

The options we use in the example above

We used the following options in our script. Most of this table is copied from the official documentation.

-r Creates a self-signed certificate.
-pe Marks the generated private key as exportable. This allows the private key to be included in the certificate.
-n Specifies the subject’s certificate name. This name must conform to the X.500 standard. The simplest method is to specify the name in double quotes, preceded by CN=; for example, -n “CN=myName”.
-b Specifies the start of the validity period. Defaults to the current date.
-e Specifies the end of the validity period. Defaults to 12/31/2039 11:59:59 GMT.
-eku Inserts a list of comma-separated, enhanced key usage object identifiers (OIDs) into the certificate. The following MSDN document contains a list of supported OIDs http://msdn.microsoft.com/en-us/library/windows/desktop/aa378132(v=vs.85).aspx
-ss Specifies the subject’s certificate store name that stores the output certificate.
-sr Specifies the subject’s certificate store location. location can be either currentuser (the default) or localmachine.
-sky Specifies the subject’s key type, which must be one of the following: signature (which indicates that the key is used for a digital signature), exchange (which indicates that the key is used for key encryption and key exchange), or an integer that represents a provider type. By default, you can pass 1 for an exchange key or 2 for a signature key.
-sp Specifies the subject’s CryptoAPI provider name, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider. If both -sp and -sy are present, the type of the CryptoAPI provider must correspond to the Type value of the provider’s subkey.
-sy Specifies the subject’s CryptoAPI provider type, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types. If both -sy and -sp are present, the name of the CryptoAPI provider must correspond to the Name value of the provider type subkey.
-len Specifies the generated key length, in bits.

List of some possible Providers and Provider Types

The following list is based on the available Providers at my dev machine.

Provider Name Provider Type
Microsoft Base Cryptographic Provider v1.0 1
Microsoft Enhanced Cryptographic Provider v1.0 1
Microsoft Base Smart Card Crypto Provider 1
Microsoft Strong Cryptographic Provider 1
Microsoft Base DSS Cryptographic Provider 3
Microsoft RSA SChannel Cryptographic Provider 12
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft DH SChannel Cryptographic Provider 18
Microsoft Enhanced RSA and AES Cryptographic Provider 24

Documentation

Network Security Groups in Azure

Network Security Groups (NSG) is one of the new network features that’s available in Azure. At least as long we are using the data center in North Europe (https://azure.microsoft.com/en-us/updates/new-networking-features-now-available-in-the-north-europe-region/). By leveraging NSGs we are able to control inbound and outbound network traffic all the way down to each separate VM. This is great in those cases where we have to implement high security and hard policies on our services. For example between the public facing endpoints and backend servers in a SharePoint deployment.

Concept drawing of Network Security Groups

To use it, we need version 0.8.10 of the Azure PowerShell module, and the commands are

  • Get-AzureNetworkSecurityGroup
  • Get-AzureNetworkSecurityGroupConfig
  • Get-AzureNetworkSecurityGroupForSubnet
  • New-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroupConfig
  • Remove-AzureNetworkSecurityGroupFromSubnet
  • Remove-AzureNetworkSecurityRule
  • Set-AzureNetworkSecurityGroupConfig
  • Set-AzureNetworkSecurityGroupToSubnet
  • Set-AzureNetworkSecurityRule

 

The function is somehow self explained and the link at the bottom of this post explains it even a little bit more. But the best way to get to know them is to use Get-Help, and then just try 🙂

Documentation

If you ever forget the password for an PFX file

Had a case yesterday where we needed the password for a Certificate PFX file.

Luckily we found this tool, and after a short time using brute force we got the password: http://crackpkcs12.sourceforge.net/

If you have a netbook or a small laptop, why not spin this up in Azure using a Linux machine?
http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/

Anyhow, it works, and the service is back on line 🙂

Permissions in Office 365

Just a quick post this Saturday evening.

I see in multiple forums that the permission model in Office 365 is both a unknown territory and slightly scary one. So I want to post a link to a great article over at Microsoft Office Support, explaining the model thoroughly.

It’s great evening reading, so dive in

http://office.microsoft.com/en-us/help/permissions-in-office-365-HA104043996.aspx