\>Get-CsJosh -Blog: July 2015

Wednesday, July 29, 2015

Exploring Azure AD Connect - Part 2: Configuring SSO with AD FS

Configuring Azure AD Connect with AD FS for Single Sign-On (SSO)

In the last post of this series I went over the basic, and fairly pain-free, process of syncing users and passwords from an On-Prem Active Directory environment to an Azure AD instance using the Express Configuration of Azure AD Connect. However, in some organizations, a requirement for single sign-on (SSO) may exist. After all, who wants to log into their laptop at the office, and then proceed to have to login to their O365-based OWA and SharePoint sites with the same credentials?! Not this guy.

Thus, a need for SSO exists, and Azure AD Connect can help meet this need by connecting to our Azure AD from our on-prem environment, setting up synchronization, AND installing and configuring AD FS. All this is done from the Azure AD Connect wizard, which is even more amazing. The wizard installs the needed pre-requisite software on the AD-joined server that you have set aside for Azure AD synchronization, and then proceeds to walk you through connecting to Microsoft Services Online (MSOL), following up with installing and configuring AD FS on the servers that you set up ahead of time.

Let's take a look at what this process looks like.

Office 365 Environment

I am using the same Office 365 tenant that I used in my first post, using only Skype for Business Online Plan 2 licensing. To clean things up, though, I uninstalled Azure AD Connect completely from the on-prem server, deactivated synchronization in the Office 365 portal (this can take up to 72 hours to take effect), and then deleted all users that had synced from the on-prem Active Directory from the last post. Per the last post, the custom domain "s4blab.org" is already setup in the portal, with all necessary DNS records having been created. Lastly, before getting stared, I navigated to the Active Directory synchronization line at the top of the Active Users page in the Office 365 admin portal, and clicked the Manage link button. From there, I activated AD synchronization by click the Activate button, as seen below:

On-Prem Lab Environment

My "On-Prem" environment is actually a virtual environment in Rackspace's Public Cloud. All servers in this environment are running Windows Server 2012 R2, and have been fully patched, and all are domain-joined (in a typical production environment, you would have your AD FS Web Access Proxy in a DMZ, not in the AD domain). The environment consists of:

1 Active Directory Domain Controller
1 small server for installing Azure AD Connect
1 AD FS server
1 AD FS Web Access Proxy server

Please note, for Azure AD Connect to be able to install the necessary AD FS roles on both the AD FS and AD FS WAP servers, you must enable Remote Management on these servers. You must also do this on the DC, if you plan to have the wizard automatically create a Managed Service Account in Active Directory.

Configure Synchronization with SSO in Azure AD Connect

First, you must download the Azure AD Connect tool onto the server that you have joined to the domain for establishing your hybrid synchronization scenario: https://www.microsoft.com/en-us/download/details.aspx?id=47594
After you double-click the Azure AD Connect installer, the first screen you will see will prompt you to agree to the terms. The next screen prompts you to either choose Express Configuration or Custom Configuration. We do not want Express, as we need to set up ADFS. So choose the Custom option.
The next screen asks what type of Synchronization we want. The first option will only allow for synchronization, but not SSO. Select the second option, Federation with AD FS, and then click Next.

Next, you need to input your Azure AD credentials. This should be an account within Azure AD that has the Global Admin role, and it should be the an account with a domain of "@domain.onmicrosoft.com"; DO NOT use an account with the same domain name as the AD domain that you are trying to set up synchronization for.
Next, input an account with Domain Admin privileges to connect to your on-prem AD. Once you have entered the credentials for the domain that is listed in the Forest box, click on Add Directory, and the domain will be added at the bottom.
On the Uniquely identify your users screen, leave the defaults, and click Next
On the Filter users and devices screen, you can either choose to Synchronize all users and devices, or you can specify a specific group in your AD that has the users that you want to synchronize. The second option is good for pilot environments, but to be perfectly honest, I was not able to get my environment to sync until I reconfigured the Azure AD Connect tool to Synchronize all users and devices. This is very likely a config problem on my part, but still, with no errors at all indicating a problem, either in the application or in the logging, I was not able to get to far on the troubleshooting.
For the Optional Features, simply leave the Password Sync radio button checked. In the below example, I also checked Password Writeback, but that does not need to be done for SSO purposes.
Now it is time to set up the AD FS farm. At the top of the AD FS Farm screen, you can choose to either Configure a new Windows Server 2012 R2 AD FS farm, or you can choose to Use an existing Windows Server 2012 R2 AD FS farm. Leave the default, which is Configure a new Windows Server 2012 R2 AD FS farm (Remember, we have a server ready for AD FS, but have not yet set up AD FS itself). Click the Browse button next to the CERTIFICATE FILE field, browse to your certificate with private key (.pfx file), enter the password for it, and click OK. You will now see the certificate's Subject Name below, and the new AD FS Service Name. Click Next.
Next, enter the server name in the Server field and click Add. You will now see a progress bar at the bottom of the screen as connectivity to the AD FS server is verified. If you have not ensure that Remote Management is enabled on this server, as mentioned above, this step will not work until you do so.
You can now see that the AD FS server was connected to and verified. Click Next.
Repeat the above step for the AD FS Proxy server, and then click Next.
Now you need to enter credentials that the Proxy server will use to request a certificate from the AD FS server. Once you do, click Next.
On the AD FS Service Account screen, leave the first option selected, Create a group Managed Service Account. Again, this will not work if you have not enabled Remote Management on the DC that you are attempting to connect to. Click Next.
Almost through the wizard! Now you are at the Azure AD Domain. Select the domain that you want to federate with from the drop-down. If you only have one custom domain added in Azure AD, then you will only have the one domain available in the drop-down. Notice the warning at the bottom, that current logons will get disrupted during this operation. Click Next.
Finally, the Ready to configure screen will give you a nice little summary of the actions that are about to be performed. Leave the box checked for Start the synchronization process as soon as the configuration completes.
A progress bar displays the Configuring progress. Here we can see where AD FS is being setup remotely via the wizard. SO cool!
After the AD FS portion is completed, we see that the synchronization is kicked off:
The last screen, the Verify one, prompts you to set up the necessary AD FS DNS records in both your internal and external DNS zones. I had already set up the records for the AD FS service URL, and thus I clicked Verify, successfully resolving the records. Once we close the wizard, we should be able to go into our Active Users page in the Office 365 portal and view all of our newly synced users:

At this point, we want to test our SSO capabilities. I temporarily set up one of the newly synced users, josh@s4blab.org, as a Global Admin, within the Office 365 Admin portal. When I browsed to https://portal.office.com, I get the typical Office 365 login page. After typing in the username and tabbing to the password field, however, I get redirected to my on-prem AD FS forms-based login page. Office 365 detected that the domain I was logging into was setup for SSO, and knew where to forward my users to. Very cool, and it also confirmed that AD FS was setup, functional, and reachable publicly.

After entering my password, though, and hitting Enter, I received a fairly generic error about not being able to be logged in: "Sorry, but we're having trouble signing you in. Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041034".

Well, I knew that the user had synced, cause I could see him in the portal. I knew that the AD FS sign-on page was reachable. I knew that AD synchronization with SSO showed as Activated in the portal. SO what was the problem?

Well, after digging into event logs (without finding anything helpful) and doing much research online, I finally discovered that there were some certificate issues within the AD FS Management console. The publicly-issued certificate that I provided during the AADC wizard was fine, but both the Token-decrypting and Token-signing certificates showed up as not Trusted when I viewed them within the console. To correct this, I performed the below actions:

On the AD FS server, navigate to AD FS Management console -> AD FS -> Service -> Certificates.
Highlight either the Token-decrypting or Token-signing certificate by clicking on it, and then click on View Certificate... in the Actions pane.
Once the Certificate window pops up, we see the ugly message below telling us that the certificate is not trusted. Click on the Install Certificate button.
On the Certificate Import Wizard, make sure to select the radio button next to Local Machine, and click Next.
On the Certificate Store screen, check the box for Place all certificates in the following store, and then click Browse...
In the Select Certificate Store popup window, select Trusted Root Certification Authorities, and then click OK. Click Next on the Certificate Store screen, and finish up the wizard.
You should then see the below popup telling you that the import was successful. Click OK, and then click OK on the Certificate window.
Now, you should be able to open the Certificate properties window again, and this time you should not see any unsavory message about the certificate not being trusted.

And that did it! I was now able to log in to the portal, while being redirected through my AD FS sign-on page, and was successfully authenticated. I am not sure if I just initially missed something when it came to the above issue with AD FS certificates, as I am sure the intended experience is for the Azure AD Connect wizard to handle the entire setup from one place, in a simple manner. However, for those of you that run into similar issues with trying to get SSO working with your directory synchronization, I hope the above helps you. Feel free to leave comments letting me know if this helped, or if you came across another piece of the puzzle!

The next and final post in this series will be going over some of the special features that can be achieved with Azure AD Connect if you have implemented the Azure AD Premium licensing for your users.

Stay techy, my friends!

Wednesday, July 8, 2015

Configuring Cloud PBX with PSTN Calling Preview

I am taking a little detour from my three-part series on Exploring Azure AD Connect because I received my confirmation email from Microsoft granting me access to the Preview program for Cloud PBX with PSTN Calling late yesterday afternoon. Needless to say, I was eager to get started, and I wanted to take a few minutes to share the experience.

First, let's take a look at a couple details of the program that I wanted to highlight:

I was curious how the pricing/licensing would work, and here is how it is set up for Preview. You get 100 licenses to assign to your users, during a 1 month trial of the service. You are not charged during that time, and as of yet, I have not seen how much one of these licenses will cost after the trial program.
The areas with available phone numbers are limited while the service is still in Preview. For example, I wanted to select a San Antonio, TX number, but the Austin (512) area code was the closest thing available.
The capabilities for assigning numbers and placing calls seemed to be present in the portal only a couple minutes after enabling them. However, in my experience, placing a call to or from the new number went through, but the call would disconnect upon being answered. This happened for at least an hour during testing last night, and when I tried the call again this morning, it actually went through and connected. So, it would appear that certain media settings are not fully in place after a successful setup, at least not right away, for some implementations. Matt Landis highlighted his experience on his blog, and it didn't appear that he ran into that at all.

So, now that we have gone over a few key points that I wanted to touch on, let's get to the process of setting it all up!

Once you get the confirmation email from Microsoft, you need to sign into your O365 portal, and then click on a link provided by Microsoft in the confirmation email. You will come to a Confirm your order screen in the portal, and will need to click Try Now:
Next, click Continue on the Order Receipt page:
Now it's time to assign a license to a user. To do this, we go to USERS -> Active Users, select a desired user, and then click Edit Properties from the list of actions on the right-side of the screen. On the user's properties screen, we will click on the Licenses tab on the left-side menu. In this view we will now see a newly available license above the already-assigned E1 license: "Skype for Business Domestic and International calling". Check the box next to this, and then save your changes:
Next we need to go to the Skype for Business Admin Center by navigating to ADMIN -> Skype for Business. Once there, click on the Skype voice tab in the left-side navigation menu NOTE: this tab may take several minutes to show up after enabling the Preview service).
As we can see in the above image, there are now phone numbers present yet. Click on the phone icon that is labeled "New numbers". We are now presented with a screen where we can specify the State, City, and number of needed numbers for the specified area.
Below, we can see where I have searched for a number in Raleigh (919) within North Carolina (Raleigh was the only location available within NC at the time). After clicking Add, if finds a new number for you. Once you get a number, you need to ensure that the checkbox next to it is checked, and then click Finish. (NOTE: while the below example shows a search for a NC number, I used an Austin (512) number for the rest of the demonstration)
After clicking Finish above, you will then see all your available phone numbers in the Skype voice screen. As you can see, the number is present, but it shows "False" under the Assigned field.
Now, click on the voice users (preview) link at the top of the screen. You will see the licensed user below. Once you check the box next to the user, the Assign number button becomes available on the right-side. Click it.
The next screen will display the below, which lets you know that you do not currently have a number assigned, but have the option to assign a number by clicking the Assign number button. This seemed slightly redundant to me, given the previous step, but I am sure there is a workflow purpose for this. Perhaps if you assumed that a number was already present, this display would not seem as redundant.
Once you click Assign number in the above screen, you are presented with the available numbers to assign this user. Select the appropriate number, and click Save:
Finally, back on the voice users (preview) screen, we see the users that have been enabled for Cloud PBX with PSTN Calling, and the assigned phone number. Beautiful!
Now that we have assigned the number, let's get logged into our Skype for Business client. Once we do, we can see the dialpad is present in the client, just like you would expect to see for Enterprise Voice users in an On-Prem deployment of Skype for Business Server 2015:
Lastly, we can dial a phone number within client, and hit Call. As you can see, it begins dialing the user, in the normal A/V window that you would expect to see for an Audio call:

As I mentioned earlier, when I first tested the call, it successfully rang through to my cell phone, but when I answered the call, it disconnected, and the media never connected. This happened repeatedly during my first hour of testing, BUT, it worked right away this morning, with the call connecting successfully. It was awesome! Apparently, once in a while, the new settings may just need a little time to bake and then cool down.

Once the call was connected, clicking on our Call Controls button in the bottom-right corner shows that can put the call on Hold, Transfer it, and control volume.

Finally, this service also allows for Call Forwarding, and Simultaneous Ring. I tested both, and they worked like a charm!

Well, I am looking forward to playing with this a bit further, but this functionality is huge. A definite game changer for businesses that are trying to decide where to consolidate their internal communications systems. I strongly recommend digging into the Preview program, exploring the service a bit, and I am excited to see this service come to GA!

Stay techy, my friends!

Tuesday, July 7, 2015

Exploring Azure AD Connect - Establishing Synchronization with Express Configuration

Exploring Azure AD Connect - Part 1: Express Installation

Hello Unified Communications (and Office 365) enthusiasts! With the launch of General Availability for the new Azure AD Connect for Office 365 by Microsoft recently, I wanted to dig into this awesome new tool in a three-post series. For those that are not yet aware, AAD Connect is the latest version of what was DirSync, and the new features allow for a much more fluid and fully-connected hybrid environment. Check out this Office Mechanics segment to see what's new with Azure AD Connect:

This first post is going to focus on connecting an Office 365 environment with an On-Prem environment using the Express Installation. Before we dive straight in, let's take a second to talk about what our environment actually looks like.

Office 365 Environment

Rather than using a full-blown Office 365 suite, I am working with only Skype for Business Plan 2 licensing. To start with, I have a single admin user: admin@skype4businesslab.onmicrosoft.com. I have also added a test domain in called "s4blab.org", and setup all necessary DNS records through the Domain Add wizard within the Office 365 portal. Awesome!

On-Prem Lab Environment

My "On-Prem" environment is actually a virtual environment in Rackspace's Public Cloud. So far, the environment consists of:

1 Active Directory Domain Controller
1 Exchange Server (setup for later Demo of Exchange On-Prem to Skype for Business Online Hybrid configuration; stay tuned!)
1 small server for installing Azure Active Directory Connect

We will be expanding that a bit for ADFS in the other posts later in this series. So, let's get started with how to set this up!

Configuring Azure AD Connect: Express Installation

First, get familiar with accessing your Azure AD. From within the Office 365 portal, on the left-side menu, navigate to: ADMIN -> Azure AD
Once you have set up your profile for accessing Azure AD, you will see the below screen. As you can see, with Active Directory highlighted on the left, we can see that we have one directory currently setup, named "The MS UC Guy". This is the directory that was created with our Skype for Business Plan 2 subscription.
Click on the name of your existing Azure Active Directory, Once you do this, you will see where you can manage your Users, Groups, Applications, Domains, Licenses, Reports, and Directory Integration! Click on Directory Integration, and you will see that Directory Sync is currently Deactivated, but that there are a series of steps to complete. First, since we have already added our "s4blab.org" domain, we go to Step 2, where we see we need to toggle the setting to "Activated".
Once this is done, We go to Step 3, where we are instructed to download the sync tool. DO NOT DO THIS from this area in the portal (at the time of this posting, anyway), as the sync tool available for download is not the new and improved Azure AD Connect. Instead, you can download the new tool from here: https://www.microsoft.com/en-us/download/details.aspx?id=47594
Once you have downloaded Azure AD Connect onto the VM in your On-Prem lab, double-click it to get started. You will have to agree to the license terms, etc, on the first screen, and then you will see the below screen after clicking Continue:
After clicking on "Use express settings", you will briefly see the wizard install other required components before bringing you to the Connect to Azure AD screen. At this screen, you need to input credentials with Global Admin access to your Office 365 subscription. I would advise using credentials that are setup as such: admin@yourdomain.onmicrosoft.com, I tried using credentials from the domain that I was about to sync (@yourdomain.com), and I received an error about the account being in the same forest.
The next screen is where you input your Domain Admin credentials for your On-Prem Active Directory environment. These creds will obviously be from the domain that you are attempting to sync to Office 365.
Finally, you are presented with the Ready to configure screen. This screen reviews the actions that are about to be taken, allows you run the sync after installation is complete via a checkbox, and then lastly offers a checkbox for you to specify whether or not this is intended to be an Exchange Hybrid Deployment. This would be that I intended to have Exchange accounts both within Office 365, AND On-Prem. Since I do not intend to do that (remember, I only have Skype for Business Plan 2 licences at this point), I will leave it in the default un-checked state, and then click Install:
At this stage, several components get configured, and the screen updates you as it installs and configures each component:
Lastly, the wizard reports that configuration is complete, and it instructs you to log into Azure AD to check on the status of the synchronized accounts. You can now click Exit.

At this stage, the Azure AD Connect wizard is complete, all required components have been installed on-prem, and we should now be able to go into Office 365 to check on the status of our Synced accounts. Below, while in USERS -> Active Users within the Office 365 portal, you can see a few users that I created in my On-Prem environment (marked by the orange arrows). These users also have a Status of Synced with Active Directory. Respectively, we have Captain Awesome (captain.awesome@s4blab.org), Josh B (josh@s4blab.org), and Princess Toadstool (princess.toadstool@s4blab.org). You will also notice a good handful of Exchange-related accounts that were synced, and finally the "On-Premises Directory Synchronization Service Account" that was created by this process.

Also, if we go to our Azure AD portal, we can now see that our last sync was less than an hour ago, that Synchronization is Activated, and that we are good to go.

It is important to note, at this point, that while we have synced our AD, we have NOT enabled Single Sign-On (SSO). We have simply made it so that our usernames and passwords that lived on-prem are now synced to Office 365. Those users can now be assigned Skype for Business licenses (or whatever other Office 365 licenses we might buy), and can log into a Skype for Business client using the same credentials that they log into their on-prem resources with, like an Exchange mailbox, or their desktop.

Stay tuned for further exploration of the Azure AD Connect tool, including SSO capabilities, and it's awesome new Writeback features!