We wanted to integrate our existing Active Directory setup with our Azure hosted Rock RMS install. This seemed troublesome, but wasn't more than a day's work once we figured out how to do so. With these steps, hopefully it's even faster for you!

Your setup may vary, but here is where we found ourselves to start:

• Local Active Directory server (on premises) running on Windows 2016 with a functional domain level of 2008R2
• Azure hosted Rock RMS install (on cloud) running on Windows 2016 VM
  

You can go about this a couple of ways.

The Quick and Dirty

One possible way is to open up ports TCP ports 636 (used for encrypted traffic) and TCP 389 (used for unencrypted traffic) on your firewall and send them to your on-premises AD server. Don't worry about 389 being unencrypted. You will want to open it up still. No important data is sent over that port as Rock uses 636 primarily, but if you don't have 389 open, it will try it first, time out, and slow down the entire communication.

If you go this route, you will want to craft your firewall port forwarding rule in a way that ONLY permits this traffic from your Azure VM hosting Rock's IP address. This pinhole approach provides some security, is the easiest way to do this, but isn't exactly secure. And the bigger downside is that any time you reboot your local AD server (software updates, maintenance, power outage, etc) or if your local internet goes down to that on-premises server, no users using Active Directory to login to their Rock accounts will be able to do so. Your local server becomes mission critical for logins to the cloud based resource. Again, not ideal. And even if you have multiple local AD servers on site for failover, they won't help here as your firewall can only port forward to one of them. So you have no redundancy for Rock, even if you do locally.

A Better Way

We will configure our Local AD to replicate to Azure AD in the cloud, and authenticate users against that instead. This will allow our local AD to have downtime without affecting Rock user logins, is a more secure method as our Local AD server is still fully firewalled, and our local internet/server status doesn't affect Rock users trying to authenticate.

Step 1:
First we need to make sure we have proper User Principle Names (UPN) for syncing to Azure AD. A lot of Local AD servers (especially those from many years ago) were set up with a domain of NAME.local instead of NAME.com or whatever your domain extension really is. The problem is that .local names can't sync across the internet since they are totally unregulated and unauthoritative (more than one person can have Google.local if you really wanted to). So to sync with Azure AD, you must have your Local AD users set with proper UPNs.

Let's check if you have .local names or not. Check a user in your Local AD "Users and Computers" program. Click Properties on a user, then check the "Account" tab to see if their login is set as their username at your actual domain name's extension, or at a .local domain. If there are no .local names and/or if this isn't a dropdown that even has a .local option, then skip to step 2. If not, we need to change this.

You can do this in one of two ways, one of which is super long and complicated (re-address your server to not use .local at all), and the other is by adding a UPN Suffix and using a powershell script to update your users. Let's go with that. Here's a great article detailing how to add the UPN Suffix, and then how to run the powershell script to update your users. Keep in mind, with the powershell script, capitalization matters! So if your current setup is CoolChurch.local then make sure to capitalize those C's in the script or it won't update them.

https://support.office.com/en-us/article/how-to-prepare-a-non-routable-domain-such-as-local-domain-for-directory-synchronization-e7968303-c234-46c4-b8b0-b5c93c6d57a7

Now that you've done that, you can verify it worked by checking a user in your Local AD "Users and Computers" program. Click Properties on a user, then check the "Account" tab to see if their login is now set as their username at your actual domain name's extension, not your .local domain. If it still shows .local, check your powershell script for errors and try again. If you can't get that to work, you can always open each user manually and change their account dropdown accordingly. The powershell script is just a quick fix for those who have a lot of users.

Step 2:
As recommended by Azure, we need to clean up our local data before syncing it. You can do this with IdFix which is a tool provided by Microsoft. Check out this article on that and other pre-reqs you should read through to make sure you don't see any other red flags:

Info: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites
IdFix: https://support.office.com/en-us/article/install-and-run-the-office-365-idfix-tool-f4bd2439-3e41-4169-99f6-3fabdfa326ac?ui=en-US&rs=en-US&ad=US
IdFix How-To: https://support.office.com/en-us/article/prepare-directory-attributes-for-synchronization-with-office-365-by-using-the-idfix-tool-497593cf-24c6-491c-940b-7c86dcde9de0

Note that you WILL HAVE a LOT of errors in IdFix when you have a .local UPN on your server (roughly one per user). If you followed step 1 fully and set up a UPN Suffix and moved all users to have it as their primary, you should be fine to ignore the "Top Level Domain" errors that IdFix shows. But pay attention to any others about duplicates or other issues and resolve them accordingly. You will probably only have a couple or none at all. You can sort the errors by error type by clicking the error label at the top of the column.

Step 3:
It is recommended you set up the Active Directory Recycle Bin prior to syncing with Azure AD. This is an irreversible change and is disabled by default. To enable it as recommended, follow the instructions found here:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd379481%28v%3dws.10%29#enabling-activedirectory-recycle-bin

We had far more luck with the powershell script than the Ldp.exe method, though I'm sure either can work.

Step 4:
Now that your data is clean and in the right format to sync, log into your Azure portal and search for Azure Active Directory. In there, click on "Custom Domain Names" on the left. You'll see a default domain of your username.onmicrosoft.com. Let's add your actual domain here. So click "Add Custom Domain" at the top and go through the prompts to add CoolChurch.com or whatever your domain is. Now click Verify and it will tell you how to verify your domain. You need to do this. We verified ours by creating a txt record on our DNS registrar for CoolChurch.com as the prompts suggest. This can take 48 hours to propagate the interwebs so Azure sees it. Ours with NameCheap.com as our host, only took about 30 min. Keep trying periodically until verification succeeds on Azure. Once your domain is verified, set it as the primary by clicking that link.

Step 5:
Now we are ready to sync our data to Azure AD from our Local AD. Download the Azure AD Connect tool: https://www.microsoft.com/en-us/download/details.aspx?id=47594
and follow the instructions for the express installation here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-express
If all goes well, you will see a screen showing your CoolChurch.local domain saying "not added" and your CoolChurch.com domain showing "verified" and there will be an error saying "Users will not be able to sign-in Azure AD using their on-premises credentials." You can ignore that. It is talking about the .local ones and we already knew that. The other one showing "verified" will work.

For more info or for those with different AD setups involving more complications, read more here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect
If you really want to nerd out, there is an hour long demo video at the end of the article walking you through the process and what is going on in the various scenarios.

Also note, in this step, I ran into complications with my credentials connecting to Azure AD. Despite using the exact same ones I used to create my Azure account, it kept failing verification. Microsoft has a strange mix of "personal" and "work or school" accounts and both are called "Microsoft Accounts" so if you have Windows 10 with a Microsoft account, or other products... you may be in my boat of mixed up madness. I couldn't figure it out, it wouldn't let me reset my "work" password and it wouldn't work with the "personal" one, though the "personal" one is what I used to log into Azure portal... long story short, I created a new user in the Azure AD portal named AzureAdmin and gave it a secondary email address that routed to me as well. I then assigned it "Global administrator" rights under the "Directory Role" of that user. If you need to, here's how:

• Log into Azure portal and search "user" up top and click on Users when it appears
  
• Click "new user" and create whoever you want and note the password it gives them. Set their email as something you get as well (like a secondary address that routes to you still).
• Click on that user and pick "Directory Role" on the left and assign "Global Administrator" rights.
• Log in as that user with the password they gave, it will prompt you to set a new password. Set a good one.
• Use those credentials (your new user's email and password you just set) to authorize the Azure AD Connect tool to connect to Azure AD.
  

Step 6:
Now that the above tool has synced your data, you should see your users in the Users section of your Azure AD. Huzzah! Grab a snack in celebration.

Step 7:
By default, hashed passwords are shared with Azure AD, but this wasn't enough for our Rock to allow logins. This meant we had to run a quick powershell script to push hashed NTLM and Kerberos passwords as well. Use the powershell command (copy and paste it into a text editor for now) here: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started-password-sync-synced-tenant and replace the and the sections with your info. What is your info? glad you asked. To check that go to start > azure ad connect > synchronization services. This program wouldn't run for me on my local server credentials... so I had to right click it and "run as user" and give it a domain admin that had rights to the ... universe.

Once in that program, click on "Connectors" up top. These are your connectors you need for the previous powershell script. You can right click one and pick properties and copy/paste the name into your text editor where you are staging your powershell script. Now that your script is ready, copy it, open Powershell as an admin, and right click in the window to automatically paste/run the script... except for maybe the last line which you have to manually press enter to run...

Further troubleshooting if you are stuck here: https://blogs.technet.microsoft.com/canitpro/2016/07/14/step-by-step-enabling-azure-active-directory-domain-services-password-synchronization/ This article has some other scripts and screenshots that may help you sort out things.

Step 8:
Now let's set up Azure Domain Services. Check out this article here: https://community.rockrms.com/recipes/92/using-office-365-azure-ad-accounts-for-rock-authentication
When it says on step 4 to make sure you add yourself to the AAD AD Administrators Group, don't miss it! Click on that group and it will say there is no one in it. Add yourself and/or your new AzureAdmin if you had to make one above... Note that when you hit OK and it starts making the Domain... this can take a LONG time. Mine took 30+ min to just create, and then though it said it was complete, other screens still said it was in process and such and it took another 60+ before it was truly done. Go take a long lunch.

Step 9:
Now you are all locked and loaded in the cloud. Let's tie Rock in! We're almost done!

Once the deployment is REALLY finished (like seriously, maybe catch a movie and come back), click on the new Azure AD Domain Services resource (or search for it) in the Azure portal and click on the "Properties" button. It should show the "IP Address on Virtual Network." Copy that IP address down. Log into Rock RMS, click on Admin Tools -> Security -> Authentication Services -> Active Directory. Paste the IP you just noted into the Server field. Your Domain field will be your CoolChurch.com domain name you used on Azure. Click the "Active" checkbox. Hit OK!

Step 10:
Let's set up a Rock user to authenticate with Azure AD. This is the payoff! Go to a person's record and click the Security tab. Make sure they have whatever Security Role you want for them. Click to Add a User Account. Choose "Active Directory" for the "Authentication Type" and type in their username in the User Name field. If your AD user was JohnD@CoolChurch.com then you can use JohnD here and it should work. It shouldn't be case sensitive either. Log out and log in with "johnd" and the user's password.

How'd it go? Success? I hope so. Celebrate with a quick jig. You are a local hero. ;-)