Wednesday, 25 March 2015

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 IntuneUse 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:

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:

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

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.........

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: 7007The 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 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.aspxSo 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 devicesb) Azure AD receives the datac) 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.

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.

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:

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).