PowerShell, X.509, and SmartCards
That article is aimed at IT Professionals with an understanding of the inner workings of Office 365 services and are comfortable with Remote PowerShell authentication methods.
Here’s the news of the day, X509 is not supported with Remote PowerShell sessions to Azure or Office 365 Services.
Why do I need PowerShell?
The fundamental goal of Windows PowerShell is providing better, easier administrative control over systems, either interactively or from script.
Limitation
They say a picture can speak a thousand words. We don’t need a thousand, just one, X.509.
On the left, a user with a Personal Identity Verification (PIV) card attempts to access Office 365 Remote PowerShell. On the right, the same user attempts to access the Office 365 web portal with Personal Identity Verification (PIV). Even though they appear to look the same, they're not. When a company administrator deploys Active Directory Federation Services (AD FS) and enables Modern Authentication in the Office 365, the user login request will be redirected to the AD FS sign on page. The user will be prompted for credential to access Office 365 resources (Exchange, SharePoint, etc.). Active Directory accounts used for interactive logon, including administrative accounts, to use smart cards for logon, will experience this issue. This is the most far reaching and potentially disruptive experience, but also the one that represents the greatest relative security gain. If the user attempts to sign on without leveraging X.509, it will fail authentication. For more information on Smart Cards and Personal Identification Verification, follow the links below.
What is X509?
Public key cryptography relies on a public and private key pair to encrypt and decrypt content. The X.509 public key infrastructure (PKI) standard identifies the requirements for robust public key certificates. A certificate is a signed data structure that binds a public key to a person, computer, or organization. In other words, with X.509 Cyber can sleep better at night. Maybe. For more information on X.509, Bing X.509.
Why doesn't it work?
Network security requirements generally drive complex identity architecture. AD FS, Modern Authentication, Alternate Identity and, you guessed it Personal Identity Verification Card (PIV) coexisting as one happy family. As you can seen in the image on the (right), by default AD FS displays "Sign in using an X.509 certificate" when using user certificate authentication. However, certificate authentication is not supported with Remote PowerShell in Azure AD.
Here is the word from the product group, (drum roll please)….. “I was thinking about the PowerShell idea, which is useful for people to run scheduled jobs. The gap is that the current CBA support from AAD revolved around mobile devices (/en-us/azure/active-directory/active-directory-certificate-based-authentication-ios) I haven’t done the analysis to understand what it takes for AAD to support CBA for PowerShell. This is on our todo list. Yes you heard it, something magical is happening at Microsoft.
Workaround
And there you have it, a front row seat to the story of my life. 😊 For short, the work around is, you guessed it, userClass object, synced via AD Connect, with interactive logon disabled. This account will leverage AD FS with Window Integrated Authentication, and put your nightmare to rest. By default, Windows Integrated Authentication (WIA) is enabled in Active Directory Federation Services (AD FS) in Windows Server 2012 R2 for authentication requests that occur within the organization’s internal network (intranet) for any application that uses a browser for its authentication. For added security you can enable MFA for either Office 365 or Azure and it works! You should also explore using an Office 365 Cloud Account with Global Admin rights. Many organizations practice the latter of to two but, I'll leave that up to you to decide.
Update coming soon!
For more information:
Post Mortem Securing a Government Agency with Smart Cards
https://technet.microsoft.com/en-us/library/2005.11.postmortem.aspx
SmartCard Authentication
https://technet.microsoft.com/en-us/library/dd277362.aspx
Windows Integrated Authentication (WIA) with AD FS