Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 2 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page	Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.
Part 2 – Using Cloud or on Premises MFA	What changes happen in the claims and how to control where MFA takes place.
Part 3 – User Certificates	Enabling enrollment and usage of user certificates for ADFS.
Part 4 – Expired Passwords	How to detect and address users with expired passwords.

Part 2 – Using Cloud or on Premises MFA:

As documented here: https://msdn.microsoft.com/en-us/library/azure/dn394284.aspx, you can use either Azure Multi-Factor Server (on Premises) or Azure Multi-Factor Authentication (cloud based) to perform Multi-Factor for Federated (ADFS) users. Azure will honor both, as long as the “multi-factor” claim is passed from ADFS to Azure when using Azure Multi-Factor Server.

While it is not the purpose of this blog to discuss installation, it is the purpose to discuss logic and claims needed.

Two items we need to discuss before we understand the logic:

PowerShell: Set-MsolDomainFederationSettings with the –SupportsMFA parameter
Claim: Authentication Method References (http://schemas.microsoft.com/claims/authnmethodsreferences)

Domain Federation Setting:

Each Federated Domain can be configured to support MFA at the Claims Provider (ADFS Server). To change this setting, simply run the Set-MsolDomainFederationSettings to toggle the setting between true and false. More information here: https://msdn.microsoft.com/en-us/library/azure/dn194088.aspx. If the setting is True, and Azure (through configuration) required Multi-Factor, Azure will redirect to the Claims Provider (ADFS) setting the query string: wauth=http%3a%2f%2fschemas.microsoft.com%2fclaims%2fmultipleauthn and expecting the return claim http://schemas.microsoft.com/claims/authnmethodsreferences set to the value of http://schemas.microsoft.com/claims/multipleauthn.

Authentication Method Claim:

As discussed above, if leveraging Azure Multi-Factor Server integrated with your ADFS server, the claim http://schemas.microsoft.com/claims/authnmethodsreferences should be set to the value of http://schemas.microsoft.com/claims/multipleauthn to indicate that MFA has been performed. This claim is not enabled by default on your ADFS server to be sent to Azure, called “Microsoft Office 365 Identity Platform”.

If the claim is not “issued” on the ADFS server, Azure and ADFS will just loop until ADFS throws a loop detection error (Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie) as shown below. Notice the “wauth=http%3a%2f%2fschemas.microsoft.com%2fclaims%2fmultipleauthn” meaning Azure asked ADFS to perform MFA. This error can also occur if there are no MFA providers configured in ADFS.

You will get event log error: 365 with the description: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made ….

To resolve this, enable the claim http://schemas.microsoft.com/claims/authnmethodsreferences on your Azure Relying Party (discussed next).

Enabling the Authentication Method References in ADFS:

To enable the claim to be sent from ADFS to Azure, follow these steps:

Open the AD FS Management console on your ADFS Server.
Select AD FSà Trust Relationshipsà Relying Party Trust
Right click on “Microsoft Office 365 Identity Platform” or whatever you have named the Azure Relying Party and select Edit Claim Rules
Click Add Rule on the Issuance Transform Rules tab
Select the rule template Pass Through or Filter an Incoming Claim and click next
In the incoming claim type, select Authentication Methods References and leave Pass through all claim values selected and click Finish
Click OK to save the Claims Rules

Now any Azure service that requires Multi-Factor will honor the http://schemas.microsoft.com/claims/authnmethodsreferences claim.

How to use both Azure Multi-Factor Server and Azure Multi-Factor Authentication

In some cases, you may want to use Multi-Factor Server for some users and Multi-Factor Authentication for others.

If you want to support both Multi-Factor Server and Multi-Factor Authentication for a single Federated domain, follow these steps:

Use the “Set-MsolDomainFederationSettings” command and set the –SupportMFA to $false
Enable a MFA provider in ADFS
Enforce the MFA requirement on the desired users in ADFS

4. Enable the Authentication Methods References claim in ADFS

Following this method, any user who authenticates through ADFS will be MFA challenged at ADFS initial login time. Azure will honor the Authentication Methods References claim set by ADFS for these users. If a user does not have the claim Authentication Methods References set to http://schemas.microsoft.com/claims/multipleauthn via ADFS, Multi-Factor Authentication will perform a cloud based Multi-Factor authentication.

Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 3 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page	Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.
Part 2 – Using Cloud or on Premises MFA	What changes happen in the claims and how to control where MFA takes place.
Part 3 – User Certificates	Enabling enrollment and usage of user certificates for ADFS.
Part 4 – Expired Passwords	How to detect and address users with expired passwords.

Part 3 – User Certificates

Often overlooked but very effective are User Certificates. These certificates are a legitimate form of multi factor by meeting the something you have (certificates) factor.

ADFS has long supported User Certificates and Windows Server has long supported a Certificate Enrollment Website. Combining these two capabilities, we can user certificates as a single or multi factor login method.

To get started, we need to (1) allow the user to request (enroll) for a certificates and (2) allow the user the ability to authenticate with a certificate.

Allow the user to request a certificate

While it is not the purpose of this document to explain certificates services and PKI, we will assume there is an existing Certificate Services exist and that we have installed the certificate enrollment website.

Security WARNING: Most people view certificates as a highly secure capability, as it does not have an expiring password and often are long lived expiration dates. To enable a user to enroll, I strongly suggest you require multi factor, such as a Phone to verify authenticity of the user. To meet these requirements, our setup will require MFA before the user can request a certificate, which is another form of MFA. Also, our demonstration does not have a certificate approver, yet this could be a security control for your solution.

The default Certificate Enrollment Website look like this, enabling a user to request a user cert.

To securely publish the Certificate Server with Windows Server 2012 R2 Web Application Proxy and Windows Server 2012 R2 ADFS, follow these steps:

Identity the Server with the Certificate Services Web Enrollment Role enabled. My server is named: multifactor.kevinsay.scd365.net, which by default required Windows authentication.
Open the AD FS Management Console on the ADFS Server
Click AD FSà Trust Relationshipsà Relying Party Trust and select Add Non-Claims Aware Relying Party Trust
Specify a Display name, like Certificate WebSite and click next
Specify the Identifier as https://<servername>/certsrv. My identifier is https://multifactor.kevinsay.scd365.net/certsrv/ and click add and next
Select Configure multi-factor authentication settings for this relying party trust and click next
Under Locations select Extranet and click next, next and close
If promoted to edit the claim rules, simply ok this dialog box
If using a different host name for the Certificate Web Server, you will need to run the command “setspn” to register the unique SPN (used by Kerberos) else Web Application Proxy will not be able to find the server.
Use Active Directory Users and Computers to modify the Kerberos Constrained Delegation of the Web Application Proxy to include the SPN of the Certificate Services Web Enrollment Server, as illustrated below:

Open the Remote Access Management Console on the Web Application Proxy Server and select Publish
Select ADFS as the Preauthentication method
Select the name of the Certificate WebSite, as defined in step 4 and click next
Type a name, external URL, select a cert that matches the external name, a backend url and the SPN as shown below:

Click next and publish

If followed correctly and the pre requisites (including DNS) are setup, you should be able to access the External URL and once prompted for ADFS authentication and Multi-Factor authentication, you can request user certificates.

Allow the user to authenticate with a certificate

To enable users to authenticate with certificates as a single or Multi-Factor authentication, follow these steps:

Open the AD FS Management Console on the ADFS Server
Select AD FSà Authentication Policies and click Edit Global Primary Authentication
If you want to enable Certificates as a single Factor authentication for extranet users, under Extranet click Certificate Authentication
If you want to enable Certificates as a Multi-Factor authentication, click the Multi-Factor Tab and click Certificate Authentication and any other MFA method you have installed. Also determine when MFA is required (users/groups, location and devices) as shown below:

Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 4 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page	Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.
Part 2 – Using Cloud or on Premises MFA	What changes happen in the claims and how to control where MFA takes place.
Part 3 – User Certificates	Enabling enrollment and usage of user certificates for ADFS.
Part 4 – Expired passwords and locked out accounts	How to detect and address users with expired passwords or locked out accounts.

Part 4 – Expired passwords and locked out accounts

Expired Passwords are a part of life. For corporate users, they often log in using Windows, and Windows will give them (by default) a 14 day warning. ADFS, because it is exposed to the hostile internet, is not so friendly by default.

Windows Server 2012 R2 ADFS addresses passwords that expired, as show below:

ADFS, for security reasons, does not address account lockout, as shown below:

Because this error message above can be for many reasons or could be a brute force attack, addressing this error can vary based on company policy.

If you want to enable the end user to reset their password using Azure Active Directory Premium’s Reset Password (https://passwordreset.microsoftonline.com) we can notify or automatically redirect the user to the reset site.

Using JavaScript, we can detect the “errorText” is not null and take action.

My example below ask the user if they need help resetting their password and will redirect them to the Reset Password Site. You can modify as you see fit.

The HTML I used to set this up is included below:

{ if(document.getElementById("errorText").innerHTML != "")

{ if (confirm("Would you like to reset your password?") == true)

{ location.href='https://passwordreset.microsoftonline.com/?whr=kevinsay.scd365.net'; }

};

window.onload=resetPassword;

</script>

The PowerShell command to configure this is:

Set-AdfsGlobalWebContent -SignInPageDescriptionText "<script>function resetPassword() { if(document.getElementById(""errorText"").innerHTML != """") { if (confirm(""Would you like to reset your password?"") == true) { location.href='https://passwordreset.microsoftonline.com/?whr=kevinsay.scd365.net'; } }; }; window.onload=resetPassword; </script>"

Importing Azure AD information into your SIEM solution:

Written by Kevin Saye

SIEM = Security Incident and Event Management

Overview:

When leveraging cloud solutions, security organizations are concerned about losing visibility to security and events.

With “Azure Active Directory Reporting API”, discussed here: http://azure.microsoft.com/en-us/documentation/articles/active-directory-reporting-api-getting-started/, organizations can have full, API level access to SIEM level events.

This blog illustrates how to integrate your existing SIEM solution with Azure Active Directory Reporting API by exporting events to text/json/xml files.

Delegating Access in Azure AD:

In order to authenticate to the Reporting API, we must use the OAuth flow, which requires us to register an application with Azure AD.

Create an application

Navigate to the Azure Management Portal
Navigate into your directory
Navigate into applications
On the bottom bar, click "Add". ◦Click "Add an application my organization is developing".
- Name: Any name is fine. Something like "Reporting API Application" is recommended.
- Type: Select "Web application and/or Web API"
- Click the arrow to move to the next page
- Sign-on URL: http://localhost
- App ID URI: http://localhost
- Click the checkmark to finish adding the application.

Give your application permission to use the API

Navigate to the Applications tab.
Navigate to your newly created application.
Navigate to the Configure tab.
In the "Permissions to Other Applications" section: ◦Add Windows Azure Active Directory > Application Permissions > enable "Read directory data"
- Add Windows Azure Service Management API > Delegated Permissions > enable "Access Azure Service Management"
Click "Save" on the bottom bar.

Get your directory ID, client ID, and client secret

Find your application's client ID and client secret. You will also need to know your tenant name, it can be either your *.onmicrosoft.com or a custom domain name. Copy these into a separate place; you'll use them to modify the script.

Application Client ID

Navigate to the Applications tab.
Navigate to your newly created application.
Navigate to the Configure tab.
Your application's client ID is listed on the Client ID field.

Application Client Secret

Navigate to the Applications tab.
Navigate to your newly created application.
Navigate to the Configure tab.
Generate a new secret key for your application by selecting a duration in the "Keys" section.
The key will be displayed upon saving. Make sure to copy it, because there is no way to retrieve it later.

Modifying the Script:

The PowerShell script is illustrated below. Replace $ClientID, $ClientSecret and $tenantdomain with the correct values from “Delegating Access in Azure AD”.

<Code>

# This script will require the Web Application and permissions setup in Azure Active Directory

$ClientID = "<< Your Client ID Here>>" # Should be a ~35 character string insert your info here

$ClientSecret = "<< Your Client Secret Here >>" # Should be a ~44 character string insert your info here

$loginURL = "https://login.windows.net"

$tenantdomain = "<< Your Tenant Domain Here>>"

# Get an Oauth 2 access token based on client id, secret and tenant domain

$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}

$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body

if ($oauth.access_token -ne $null) {

$headerParams = @{'x-ms-version'='2013-08-01';'Authorization'="$($oauth.token_type) $($oauth.access_token)"}

# Returns a XML document containing all the reports, not used, but for reference

#$allReports = (Invoke-WebRequest -Headers $headerParams -Uri "https://graph.windows.net/$DirectoryID/reports/`$metadata")

#$allReports.Content | Out-File AllReports.xml

# Returns a JSON document for the "accountProvisioningEvents" report

$myReport = (Invoke-WebRequest -Headers $headerParams -Uri "https://graph.windows.net/$tenantdomain/reports/accountProvisioningEvents?api-version=beta")

Write-host $myReport.Content

# to output the JSON use following line

$myReport.Content | Out-File -FilePath accountProvisioningEvents.json -Force

# to output the content to a name value list

($myReport.Content | ConvertFrom-Json).value | Out-File -FilePath accountProvisioningEvents.txt -Force

# to output the content in XML use the following line

(($myReport.Content | ConvertFrom-Json).value | ConvertTo-Xml).InnerXml | Out-File -FilePath accountProvisioningEvents.xml -Force

} else {

Write-Host "ERROR: No Access Token"

}

</Code>

Executing the Script:

Comment out the file formats you do not want and schedule the code to run as needed. Once the files are created, configure your SIEM solution to include these files.

How to publish an internal web application using Microsoft Azure

In this blog post, I will detailed the steps on how to publish an internal web application using Microsoft Azure. I will publish an internal Self Service Portal for MBAM (Microsoft BitLocker Administration and Management). This Portal is used to generate BitLocker Recovery Key if you are locked out of Windows by BitLocker.

Step 1: Enable Application Proxy on your directory

Select your Directory, then select Configure. Scroll down and click on Enabled

Step 2: Establish connectivity with the network

From your internal server, select Download and install the Application Proxy Connector on your network. Select Download now.

Run the install and follow the wizard. I installed Application Proxy Connector on my MBAM Web Server, but it is not required to be installed on the same server. Once the install completes successfully, you are ready to Add an Application.

Step 3: Add an Application

Login to Microsoft Azure - https://manage.windowsazure.com. Select your Directory (mine is called Oakbourne Enterprises), then click on Applications button at the top of the page.

Select Add at the bottom of the Application page. Select Publish an application that will be accessible from outside your network.

Name: MBAM Self Service Portal

Internal URL: http://mbam.contoso.org/selfservice

Preauthentication Method: Azure Active Directory

Step 5: Assign Users

From your list of Applications, select your application, then click on Users and Groups. Select appropriate Users and/or Groups for the application to show up in the user's application list.

Note: This only affects application visibility.

Step 6: Configure Application SPN

Note: The Application Proxy and Web Site are on the same server - MBAM.contoso.org

Select Configure at the top of the page, scroll down near the bottom of the page and enter Internal Application SPN: http/mbam.contoso.org (it is not a typo that I used http/servername).

If a HTTP SPN is not already configured for server, it will have to be set using SETSPN command. To check and set if necessary, follow these commands from your webserver:

This will list all registered SPN for this server. SETSPN -L (enter server name) - example: setspn -l mbam

You should see a line containing HOST/MBAM.contoso.org - If not, proceed to Add a SPN.

If a HTTP SPN is not set, follow this command to create one:

SETSPN -S HTTP/ServerName Servername - example: setspn -s http/mbam mbam

Step 7: Configure Server Delegation

Launch Active Directory Users and Computers - find your Server, open Properties and select Delegation tab. Select Trust this computer for delegation to specified services only. Then select Use any authentication protocol, finally click Add button. Select your server, choose httpmbam.contoso.org.

Finally, logon to Azure AD Portal to launch your Application - https://myapps.microsoft.com. Click on MBAM Self Service icon to launch.

Note the differences between the URLs

External Azure: https://mbamselfserviceportal-oakbourne.msappproxy.net/selfservice

Internal Network: http://mbam.contoso.org/selfservice

Azure Storage Tables: Backing up your tables!

Written by Kevin Saye:

This blog shows how, using PHP, we can backup Azure Storage Tables to another storage account and a different table.

While there are solutions out there (http://tablestoragebackup.codeplex.com/) that can help with backing up Azure Tables, why not just copy the contents to another Storage Table? Because Azure Storage is inexpensive, compared to disk storage and bandwidth, this makes perfect sense.

Sadly, there is not a PowerShell command to clone Azure Tables, like there is for Azure Blob Storage. To resolve this, we can simply iterate through the Table entries and insert them to another storage account. Using a simple PHP file (shown below) and a Web Job, we can set this up in a matter of minutes and have peace of mind that, should something happen, we have a clone of our date. I schedule my Web Job daily.

In the file below, you see that we select all entries from the “$tableName” with no filter. We use the ConnectionString for the source table, and to simplify things, I just include the new Storage Account in the variable “$backupStorageAcct”.

This solution requires the Azure SDK for PHP, which can be downloaded here: Azure SDK for PHP.

PHP File:

<?php

require_once 'vendor\autoload.php';

use WindowsAzure\Common\ServicesBuilder;

use WindowsAzure\Common\ServiceException;

use WindowsAzure\Table\Models\Entity;

use WindowsAzure\Table\Models\EdmType;

$backupStorageAcct = "DefaultEndpointsProtocol=https;AccountName=%AccountNameRemoved%;AccountKey=%AccountKeyRemoved%";

$tableRestProxy = ServicesBuilder::getInstance()->createTableService($_SERVER["CUSTOMCONNSTR_StorageAccount"]);

$tableRestProxyBack = ServicesBuilder::getInstance()->createTableService($backupStorageAcct);

$tableName = "%YourTableNameHere%";

$today = new DateTime();

$today = $today->format("mdY");

$backuptablename = $tableName . "backup" . $today;

createTable();

backupTable();

#To do: Delete old tables?

function backupTable() {

global $tableName, $tableRestProxy, $tableRestProxyBack, $backuptablename;

$filter = "";

echo "Backing up table $tableName<br>";

try {

$result = $tableRestProxy->queryEntities($tableName, $filter);

}

catch(ServiceException $e){

echo $code.": ".$e->getMessage()."<br />";

}

$entities = $result->getEntities();

foreach($entities as $entity){

$tableRestProxyBack->insertEntity($backuptablename, $entity);

echo ".";

}

function createTable() {

global $backuptablename, $tableRestProxyBack;

echo "Creating table $backuptablename<br>";

try {

$tableRestProxyBack->createTable($backuptablename);

}

catch(ServiceException $e){

echo $code.": ".$e->getMessage()."<br />";

}

C:\MSOCache\All Users\{90120000-0030-0000-0000-0000000FF1CE}-C\setup.exe /modify /Enterprise /config \\server\share\config.xml

Config.xml File:

http://technet.microsoft.com/en-us/library/bb693755.aspx

Features that Are Not Supported on the Internet

Not all Configuration Manager 2007 features are appropriate for the Internet, and so they are not supported when clients are managed on the Internet. The features that are not supported for Internet management typically rely on Active Directory Domain Services (which is not accessible from the Internet) or are not appropriate for a public network (such as network discovery and Wake On LAN).

The following features are not supported when clients are managed on the Internet:

Software distribution that is targeted to users (either directly or through Microsoft Windows security groups).
Branch distribution points (a branch distribution point cannot support Internet clients, and clients on the Internet cannot be configured as a branch distribution point).
Client deployment over the Internet.
Auto-site assignment.
Network Access Protection (NAP).
Wake On LAN.
Operating system deployment.
Remote control.
Out of band management in Configuration Manager 2007 SP1.
The client ping functionality used with the client status reporting feature in Configuration Manager 2007 R2.

Additionally, Internet-based client management does not support roaming, which allows clients to always find the closest distribution points to download content. Clients that are managed on the Internet have a fixed Internet-based management point and communicate with that management point only when they are on the Internet, and with site systems in the site that are configured for Internet-based client management.

Clients connecting over the Internet will download content from any of the Internet-based distribution points in the site, regardless of bandwidth or physical location. For this reason, you cannot configure a protected site system to support Internet-based client management.

____

You must enabled Named Pipes after installing MDT and Creating a Database.

Launch SQL Server Configuration Manager – SQL Server Network Configuration – Protocols – Named Pipes – Select Enabled.

Otherwise, you will get SQL Connection Errors.

This scenario is for companies that are using SCCM for Software Updates.

Create Group Policy Preferences to detect if SCCM Client is installed by detecting if a Local WSUS Server has been specified via the SCCM Client. If specified, the Policy will ignore since the SCCM Client is installed. If not specified, the Policy will add a WSUS/SUP that will install the client.

Create new Registry Item for WUServer

Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: Software\Policies\Microsoft\Windows\WindowsUpdate
Value name: WUServer
Value type: REG_SZ
Value data: http://wsus

Set Item-level targeting for Registry Match

Match type: Value exists
Hive: HKEY_LOCAL_MACHINE
Key path: SOFTWARE\Policies\Windows\WindowsUpdate
Value name: WUServer
Value type: REG_SZ
Item Options: Is Not

Create new Registry Item for WUStatusServer

Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: Software\Policies\Microsoft\Windows\WindowsUpdate
Value name: WUStatusServer
Value type: REG_SZ
Value data: http://wsus

Set Item-level targeting for Registry Match

Match type: Value exists
Hive: HKEY_LOCAL_MACHINE
Key path: SOFTWARE\Policies\Windows\WindowsUpdate
Value name: WUStatusServer
Value type: REG_SZ
Item Options: Is Not

Create new Registry Item for UseWUServer

Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: Software\Policies\Microsoft\Windows\WindowsUpdate\AU
Value name: UseWUServer
Value type: REG_DWORD
Value data: 1 *Decimal

Set Item-level targeting for Registry Match

Match type: Match value data
Hive: HKEY_LOCAL_MACHINE
Key path: SOFTWARE\Policies\Windows\WindowsUpdate\AU
Value name: UseWUServer
Value type: REG_DWORD
Value data: 1 *Decimal
Item Options: Is Not

Download: http://technet.microsoft.com/en-us/systemcenter/dd408384.aspx

On your workstation, change the data value in the following key:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Setup
Data: Type
Data Value: dword:00000001
Usually this is set to 00000004 on a workstation signifying just the admin console. 00000001 Is for Primaries, type 00000002 is for Secondaries.

How to setup Azure SQL Integrated Authentication

Error: “Could not discover endpoint for Integrate Windows Authentication” when attempting Active Directory Integrated Authentication

Details of error message:

Failed to authenticate the user NT Authority\Anonymous Logon in Active Directory (Authentication=ActiveDirectoryIntegrated).

Error code 0xCAA90022; state 10

Could not discover endpoint for Integrate Windows Authentication. Check your ADFS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (Microsoft SQL Server, Error: 0)

Image:

Caused: Caused when attempting “Active Directory Integrated Authentication” from the SQL Management Studio using ADALSQL with default ADFS Settings.

Reason: By default, ADFS does not enable Integrated Windows Authentication for WS-Trust 1.3, as shown below:

Solution: Enable Integrated Windows Authentication for WS-Trust 1.3 for the Transport Security Mode and if desired, enable for Proxy access, as shown below:

Upon enabling the setting you can log into SQL Azure, using Active Directory Integrated Authentication, and verify that, if your account has permissions, you can access SQL Azure without an id or password.

How to enable password + user certificate authentication in ADFS 3.0

posted for Kevin Saye

Overview:

With the large usage of consumer and enterprise devices from inside and outside the organization, many customers are asking what Microsoft’s native MFA (Multi Factor Authentication) options are.

This blog discusses the how to architect, implement and troubleshoot: internal and external devices, password and/or certificates and users and/or groups to accomplish multi factor needs for ADFS aware applications.

What is Multi Factor Authentication and what does Microsoft offer?

While different people have different interpretation of MFA, most will agree it is generally view and accomplished by combining 2 different factors to identify the user. The most common are what you know (password) and what you have (some artifact that cannot be in 2 places at once).

The most common deployments are password + hard token. More cost effective are “soft” tokens, which are forms of software running on a device that cannot be cloned.

Microsoft offers 2 forms of “MFA” out of the box: certificates and software such as PhoneFactor. ADFS 3.0 supports both for passive profile applications.

Architecting ADFS for MFA:

Out of the box, ADFS 3.0 can determine:

internal or external access networks
Registered or non-registered devices
User / group membership
Devices with and without user certificates

ADFS also has a pluggable ecosystem for third party solutions. Microsoft maintains a “step by step” list of ADFS solutions here: http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(v=WS.10).aspx.

Using the above 4 options we can construct enforcement policies such as:

You can access all “non-sensitive” applications without MFA
If not on the corporate network, you must have MFA to access a specific application
If not on the network and not on a registered device, you must have MFA
If not on the corporate network, you can’t use Outlook, but you can use ActiveSync
If a privileged user, must always have MFA
On a non-standard device, must always use MFA
If not accessing from in country locations (need: http://www.ip2location.com/ database) must use MFA

As you can see from above, we can combine many forms of policy and enforce it at ADFS.

Implementing a MFA restriction:

Implanting MFA takes 3 core steps:

Enable Certificates as an authentication method
Defining MFA at the Global Policy
Requiring MFA on a “Relying Party Trust” basis
[Optional] Defining Issuance Authorization Rules for each “Relying Party Trust”

Enable Certificates as an authentication method:

Configure AD FS -> Authentication Policies -> Edit Global Primary Authentication to allow Certificate Authentication on the location you desire.

Defining MFA at the Global Policy

Configure AD FS -> Authentication Policies -> Edit Global Multi Factor Authentication Policy to determine what other options qualifies as MFA. Below you see I have selected certificates, which will qualify user certificates as MFA.

Requiring MFA on a “Relying Party Trust” basis

Configure AD FS -> Authentication Policies -> Per Relying Party Trust to determine when and to whom MFA is required.

[Optional] Defining Issuance Authorization Rules for each “Relying Party Trust”

To require a specific “Relying Party Trust” to use certificate type or to deny/allow based on device and or protocol, you can define an Issuance Authorization Rule to allow / disallow based on any claim you choose. Example below says “must be cert” but the options are endless.

Troubleshooting / Logging MFA Access:

Enable Auditing in the Federation Services Properties.

When you user logs in with multiple factors, you will see:

If they log in with forms based authentication and a certificate you will see:

If they log in with integrated authentication:

If the user logs in from the intranet, you will see:

To see what the application is and if it came through a proxy:

ADFS 2.1 User Certificate Authentication and/or Device Registration Authentication Fails with Server 2012 R2

Problem: Using Certificate Authentication or Device Registration with ADFS on Server 2012 R2 fails when published externally. Internally it works, externally it fails.

Cause: Changes were made in ADFS on Windows Server 2012 R2 to support Device registration. These same changes apply certificate authentication, where the client (machine and / or web browser) initiates a TCP connection to the ADFS or WAP server on destination port 49443. This design change is documented here: http://technet.microsoft.com/en-us/library/dn486819.aspx.

Solution: On your external Firewall, in addition to TCP port 443, publish TCP port 49443 for ADFS or the WAP (preferred method).

Managing Mobile Devices Encryption with Configuration Manager and Windows Intune

In this blog I will detail the steps (with screenshots) on how to implement and monitor Mobile Device Encryption using Configuration Manager 2012 R2 and Windows InTune. I will outline the following:

Enroll a Windows Phone 8.1 Device to be managed by Configuration Manager and Windows Intune
Create Windows Intune Collections (Users and Devices)
Create Compliance Settings – Configuration Item with Encryption Policy
Create Compliance Settings – Configuration Baseline with Configuration Item
Deploy Configuration Baseline to Collections
Monitor Configuration Baseline Deployment

This blog post assumes that you already have Configuration Manager and Windows Intune up and running and are knowledge operating and managing devices with Configuration Manager.

Enroll a Device

These are the steps to enroll a Windows Phone 8.1 Device to be managed by Configuration Manager and Windows InTune.

Go into Settings on Windows Phone 8.1 Device and select Workplace. Click on Add Account and then enter your email address and select Sign In.

Enter your Password and click Sign In to Enroll. Finally, select Install Company App and Click Done.

Once you Enroll your phone, you can expect policy and changes to take effect within an hour. You can also force a policy refresh by clicking on the Refresh Button.

Create Configuration Manager Collections

I created User and Device Collections. I have a User Collection called All Windows Intune Users and multiple Device Collections. I will focus on creating the Device Collections below:

All Mobile Devices

Built-In Collection. All Mobile Device Collections below are limited to this Collection

All Mobile Windows Phone Devices

Criteria: System Resource.Agent Edition is equal to 4

All Mobile iPhone Devices

Criteria: System Resource.Agent Edition is equal to 8

All Mobile Android Devices

Criteria: System Resource.Agent Edition is equal to 11

I only have one Windows InTune Users Collection that queries an AD Group. This collection defines which users will be able to enroll there devices for management.

All Windows InTune Users

Criteria: User Resource.User Group Name is equal to "CONTOSO\Windows Intune Users"

Create Configuration Item – Encryption Policy

From the Configuration Manager Console, Navigate to Assets and Compliance Node. Select Configuration Items and Right Click to Create Configuration Item.

Select Encryption under the Select the mobile device setting groups to configure. Click Next.

Change File encryption on mobile device from Not Configured to On. You can select Remediate noncompliant settings to force Encryption on devices that support that feature. I change Noncompliance severity for reports to Critical.

Under the Supported Platforms screen, uncheck Select All and then only select Windows Phone 8.1.

The following page is the Platform Applicability. If any settings are not supported by all platforms, they will be listed on the following screen. Encryption is supported on Windows Phone 8.1, so nothing to show here. I just clicked Next.

Next is the Summary Page.

Completion Page.

Create and Deploy Configuration Baseline

Navigate to Assets and Compliance Node in Configuration Manager Admin Console. Select Configuration Baselines, Right Click and Select Create Configuration Baseline.

Enter a Name: All Windows Phone 8.1 Encryption Baseline and Description is desired.

From the Configuration Data section, click on Add and Choose Configuration Items.

Select All Windows Phone 8.1 Encryption Policy Configuration Item that was created in the previous step and Click Add then OK. You can add multiple Configuration Items if desired.

Now that the Configuration Baseline is created, the next step is to deploy the Baseline to a Collection.

Right Click Configuration Baseline and Select Deploy. You can select multiple options for Remediation and Generating an Alert. I choose All Windows InTune Users Collection and a Simple Schedule to Run Every 4 Hours.

Click OK to Complete the Deployment.

Monitoring Baseline Deployment

There are multiple ways to monitor and report on the Encryption Status of the devices in our Deployment. Navigate to Monitoring Node in Configuration Manager Console. From here, we can utilize Alerts Node, Reporting Node and Deployments Node to monitor and track Encryption Status of the devices.

Here are screenshot from the Deployment Status:

Each Deployment Status will show Compliant, Error (if a Configuration Item does not apply), Non-Compliant and Unknown (if a device has not gotten the policy).

This screen shows that Andrew's Windows Phone is Encrypted and therefore Compliant.

The Non-Compliant Tab shows that Dawn and Madison's Windows Phones are not Encrypted and therefore Non-Compliant.

There are also 17 Built-In Compliance and Settings Reports.

And finally, we have Alerts that can be configured when deploying each Baseline.

This concludes a high-level overview of how to monitor the Encryption Status (or any other Mobile Device Setting).

Step 1: Connect to Exchange Online using remote PowerShell – http://technet.microsoft.com/en-us/library/jj984289(v=exchg.150).aspx

Launch Windows PowerShell from a Windows 7, 8 or 8.1 with .NET Framework 4.5 or higher and Windows Framework 3.0 or higher

Run the following command: $UserCredential = Get-Credential

Type your Exchange Online user name and password, and then click OK

Run the following command: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Run the following command: Import-PSSession $Session

Step 2: Updates Templates for Exchange Online – http://technet.microsoft.com/en-us/library/dn642472.aspx

Using Windows PowerShell in Exchange Online from Step 1

Run the following command: Import-RMSTrustedPublishingDomain -Name "RMS Online – 1" -RefreshTemplates –RMSOnline

To confirm that the templates have imported successfully, wait a few minutes

Run the following command: Get-RMSTemplate

Note: I used the default TPD Name "RMS Online – 1". To verify your TPD name, you can run the following command Get-RMSTrustedPublishingDomain

Azure Rights Management, enables implicit trust between organizations and users in any organization. This means that protected content can be shared between users within the same organization or across organizations when users have Microsoft Office 365, or Azure Rights Management, or users sign up for RMS for individuals. There is a default Do Not Forward template that can be used across organizations. The Do Not Forward Template allows recipients to read the message, but cannot Forward, Print or Copy content. For additional settings and templates to use across organication, you must create a new Rights Management Template using PowerShell.

I will detail the steps in this blog to show how to create an Azure Rights Management Template for Users Across an Organization.

Step 1: Connect to Azure Rights Management using Windows PowerShell

Run the following command: $AdminCredentials = Get-Credential

Type your Azure user name and password, and then click OK

Run the following command: Connect-AadrmService -Credential $AdminCredentials

Step 2: Create Azure Rights Management Template

Run the following commands to create a Template for Marketing where joe@company123.com only has View and Export rights and the Marketing Department has Co-Author rights:

Specify Name and Local Variable: $names = @{}

Specify Name and Local: $names[1033] = "Company123 – External Company Confidential"

Specify Description Variable: $descriptions = @{}

Specify Description: $descriptions[1033] = "This content is confidential and should only be Viewed by Joe at Company 123"

Specify Rights for Joe at Company 123: $r1 = New-AadrmRightsDefinition –EmailAddress joe@company123.com -Rights "VIEW","EXPORT"

Specify Rights for Marketing Department: $r2 = New-AadrmRightsDefinition –EmailAddress marketing@contoso.com -Rights "Co-Author"

Create and Publish Template: Add-AadrmTemplate -Names $names –Descriptions $Descriptions -RightsDefinitions $r1, $r2 -Status Published

Step 3: Connect to Exchange Online using remote PowerShell

Launch Windows PowerShell from a Windows 7, 8 or 8.1 with .NET Framework 4.5 or higher and Windows Framework 3.0 or higher

Run the following command: $UserCredential = Get-Credential

Type your Exchange Online user name and password, and then click OK

Run the following command: Import-PSSession $Session

Step 4: Updates Templates for Exchange Online

Using Windows PowerShell in Exchange Online from Step 3

Run the following command: Import-RMSTrustedPublishingDomain -Name "RMS Online – 1" -RefreshTemplates –RMSOnline

To confirm that the templates have imported successfully, wait a few minutes

Run the following command: Get-RMSTemplate

Note: I used the default TPD Name "RMS Online – 1". To verify your TPD name, you can run the following command Get-RMSTrustedPublishingDomain

MSDN Links:

Azure Rights Management Cmdlets – http://msdn.microsoft.com/en-us/library/azure/dn629398.aspx

Connect-AadrmService – http://msdn.microsoft.com/en-us/library/azure/dn629415.aspx

Add-AadrmTemplate – http://msdn.microsoft.com/en-us/library/azure/dn727075.aspx

Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 2 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page

Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.

Part 2 – Using Cloud or on Premises MFA

What changes happen in the claims and how to control where MFA takes place.

Part 3 – User Certificates

Enabling enrollment and usage of user certificates for ADFS.

Part 4 – Expired Passwords

How to detect and address users with expired passwords.

Part 2 – Using Cloud or on Premises MFA:

While it is not the purpose of this blog to discuss installation, it is the purpose to discuss logic and claims needed.

Two items we need to discuss before we understand the logic:

PowerShell: Set-MsolDomainFederationSettings with the –SupportsMFA parameter
Claim: Authentication Method References (http://schemas.microsoft.com/claims/authnmethodsreferences)

Domain Federation Setting:

Authentication Method Claim:

You will get event log error: 365 with the description: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made ….

To resolve this, enable the claim http://schemas.microsoft.com/claims/authnmethodsreferences on your Azure Relying Party (discussed next).

Enabling the Authentication Method References in ADFS:

To enable the claim to be sent from ADFS to Azure, follow these steps:

Open the AD FS Management console on your ADFS Server.
Select AD FS à Trust Relationships à Relying Party Trust
Right click on “Microsoft Office 365 Identity Platform” or whatever you have named the Azure Relying Party and select Edit Claim Rules
Click Add Rule on the Issuance Transform Rules tab
Select the rule template Pass Through or Filter an Incoming Claim and click next
In the incoming claim type, select Authentication Methods References and leave Pass through all claim values selected and click Finish
Click OK to save the Claims Rules

Now any Azure service that requires Multi-Factor will honor the http://schemas.microsoft.com/claims/authnmethodsreferences claim.

How to use both Azure Multi-Factor Server and Azure Multi-Factor Authentication

In some cases, you may want to use Multi-Factor Server for some users and Multi-Factor Authentication for others.

If you want to support both Multi-Factor Server and Multi-Factor Authentication for a single Federated domain, follow these steps:

Use the “Set-MsolDomainFederationSettings” command and set the –SupportMFA to $false
Enable a MFA provider in ADFS
Enforce the MFA requirement on the desired users in ADFS

4. Enable the Authentication Methods References claim in ADFS

Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 3 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page

Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.

Part 2 – Using Cloud or on Premises MFA

What changes happen in the claims and how to control where MFA takes place.

Part 3 – User Certificates

Enabling enrollment and usage of user certificates for ADFS.

Part 4 – Expired Passwords

How to detect and address users with expired passwords.

Part 3 – User Certificates

Often overlooked but very effective are User Certificates. These certificates are a legitimate form of multi factor by meeting the something you have (certificates) factor.

To get started, we need to (1) allow the user to request (enroll) for a certificates and (2) allow the user the ability to authenticate with a certificate.

Allow the user to request a certificate

The default Certificate Enrollment Website look like this, enabling a user to request a user cert.

To securely publish the Certificate Server with Windows Server 2012 R2 Web Application Proxy and Windows Server 2012 R2 ADFS, follow these steps:

Identity the Server with the Certificate Services Web Enrollment Role enabled. My server is named: multifactor.kevinsay.scd365.net, which by default required Windows authentication.
Open the AD FS Management Console on the ADFS Server
Click AD FS à Trust Relationships à Relying Party Trust and select Add Non-Claims Aware Relying Party Trust
Specify a Display name, like Certificate WebSite and click next
Specify the Identifier as https://<servername>/certsrv. My identifier is https://multifactor.kevinsay.scd365.net/certsrv/ and click add and next
Select Configure multi-factor authentication settings for this relying party trust and click next
Under Locations select Extranet and click next, next and close
If promoted to edit the claim rules, simply ok this dialog box
If using a different host name for the Certificate Web Server, you will need to run the command “setspn” to register the unique SPN (used by Kerberos) else Web Application Proxy will not be able to find the server.
Use Active Directory Users and Computers to modify the Kerberos Constrained Delegation of the Web Application Proxy to include the SPN of the Certificate Services Web Enrollment Server, as illustrated below:

Open the Remote Access Management Console on the Web Application Proxy Server and select Publish
Select ADFS as the Preauthentication method
Select the name of the Certificate WebSite, as defined in step 4 and click next
Type a name, external URL, select a cert that matches the external name, a backend url and the SPN as shown below:

Click next and publish

Allow the user to authenticate with a certificate

To enable users to authenticate with certificates as a single or Multi-Factor authentication, follow these steps:

Open the AD FS Management Console on the ADFS Server
Select AD FS à Authentication Policies and click Edit Global Primary Authentication
If you want to enable Certificates as a single Factor authentication for extranet users, under Extranet click Certificate Authentication
If you want to enable Certificates as a Multi-Factor authentication, click the Multi-Factor Tab and click Certificate Authentication and any other MFA method you have installed. Also determine when MFA is required (users/groups, location and devices) as shown below:

Advanced Customization of ADFS for Cloud Usage

Written by Kevin Saye

This is part 4 of a 4 part blog about customizing Microsoft’s ADFS for advanced user scenarios. I will break down this series into the following parts:

Part 1 – Customizing the Login Page

Customizing the Login Page for advanced features. We will add icons and have automated presentation logic.

Part 2 – Using Cloud or on Premises MFA

What changes happen in the claims and how to control where MFA takes place.

Part 3 – User Certificates

Enabling enrollment and usage of user certificates for ADFS.

Part 4 – Expired passwords and locked out accounts

How to detect and address users with expired passwords or locked out accounts.

Part 4 – Expired passwords and locked out accounts

Windows Server 2012 R2 ADFS addresses passwords that expired, as show below:

ADFS, for security reasons, does not address account lockout, as shown below:

Because this error message above can be for many reasons or could be a brute force attack, addressing this error can vary based on company policy.

Using JavaScript, we can detect the “errorText” is not null and take action.

My example below ask the user if they need help resetting their password and will redirect them to the Reset Password Site. You can modify as you see fit.

The HTML I used to set this up is included below:

{ if(document.getElementById(“errorText”).innerHTML != “”)

{ if (confirm(“Would you like to reset your password?”) == true)

{ location.href=’https://passwordreset.microsoftonline.com/?whr=kevinsay.scd365.net’; }

};

window.onload=resetPassword;

</script>

The PowerShell command to configure this is:

Set-AdfsGlobalWebContent -SignInPageDescriptionText “<script>function resetPassword() { if(document.getElementById(“”errorText””).innerHTML != “”””) { if (confirm(“”Would you like to reset your password?””) == true) { location.href=’https://passwordreset.microsoftonline.com/?whr=kevinsay.scd365.net’; } }; }; window.onload=resetPassword; </script>”