Microsoft recently made Azure AD Connect generally available and in doing so introduced a method for filtering users based on their membership in a specific group. Unfortunately, this is considered a pilot mode for Azure AD Connect – this means that if you wish to permanently filter objects based on their group membership, you’ll forever be in pilot mode. Another caveat is that you cannot change this group easily. You would need to remove Azure AD Connect and re-install it to select a different group. Indeed if you upgraded from Azure Active Directory Sync Services as I did, this option is completely unavailable to you unless you’re willing to remove and re-install Azure AD Connect.
The reason, as far as I can ascertain, is that there is no attribute of a user object that looks like memberOf on which you can perform some logical decision with the Synchronization Rules Editor.
So how do we filter? There are three methods: Domain, OU and Attribute. In my getting started with Azure Active Directory Sync Services series earlier this year, I showed how to do both of these. The first, Domain, is the obvious one. If you want objects from a domain, you would attach to it during installation. The second, OU, is buried a little deeper inside miisclient.exe but it’s something I’ve demonstrated already in my getting started guide, so I’m not going to cover old ground. The third, Attribute, is what this post is about.
When I say user attribute, what do I mean? These:
Simply put, we’re able to filter objects that are to be synchronised with Azure AD using these attributes. I’m going to demonstrate how users can be filtered in the following steps and I’m also going to demonstrate a method of using PowerShell in conjunction with the attribute filtering rule to enable the use of group membership to identify who should get an Azure AD account – pseudo group filtering. Continue reading Filtering objects from Azure Active Directory
In my last mammoth post, I posted an update/re-write to an article originally written on the Azure website that used some libraries provided by Microsoft to enable custom PHP applications to sign-on to Azure AD using WS-Federation. In that post I described a method for installing and configuring SimpleSAMLphp to IIS that enables it to be used by any number of sites on the same server, all that’s required is to add a simple Virtual Directory to each site. If you want to configure SimpleSAMLphp on IIS, check that post out.
The intention with this post is to do away with Microsoft’s libraries altogether and use only SimpleSAMLphp in a more integrated way. The purpose is to avoid having to re-write a lot of functionality already provided by SimpleSAMLphp that’s likely to be missing from Microsoft’s libraries, and of course open up access to SimpleSAMLphp’s documented API.
I will assume you have configured SimpleSAMLphp already using the method documented in the last post. In order to proceed in this post, you also need to have configured an application within Azure Active Directory. Again, you can find instructions for that included in the previous post.
The largest difference with this post is, as I mentioned, better integration with SimpleSAMLphp – as such, there’s more configuration to complete within SimpleSAMLphp than there was in the previous post.
- We’ll import federation data from our Azure application in to SimpleSAMLphp.
- We’ll configure SimpleSAMLphp as a Service Provider.
- We’ll create a little code to get us authenticating.
Continue reading Single Sign-on to Azure AD using SimpleSAMLphp
So, what’s this massive post about? I recently read an article on the Azure website about using Azure AD authentication with bespoke PHP applications. While the article is quick and concise – it has a number of serious issues.
First and foremost, the end result is that the solution just doesn’t work. It obviously took the writer a good amount of time to write the code for the article (assuming he did that is) but despite that, it has suffered from bit rot and a lot of people have tried and failed to use the article as a learning tool.
I’d still suggest using the article as reference material – everything has its value at the end of the day but if you do actually want custom PHP applications with Azure AD authentication to work, that article won’t give you a working solution. I’ve re-written the article and explained a few more of the concepts and expanded on a few decision points that are useful to the reader while doing battle with the code and its bit rot.
As per the original article’s introduction:
This tutorial will show PHP developers how to leverage Azure Active Directory to enable single sign-on for your own custom PHP applications. You will learn how to:
- Install and configure SimpleSAMLphp on to an IIS web server.
- Obtain and edit the necessary sample code associated with the original article.
- Create and configure a custom Azure application inside Azure AD.
- Protect the application (err, page) using WS-Federation.
- Demonstrate actual authentication with Azure AD as well as federated authentication with an on-premises domain via Azure AD.
Continue reading Single sign-on with Azure AD in PHP