Post

Feb 22
Blogging over at Semperis

Hi folks,

My blogging here has been a bit quiet. But I am still blogging -  over at Semperis. They have terrific Active Directory disaster recovery and ​state manager products, and they've graciously let me blog about a variety of identity related topics. Check out my posts about fixing AD objects for Office 365, situations that put your AD at risk, and security risks in managing SaaS applications you might not be aware of.

Semperis Blog

Dec 31
Microsoft Identity Manager (MIM) Adds Privileged Access Management Capabilities

​Back in November, Alex Simons posted a big announcement to the Active Directory Team Blog that you might have missed, given the flurry of end-of-year Azure Active Directory announcements coming from the team. In this post he announced that the next generation of Forefront Identity Manager (FIM), with the defunct "Forefront" branding sensibly dropped for "Microsoft" (and thus MIM"), had entered public preview. What you almost certainly missed inside this post was the most significant on-premises Active Directory Domain Services capability in years.

MIM isn't just another tweak to the FIM code base. It's a major rewrite, and focuses on three areas: Modernization and ease of use, the ability to better integrate with Azure AD, and privileged access management. This last one's a biggie, and deserves more explanation.

Privileged access management, isolation, and elevation

Management of privileged groups in Active Directory has always been a pain. Everyone wants privileges, of course, and they want them yesterday. And unless have the knowledge and time to develop (and stick to) an AD delegated administration model, you end up with a bloated Domain Admins account. Once attained, no one wants to lose those admin privileges, so unless you have strict attestation procedures to constantly review group membership and remove expired users the number of privileged accounts grow and grow. The number of attacks on businesses have both grown exponentially in the last few years and become more sophisticated, and their focus is often to gain access to these administrative accounts. Privileged Access Management (PAM), isolation and elevation capabilities in MIM are designed to mitigate this vulnerability.

MIM - PAM.jpg 

PAM uses a new concept: The privileged forest. This one-domain forest only contains shadow copies (first from SIDHistory and later from foreign principal groups) of privileged groups and accounts in a corporate account forest, synchronized by MIM. To quote the documentation, "when a user requests elevation using the PowerShell cmdlets, and their request is approved, the MIM Service will add their account in the PRIV forest to a group in the PRIV forest.  When the user logs in with their account, their Kerberos token will contain a Security Identifier (SID) identical to the SID of the group in the CORP forest.  Because the CORP forest has been configured to trust the PRIV forest, when the user uses their account to access a resource in the CORP forest, that resource will receive the user's group memberships from Kerberos that will cause that user to appear to be in a group in the CORP forest. 

Furthermore, these memberships are time limited so that after a preconfigured interval of time, the user's administrative account will no longer be part of the group in the PRIV forest.  As a result, that account will no longer be usable for accessing additional resources."

Self-service password reset using Azure multi-factor authentication

Previously (FIM 2010 R2), there were two ways a user could authenticate themselves during a password reset process. First, they could answer a series of security questions and answers. Or they could obtain a one-time password (OTP) from a third party provider. MIM adds another way to authenticate: A phone call from the Azure multi-factor authentication (MFA) service. Because this is an Azure service and thus doesn't require you deploy on-premises SMS services or other telecom capabilities, it's much easier to deploy phone-based authentication.

Certificate Manager updates

In the MIM preview, Certificate Manager has gained a new Windows Store-style application to handle self-service tasks related to smart cards, virtual smart cards, and certificate management. This allows users to enroll themselves new smart cards or renew or reset certificates. It also works for devices that aren't domain joined – which breaks the Catch-22 situation of not being able to renew a smart card because yours smart card has expired and you can't reach the domain.

 Microsoft

Updated support

Finally, MIM supports platforms not previously supported by FIM 2010 R2: Windows Server 2012 R2, Sharepoint 2013, SQL Server 2014, Exchange 2013, and Visual Studio 2013. It will also support Windows Server 10.

These capabilities will breathe new life into the moribund FIM product. It will certainly be a best practices configuration for forest administrators with stringent security practices or compliance requirements. And Microsoft has tied MIM to Azure Active Directory Premium (which provides the bits and usage rights as part of this subscription), thus hoping to further drive adoption of both.

For more information and short videos explaining the new features (a good idea), have a look at Simon's blog post. Remember that before you can download the bits and doc, you must join the program from the Microsoft Connect directory of preview programs.

Keep up with my posts on various social media at about.me/seandeuby.

Dec 19
Azure Active Directory Connect (AAD Connect) Enters Public Preview

beisuboru.pngI have this vision.

In it, Azure Active Directory chief Alex Simons is screening Kevin Costner's "Field Of Dreams" for his team of program managers, drumming a couple of the movie's central themes into their heads: If you build it, he (they) will come. Ease his (their) pain. These themes must have sunk in, because Azure AD Connect, the latest (and last, we're told) utility from Microsoft to simplify and encouraging bridging on-premises identity to Azure AD, has entered public preview.

Azure AD Connect is designed to address one of the major pain points in Microsoft's hybrid identity solution: its identity bridge. The complexity of setting up Active Directory Federation Services for federation and DirSync (recently upgraded to Azure AD Sync) for identity synchronization between on-premises Windows Server Active Directory and in-the-cloud Azure Active Directory has been a speed bump for many organizations looking for single sign on (SSO) to Office 365 and other Microsoft Online Services.

Each of these on-premises services has been enhanced over the last few years to both make them easier to deploy and more useful. DirSync / Azure AD Sync has gained sorely-needed multi-forest capability, and AD FS has seen a raft of new features such as Workplace Join, multi-factor authentication, and conditional access control added to its base federation capabilities. Nevertheless, for companies interested solely in Office 365 SSO (at least at first), it's a lot to swallow compared to third party identity bridges. As a mission critical identity component for SSO to Microsoft's cloud identity component, AD FS needs to be in a high availability configuration.

There's also been a good amount of confusion as the company worked to streamline and simplify its bridging by previewing (i.e. publicly beta testing) new utilities and features as soon as they coded them. In the beginning there was DirSync. Then DirSync gained features to match new Azure AD capabilities. Then came Azure AD Sync, which had new features DirSync didn't have - but didn't yet have some features the older DirSync had. Finally, we have Azure AD Connect.

It's important to note that this is the end of the line for DirSync. It's also the end of the line for the short-lived Azure AD Sync. As Simons points out in his Active Directory Team Blog post, "There will no longer be separate releases of Azure AD Sync and Azure AD Connect. And we have no future releases of DirSync planned. Azure AD Connect is now your one stop shop for sync, sign on and all combinations of hybrid connections."

In building the Azure AD Connect utility, the Azure AD team hopes that they – the hundreds of thousands of enterprises that have Windows Server Active Directory as the cornerstone of their identity infrastructure – will come more readily to Office 365 and the rest of Microsoft's cloud solutions.

I write about cloud identity, Microsoft hybrid identity and whatever else I find interesting at Enterprise Identity and on Twitter at @shorinsean.

Nov 19
Everything you need to know about Active Directory Kerberos Vulnerability CVE-2014-6324

Yesterday, Microsoft released an out-of-band critical update for Active Directory. Those last eight words should make you pay attention. Here's what you need to know, and what you need to do right away.

 

What you need to know

The vulnerability, as described in Microsoft Security Bulletin MS14-068 - Critical, is in the Kerberos Key Distribution Center kd8g11.jpg(KDC) component of Windows Server Active Directory, present on every domain controller. It allows any domain user to execute an elevation-of-privilege attack to gain domain administrator privileges. Remote users can execute this attack as well as local network users. It affect ALL supported versions of Windows Server Active Directory, from Windows Server 2003 SP2 all the way up to Windows Server 2012 R2. And it affects both Full and Server Core installation options.

 

This is a big one folks, the biggest I've ever seen when you combine the elevation of privilege (domain admin), the scope of vulnerability (any domain user can do this), and the attack surface (all versions and installation options of Windows Server AD). There are no workarounds. To add to the urgency of the matter, it's in the wild: Microsoft has found limited, targeted attacks trying to use this vulnerability.

 

What causes the vulnerability? This Kerberos checksum vulnerability (CVE-2014-6324) can apparently fail to properly validate signatures, which can allow certain aspects of a Kerberos service ticket (which grants access to a server service - Sean) to be forged." The PAC (privileged attribute certificate) in Kerberos ticket is a data field that, in the protocol standard, can be used by specific implementations to carry what they need. In Active Directory's case it carries user and group SIDs used to authorize access to domain resources. The ticket, and therefore the SIDs in the PAC, are signed by the KDC to ensure its validity. Before this update, an attacker could put the Domain Admins well-known SID (S-1-5-< domain >-512) into the PAC and forge the signature, thus elevating the user SID in the PAC (and ticket) to be a member of Domain Admins.

 

What you need to do

An update from the Microsoft Security Research and Defense Blog describes the vulnerability in more detail, with helpful background on how Kerberos works for those of you that don't keep information on service tickets, session tickets, ticket-granting tickets, and three headed dogs. But what you need to do is

  1. Go to affected software on the Security Bulletin page, and download the appropriate updates for your Active Directory domain controllers.
  2. Patch DCs running Windows Server 2008 R2 and lower
  3. Patch DCs running Windows Server 2012 and higher (second because this OS has better overall security)
  4. Patch all other systems running any version of Windows

 

Wow, that's last one's a big statement, even though the vulnerability is much lower. I'd add that It's more important to patch servers before clients, because one could promote an unpatched server to a domain controller and thus make it vulnerable.

 

Enough said. Get patching!

Nov 18
Multifactor Authentication Coming to Office 365 and Office 2013

Microsoft recently announced an important update for its Office clients across most of its supported platforms. Why should you care? A lot of customers will welcome this enhancement because it enables some important capabilities such as multifactor authentication (MFA), full federated login, and smart card or certificate-based authentication for apps like Outlook. It's one more step towards reducing our dependence on passwords​ and increasing security.

All these enhancements have been made possible by incorporating the Azure Active Directory Authentication Libraries (ADAL for short) into the Office clients. When ADAL was announced, it didn't raise much interest among IT pros. It was a big deal for developers, however, because it enables them to easily incorporate Azure AD or Windows Server AD AuthN into their applications and take advantage of new possibilitites. Office client AuthN architecture using ADAL 

Goodbye, Outlook basic auth

One of the first things you'll notice is that Outlook no longer requires basic authentication, and the need to be re-authenticated if a connection is lost; instead, it's handled directly by the IdP. As anyone that's had to keep re-entering their Outlook / Exchange password - even though they're already authenticated to Active Directory - can attest to, this is a very nice enhancement to see.

Multifactor authentication

What will ADAL in Office 2013 do? First, it enables MFA for Outlook, Word, Excel, etc. One common scenario where this would come in handy: A bad guy has gained access to a user's password, then attempts to access the user's mail, either from OWA or by adding the user's Exchange account to an Outlook client. With MFA enabled, this will fail unless a second factor (text or phone call or authenticator app) is provided. (This is the same way it works with Google 2-Step Verification.)

Smart cards

Using ADAL also enables Office to use smart cards or certificate-based AuthN. Personally, I'd like to see support of the new U2F standard from the FIDO alliance. This would allow you to use the new cool Yubico FIDO U2F Security Key or the tiny Yubikey NEO-n key. The NEO-n stays inserted into a USB port, and it's tip-of-thumbnail size; when it's time to authenticate, a tiny LED glows. You merely touch the key with your finger, and you're in.

SAML 2.0 support

Last but not least, the ADAL libraries have SAML 2.0 federation support (SAML-P to be precise). This means that, if you have federation set up with an identity provider other than Windows Server Ad or Azure AD, you can use them to authenticate you.

The updated authentication capability will shortly be entering private preview where select companies will kick the tires before Microsoft makes it generally available. You can read the full announcement here:

Office 2013 updated authentication enabling Multi-Factor Authentication and SAML identity providers

Nov 17
Even Homeland Security Is Piling On To Windows Server 2003

There's no mercy or respect for age in the technology world. Windows Server 2003, that stalwart of data centers for many years,us-cert-logo.jpg has fallen prey to numerous vulnerabilities as bugs are discovered, exploits are leveraged, and hacking methods grow ever more sophisticated. As companies scramble to get their servers off the venerable server OS that reaches end of support on July 14th of next year, a team in Homeland Security has added their warning to the chorus.

US-CERT (United States Computer Emergency Readiness Team) has issued Alert TA14-310A about Windows Server 2003. The alert doesn't really say anything new beyond what you've already been telling your bosses: Window Server 2003 is old, it's vulnerable, it's non-compliant.

For you IT professionals trying to jackhammer some Windows Server 2003 migration funds from their tight-fisted managers, this very official alert from DHS is one more bit of ammunition to move you out of this potentially dangerous (and certainly non-compliant) situation.

Nov 17
Transitions

Welcome to Enterprise Identity and my new blogging platform!

After many years in enterprise IT, almost as many as a Windows IT Pro contributing editor, and four more years as Technical Director for its parent Penton Technology Division, I'm diving back into the deep end of technology pool. Or perhaps I should come up with a cloud analogy, because that will be my focus: Consulting on hybrid identity systems, specifically identity as a service (IDaaS).

The last few years (and my network of brilliant identerati friends) have taught me a huge amount about cloud identity and its central role in managing access to the ever-increasing number of devices, apps, workplaces, and now even just things we use every day. There's an enormous gap between the capabilities of a typical identity and access management (IAM) environment in companies today and what they need to have in the future. These future, hybrid IAM systems need to securely manage seamless access to both on-premises resources and web-based service providers (for example, SaaS apps) for the company's users – wherever they are, whenever they need access.

Because of my many years' experience as a Microsoft directory services MVP and Intel Active Directory design engineer, I'll be focusing on Microsoft's rapidly-growing Azure Active Directory service. Microsoft is deadly serious about building Azure AD out as a first-class member of Azure, and making equal or superior to any service in the market. However, there are other, very fine non-Microsoft IDaaS solutions in the market, and each have unique capabilities that may make them perfect for your company's requirements. I've worked with many of them, and spent the last few years outside the Microsoft bubble to see (and recommend) the very slick solutions these companies – like Okta, Ping Identity, OneLogin, Centrify, and others – have to offer companies of every size.

When I was at Windows IT Pro, I looked at my Enterprise Identity column as a "bully pulpit" to help inform IT professionals on identity-related trends they needed to be paying attention to. I intend to continue that mission here: Blogging about identity news and big trends the IT pro needs to know about and pay attention to. I hope you choose to come along for the ride - because the train's not slowing down!

- Sean