Configuring the Windows Web Server role and assigning a certificate

I’ve detailed the different Office 365 Identity options previously. I’ve also detailed how to install Azure AD Connect (which replaces both Azure AD Sync and DIRSYNC) and why it is necessary for both synchronised and federated Office 365 identities.

What I plan to cover in upcoming articles is how to establish federated identities (i.e. ADFS) for Office 365. I’ll break these down into a number of posts and then bring everything together as a single point of reference at the end.

This post will take you through the initial process of configuring the pre-requisites on the ADFS server. This means installing the Windows Server Web Server role and assigning a certificate to this Windows Web Server.

Prior to the steps here, I already have established a domain controller (DC) on the network. The local domain is called kumoalliance.com I have already successfully installed and configured Azure AD Connect on this DC. I am successfully synchronising user information from the local Active Directory (AD) to Office 365 via Azure AD Connect. I have also installed and configured the custom domain kumoalliance.com into my Office 365 tenant. This ensures that the UPN of the local AD matches those in Office 365. I have also assigned the appropriate Office 365 licenses for active users.

I have also added a separate member server (called CIAOPS365-ADFS) to this domain that will function as the ADFS server. I am now ready to configure the pre-requisites for ADFS which is the Windows Web Server role and an SSL certificate. The Web Server on this machine will be configured to respond to the URL https://adfs.kumoalliance.com for clients on the local network. Clients outside the domain (i.e. external) will use an ADFS proxy which will be configured later on after the ADFS server has been configured.

Launch the Server Manager Dashboard as shown above.

In the top right hand corner select the Manage menu item and then Add Roles and Features from the menu that appears.

This will launch the Add Roles and Feature Wizard as shown above.

Select Next to continue.

Ensure that Role based or feature based installation is selected, then select Next to continue.

Select the ADFS server name from the list of servers displayed. Typically, that should be the only server that appears. Select Next to continue.

Scroll down the list of roles until you locate Web Server (IIS) and select this.

This will pop up a dialog shown above. No configuration is required, so simply select the Add Features button to continue.

You’ll be return to the list of roles and you should now see that Web Server (IIS) is selected as shown above. Select Next to continue.

No additional options need to be made. Select Next to continue.

Select Next to continue.

No additional options need to be made. Select Next to continue.

Select the Install button.

The wizard will now install and configure Internet Information Services (IIS) on the server. This process should only take a few minutes and not require the server to be rebooted.

Ensure the installation process completed successfully then select the Close button to complete wizard.

In the top right of the Server Manager Dashboard you should see a message flag. if you select this you should receive confirmation that the Web Server role has been successfully installed.

In the Server Manager Dashboard, select the Tools option in the top right and then Internet Information Services (IIS) from the menu that appears.

Select the server name in the right pane. Then from the icons in the middle pane double click Server Certificates.

In the top of the right pane select Create Certificate Request.

Use the FQDN of the server (i.e. adfs.kumoalliance.com) as the Common name.

Complete the remaining fields with the information from the organisation. Select Next to continue.

Leave the Cryptographic service provider set to Microsoft RSA SChannel Cryptographic provider. However, ensure that the Bit length is set to 2048.

Select Next to continue.

Enter a file location to write the server key and select Finish to complete the process.

If you look at the file created you should see that it is simply a text file like that shown above.

You now need to take that certificate request information to your certificate provider and use it to request a certificate.

In this case I am using Digicert which allows me simply to copy and paste the text from the server certificate request directly into a web page, nominate which web server it came from (in this case IIS 8.0) and complete the certificate request.

In short order, you should receive confirmation that the certificate has been approved and in this case I am sent the certificate files as an attachment.

Copy the certificate files to the server and check to see that the files include a .CER file, which is the actual certificate.

Return to to the IIS Manager and in the top right now select Complete Certificate Request.

Provide the location to the certificate file received from the certificate authority in the first field.

For the friendly name enter the FQDN of the server (here adfs.kumoalliance.com).

Leave the certificate store as Personal and select OK.

When this process completes you should see the new certificate listed as shown above.

On the left hand pane of the IIS Manager, drill down and select Default Web Site.

Now on the right hand pane select the Bindings option towards the top.

Select the Add button in the top right of the dialog that appears.

Change the Type field to https.

Leave the Host name field blank.

In the SSL certificate area select the certificate that was added from the certificate authority (here, adfs.kumoalliance.com). Then select OK to complete the configuration.

You should now see an entry for https on port 443 displayed in the bindings as shown above.

Select the Close button.

You now need to create an entry in the DNS for the local domain so that requests to https://adfs.kumoalliance.com will be directed to the web server on this machine.

Open DNS management on the domain controller. navigate to the Forward Lookup Zones for the local domain (here kumoalliance.com).

Right mouse click on an empty location in the right panel and select he option to Add a new A record.

In the name field enter the first part of the common name you used when requesting the certificate (here adfs). The local domain will be appended to this name to create the FQDN of the server (here adfs.kumaolliance.com). This needs to generally match the common name on the certificate generated from the certificate authority.

Enter the IP address of the ADFS server on which IIS has just been installed. Then select Add Host button to complete the process.

To ensure everything is working as expected try and ping the FQDN of the ADFS server (here adfs.kuoalliance.com). You should receive a resolution to the IP address of the ADFS server, although the actual ping may time out due to firewall configurations. The important thing is that the name is resolved to the IP address of the ADFS server.

If that is successful, open up a web browser on the domain controller and navigate to the FQDN of the ADFS server (here https://adfs.kumoalliance.com) . Ensure you use https to verify that SSL and the certificate are operational. If they are you should be greeted with the default IIS web page as shown above.

If you then examine the certificate you should be able to verify that it is valid and issued by the certificate authority you used above.

Now that a secure Web Server has been configured on the ADFS machine, the next steps is to add the ADFS role to this same server. This will be the subject of an upcoming post so stay tuned.

Office 365 Identity options comparisons

Office 365 has three basic identity models that you can elect to implement. Each model uses a combination of Azure Active Directory for cloud based identity and Windows Server Active Directory for on-premises identity. The cloud only model for example, only uses Azure Active Directory (AD), while the synchronized identity model combines both Azure AD and Windows Server Active Directory, while the federated model solely uses on premises Windows Active Directory. Each has advantages and disadvantages which we’ll now cover.

The most basic identity model is the cloud only identity. This is where a users identity information is managed, maintained and mastered in Office 365. All changes need to be made to user information via the Office 365 admin web portal. The benefit of the cloud only model of identity is that no on-premises equipment or configuration is required and can therefore be accomplished anywhere access to Office 365 is available either via a browser or PowerShell. The disadvantage is that a user may require different credentials to login to their desktop, other cloud services and Office 365. This means, in essence, there is no single sign on (SSO) with the user having to remember the login for each service.

The next identity model is what is known as synchronised identity. Here user properties such as name, email address and so on are copied (or synced) from a local directory (typically Windows Active Directory) to Office 365. This is accomplished through the use of synchronisation software which today typically means Azure AD Connect.

There have been a number of iterations of this synchronization software which initially started life out as DIRSYNC. The problem with DIRSYNC was that although it could copy user object information it could not copy the users password from on-premises to Office 365. This meant that the password would have to be manually set in Office 365 to match the password on-premises. Thus, with DIRSYNC it was entirely possible for on-premises password to differ from Office 365 which was very confusing for users.

The next iteration of the synchronisation software was called Azure AD sync. This included all the features of its predecessor, DIRSYNC, but now incorporated the synchronisation of secure password hashes.

This meant that now not only was a users details synchronised from on-premises but so was an encrypted version of their password. With Azure AD sync in place users on-premises password was now automatically replicated in Office 365.

The current iteration of the synchronisation software is called Azure AD Connect and brings all the benefits of Azure AD Connect but with additional features to allow things like the integration across multiple Active Directory Forests, integration with other third party directories on premises as well as better integration into the cloud.

The synchronised model copies the users details and password hash to Office 365. It however, is not a bi-directional sync, Azure AD Connect (and the previous synchronisation tools) copies from on-premises to Office 365, over writing anything that may already exist there. They do not copy back from Office 365 to a local directory.

The synchronised model requires synchronisation software to be running on a server in the local network. Best practice is to run this synchronisation software on a member server but Azure AD Connect does support being installed on a domain controller while previous versions of sync tools did not.

See my previous articles on installing the various sync tools:

Azure AD Connect tools – the basics –https://blog.ciaops.com/2015/07/azure-ad-connect-toolthe-basics.html

Azure AD Sync Services tool – the basics –https://blog.ciaops.com/2015/06/azure-ad-sync-services-toolthe-basics.html

Windows Azure Active Directory Sync tool (DIRSYNC) – the basics – https://blog.ciaops.com/2013/10/windows-azure-active-directory-sync.html

The final identity model extends on the synchronisation model by adding Active Directory Federation Services (AD FS) to establish a trust between on premises AD and Office 365. This means that when a user requests an Office 365 services, Office 365 queries the local AD via AD FS to confirm the provided user credential. If the local AD confirms the identity a security token is passed back to Office 365 authenticating the user identity so that Office 365 can then allow the user access to the services.

A federated identity model requires the installation of an AD FS farm on premises, which is a role available on a Windows Server. This farm must be installed on member servers within the existing network. AD FS also requires third party certificates to be installed and maintained. Also, if the business requires users to roam outside the organisation and continue to access Office 365 it will also need to install a secure AD FS proxy farm to handle these external requests from outside its network.

Thus, if a user inside the network needs access to Office 365 services they are authenticated via the internal AD FS and the local AD. If an external user needs to access Office 365 services they do so via the AD FS proxy, which connects securely to the internal AD FS server and then to the local AD.

The challenge with federated identity is that the local AD, AD FS farm and AD FS proxy farm need to be available at all times to provide authentication. If they aren’t then no user login to Office 365 is possible because Office 365 can’t verify the identity of any users because it can’t access the local AD. Best practice is therefore to install these in a load balanced environment which means multiple servers.

The advantage that federated identity provides is that once users are logged on to their local AD they are not prompted again for separate Office 365 credentials. Because Office 365 has established a trust with the local AD, all Office 365 services are provided by credential pass through. This basically means a user isn’t prompted to access Office 365 because they have already logged into their local AD and Office 365 already trusts this. This provides users with a single sign in (SSO) experience.

Each of the models can easily be incorporated into any Office 365 but the most cost effective solution for environments with an existing AD infrastructure is the synchronised model as it generally does require the additional equipment that the federated model does.

You should therefore select the simplest Office 365 model for your needs. It is also possible to change between the models if required but getting it right up front can save a lot of extra configuration down the track. So plan your Office 365 identity requirements early and provide the best login experience for your users.

Connecting Cortana to Office 365

Using speech to interact with technology is not only cool but it can also be very productive. It is generally much quicker to record a voice message than write something down or send an email. With that in mind, and the enhanced abilities of Cortana we are seeing in Windows 10, it make sense for all this to connect up to Office 365 as well.

To start with you are going to need to have a Windows 10 machine and Cortana already configured on your machine.

An Office 365 administrator will need to login to the admin center and select Cortana from under the Service Setting on the menu on the left. They will then need to ensure that Manage access for Cortana on the right is set to On.

On a Windows 10 machine with Cortana already configured simply click into the search box to ‘wake up’ Cortana. Doing so should reveal something like you see above.

If you now select the second icon under the hamburger menu on the left (i.e. the one under the Home icon) you should a list of configuration options for Cortana as shown above.

From here select the Connected Accounts option.

At the moment the only option that is available is Office 365 so select this and set it to On.

You should now see the option as On.

To actually use Cortana with your Office 365 information you’ll need to configure your Office 365 account in both the native Windows 10 email and calendar apps. You do this simply by adding the account and selecting the Office 365 option as shown above.

With all this connected up Cortana has access to your appointments and will prompt you when meetings are scheduled. You’ll also be able to make appointments and do other helpful things all thanks to the wonders of Cortana.

The power and integration of Cortana will continue to grow in both Windows 10 and Office 365, so remember this is still early days. However, I see speech as key technology going forward that is going to make using technology much easier for the average user. So jump on board today, configure Office 365 with Cortana and prepare for the future.

Need to Know podcast–Episode 90

I’m joined again by Jeff Alexander from Microsoft to continue our discussions around Windows 10. Jeff is back from Seattle with all the latest news about the deployments and we dive deep into the Windows as a Service offering and differences it will bring. We also talk about Windows 10 Office apps and getting Windows 10 connected to Server 2012 R2.

If you missed the previous two episodes Jeff did then you will find them at:

Jeff Alexander on Windows 10 – Episode 1

and

Jeff Alexander on Windows 10 – Episode 2

You can listen to this episode at:

http://ciaops.podbean.com/e/episode-90-jeff-alexander/

or subscribe to this and all episodes in iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show. I’m also on the hunt for some co-presenters so if you are interested on being a regular part of the show please contact me.

Resources

Windows as a Service – https://channel9.msdn.com/Events/Ignite/2015/BRK2322

Windows 10 Office apps – https://blogs.office.com/2015/07/29/office-mobile-apps-for-windows-10-are-here/

Join at Azure AD – https://blog.ciaops.com/2015/07/connect-windows-10-to-azure-ad.html

Jeff on Twitter – https://twitter.com/jeffa36

Jeff’s About.me page – https://about.me/jeffa36

Windows Insider program – http://insider.windows.com

Windows 10 uservoice – https://windows.uservoice.com/forums/265757-windows-feature-suggestions

Windows 10 Blog – http://blogs.windows.com

Need to Know podcast–Episode 88

I’m joined again by Jeff Alexander from Microsoft to talk about Windows 10. If you missed our previous episode check it out at:

https://blog.ciaops.com/2015/07/need-to-know-podcastepisode-86.html

Jeff and I dive a bit deeper into what Windows 10 offers, the new features it brings to the table and why everyone really should upgrade.

Look out for further podcasts with Jeff around Windows 10 as it ramps up over the coming weeks.

You can listen to this episode at;

http://ciaops.podbean.com/e/episode-87-jeff-alexander/

or subscribe to this and all episodes in iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Resources

Jeff on Twitter – https://twitter.com/jeffa36

Jeff’s About.me page – https://about.me/jeffa36

Windows Insider program – http://insider.windows.com

Windows 10 uservoice –https://windows.uservoice.com/forums/265757-windows-feature-suggestions

Windows 10 Blog – http://blogs.windows.com

Connect Windows 10 to Azure AD

One of things that really excites me about Windows 10 is its ability to be directly joined to an Azure Active Directory. I think this ability is a major change in the way identity for desktops is going to be managed going forward.

The way that you facilitate a Windows 10 machine doing just that is to firstly go into your Azure AD and select the Configure option as shown above.

You then scroll down to the devices area and ensure that the Users may Azure AD join devices is either set to All or Selected, as shown above.

Then you go to the Windows 10 machine you wish to join to Azure AD and select Settings.

Then select About from the bottom of the menu options on the left.

Then on the right hand side select the link Connect to cloud as shown above.

From the window that appears select Continue.

Enter the credential of a user permitted to connect to your Azure AD and select Sign In.

A few moments later the process is complete and the Windows 10 machine is joined to Azure AD.

If you then check back in your Azure AD and select the user who completed the join and then select the Devices option from the options across the top. That should display a list of Windows 10 machines that are now connected as shown above.

To remove the device from Azure AD simply visit the Settings | About page again and this time select the link Disconnect from the organisation. You’ll be prompted to Disconnect as shown above.

You’ll then need to enter the credential for a local machine administrator (i.e. a users with admin privileges on the Windows 10 desktop).

Enter OK to proceed.

The last step will then be to restart the machine to complete the separation process, much like you would when joining an on premises AD.

So there you have it, joining an Azure AD is very simple on a Windows 10 desktop. Look out for more articles on Windows 10 and Azure AD soon.

Creating a Domain Controller in Azure

Setting up a Domain Controller (DC) in Azure is a little different than on premises. This post is by no means an extensive guide or best practices document on doing that. It is however designed to give you the basics so you can get up and running quickly.

I am going to assume you are starting totally fresh here. The first task is to create a new Azure network in the location that you desire. For more details on doing this see:

Tutorial: Create a Cloud-Only Virtual network in Azure

The next step is to run an Azure virtual machine that will be your Domain Controller. The only step that is slightly different from the norm is that you need to select the virtual network you created previously in the Region/Affinity Group/Virtual network option as shown above.

You then continue on as normal and create the virtual machine and allow it start up.

For more information on creating an Azure virtual machine see:

How to Create a Custom Virtual Machine

Before you connect to the new virtual machine that will be you file server you need to add an additional hard disk to it. From the list of virtual machines you have in Azure select your new machine. Then select the Add button at the bottom of the page. From the menu that appears select Attach empty disk.

Complete the details for the additional disk and save the configuration. For more information on adding an additional disk to a virtual machine see:

How to attach a data disk to a Windows virtual machine

When you log into the virtual machine you’ll see that it already has a dynamic IP address (here 10.0.0.4). This comes from the virtual network you created previously. It is important that you DON’T assign static IP addresses to Azure virtual machines, even in the case of a domain controller. All Azure virtual machines should ONLY have dynamically assigned IP addresses.

If you look at the storage layout of your new virtual machine you’ll see a C: and D:. Beware, D: drive is a temporary drive that gets erased and recreated on reboot. Thus, the only stuff you want on there is temporary stuff like the page file. Good practice is not to have the Active Directory databases on the boot partition, because if that becomes inaccessible then bye bye AD, unless you have a backup. This is the reason why we attached an additional disk to our new virtual machine.

Everything now is pretty as it would be with on premises equipment. Go into the Windows Disk Management console and initialise the new disk.

Create a new volume on this additional disk and format it. At the end you should have a drive letter you can access. Here, F:.

If you again view the storage configuration of your virtual machine you should see a new disk (here F:) which will be the destination for the AD database.

Things remain the same when you configure your server to be a domain controller. Simply go in and add the role as you would normally.

Allow the configuration to complete.

Once the role has been enabled you now need to raise the server to being a domain controller exactly how you would on premises. The only difference is that you should re-locate the AD DS database, log files and SYSVOL to the disk you added (here F:).

Just before you complete the process of raising the server to be a domain controller, you’ll see the above warning about a domain controller requiring a static IP address. Again, in Azure this DOES NOT apply. In Azure we want all servers to have dynamic IP addresses.

Once you Domain Controller is running go into the DNS manager, right mouse click on the DNS server (here the domain controller) and select properties. In the Forwarders tab remove any IP address listed.

The last step is to go back and edit the properties of your virtual network. In the Configure tab for the network you will find the option for dns servers as shown above. Add the IP address and machine name here and save it. Although, the IP address assigned is dynamic it is on a extended lease so it should effectively ‘remain’ static. if you do power up and down your DC regularly for testing like I do, simply ensure that your DC is the first machine your fire up on that virtual network.

So now you have an Azure hosted Windows Domain Controller (DC) without too much additional fuss.

So now, if I want to add another Azure virtual machine into this network and onto the domain, I simply run up an Azure virtual machine as normal. When you do you’ll see it get a different IP address (here 10.0.0.5, while the DC is 10.0.0.4).

Then, as you would anywhere else, simply add that machine to the domain. You’ll be prompted for administrator credentials to verify the domain join.

If that is all you now have a second machine on this domain.

So in summary, the key points with a Windows Domain Controller in Azure is:

– Add an extra disk and install the AD database, logs and SYSVOL here

– Don’t give DC a static IP address

– Assign the DC IP address to the DNS setting in the virtual network configuration.

For more details on doing this see:

Install a new Active Directory forest on an Azure virtual network

Need to Know podcast–Episode 86

I’m joined by Jeff Alexander from Microsoft to talk Windows 10. As excitement builds ahead of the July 29 release we cover off things such as what the upgrade entails, what are the benefits of Windows 10 and why most people should consider an upgrade as soon as they can. There was just so much to talk about that we agreed to do a follow up session in the near future. So download, tune in and begin your upgrade to Windows 10 today!

You can listen to this episode at:

http://ciaops.podbean.com/e/episode-86-jeff-alexander/

or subscribe to this and all episodes in iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Resources

Jeff on Twitter – https://twitter.com/jeffa36

Jeff’s About.me page – https://about.me/jeffa36

Windows Insider program – http://insider.windows.com

Windows 10 uservoice – https://windows.uservoice.com/forums/265757-windows-feature-suggestions

Windows 10 Blog – http://blogs.windows.com