Using RADIUS with AD FS MFA

Active Directory Federation Services, AD-FS, is the de facto identity provider in a Microsoft environment. Many organizations will be using it to authenticate Office 365 users to an on-premise Active Directory. Support amongst cloud service providers is growing, allowing you to authenticate not just O365 users but users of a variety of business applications.

In certain circumstances, you may want to require multi-factor authentication (MFA). Out the box, AD-FS only provides support for X.509 certificates. Thankfully there’s the concept of Authentication Adapters, allowing you to develop your own MFA plug-in. I’ve developed a quick RADIUS plugin that allows you to prompt users to enter a one-time PIN and send the response to a RADIUS server, along with the accounts userPrincipalName, for validation.

RADIUS Authentication Adapter

The software is open-source and licensed under the GPL and relies on the excellent Radius.Net library.

Download

I strongly recommend compiling your own version rather than downloading a DLL and installing it into your AD FS servers. If you’re comfortable with the risks of that, you can download it from the links below.

Download Sourcecode (C#, 4.5)
Download Binaries (Version 1.0).

Installation

The below instructions cover installation into AD FS and make no attempt to document any RADIUS/NPS configuration.

  1. Extract the zip file to a convenient location and open install.ps1 in your favorite editor;
  2. Ammend the variables in install.ps1 to match your RADIUS server, shared key and any ports needed;
  3. From an elevated PowerShell prompt, run install.ps1
  4. Restart the AD FS service to complete registration
  5. If you have multiple AD FS servers in your farm, repeat the process on each but press CTRL-C when promtped to register the authentication adapter

Extract private key from Cisco private-config

This blog post discusses extracting a private key from Cisco IOS’s private-config file. I recently generated a keypair on an IOS router and had forgot to flag it as “exportable”, making it difficult to backup. As the key-pair was used for IPSec authentication it was an important key to backup.

The first step is to recover private-config from the device, which I’m not going to cover in this post. Opening the file in a text editor, locate the section that begins “crypto RSA-key-pair” and save the hexadecimal values to a text file, the section will look like this:

crypto RSA-key-pair MyKey 0 1440004978
308204BC 02010030 0D06092A 864886F7 0D010101 05000482 04A63082 04A20201
00028201 0100DE8D 63241465 57356A77 57FC2C3D BBDD8454 F25B6B1A DB487C6D
AA0C1157 F665AF18 08EFC785 C23D3185 06F3D51A 42C94F06 5A97756A C83693C6
...

When saving to a text file, omit the section beginning “crypto RSA-key-pair”, only the hexadecimal values are required.
Continue reading Extract private key from Cisco private-config

Office 365 “A local loop was detected”

Yesterday I encountered a problem with an Office 365 hybrid environment where mail suddenly began looping back and forth between the on premise environment and office 365 for all remote mail users. No changes had been made to the environment.

Mail was transferred successfully to Office 365 using the correct connector, but office 365 was then passing the mail back to on premise. This resulted in a mail loop and users sending e-mail to office 365 accounts receiving an NDR with the following:

servername.local #<servername.local #5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop>

Following a support call with Microsoft lasting around 4 hours, it turns out an internal change has been made to the way Microsoft deal with wildcard certificates. By changing the Office 365 inbound connector to use the SubjectAlternativeName of the wildcard certificate rather than the subject, our issue was resolved:

Before

PS C:\> Get-InboundConnector "Inbound" | fl Id,Tls*
Id                       : Inbound 2
TlsSenderCertificateName : <I>CN=COMODO RSA Organization Validation Secure Server CA, O=COMODO CA Limited, L=Salford,
S=Greater Manchester, C=GB<S>CN=*.domain.co.uk, OU=PremiumSSL Wildcard,
O=Organisation, STREET=Road Name, L=Location,
S=County, PostalCode=Postal Code, C=GB

After

PS C:\> Get-InboundConnector "Inbound" | fl Id,Tls*
Id                       : Inbound 2
TlsSenderCertificateName : *.domain.co.uk

The subject of the certificate had been automatically used by the hybrid configuration wizard and been working for at least the past three months.

Updated 3rd November

Microsoft have now provided the following update, though no such incident appears in the Office 365 portal (for me at least).

Current Status: Engineers have confirmed with some customers that the workaround resolves the issue. Currently, engineers are developing and testing a long-term fix for the code defect, which is expected to take an extended period of time to complete. User Impact: Users with mailboxes hosted on-premises are receiving an error message when attempting to send email to Office 365-hosted users. As a workaround, administrators can enable IP-based inbound on-premises connectors in Office 365 to successfully send email. Customer Impact: Your organization is affected by this event. Impact is specific to a subset of your users. Engineers have received a few isolated customer reports of this issue. Incident Start Time: Monday, November 2, 2015, at 8:53 AM UTC Preliminary Root Cause: A code defect caused an issue with a certificate-based connector. Next Update by: Wednesday, November 4, 2015, at 8:00 PM UTC