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
Microsoft recently released to GA (Generally Available) Azure AD Connect which is a much simplified installation and replacement for DirSync and Azure Active Directory Sync Services. Under the hood, it’s the same as Azure Active Directory Sync Services except it improves the installation experience. For an introduction to Azure AD Connect and why you might want to use it, give this place a visit.
I thought that, since I’ve already done a series on Azure Active Directory Sync Services, I’d simply show the process to upgrade from Azure Active Directory Sync Services to Azure AD Connect. It is pretty idiot proof so let’s get to it.
First, download Azure AD Connect. Once you’ve downloaded it, copy it to the server that is currently running DirSync or Azure Active Directory Sync Services and double-click it.
Continue reading Upgrading to Azure AD Connect from AADSS
This is my latest effort in an attempt to offer myself slightly more robust backups of my personal website. I’m using PowerShell and Azure PowerShell to automate the process of zipping up a folder (actually my website’s application folder) and its associated MySQL database in to a zip file and finally, as well as storing the zip locally on-disk (yes, I know!…. wait for it!) uploading the file to Azure Blob Storage. Using some new functionality in .NET Framework 4.5 (zip files, yay) and Azure PowerShell to get the job done.
Here’s a quick snippet from the script:
Send-FileToAzureBlob -AzureStorageAccountName $StorageAccount -AzureStorageContainer $StorageContainer -FilePath $BackupDestinationLocation$ZipFileName -BlobName $BlobName
I also ensure I’m optimising my use of Azure Storage by only retaining the latest 4 files in the target container and deleting anything older than 30 days on the local machine. Run once per week, this will give you one month’s worth of backups and help you sleep a little easier.
Even without the MySQL dump integration, this is a handy script for backing up a folder and all of its child contents then uploading it for safe keeping to Azure Storage…. Continue reading Automating upload to Azure Blob Storage
In the previous posts in this series we went through the process of creating a cross-premises Site-to-Site VPN with Azure by gathering some information about our local network, configuring the Azure Virtual Network and gateway and finally configuring VyOS so that the tunnel connected.
Now that the cross-premises tunnel is connected, in this post we’ll run through the process of creating a Virtual Machine in Azure which will reside in the Virtual Network we created in part 2. Before we start, our current network looks as follows (no VM in Azure).
Continue reading Configuring Azure Site-to-Site connectivity using VyOS Behind a NAT – Part 4
In this, part 3 of the series, we’ll implement the configuration required for VyOS to enable it to become a VPN endpoint with which we can connect to our Azure Virtual Network Gateway to form our Site-to-Site VPN.
If you still haven’t, consider reading part 1 and part 2 of this series to provide the background of our modest network and how we configure Azure to create its side of the VPN cross-premises connection. As a reminder, our network configuration looks as follows (no tunnel and no Azure VM yet).
Continue reading Configuring Azure Site-to-Site connectivity using VyOS Behind a NAT – Part 3
If you haven’t read part 1 of this series, please review that before proceeding here. In part 1, I describe the network that we are starting with (mine) and how it is configured to enable routing across a virtual software router called VyOS between a home lab (a Windows domain called transishun.local) hosted in VMware ESXi 5.5 and my main “everyone’s phones are on it” network – I’ll call this the DMZ from here on. I also mention that my primary “edge” router is an off-the-shelf type on which I have installed DD-WRT which adds capabilities that permits it to perform source NAT for more than just the primary network, thereby avoiding double-NAT (bleugh!). If that’s something you’re interested in doing for yourself, it’s educational and I’m always here to answer questions should you feel the need.
As a reminder, here’s the current network before we do anything in Azure.
Continue reading Configuring Azure Site-to-Site connectivity using VyOS Behind a NAT – Part 2