Azure AD, Multifactor Authentication and app passwords

One of the pretty cool things that Azure AD added in late 2013 is Multi-factor authentication.    This rolled out in early February to more O365 licensees, and throughout the year, more and more organizations have been taking advantage of this functionality.

• Documentation
• Announcement (2013) - Released
• Announcement (2014) - Added to many Office 365 plans
• MSExchange.org three part series on configuring and deploying

Microsoft's implementation of MFA is actually pretty nice and integrated.  We use it along with ADFS, so when I sign into web based services, I am asked for:

1. My username
2. My domain password
3. The code that has been texted to my mobile device

Perfect, one thing known by a few people, one thing known to one, and one thing I need to have.

You can also see here that I can select to not use the MFA for 60 days.  This is actually a setting administrators can choose to allow or not.  However, not allowing it, the box still appears, so your users can click it all they want, they will be needing their mobile to sign in to any web services.  I really think if it isn't allowed by your administrator, the option should never be displayed, it just makes users think that something is broken.

When you first sign in after enabling MFA on an account, you will be prompted to enter or update your phone numbers used for account security.  This is actually pretty neat, and as you can see there are multiple methods of MFA available to your users.

 Additionally, you can see that there is a Mobile App for authentication, so if you have users who don't have text/SMS plans, you can advise that they use the mobile app.

Of course, there are some things that do not work with MFA at all.   Thick clients, OneDrive, Word/Excel/Outlook.   The answer for this are app passwords.   The implementation of MFA also prevents powershell access to your tenant, and app passwords do not work for PowerShell.

App passwords are also:

1. all 16 characters
2. all lower case alphabetical characters only
3. can not be set to expire
4. can not be individually managed by administrators

 They can be disabled entirely by administrators, but that rules out a lot of functionality for your MFA enabled users.

You can tell by the name, I was testing PowerShell access.  This is really the biggest downside of MFA in my opinion - the accounts you would want to protect the most, your elevated ones, you can enable MFA, but then they cannot do bulk edits in any of the online shells (MSOL, Azure AD, EXO, SPO, LYO)  and doubly worst, since Disabling MFA is something you cannot do to your own account, you either need to find another Global Admin to toggle this setting, or you need to have a "less secured" account for your bulk edits.  Maybe one that you enable/disable as needed would be the best security practice there?  I'd prefer they made app passwords work for PowerShell but require that you input allowed IP ranges for PowerShell connections.  A lofty request I am sure.

As shown above, the "Name" of your app password means nothing and is entirely for users to label/remember where they used it.  Also, Admin's can't "reset" an app password, the user needs to self manage these.

The "copy password to clipboard" dialog really surprised me.  In a world where tinyurl, imgur and other sites have this integrated, Microsoft has opted to deliver this via JavaScript pop up, forcing you to click once, Hit Ctrl-C then click to close the dialog.  It's less effort to highlight and Ctrl-C.



In all, the MFA implementation at this point works pretty well for users, but can introduce more security related helpdesk tickets with the way app passwords are implemented.  And for Admin accounts MFA is fairly useless.  Most things I need to do I do in PowerShell.  Also, if you work for a very tightly secured organization, the lack of app password manageability or oversight could prevent your InfoSec team from allowing you to use it.

Lync Online PowerShell issues and solutions

So, I was asked to implement the fixes documented in Christian Burke's blog entry, SOLVED: Online Meeting Icon Missing from OWA in Exchange Online - which is a fairly complex and PowerShell heavy blog - he makes use of Lync Online PowerShell, Lync On premises PowerShell, and MSOL PowerShell(Microsoft Online Azure PowerShell)

I didn't think it would be, but the most complex part of completing the tasks on that blog was getting me connected to our Lync Online PowerShell!

Issue #1 - when running the New-CsOnlineSession, you are prompted for a TargetServer
You installed Lync on premise tools since you installed Lync Online.   Uninstall and reinstall the Lync Online Powershell.  See KB2955287.

Issue #2 - when running New-CsOnlineSession, you are getting "Unable to discover Powershell endpoing URI"  (Yes, the error has endpoint spelled incorrectly)

Your Lync autodiscover record is either pointed to on premise or non-existant.  If it is pointed to your on premise, you need to use -OverrideAdminDomain and specify your tenant domain.

Issue #3 - when running New-CsOnlineSession, you are getting errors like "Get-CsWebTicket : Arithmetic operation resulted in an overflow." or "Get-CsWebTicket : Failed to logon with given credentials" when you know your credentials are correct.

This one took a while.  I had MFA enabled and enforced on my account.  Apparently this will prevent me from using PowerShell.  Workaround is to utilize app passwords, or disable MFA to connect to PowerShell.  
4/20/2015 Update:  App Passwords worked for a very short window for this purpose.  Accounts with MFA enabled will need MFA disabled to use PowerShell

More on App Passwords in my next article "Azure AD, Multi Factor Authentication and App Passwords"

I'll post up any more as I find them, but these three hopefully will help some of you!
Chris