Wednesday 25 March 2015

See "Microsoft Intune Conditional Access" in action

EMS Landing page

Microsoft Intune Conditional Access was first released in December 2014. It is particularly cool. Now we can fight Shadow IT and block access to corporate resources from un-managed devices. Many enhancements have been made to the service since.

Have a look at the following TechNet library document:

Control access to Exchange and Office 365 with conditional access in Microsoft Intune

Use Conditional access in Microsoft Intune to secure email and other services depending on conditions you specify.

When devices do not meet the conditions, the user is guided though the process of enrolling the device and fixing the issue that is preventing the device from being compliant.

To implement conditional access, you configure two policy types in Intune:

  • Compliance policies are optionally deployed to users and devices to define the rules and settings that the device must comply with in order to be allowed access to services. These rules include passcode, encryption, whether the device is jailbroken or rooted, and whether email on the device is managed by a Intune policy. If a compliance policy is not deployed, then the conditional access policy will treat the device as compliant.
  • Conditional access policies are configured for a particular service, and define rules such as which Azure Active Directory security groups or Intune groups will be targeted and how devices that cannot enroll with Intune will be managed.
Unlike other Intune policies, you do not deploy conditional access policies. Instead, you configure these once, and they apply to all your managed devices.

The currently supported scenarios are:

Standalone Intune
  • Exchange On-Premise (Exchange 2010 and later)
  • Exchange Online
  • SharePoint Online

ConfigMgr/Intune integrated
  • Exchange Online (very recent)

In this blog I have concentrated on configuring an Exchange On-premise conditional access solution (because I don't have Exchange or SharePoint Online labs). I will demonstrate how to carry out the following:
  1. Install the Microsoft Intune Exchange Connector
  2. Create an Exchange On-premises policy
  3. User testing and experience

See here for more information

Set up mobile device management using Exchange ActiveSync in Microsoft Intune


1. Microsoft Intune Exchange Connector

If your instance of Exchange Server is on-premises, you must download, install, and set up the Microsoft Intune On-Premises Connector on a computer in your infrastructure. 

See here for the requirements:


Requirements for the On-Premises Connector


You must create an Active Directory user account that is used by the Intune Exchange Connector. The account must have permission to run the following required Exchange PowerShell cmdlets: 

  • Get-ActiveSyncOrganizationSettings, Set-ActiveSyncOrganizationSettings
  • Get-CasMailbox, Set-CasMailbox
  • Get-ActiveSyncMailboxPolicy, Set-ActiveSyncMailboxPolicy, New-ActiveSyncMailboxPolicy, Remove-ActiveSyncMailboxPolicy
  • Get-ActiveSyncDeviceAccessRule, Set-ActiveSyncDeviceAccessRule, New-ActiveSyncDeviceAccessRule, Remove-ActiveSyncDeviceAccessRule
  • Get-ActiveSyncDeviceStatistics
  • Get-ActiveSyncDevice
  • Get-ExchangeServer
  • Get-ActiveSyncDeviceClass
  • Get-Recipient
  • Clear-ActiveSyncDevice, Remove-ActiveSyncDevice
  • Set-ADServerSettings
  • Get-Command
You will need to speak nicely to your Exchange Admin to configure the required permissions. I cheated every so slightly in the lab.


I assigned my account way more permissions than I needed (OK in a lab, not so clever in production).


Navigate to Administration > Microsoft Exchange > Set Up Exchange Connection. Select to "Download On-Premises Connector".


See the Connector executable and Intune certificate files. Note that these two files must be present in the installation folder.


Double click Exchange_Connector_Setup to launch the Microsoft Intune Exchange Connector Setup Wizard". Click Next to continue.


Review the terms and click Next to Install.


The Connector installs.


The setup has completed. Click Finish to start the Connector.


Welcome to the "Microsoft Intune Exchange Connector".  Enter the required details:
  • Exchange Client Access Server name
  • Domain account that you created earlier
  • Optional email address
Click Connect to create the communication between Intune and Exchange.


The connection is being created.


The connection has been created. We are told where we can see the synchronization status.


Note that you can update the connector details if you need to. I have added an email address here.


Back in the Intune Portal we can see that the connection has been created but the initial sync has not been run. Click "Run Full Sync" to kick that off.


Synchronization is in progress.


After synchronization has been completed we can run a Mobile Device Inventory Report. This will tell us the bad news. Which of my devices are un-managed but are still accessing Exchange? We need to contact these users to make arrangements for enrolling these devices. Once we apply a conditional access policy these users will lose access to email.


2. Create an Exchange On-premises policy

It's very easy to create the Conditional Access policy. Navigate to Policy > Conditional Access > Exchange On-premises Policy.


Check the box "Block email apps from accessing Exchange On-premises if the device is non-compliant or not enrolled". 

Select the Targeted Groups (in other words the groups that should receive the policy). In my lab I chose "All Users".

Select the Exempted Groups. The policy will not apply to these users. If a user is in both targeted and exempted groups the policy will not apply. I have chosen a group "Excluded from Conditional Access".


The default rule should be "Allow the devices to access Exchange".

See that you can customise the User Notification". Save the policy.


See that I have allowed only Mike and Pat to be exempt from the policy (as they are VIPs and have to be treated differently).


3. User testing and experience

I am testing on an un-managed Android device. Remember we have allowed Pat to be exempt from the Conditional Access Policy. Therefore he should be allowed to connect to Exchange........


.....and he can.


Good for Pat.


Gerry is not so lucky. He is not a VIP so the policy will apply.


He cannot connect to Exchange.


He actually receives an email to his mailbox explaining the situation and telling him that he is trying to access Exchange with an un-managed device. Perfect.


Gerry then installs the Intune Company Portal and enrolls the device.........


.....and finally can access his email.




Microsoft Intune Exchange Connector Error 0x000000b

EMS Landing page

I encountered this error today and the solution was easy. Yesterday a user had previously tried to connect to the corporate Exchange server using their new personal Android device. They were unable to do so due the Microsoft Intune On-Premise Exchange policy that was in place. Perfect behaviour. However I enrolled the device using the Intune Company Portal but was still unable to connect to the user's mail.

Intune knew that the device was now enrolled (I could see it in the console). Exchange did not. That would suggest a communication problem between Intune and Exchange. 


On investigation I noticed a lot of Microsoft Intune Exchange Connector errors in the event log.

Event ID: 7007
The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.


I tried to update the connector......


.....but received the same error (with an error code of 0x000000b)


The fix was easy. I simply restarted the MIcrosoft Intune Exchange Connector Service.


I could then update the connector.

Normal service was resumed and there was communication between Intune and Exchange again. The user could then access their corporate email on their new device.



Friday 20 March 2015

How to use Cloud App Discovery

EMS Landing page

How cool is this? Cloud App Discovery (Preview) was released in 2014. The tool is still in Preview but is rapidly becoming one of the most utilized Azure services. 

What is it for?: You want to implement Software as a Service for your users. You want to manage the cloud apps rather than have your users engage in Shadow IT. However you have no idea what they are doing - enter Cloud App Discovery.

See a recent blog from the Active Directory Team where they discuss the new and exciting features of Cloud App Discovery.

http://blogs.technet.com/b/ad/archive/2015/02/16/new-updates-to-cloud-app-discovery.aspx

So how do we use it. It's really easy. 

 
  

Sign in or sign up. Log in with your Azure account or create an account.


You are presented with the instructions. Click Next to continue.

Instructions (as simple as ABC)
a) Download and run the agent on your devices
b) Azure AD receives the data
c) Discover the cloud services on your dashboard 

 

a) Click Download


Extract the files. See the tenant.cert file. This must be in the same folder as the Agent executable for installation.

Double-click EndpointAgentSetup.exe on one of your devices.


The Cloud App Discovery Endpoint Agent installation wizard is launched (note - still in Preview). Agree to the terms and click Install.



The agent has been installed.


See the new "Microsoft Cloud App Discovery Endpoint service".


Log back in to the Cloud App Discovery Portal

https://appdiscovery.azure.com
 
b) No apps have been discovered yet.


We see that data collection is in progress.


c) In a short space of time you will see data in your dashboard (less than 30 minutes).


You can see what Apps are being consumed by your users.


See that Cloud App Discovery is still in Preview.


 See that you can choose to display "All Apps" or just "Business Cloud Apps"


You can use a software deployment solution to distribute the agent to your devices. See that Microsoft have provided specific deployment guides using Group Policy and System Center Configuration Manager.

Group Policy Deployment Guide

System Center Configuration Manager Deployment Guide





Thursday 19 March 2015

Installing the Azure Active Directory Sync Service (AAD Sync)

EMS Landing page

Meet DirSync's big brother - Microsoft Azure Active Directory Sync Service. The official documentation can be found here

https://msdn.microsoft.com/en-us/library/azure/dn790204.aspx

Azure AD Sync is the new synchronization service that will allow customers to do the following:
  • Synchronize multi-forest Active Directory environments without needing the complete feature set of Forefront Identity Manager 2010 R2.
  • Advanced provisioning, mapping and filtering rules for objects and attributes, including support for syncing a very minimal set of user attributes (only 7!)
  • Configuring multiple on-premises Exchange organizations to map to a single AAD tenant
A full feature comparison of DirSync and AAD Sync can be found here

https://msdn.microsoft.com/en-us/library/azure/dn757582.aspx



You see that AAD Sync is essential when managing multi-forest environments. DirSync can still be used for single-forest. However note that DirSync does not support write-back of passwords from self-service password resets.

Also see FAQ:


https://msdn.microsoft.com/en-us/library/azure/dn783460.aspx

Some points of note for AAD Sync:
  • Can be installed on a Domain Controller
  • Supports SQL Express for all but very large organisations (100,000 objects)
  • Uninstalling DirSync and then installing AAD Sync on the same server seems to be troublesome

See here for installing the service:

https://msdn.microsoft.com/en-us/library/azure/dn757602.aspx

The following Operating System versions are supported:
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
Your computer can be stand-alone, a member server or a domain controller.
The following components need to be installed:

  • .Net 4.5
  • PowerShell (PS3 or better is required)
This document also provides assistance on the account permissions required to install and maintain the service. For the purposes of demonstration in my lab I will use the Domain Admin account (this is not best practice in production).

Martyn Coupland has written a good blog about this here

http://www.martyncoupland.co.uk/2015/03/permissions-used-in-aadsync.html 


Download AAD Sync from here

http://www.microsoft.com/en-ie/download/details.aspx?id=44225


Extract and launch the tool.


The Microsoft Azure Active Directory Sync Services installation wizard starts. Agree to the terms and click "Install".


 The AAD Sign-In client is installed.


 SQL Express is installed.


 The Synchronization Service is installed. The tool now restarts and can take a little while to be available again. Don't be alarmed.


Enter your Azure AD credentials (Global Administrator).


The Azure AD Connector is initialized.


Enter your local AD details (in the format domain\username) and select "Add Forest".


 See that you can repeat for multiple forests - lovely. Click "Next".


The installer gathers forest/domain schema information.


See the previous links for official documentation to give you guidance here. I chose the defaults which is to use UPNs to match local users with Azure AD. Click "Next". 


You can choose optional additional features here. I have chosen "Password Synchronization" and "Password write-back". 


See what happens when I choose "Azure AD app and attribute filtering". More configuration items become available.


 We can filter by Apps.


 We can filter by attributes.


Click "Configure" to continue.


The selected options are configured.


Initial configuration has been completed. Uncheck the "Synchronize now" box (unless you want your entire AD synchronized with Azure). I want to carry out further configuration to select a specific OU.

Sign out of Windows at this stage and log back in.


Locate and launch the Azure AD Sync Synchronization Service.


Open the Connectors tab. See the AD Domain Services connector. Double click to see the properties.


Navigate to "Configure Directory Partition". Select "Containers".


Enter your credentials.


Now you can choose your OUs. Select OK to close the dialog boxes.


Select Run.


Choose "Full Import".


See successful import to Azure. However, this is not immediate and it will take some time for the users to be available in Azure (I am impatient so thankfully there is a way to force the sync).

Previously with DirSync we used "start-onlinecoexistencesync". This has now been replaced in AAD Sync with "DirectorySyncClientCmd.exe".


 Navigate to C:\Program Files\Microsoft Azure AD Sync\Bin and launch DirectorySyncClientCmd.exe


Users from my selected OU are available in Azure AD within a few minutes (almost immediately).