Typical End User…

 

Animation by Lisa Larson-Walker. Images by Den Rise/Shutterstock, courtesy of Rosa Menkman/Flickr Creative Commons.

A simple under the covers description of NTLM/Kerberos

I did not write this, but I liked it. All credit to Summit7.

NTLM

NTLM is a Windows challenge/response authentication protocol that leverages the interactive use of a login box that requires the end user to input their network credentials manually. Those credentials would include the users Username, password and domain name if logging into an organizations domain.

Plain English: end users log in by entering a username, password and domain into a login box. That being said we need to understand at least the basics of the process.

1. NTLM authenticates end users by first creating an encrypted one-way hash of the users password, discarding the original password and then sending the user name to the server in plain text.
2. The server responds to the client with a 16-bit challenge called a nonce.
3. The client encrypts the nonce and the hash of the users password and returns them to the server. This is the Response.
4. The server in turn sends three items to the domain controller; the users name, the challenge sent to the client and the clients response to the challenge. The domain controller retrieves the hash of the user name is has received from the Security Account Manager (SAM) database and uses that hash to encrypt the challenge.
5. Once the challenge has been encrypted by the domain controller it is compared to the challenge encrypted by the client and if they match the end user is authenticated successfully.

Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.

Kerberos

The Kerberos security protocol has been a part of Windows since Windows Server 2000 and was intended as a replacement for NTLM. Obviously that hasn’t happened and the two can often be found working together or in a mixture across Windows environments everywhere.

Kerberos is a Windows Security Protocol designed to authenticate users and services on an organisations network and relies on three components; a client, a service and a trusted third party. The trusted third party in most Windows networks would likely be the Key Distribution Center (KDC) which creates the shared secret that is leveraged to allow access to the service. A simple view of the process might look like this:

1. A user account is created in the domain and assigned a password.
2. The Kerberos client adds a text string, or a SALT and the Kerberos version number to the unencrypted password and runs them through a process known as the “string2key” This conversion generates the “shared secret”.
3. At the client the user enters their username and password and requests access to an application or service.
4. When the user submits their username and password the Kerberos client creates the secret key on the client based on that information. Because the client uses the same key to generate the secret key that the KDC does the two will match, or should anyway. If they don’t match authentication fails and access id denied.

Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.

Thanks to Summit7 for this – full link –> http://summit7systems.com/claims-based-authentication-adfs-3-0-and-sharepoint-2013-beginners-guide/

Setup a secure point-to-site connection to a virtual network in Azure

Configure the network and gateway

Log in to the Azure portal (http://manage.windowsazure.com/). Create a new Virtual Network. Click Custom Create. On the DNS Servers and VPN Connectivity page, then click on: 

• Configure Point-To-Site VPN: Select the checkbox.
• On the Point-To-Site Connectivity page, specify the IP address range from which your VPN clients will receive an IP address when connected. Don't overlap with an on-premise address.

Update the IP range for the Azure subnet

When your virtual network has been created, you will see Created listed under Status on the networks page in the Azure portal. Once your virtual network has been created, you can create your dynamic routing gateway.

 

The gateway type must be configured as dynamic. Static routing gateways will not work with this feature.

1. In the portal, on the Networks page, click the virtual network that you just created, and navigate to the Dashboard page.
2. Create Gateway. It can take around 15 minutes for the gateway to create.

 

Generate and upload certificates

Previously, you were required to generate your own self-signed certificate. Now, you can now use certificates that you generated using an enterprise solution. You can upload up to 20 root certificates to Azure.

Option 1: Planning to use an enterprise certificate solution, the steps within each section will be different, but you'll still need to do the following:

• Identify or generate a root certificate.
• Upload the root certificate .cer file to Azure.
• Generate a client certificate.
• Export and install the client certificate.

Option 2: Planning to use a self-signed certificate, use the steps:

• One way to create an X.509 certificate is by using the Certificate Creation Tool (makecert.exe). To use makecert, download and install Microsoft Visual Studio Express, which is free of charge.
• Navigate to the Visual Studio Tools folder and start the command prompt as Administrator.
• The command in the following example will create and install a root certificate in the Personal certificate store on your computer and also create a corresponding .cer file that you'll later upload to the Azure portal.
• Change to the directory that you want the .cer file to be located in and run the following command, where RootCertificateName is the name that you want to use for the certificate. If you run the following example with no changes, the result will be a root certificate and the corresponding file RootCertificateName.cer.

Because you have created a root certificate from which client certificates will be generated, you may want to export this certificate along with its private key and save it to a safe location where it may be recovered.

• Download Visual Studio 2013 Express and makecert is included. http://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx

C:\Program Files (x86)\Windows Kits\8.1\bin\x64>makecert -sky exchange -r -n "CN=NewRootCertName" -pe -a sha256 -len 4096 -ss My "NewRootCertFile.cer"

• NewRootCertName refers to the self-signed root certificate that you generated.

Upload the root certificate .cer file to the Azure portal

1. In the Azure portal, on the Certificates page for your virtual network, click Upload a root certificate.

Generate a client certificate

The steps below are for generating a client certificate. On the same computer that you used to create the self-signed root certificate, open a Visual Studio command prompt window as administrator.

1. Change the directory to the location where you want to save the client certificate file. RootCertificateName refers to the self-signed root certificate that you generated. If you run the following example (changing the RootCertificateName to the name of your root certificate), the result will be a client certificate named "ClientCertificateName" in your Personal certificate store.

C:\Program Files (x86)\Windows Kits\8.1\bin\x64>makecert.exe -n "CN=NewClientCertificateName" -pe -sky exchange -m 96 -ss My -in "NewRootCertName" -is my -a sha256



2. All certificates are stored in your Personal certificate store on your computer. If you want to reuse it export it

Installing a client certificate on each computer that you want to connect to the virtual network is a mandatory step.

The steps below will walk you through installing the client certificate manually.

1. A client certificate must be installed on each computer that you want to connect to the virtual network. This means you will probably create multiple client certificates and then need to export them. To export the client certificates, use certmgr.msc. Right-click the client certificate that you want to export, click all tasks, and then click export.
2. Export the client certificate with the private key. This will be a .pfx file. Make sure to record or remember the password (key) that you set for this certificate.
3. Copy the .pfx file to the client computer. On the client computer, double-click the .pfx file in order to install it. Enter the password when requested. Do not modify the installation location.

Configure your VPN client

The client requires both a client certificate and the proper VPN client configuration in order to connect.

Create the VPN client configuration package

1. In the Azure portal, on the Dashboard page for your virtual network, navigate to the quick glance menu in the right corner and click the VPN package that pertains to the client that you want to connect to your virtual network.

2. After you generate and download the VPN client package from the Azure portal, you can install the client package on the client computer from which you want to connect to your virtual network.

3. If you plan to install the VPN client package to multiple client computers, make sure that they each also have a client certificate installed. The VPN client package contains configuration information to configure the VPN client software built into Windows. The package does not install additional software.

Install the VPN configuration package on the client and start the connection. Done.

 

 

This information is a simplification of the article https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-point-to-site-create/#create-your-certificates