Posts about:
One of the most important aspects of moving to a cloud solution like Office 365 is to provide a way for users to authenticate to their cloud resources. Organizations typically want to reduce administrative overhead and user confusion by managing only one directory, be it the on-premises directory (AD) or the cloud directory (Azure AD).
Ignite ended about a month ago, and it’s time to start exploring some of the new features and services that were introduced in Atlanta. In this article, we will take a look at Azure Information Protection, the next chapter in Microsoft’s data protection story.
Identity management is a huge part of any organization's migration into “the cloud.” Sure, you can move your email, your IM and presence, your document libraries, maybe even your voice and video services into Office 365. But unless your organization is very small, identity management will still take place in your own on-premises Active Directory.
Without any big announcements, a preview version of the Azure AD PowerShell module was released last week. In this article, we will go over the release in a bit more detail and cover some of the changes in comparison with the MSOnline module.
Azure Rights Management Service (RMS) is an information protection solution, the cloud-based version of AD RMS. The service has been rapidly evolving in the past few months, introducing features such as: the Tracking portal, which gives users the ability to audit the consumption of their protected content and revoke access if needed; full multi-factor authentication support across all RMS clients; the RMS protection tool, which provides PowerShell cmdlets to bulk (un)protect files and replaces the AD RMS Bulk Protection Tool; the Azure RMS usage logs; and more.
A few weeks ago, I wrote a blog post here covering how to deploy Azure Active Directory Connect 1.1. Due to popular demand, today I'm going to circle back and review some of the advanced configurations of AAD Connect as well as some troubleshooting tips to cover you in case you run into a hitch with your AAD Connect deployment.
Active Directory Synchronization for Office 365 and Azure has been a vital, but fairly straight forward, part of Office 365 migrations for almost 5 years now. DirSync was updated to Azure Active Directory Sync, and AAD Sync was updated to Azure Active Directory Connect. In this blog post, I’m going to cover everything you need to know about deploying the newest version of AAD Connect.
Consider the following scenario: you are about to implement directory synchronization for Office 365. You have multiple Active Directory sites across several, geographically dispersed, locations all over the world. Unsurprisingly, some of these locations have better connectivity than others and you might not want AAD Connect to connect to Domain Controllers in locations with a slow or high latency connection at the risk of slowing down the entire process.
On December 3, Microsoft had an outage that affected their Office 365 service for customers in most of Europe. More precisely, the outage was actually in Azure Active Directory.
Microsoft released Azure AD Connect to the public on June 24. The long-anticipated tool is the successor to Azure AD Sync and DirSync. But it’s much more than that.
Although a large part of Azure AD Connect still revolves around directory synchronization, I like to look at it more as a "Cloud Identity Enablement" — a solution rather than just a synchronization component. This is because Azure AD Connect not only allows you to deploy directory synchronization for almost every possible identity scenario you can dream of, but it also enables you to set up and configure identity federation through Active Directory Federation Services from within the same wizard.
