Windows Server-2012

Author: Enterprise Mobility Team
Subject: Registering BYOD devices

View article…

As Carol Burnett often said, “Seems we just get started, and before you know it…” We hope that you enjoyed this blog series (although there was no singing during its creation) and–more importantly–seen some of the newest features of identity, mobile device management, virtualization, and Access and Information Protection. Perhaps you’ve even been inspired to try some of them out.

Just as our blog posts—and funny TV shows—wind down, so sometimes do the relationships among a device, a user, and the organization. People resign (or are asked to leave); projects change; and—unfortunately—devices are lost, stolen, and repurposed. Sometimes, they leave the authorized user’s hands (or the user leaves) without the IT department having had a chance to properly sanitize the corporate data.

An advantage of the Microsoft enterprise mobility capabilities is the ability to selectively wipe the corporate data from the client. Some devices support a complete wipe of the device, which is appropriate in some instances, but with the blend of personal and corporate information, organizations may not be authorized to fully wipe a device. This is particularly true if the device is returned to solely personal use.

The ability to selectively wipe a device is delivered through the Windows Intune Selective Wipe feature (or other Windows Encrypting File System application programming interface [API] management tools). How the data is actually wiped (at a technical level) varies by platform. Always, the information becomes inaccessible; whenever possible, it is also removed.

If you use Windows Intune, you can invoke Selective Wipe through the Intune interface, but because selective wipe is API-based, developers can call the API directly. An increasing number of apps are using Selective Wipe, such as Work Folders and the Windows Store Mail app, which store or synchronize data on a client device. For an overview of Selective Wipe, see Windows Selective Wipe for Device Data Management.

For Work Folders, all you have to do to selectively wipe the organization’s data from the device is to remove the device from management, that’s it.

Author: Enterprise Mobility Team
Subject: Registering BYOD devices

View article…

Work Folders allow you to maintain control of corporate data by storing it on server file shares while making it available consistently across a user’s multiple devices, including when the user’s device is disconnected from the network. Users want to get at the data—which they consider “theirs”—whenever and where ever they want to work. They often want to work with a local copy, but you need to maintain control of the data, even while making it available. (I’m sensing a recurring theme here.)

Have you ever had users email documents to themselves? Have you ever filled a USB flash drive port with epoxy or created a firewall rule to block consumer-based storage platforms (such as Box.com, Dropbox, or Microsoft OneDrive)? With Work Folders, you can stop fighting with users and allow appropriate, secured, protected synchronization of files.

Users can sync their work data to their devices, but files can still be classified, so that protection can be applied to sensitive data. Another quite important thing is that a copy of the information is always kept within the corporate realm, available and backed up.

For general information about Work Folders, visit Work Folders Overview.

In our next and final post on this topic, I’ll look at how you can totally protect your corporate data by removing it from a device if that device is lost, stolen, or taken home when someone leaves the company. But first, let’s look at how to set up Work Folders, and then sync and classify some data.

Setting up Work Folders on a file server

To set up Work Folders, first take care of the basics: Have a domain controller (or better, two!), with proper connectivity such as Domain Name System and Dynamic Host Configuration Protocol servers.

You implement Work Folders on file servers, where you set up sync shares. You configure one share per user, and you can enforce a quota. So, set up a Windows Server 2012 R2 computer as the file server. There, add the Work Folders Role service, found under the File and iSCSI Services node of the File and Storage Services role.

With the role service installed, a new menu item is created in Server Manager. Launch the New Sync Share Wizard.

You can then publish Work Folders directly through a reverse proxy or enforce conditional access by using Active Directory Federation Services, which, in turn, can use device registration information. The wizard will ask you for an existing share or a path for a new Sync Share.

Work Folders are designed so that each user assigned to the Sync Share has a personal folder within that share (with NTFS permissions protecting it, of course). This is similar to the “home folder” idea, and many organizations use the same structure. Users can access the Sync Share over Server Message Block (SMB) or Network File Share, as well.

As you work through the wizard, most of the options are fairly self-explanatory. A few might warrant some additional details, however.

On the Sync Access page, for example, you’re asked to specify the groups that you will allow to access this Sync Share. You can also specify individual users, but that would be silly. This setting controls who can use Work Folders hosted on this share on this server.

You are also asked to define the device policies. You can require that the files synced to a device must be stored in an encrypted format or that the device must have an auto-lock with a password. Work Folders use a different encryption key than any other encryption used on the device, which makes it much easier to wipe only the Work Folders, if needed.

Connecting a Windows client and synchronizing files

Now, turn your attention to a Windows 8.1 client and complete the client-side setup. Here are the simplified steps:

1. Launch Control Panel. Tap System and Security, and then Work Folders.
2. Provide your work email address.
   The system uses this address to construct the URL required to reach the File Server.
3. Enter your logon credentials, if prompted.
   If the client is a member of the domain, you won’t be prompted for credentials.
4. Specify the location in which to store the files.
5. If security policies have been specified on the server, they will appear in the setup wizard. Select the check box to accept them, and then tap Setup Work Folders.

There you have it: You can now access, change, and create folders on any of the devices that you’ve configured and optionally through the SMB share, as well. As you work online, you will see changes reflected quickly across all devices.

For a complete step-by-step guide to setting up and testing Work Folders see the Storage Team Blog entry Work Folders Test Lab Deployment, or the documentation page Deploying Work Folders.

Note that Windows 7 clients can participate with an optional download, as explained in Work Folders for Windows 7. Support for other devices is planned but has not yet been announced.

File classification and Work Folders

For extra credit, explore what happens when you configure Automatic File Classification on the file server. Perhaps you have a File Classification rule that all Microsoft Excel spreadsheets must have a Rights Management template applied (using Active Directory Rights Management Services [RMS]).

If a user creates a new Excel spreadsheet while working offline, as soon as the client is reconnected and the folders synchronized, the file classification goes into effect, applying the RMS template.

Managing rights to information

AD RMS is an important part of an information protection strategy; and now, it is complemented with Azure RMS. Traditionally, access to a computer file is governed by a discretionary access control list (DACL) that contains entries specifying who can have what types of access to the file. In Windows, DACLs are part of the file system and enforced by the operating system. However, once an authorized user is granted access to read or copy a file, nothing prevents that user from keeping a copy, and then redistributing it to others, whether those other people are authorized or not. RMS helps secure you against such risks.

AD RMS protects a file by storing it in an encrypted format. Instead of a simple DACL, permissions are enforced using encryption keys, policies, and licenses. This means that the owner of the document can set rules about how the document can be used, whether it can be printed or redistributed, or even have it expire after a set period of time.

Administrators can design templates (e.g., “internal use only” or “do not forward, do not print”) for documents, and the Windows Server 2012 File Classification Infrastructure (FCI) can be used to automatically apply templates based on the location, type or content of the file.

For more information about AD RMS, see Active Directory Rights Management Services on TechNet, or the implementation details in AD RMS Overview on MSDN. An example scenario of FCI is featured in Scenario: Get Insight into Your Data by Using Classification.

Azure RMS takes the RMS even further. Azure RMS is a cloud-based service that uses Azure AD as an identity store. Azure RMS offers additional flexibility to on-premises AD RMS, including support for not only Microsoft Office and Office 365 but also native viewers on Windows, Windows RT, Windows Phone, iOS, Android, and Macs.

Azure RMS supports the protection of many file types, including PDF and XML files, or entire ZIP files that can contain anything. Support remains for Office Documents, e-mail, and SharePoint libraries. And, protection can be extended to users outside of your own organization much more easily than with AD RMS. As with AD RMS, administrators can use templates and policies to protect documents. In fact, individuals outside of a corporate organization can even create a free individual RMS account, allowing your organization to securely share and manage documents with even the smallest of contractors or partners.

Get more information about Azure RMS at Azure Rights Management on TechNet.

Author: Enterprise Mobility Team

Article…

Making resources available to users

Yesterday, we kicked-off our blog series on Access Information Protection (AIP) by talking about setting up the environment. In today’s post, we continue our look at AIP and specifically ways you can make resources available to users, who are connecting from various devices, inside and outside of the LAN, while keeping the company’s information safe and making sure that you maintain all mandated compliance.

One way to approach this task is to use Web Application Proxy combined with Active Directory Federation Services (AD FS) to publish resources.

Using the Web Application Proxy, you can publish access to internal web applications, allowing access from user devices either by native applications or through a web browser. Web Application Proxy in conjunction with AD FS can also preauthenticate the user and the user’s device and enforce access policies based on the user, the device, or the location.

Web Application Proxy is integrated with AD FS and uses information stored in Active Directory Domain Services. It uses user identity information, such as verifying credentials and device registration information. You can also require Multi-Factor Authentication on a per-Application basis. This integration with AD FS lets you apply conditional access rules for granular controlover how and where users can access the application. You can implement this granular control with applications that use AD FS claims, Kerberos web apps, Microsoft Office Forms-Based Access, and Representational State Transfer (REST)-ful OAuth apps.

Alternatively, Web Application Proxy can provide a generic reverse HTTP over Secure Sockets Layer (HTTPS) proxy to publish applications without AD FS that will then use NTLM or Basic authentication to validate the user.

For more general information about Web Application Proxy, check out Overview: Connect to Applications and Services from Anywhere with Web Application Proxy.

To use Web Application Proxy, you need to install the role service on a computer running the Windows Server 2012 R2 operating system as part of the Remote Access role. In a large environment, you may want to install multiple servers to handle the traffic. Make sure that you have the correct Public Key Infrastructure certificates, either issued by your own certification authority (CA) or purchased from your favorite publicly trusted CA. In addition, make sure that all of the servers involved have the correct time (which is usually automatic in a domain).

When using AD FS for granular control or preauthentication, several HTTPS redirects occur. Here’s the basic sequence with Web Application Proxy using AD FS for preauthentication:

1. A user request a resource URL that is a public address on which Web Application Proxy is listening.
2. Web Application Proxy redirects the request to AD FS, including encoded parameters (such as the requested resource and a relying party identifier).
3. AD FS validates the user according to the rules you’ve defined; if authenticated, it redirects the request to Web Application Proxy with a new security token included in the request (the edge token).
4. Web Application Proxy validates the token and now has access to the user’s identity information, which it can used, for example, to obtain a Kerberos ticket for a back-end system.
5. If the token is valid and not expired, Web Application Proxy forwards (or “proxies,” if you prefer), the HTTPS request to the published web application.
6. The client can now access the application. (Note, however, that some applications may require additional information for authentication.)
7. Web Application Proxy uses a cookie to identify the session and mark that preauthentication is no longer required.

Similar processes are used for Windows Store apps, Office Web apps, claims-aware (claims-based) applications, and Integrated Windows Authentication–based applications. Details on the steps and the differences between app types can be found in Plan to Publish Applications using AD FS Preauthentication.

Microsoft has prepared several walkthroughs and planning guides for using Web Application Proxy:

• Installing and Configuring Web Application Proxy for Publishing Internal Applications
• Walkthrough Guide: Connect to Applications and Services from Anywhere with Web Application Proxy
• Active Directory Federation Services How-To Video Series: Installing the Web Application Proxy (Video)

We mentioned that you could use AD FS with Web Application Proxy to preauthenticate or evaluate devices, not just users. Here’s today’s cliff-hanger: Come back tomorrow and read about how you can allow users to register their own devices to access resources (while giving you some control over which devices to recognize).

Learn more about Access and Information Protection here.

Author: Enterprise Mobility Team

Article…

Setting up the environment

Last week, we looked at desktop virtualization. Now, let’s turn our attention to Access and Information Protection.

In many ways, Access and Information Protection (AIP) are two sides of the same coin. When you think of the term access, you may first think of access controls—that is, permissions and other constraints—but that’s not how users think of access. They simply think of wanting to access “their” data and the applications that they need to work with, no matter where, no matter when, no matter what device they happen to be using.

In many parts of the world, users have ample access to affordable and fast cellular and Wi‑Fi networks. These users are increasingly mobile and want to blend access to personal and corporate data on their devices (whether owned by the company or the individual).

At the same time, your organization views that same data as a corporate asset, one that needs to be protected. As an IT pro, you must manage security, identity, and access control. You likely face increasingly stringent regulatory requirements, such as the Health Insurance Portability and Accountability Act Privacy Rule and Sarbanes-Oxley Act of 2002 if you’re in the United States (or do business there) and similar legislation in many other countries. Even if you don’t have a legislative or regulatory duty, you probably have standards that industry associations, payment processors (such as Payment Card Industry Data Security Standard), auditors, or senior management have imposed.

You need to retain control and compliance, deploy and configure capabilities for providing access and enabling both productivity and information protection. This is the realm of AIP.

To learn how our Access and Information Protection solutions can help secure your organization’s information, see the Access & Information Protection: Master of Mobility video.

That video illustrates what Microsoft Access and Information Protection solutions offer. Over the next few days, I’ll explore the technology more deeply through a five-part blog series.

Scenarios

Microsoft’s products are designed to enable access and provide information protection. In these products, Microsoft considers AIP from a people-centric IT point of view, where it contains three pillars:

• Enable users to be productive
• Protect your corporate data
• Unify your environment

In this week’s series of posts, we won’t be discussing how to unify your environment: You’ve already seen elements of that, particularly in the discussions about Hybrid Identity. Instead, we will focus on enabling users while protecting your data.

Here are some examples:

• Use Workplace Join (a feature of Active Directory Federation Services), Web Application Proxy, and Active Directory Domain Services (AD DS) to allow users to register devices to gain access to corporate resources.
• Use Work Folders so that users can synchronize their work files across all of their devices.
• Use Web Application Proxy so that the IT department can publish corporate resources to users working outside the LAN on various devices.
• Use Microsoft Azure Multi-Factor Authentication (MFA) along with these other features to enforce additional user identity verification on access.
• Use Dynamic Access Control and File Classification to ensure that compliance requirements are met.
• Use Microsoft Rights Management services to protect corporate information at rest and in transit, and require authentication on open

Sounds exciting, doesn’t it? Are you ready to enter this new world, where access and information protection are ubiquitous?

Setting up your environment

Like most things in computer technology, some steps have to happen first. Each version of the operating system introduces new features, but another key component of Microsoft’s strategy is building on your existing investments.

The most important starting point is a consistent view of identity—of who your users are and what you know about them. We discussed this in some detail a couple of weeks ago, so if you didn’t read that at the time, you might want to review those posts.

The good news is that most of you are well on your way, because you’re probably already using Active Directory and Microsoft Azure Active Directory. About 93 percent of Fortune 500 organizations use Active Directory, and Azure Active Directory is currently completing over 2 billion authentications per day.

Your environment can be completely on-premises (AD DS) or completely cloud based (Azure Active Directory), but for most of us, there will be a combination of the two. Review the Hybrid Identity posts to learn about how to federate or synchronize between the two.

To use some of the new features, certain elements must be in place. Refer to the following table to see which features are available to you and where you might want to upgrade.

Now that you have an idea of what you need, tune in tomorrow to start making resources available to users.

Learn more about Access and Information Protection here.