Last week I ran the Azure AD Core Skills Jumpstart on Microsoft Virtual Academy and, as always, there were lots of questions from the audience. I thought I’d take all the questions that I could find in the questions queue and dump them to a file and compile and FAQ for you to peruse. Useful if you did or didn’t, get your question answered.
This is a really great question and the answer is they can use whatever you setup for them here’s some options:
This is a kind of long and difficult question to answer, I’ll keep it under a paragraph but you should read more on TechNet around this if you want to go deeper.
Azure AD is designed for a mobile world, as such it is globally available by default and isn’t based on you building your own domain controllers. It’s built to deal with hyper-scale (really large) and deals with about 18bn auths per week. Azure AD can be used for OAuth2.0 apps, which is basically how the modern web does authentication. We designed Azure AD to federate and connect with thousands of applications, prime among them Office 365, Microsoft Intune and Azure itself. That gives us a huge amount of telemetry about how people use the service that the developers can act upon.
Contrast this with on-premises, where you design and build the infrastructure. Apps interact with AD DS either natively or via LDAP queries. You hand crank every federation and connection (and we know that many people don’t) and the data on how you use AD DS often doesn’t reach our engineers.
There are other, huge differences but in a couple of lines that’s a starter. There is also this MSDN Article you can check out.
This question is much easier: No.
However, you do have some components on-premises. Azure AD Sync synchronizes users from on-premises AD to Azure AD. Active Directory Federation Services (AD FS) keeps authentication on-prem and features such as Azure AD Application Proxy rely on an on-premises connector to enable reverse proxy.
No. It’s not possible to domain join a Windows PC to Azure AD today without on-prem domain controllers and computer accounts aren’t synchronized to Azure AD. In the future, you will be able to log into Windows 10 with an Azure AD user. Today, it is possible to “workplace join” a device to Azure AD thus creating an identity for the device against the joining user account. This is useful for conditional access uses, such as preventing mail flow to unregistered devices.
Azure AD Premium includes some extra, premium reports that add capabilities to your IT admin arsenal. I consider some “big data for IT admins”. There are some other useful reports too and you can find a full breakdown by reading this MSDN library article on what they all do. However, here’s a quick list of the premium reports if you need them:
Check out my earlier post on Setting up a strong identity management solution.
Jen Field, one of the Program Managers in the Identity team at Microsoft has a great blog post on exactly that: External authentication providers in AD FS in Windows Server 2012 R2: Overview
This is actually a pretty common thing to need to do, so the answer is pretty easy. First authorize the domain in Azure AD. Then add the new UPN suffix to on-prem AD DS and assign specific users that UPN in their account. From this point forward they can log on as nlcompany\user or firstname.lastname@example.org they won’t be able to use the nlcompany.local domain any further but you can add it as an extra attribute if it needs to be referenced by other apps and then point the other apps at the new attribute.
It really depends upon how you’ve configured your synchronization. If you don’t have any synchronization then you’ll need to manage Azure AD through the web portal or through PowerShell. If you’re syncing then you can, and should, be managing your user accounts and their attributes from the on-prem AD DS. Even in a synced scenario though you will need to go to the management portal or to use PowerShell to to manage parts of Azure AD that only exist there, such as reports.
No – but that doesn’t mean you can’t manage settings effectively. Let’s think back to where Group Policy came from, it was grounded in doing a better job of managing Windows than simply deploying reg setting through a script. Group Policies are still incredible at this and they will be around for this purpose for a long time to come. However the types of devices that we use has changed and many of them aren’t Windows now. As such the “group policy” engine for Azure AD is Microsoft Intune and its MDM capabilities.
Actually no, that’s not possible but probably only, respectfully, because the question isn’t very well scoped. Why would you only be worried about people potentially logging in from other countries? There are just as many, possibly more risks with users logging on without MFA in their home country. What is possible is to specify IP ranges that are exempt from requiring MFA. I would deploy this in places where I have a good expectation around physical security – such as the HQ with a small army of security professionals with guns and badges. I’d probably also deploy this to my VPN address range so as not to overly annoy users with extraneous authentication.
Another option, now in preview, is to enable MFA on a per app basis. So, for example, your users don’t need MFA to use the company intranet (published with Azure AD Application Proxy) but they do need it to use the customer information in SalesForce.
The best practice is to install it on another server that can talk to the SharePoint server. Given that the server can be virtual then that shouldn’t be overly hard to do and because it’s talking over standard ports you can make your own, informed, decision over DMZ placement.
Currently groups and their membership are synchronized from on-prem to the cloud but write-back isn’t available.
We look for correlation with attempts to contact malware servers from the devices that users sign-in from.
Yes and the answer to this question depends upon which apps you are using that are dependent upon Azure AD. Luckily you don’t need to know exactly which attributes each app needs, although it is documented here, since the Azure AD Sync setup will do this for you.
Thank you very much for joining me for episode one of the Enterprise Mobility Core Skills Jumpstart Series. Next month, April 2014, we will be live again talking about the core skills you’ll need for Microsoft Intune. Register here.
The post FAQ ME! Answering Questions from the Azure AD Core Skills Jumpstart appeared first on Enterprise Devices + Infrastructure.
On this weeks Edge Show I talk to Fabian from the WorkFolders team about their iPad client and I get an exclusive first look at the iPhone app too! If you aren’t familiar with work folders, it’s a really nice solution to use your existing Windows Server 2012 R2 File server infrastructure to enable sharing – across the internet – from those servers. Giving you the best of the cloud and making the best use of your on-prem investments.
The post Edge Show: WorkFolders for iPad + exclusive first look at iPhone appeared first on Enterprise Devices + Infrastructure.
Not everyone has a simple Active Directory structure, not everyone can move all their user objects and every single attribute to Azure AD, without a little nip-and-tuck. This post is going to help you deepen your core skills around Azure AD Sync Services, so you can go beyond the basics!
In a previous post on the blog, you learnt the 5 reasons why I consider connecting your on-prem AD DS to Azure AD an essential step, for everyone. Really just boils down to one thing – making your corporate identity more available, securely. By making it possible to authenticate and authorize your users on the devices and to the apps they’re using, wherever they are, you are making your life easier from an IT management standpoint.
In this post, we’re going deeper than just setting up a simple sync. Let’s ramp your skills up!
How long have you been running on your current AD? At the very most it is about 14 years… Wowzers! People’s kids have started and FINISHED school in that time and now their thinking about college!
It’s quite possible that some of those objects in your on-prem AD DS might not be all that fresh or important anymore. Perhaps you’ve got some attributes that you just don’t need, perhaps you’ve got some user objects that you don’t need to be cloud enabled, perhaps – just perhaps – you have a non-“standard” AD DS (!)
Azure AD Sync service, if you aren’t familiar with it yet, is the replacement technology for DirSync. Azure AD Sync makes some default assumptions about your environment that you need to understand.
Having said that these are the default assumptions doesn’t mean that you can’t challenge them. Out of the box (so to speak) Azure AD Sync setup drop-dead easy for a simple scenario. Either single or multi AD forests, where there is no duplication.
But what if there is duplication? Azure AD Sync can help here too, you just might need to break out the more advanced tools.
Let’s first take a look at the components that we need to understand.
One single Azure AD can be the “recipient” of users, groups, contacts and InetUsers from multiple on-premises Active Directories. Centralization is one of Azure ADs most powerful features, but you need to help Azure AD Sync service to understand exactly what your plan is. The first step is to identify the forests that you’re going to sync from and how those forests work with each other.
There are typically three types of forest topologies:
The first is pretty simple, two forests that don’t trust each other. For example, you might come across this if Contoso and Fabrikam were two companies under the same parent organization that shared no management structure. In this case, you could just use Azure AD Sync out of the box.
The second option is more complex. Here you have two on-premises AD DS forests that trust each other. There might be duplicated user accounts and contacts in the GAL in each company. For example, if Contoso acquired Fabrikam, IT set up trusts between them and they started to share business functions. Here you will need to set up “matching” across the forests – usually on the mail attribute as it’s uncommon for a corporate user to have multiple email address (although it does happen).
The third option is when there are one or more account forests with active user accounts. Here, one forest trusts all the account forests and typically shared resources live in that forest. For example, Contoso and Fabrikam are subsidiaries of Tailspin, Tailspin is the resource forest.
Azure AD Sync’s job is to make sense of the objects in your on-premises AD DS and deliver them into Azure AD. Azure AD Sync takes the information stored in objects in your AD DS forests and projects them into a construct (actually a SQL Server DB) called the Metaverse. Azure AD Sync does this based on synchronization rules, both inbound and outbound in Connector Spaces.
We are getting into the internal workings, but it’s important to understand what’s happening for a less “off the peg” scenario. Really, it’s all about matching and provisioning.
When Azure AD Sync finds and object, it takes a look at what it already knows in the metaverse to see if the new object in the connector space matches anything already there. If it does, it will, based on some attributes, join the objects. If not it will either provision or disregard the object.
Let’s move on to look at the objects we are syncing.
Users can exist in any synchronized forest. An active account will always contribute login information, including userPrincipalName and sourceAnchor. The user will have a number of attributes, some of those attributes can be used by the Azure AD Sync tool for user matching. For example the Mail attribute.
Of course, many of those other attributes store lots of bits of information. The available attributes depend upon how the AD DS schema was extended. Do you have Exchange or Lync, for example? Azure AD Sync usually creates an Azure AD User for a user account when it doesn’t see a matching instance in the metaverse, but if it does see a match then it will join the objects.
Disabled accounts are also synchronized to Azure AD. For non-Exchange folks, disabled accounts are often used to represent resources such as conference rooms in Exchange. A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox in which case it’s effectively ignored because an active account will be found later.
Contacts are common in scenarios where a global address sync has taken place between two forests. When Azure AD Sync sees a match between a Contact and a User in the metaverse it will join the two. If a User object isn’t seen, a Contact object is created. However, if a subsequent User object is found that matches the Contact then it is promoted to a User and a User object is created in Azure AD, ultimately.
It’s really hard to see what the effect will be before synchronizing directories and assembling the metaverse. However, the net is that you’ll have a deduplicated, single Azure AD.
Azure AD Sync is designed to run continuously ,on a periodic basis. On an first sync, where multiple AD DSs are imported into the metaverse, it’s impossible to know with accuracy which objects from which AD DS will be imported first. That’s why Azure AD Sync takes the approach it does to matching.
Having grasped the basics of the sync engine, you can start to make tweaks to the rules that make sense for your organization. For example, you can change the rules for how objects in your AD DS are joined to existing objects in the metaverse. Or you can “transform” the information in the attributes, changing almost anything about it. Transformation is actually a very powerful feature and has a rich language all its own, so you can get really custom. If you’re familiar with IdFix this is a better way of fixing issues that IdFix may have found.
You can find information on exactly how to change the Synchronization Rules in the documentation.
One of the other, less “off the peg” requirements you might have, is to not synchronize everything to Azure AD. There are three ways that you can filter your AD DS based on what’s going to meet your needs. Filtering will, essentially, prevent some objects from being created in the metaverse that otherwise would.
If you manage Contoso and Contoso has two domains, Contoso-US and Contoso-DK, but only the Chief Security Officer from the US part of the organization is comfortable with storing User objects in Azure AD and her German counterpart isn’t, then this is the filtering method you would use. (Also you should have a word with that CSO and possibly mail her the link to the Azure Trust Center).
If Contoso has a Physical-Access-Only OU, which is only used to hold the most secure user objects then OU-based filtering is the way to go.
If Contoso doesn’t have a natural partitioning structure based on AD DS or, has users with a specific attribute that must or must not be synchronized this is the way to go. For example you could add an extension attribute with a value of “NoSync” to all the user objects that you don’t want synced for some reason.
It’s important to know that this is very different from configuring attribute synchronization in the wizard. Attribute-based filtering will import (or not import) objects into the metaverse based on attribute values for that object. Configuring the attributes (or apps) that are synchronized to Azure AD in the wizard will configure which attributes are synchronized for the objects in the metaverse. Two very different things.
The next important thing to realize is that there are two different types of attribute-based filtering, inbound and outbound, as defined from the viewpoint of the metaverse. That is, inbound attribute-based filters control what comes into the metaverse and outbound filters control what leaves to metaverse. When we work with synchronization rules we don’t want to mess around with the predefined rules because we would lose our changes upon upgrade of Azure AD Sync.
For the most part, inbound attribute filtering will do what you need, only projecting the objects you want from AD DS into Azure AD. However there are times when there isn’t enough information in the attributes to filter as you would like. As an example, take the account resource forest topology. There the information as imported from the objects in the resource domain might not be enough on its own and Azure AD Sync might need to join it with information from the user domains.
Attribute-based filtering can be configured at any time, and if you remove something through filtering it will also be removed from Azure AD. It’s possible to configure filtering in Azure AD Sync I’m not going to dive into thousands of words on this since the documentation is so good at explaining how.
Now we’ve covered what the objects are and how to control their appearance in the metaverse and subsequently Azure AD, let’s cover attributes.
One of the most useful and intelligent features of Azure AD Sync is that, during setup, you can specify what attributes are to Azure AD.
You might not be an expert on exactly which attributes you need though, so the Azure AD team made it easy. Azure AD Sync gives you a list of all the Office 365, Microsoft Intune and Azure AD enabled apps from Microsoft, simply select which apps you use and Azure AD Sync will work out the attributes you need to sync.
This is one of the most important questions that your organization needs to answer. The ramifications are pretty huge.
If you do choose to sync your passwords you need to know that you aren’t actually sinking the passwords. You are syncing a non-reversible hash of the passwords. To put it simply: When a user attempts to authenticate against Azure AD, the authentication provider (which could be an app or a web page) will hash the characters they enter as the password. This hash is then sent to Azure AD and compared with the hash that Azure AD has. If they match, the user gets in, if not they don’t.
Password sync can be two way. Initially all passwords for synced users are hashed and stored in Azure AD. If a user changes their password on-prem, the password sync is quickly to Azure AD (the default is within 2 minutes). If the user changes their password in Azure AD (if you let them by enabling self service) then the reverse will happen, updating the users password on-prem.
If you choose not to use password sync you then need to implement AD FS. You can find details and tons of resources here.
What’s super-cool though, is that you can choose to do both. This means that if you implement AD FS and it fails for some reason, like you’re data center floods, then your users will still be able to authenticate with Azure AD using password sync. Pretty neat.
The one sacrifice you make here is that without AD FS you won’t be able to get Single Sign On (SSO) because there isn’t any way to synchronize or share tokens.
Checkout this article for lots of info on setting up password sync.
This is a whistle-stop 2000 word run through that drills deeper into your Azure AD Sync core skills. You can get even more by joining me for the Azure AD Core Skills Jumpstart on Microsoft Virtual Academy.
The post Setting up a solid identity and access management foundation appeared first on Enterprise Devices + Infrastructure.
In this episode, Brad talks about a recent trip to some customers in the mid-west, an incredible learning experience, seeing some of the real world challenges of trying to cobble point solutions together for EMM. Simon and Brad then talk about Conditional Access controls, Microsoft Ignite and much more.
Don’t forget to register for the Enterprise Mobility Core Skills Jumpstart Series, starting with Azure AD Core Skills and checkout the introductory blog post.
Brad also mentioned the Enterprise Mobility Roadmap
Check out these sessions at the Ignite conference about Enterprise Mobility:
The post Endpoint Zone Episode 6: Conditional Access, Ignite, Azure Remote App appeared first on Enterprise Devices + Infrastructure.
The Microsoft Word, Excel, PowerPoint and OneDrive apps are hugely popular on iOS and are natively instrumented for management only with Microsoft Intune. On Android, OneDrive, Office Mobile, and many other apps are also natively instrumented only for Intune. In this post, you’ll learn about Mobile Application Management in Microsoft Intune, including containers, encryption, policies, and app deployment. Dive in!
Enterprise Mobility Management (EMM) is a rapidly evolving technology. Every few weeks the operating systems we manage add new features, new apps are released and our users do something new. One of the technology subsets of EMM that’s arisen is the Mobile Application Management (MAM): essentially application deployment, lifecycle, policy, and removal technologies. Every EMM platform has them. Of course, the one I’m most interested in is Microsoft Intune (itself the MDM and MAM subset of Enterprise Mobility Suite) which interacts at the Mobile Device Management (MDM) layer.
MAM lets you have granular control of applications and provides a container that isolates corporate data and apps from personal ones on the device.
Most EMM products have their own apps that can live within these containers to perform “good enough” functions that users commonly need. The trouble is that “good enough” and “choice” don’t sit well together. Why should your spreadsheet application be “good enough” when your users can go get Microsoft Excel from the app store? Why use a document app when you can use Microsoft Word? The list goes on.
The Microsoft Word, Excel, PowerPoint apps top the charts on iOS, Android, and Windows. It is clear people love them.
Why do organizations need to use MAM? That’s clear too. We need to protect our company resources; our intellectual property, our customer information and our personnel information. Where’s the intersection of these two stories? Microsoft Word, Excel, PowerPoint, OneNote and OneDrive come with mobile application management built in and managed through Microsoft Intune!
Microsoft Word, Excel, PowerPoint, OneNote iOS apps and OneDrive iOS and Android apps have the Microsoft SDK built into them, meaning that they know how to interpret configuration payloads from Microsoft Intune. The Office team took the SDK and implemented it right into the Office code. As a matter of fact, they are only natively instrumenting for Microsoft Intune.
SDK managed apps live in an encrypted container on iOS using the inbuilt iOS encryption engine, which is FIPS 140-2 certified. On Android, SDK managed apps implement their own encryption algorithm. Any corporate data is protected inside the container.
SDK managed apps also can “policy managed”, meaning that they know how to interpret a payload that Microsoft Intune sends to the device. This allows IT to control many aspects of the apps’ behaviors. For example, by setting an Intune Managed Application Policy, it’s possible to redirect any web browsing to a Secure Browser. IT can also enable policy managed apps to need a PIN or authentication of corporate credentials before allowing the user into the app, increasing the container security. Other neat features include encrypting data when saving files to external storage, such as SD cards.
A mobile application management policy spans apps, meaning that the policy becomes the “link” between, for example, Word, Excel and OneDrive. All the data is secured by the policy and the apps are managed by the policy.
When a developer integrates the Microsoft Intune SDK into an app they can later publish the app to the store. Microsoft is working with partners to do this right now.
One of the biggest concerns with enterprise mobility is the “un-enrollment” scenario, or what happens when a user no longer requires access to corporate information. Since SDK managed apps are generally published to a public store there is always the possibility that they will also have interacted with personal data which the user might want to keep private (although there is a policy to disable this if IT want). In the case of an SDK managed app, when the device is “un-enrolled” the app data is wiped out, but the app remains.
In the future, it will also be possible to use the SDK for a Line of Business (LoB) app, but another route, App Wrapping, might be more suitable.
Although I’m focusing this post on managing Office apps on iOS and Android they probably won’t exist alone. Many organizations are developing custom LoB apps for iOS, and they want to be able to secure them too. Budgets for LoB apps, however, remain tight in most organizations and so redeveloping an existing app to incorporate the SDK might not always be good. Enter the app wrapper.
Today, wrapping is available for iOS and it requires the wrapping be done from a Mac; not a problem, since you need a Mac to develop for iOS. There are some requirements around wrapping:
The wrapped app are managed with the same mobile application management policies as SDK managed apps. This means that they form part of the container and that the same policy requirements are apparent.
There is a third type of app that Microsoft Intune cares about: Managed Apps. These are apps in the iOS store that include specific iOS functionality such as implementing managed open in. To cut to the chase, these applications can be set as Required Installations, meaning that they are installed automatically. Additionally, using a mobile device policy for iOS in Microsoft Intune, you can control the behavior of even these apps, allowing or preventing those apps sharing data with unmanaged apps.
For completeness, unmanaged apps are those apps available from the app store that do not implement wrapping or the Microsoft Intune SDK and are not managed by Microsoft Intune using MDM application management policy. AKA they’re just another app.
We’re going to start by assuming that you have Microsoft Intune (and an Office 365 subscription for the Office apps). If you don’t you can go start a Microsoft Intune trial.
Let’s start by adding PowerPoint as a managed app in Microsoft Intune. In the Intune console select the Software workspace and then Managed Software. Next click Add Software to start the process. A ClickOnce installer will download that you need to run. Upon doing so you’ll be asked to sign in with a Microsoft Intune administrator account.
Once you’re signed into the Microsoft Intune Software Publisher, select Add software and click Next. Because Microsoft PowerPoint is in the iOS App store, let’s select Managed iOS App from the App Store and then specify the URL to the app in the App Store. Personally I usually find this by opening a browser and just searching for the app. The URL will be something like: https://itunes.apple.com/us/app/microsoft-powerpoint/id586449534?mt=8 . Click Next to move on.
Now we need to set some information about the app. Remember, your users will see this in your Company Portal app. I usually also use the Snipping Tool to grab the app icon from the App Store web page. When you’ve provided your info, click Next and select which device type (iPad, iPhone or both) you want to target. We’ll select iPad. Click Next again, read the summary and click Upload. Since all you are uploading is your app icon it will complete very quickly!
Back in the Microsoft Intune management portal, click Detected Software and then back to Managed Software to refresh the list and confirm that PowerPoint is listed. Highlight PowerPoint and click View Properties at the top of the Managed Software list. Notice that the Supports App Policy detail is marked Yes; this indicates it’s a wrapped or SDK managed app.
We now need to create a policy to manage the app. Click the Policy workspace and navigate to Configuration Policies. To create a new mobile application management policy click Add… Next on the Create a New Policy screen, select the Software drop down and then select Mobile Application Management Policy (iOS 7 and later). Then select Create a Policy with the Recommended Settings and click Create Policy.
Now select your new policy which, at this point, is called Mobile Application Management Policy (iOS 7 and later) create and click Edit… You now have the opportunity to rename the policy and change any of the default settings that created by this template. By default this Mobile Application Management policy will:
*this is a Conditional Access Policy and will make sure that the device is not jailbroken and has a long, complex enough password for your organization. This policy can be set in the Compliance Policies node.
The next step is to associate the policy to the app and deploy the app. Go back to the Software workspace, select Managed Software and PowerPoint then click Manage Deployment… Now select the users that need the app. You can select All Users, a group, or a device group. All Users is good in a lab, then click Add and Next.
For Deployment Action, there’s a couple of options. Required Install will automatically install the app when the user enrolls their device or when policy is next refreshed for devices already enrolled. Available Install will place the app into the Company Portal application for the user to manually select. In this case, choose Required Install and click Next.
Now choose the App Management Policy that we created earlier and click Next. Next is choosing a VPN profile. Selecting a VPN profile, if you have one, will tunnel all the app’s traffic through the VPN connection, useful if your app is on-premises. In our case, Office 365 is not on-prem so we can just click Finish.
PowerPoint will now be deployed to users’ iPads upon enrollment or policy refresh and will be protected by the mobile application management policy.
So that PowerPoint has something to talk to, repeat this process to add Microsoft Word, Excel and OneDrive. You don’t need to create a new mobile application management policy though, so just repeat step 1 and step 2 above.
Take a look at the video below to see the outcome of what we just built, which of course you can try on any iOS devices you’ve enrolled:
Adding Android apps is very similar to iOS but with a few differences. First let’s add OneDrive for Android.
In the Intune console select the Software workspace and then Managed Software. Next click Add Software to start the process, a ClickOnce installer will download that you need to run. Upon doing so you’ll be asked to sign in with a Microsoft Intune administrator account again.
Once you’re signed into the Microsoft Intune Software Publisher, select Add software and click Next. Because Microsoft OneDrive is in the Google Play store, let’s select External Link and then specify the URL to the app in the Google Play Store. Again I usually find this by opening a browser and just searching for the app. The URL will be something like: https://play.google.com/store/apps/details?id=com.microsoft.skydrive . Click Next to move on.
Enter the publisher details, and again, snip the icon from the Google Play store. Click Next and then Upload. Finally, click Close.
We now need to create a policy to manage the app. MAM policies are specific to each platform, iOS and Android. Click the Policy workspace and navigate to Configuration Policies. To create a new mobile application management policy click Add… Next, on the Create a New Policy screen select the Software drop down and then select Mobile Application Management Policy (Android 4 and later). Then select Create a Policy with the Recommended Settings and click Create Policy.
Select the new policy called Mobile Application Management Policy (Android 4 and later) create <today’s date> and click Edit… You can again change any of the template settings which in this case are:
Save any changes by clicking Save Policy.
The next step is to associate the policy to the app and then deploy it. Go back to the Software workspace, select Managed Software and OneDrive then click Manage Deployment… Now select the users that need the app. You can select All Users, or a user group; All Users is good in a lab. Then click Add and Next.
For Deployment Action, Android only gives us one option; Available Install, which places the app into the Company Portal for the user to select. Select Available Install and click Next.
Now, choose the App Management Policy created earlier and click Next. Android doesn’t allow us to give a per-app VPN so just click Finish.
Other managed apps are in the Google Play store:
Today, not as many Office apps for Android are manageable as on the iOS platform. Android, while a great platform, isn’t as natively manageable as iOS at this stage (although Lollipop should change this, but isn’t widely available at time of writing).
We’ll be covering more on MAM in the upcoming Microsoft Intune episode of the Enterprise Mobility Core Skills Jumpstart series. Also, take a look at this course on Microsoft Virtual Academy on Samsung KNOX management with Microsoft Intune, this free virtual Lab on TechNet and the following places in the Microsoft TechNet library:
The post Enable Mobile Application Management of Office apps for iOS and Android appeared first on Enterprise Devices + Infrastructure.