One of my favorite parts of being ENow’s CTO is bragging on the work our technical team does. I’m delighted to announce the latest GA release of the ENow Management System, 188.8.131.529. (Yes, that’s an odd version number—we purposely chose it in honor of Prince’s passing. Now we can, with a straight face, tell our customers to party like it’s 1999, as long as “party” means “upgrade” and “like it’s 1999” means “with our awesome new installer.”)
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.
The good people at ENow asked me to do a webinar on Identity and Authentication Management for Office 365, which I presented live on November 18. I’m adding this blog post as a companion piece to that webinar, which can be found at this link.
One of the most important parts of any migration to Office 365 is the identity and authentication management piece. Microsoft wants Office 365 to be a flexible platform that can meet the requirements of any organization. In order to meet wildly varying requirements, Microsoft has had to build quite many options into the identity and authentication management platforms for Office 365.
While options are great, they do mean complexity, and complexity is the enemy of availability. No one should plan a migration to Office 365 without a thorough understanding on the options, and how the choices you make will affect your Office 365 deployment years down the road.
Earlier this week, Tony Redmond wrote about Jeffrey Snover – also known as the godfather of PowerShell – being promoted to Technical Fellow at Microsoft; one of the highest achievable ranks.
Given that Jeffrey is considered to be the founding father of PowerShell, that does not really come as a surprise, as PowerShell has changed the way we work and interact with systems. And this does not only apply to large-scale environments or cloud solutions like Office 365.
Welcome to the fifth part of this article series about Azure AD Connect. In the previous article, we've taken a look at some of the optional features you can enable for directory synchronization. In this article, we'll cover a few more features -- more specifically the User and Group write-back capabilities.
Before discussing these features, note that they are currently in preview. You can test the features, but should not use them in production unless you have explicit permission by Microsoft.
Now that the disclaimer is out of the way, let's have a look at the User write-back feature.
Welcome to the fourth part of this article series about Azure AD Connect. In the previous article, I discussed permissions for a custom installation, and we dived a little deeper into the upgrade capabilities. Before jumping into the 'advanced' customization options such the filtering abilities, I wanted to take a look at some of the additional (preview) features that Azure AD Connect offers to date.
Welcome to the third part of this article series about Azure AD Connect. In the previous article, I discussed the various custom installation options and the implications of using a separate SQL database.
Following that article, I received a few interesting questions that warranted some follow-up. More specifically, I had a few people call out that documentation regarding the required permissions for Azure AD Connect is scarce. Although the requirements are documented as depicted in the image below, I agree that there might be some confusion, depending on your deployment configuration.
Yesterday, Microsoft announced the General Availability (GA) of Azure AD Connect. Azure AD Connect is consiered to be the successor to DirSync/AADSync. However, it is much more than just a synchronization engine. The tool allows customers to use a single wizard to configure various aspects of identity synchronization and authentication with Microsoft's Online Services.
The wizard - which shows similarities to the one used in AADSync - allows you to install and configure various Directory Synchronization options and now also includes the ability to automatically setup and configure Active Directory Federation Services. Before, you still had to manually enable a domain for federation after having isntalled and configured AD FS yourself. Now, the wizard allows you to "pick and choose"
which servers you are designating for AD FS and it will go out and perform the installation and configuration in Office 365 for the selected domains for you.
The biggest benefit of the tool is that it greatly simplifies the process so that administrators don't have to unnecessarily struggle with the entire process. After all, even though the sync and authentication process in itself are pretty straightforward, setup and configuration have proven to sometimes be quite challenging.
Next to these GA features, Azure AD Connect also includes the ability to preview features such as User- and Group Writeback; which Microsoft said to be releasing later.
For more information, have a look at the original announcment here or get started immediately and download the tool here.
Many companies have business relationships with SaaS partners that use SAML for authentication. ADFS works very well for many as a SAML & WS-* federation infrastructure, although we have had some hiccups and incompatibilities along the way. One thing that comes up every now and then is applying business rules to the federation trust with a partner. Microsoft has done a very good job of explaining how to implement certain business rules for Office365 in some of their official blog posts by PFE’s. But what I have not seen is some of that practical help applied to non microsoft services that we rely on. The rest of this article will address how we implemented a couple of these. 2 simple rules we are asked about are:
- We want our users to be able to only use this SaaS service when they are on our internal network or VPN. This may provide the business/security/compliance stakeholder a bit of extra confidence that the SaaS service is being used properly.
- We want only the users in this Active Directory group to be able to access this SaaS service. This could be a licensing requirement or a data security issue.
These business rules are typically requested for a specific SaaS application, so they are implemented as claims rules on the specific relying party trust for that SaaS application. It could also be applied in a service provider relationship but you would have to re-examine the logic. So just open the ADFS management tool, in a dev environment please!. Then go to Relying party trusts and select the trust you want to test with. Then click Edit Claims Rules.
Last year, Exchange Server MVP Mike Crowley wrote a script which would interactively report on the Office 365 Directory Synchronization tool. In the meantime –last September to be more exact – Microsoft released the new “Azure AD Sync Service” tool which seems deemed to replace DirSync at some point in the future.
As I do see the tool being used in production from time to time, effectively already replacing DirSync, I thought it would be useful to “upgrade” Mike’s script to work with the new kid on the block.
As Mike and I were going back and forth about this, he had a great idea to make the script create an HTML report instead of having it display the information interactively. As such, you can schedule the task and have the report emailed to you.
While the code below is definitely a “version 1” and it can use some improvements like error handling, I did not want to keep it from you. Over time – especially as AADSync gets new features – I will be adding new functionalities to this script as well.
You can use the script, as depicted in the following example. The script will create a filed called “AADSyncInfo.html” in the specified file path: