BYOD user and device considerations
The first user and device issue you need to address is how the technologies in place will affect the user experience when securely accessing company resources. Addressing the user experience across different devices can be challenging, not only from a security point of view, but also from the perspective of app development. The communication channel between the device and company resources must be considered for the proper level of network security required to avoid data leakage while data is in transit.
The sections that follow are based on components for the Users and Devices subdomain shown in Figure 1 in BYOD Problem Definition, which is the conceptual diagram for the BYOD problem domain.
Understanding users’ needs and requirements to perform their jobs from the devices of their choice is essential when designing your BYOD infrastructure solution. Not all users will have the same requirements; some users will always access data on-premises, and policy enforcement for them can be different. Remote workers will be accessing company data from a variety of locations and circumstances. You must consider the options available to address these needs. Determine each user’s profile according to their needs:
Do they need to access apps only?
Do they need to access folders located on a file server?
Though the following table suggests a set of requirements for each user’s profile, you can customize this table by adding or removing requirements based on your company’s needs. The rationale of each profile category compared to what it should contain is based on the resources it consumes. For example, the light profile means low utilization of resources on the device and low network requirements. Ensure that you understand each user’s profile footprint; this will allow you to make more appropriate choices throughout the rest of the design process.
Use the following table to determine the user profile type and common capabilities that should be available.
User profile types
You will need to determine which user profile is more suitable for your BYOD infrastructure solution. You might consider establishing multiple users’ profiles according to their job requirements. Ideally, the technology that you use to implement your BYOD infrastructure solution should be able accommodate all user profiles, because the requirements might vary according to each individual. Refer to 4.2.3 Network for more information about the network options available.
IT must determine if it requires knowledge of devices. For example, one BYOD scenario is hourly employees checking their time sheets or reviewing corporate notices or social sites when out of the office. In many organizations, these requirements were traditionally LAN-only services, but now they may be opened to personal devices. Does someone checking their schedule require device management? Understanding the devices’ footprints will help IT to:
Track which user is registering devices: a user registering a number of devices every week might indicate suspicious activity.
Understand devices’ footprints: knowing which types of devices are in use on the network can help IT support those devices.
Consider having the link between the device and the user stored in a central location that can be later used by IT when performing auditing or reporting. IT needs to move from an unknown device state to a known device state to enable BYOD. This will allow IT to have more control of devices that are corporate assets. Usually, companies approach this requirement in three different ways:
Approach 1: Installing a management agent in each user’s device.
Approach 2: Registering each device in a central repository without installing a management agent.
Approach 3 (1+2): Registering and installing a management agent in each user’s device.
The following table lists the advantages and disadvantages of each of these approaches.
Unknown-to-known device options
Installing a management agent in each user’s device.
Registering each device in a central repository without installing a management agent.
Registering and installing a management agent in each user’s device.
In Windows Server 2012 R2, the new concept of Workplace Join allows IT to move the device from an unknown state to a known state. The device can also be used as second-factor authentication and single sign-on to workplace resources and apps. Workplace Join is natively available in Windows 8.1, but it is also supported in other platforms such as iOS and Android. Workplace Join leverages the Device Registration Service (DRS). For more information about DRS, read Configure a federation server with Device Registration Service. Workplace Join is new technology and works with specific use cases. See Secure access to company resources from any location on any device for more information about a solution that leverages Workplace Join with single sign-on.
If you consider using DRS, understand that this feature does not provide management capabilities. If your company needs more security controls in order to have more options available to control users’ devices, consider using DRS in conjunction with mobile device enrollment as the management agent solution. However, if you choose this option, you must have a Windows Intune subscription. For more information about Windows Intune, see the Windows Intune Getting Started Guide.
Corporate network access from the user and device perspective must be addressed. How will users access company data while using their own devices? Most BYOD infrastructure solutions focus only minimally on remote access from users’ devices; however, from a people-centric approach, you must consider where users are physically located. You should focus on not only remote access, but also how users will access the data while on-premises. In addition, you will need to consider regulatory issues specific to your organization's geopolitical alignment. For example, how can users that are physically located in a different country have personalized network access?
If your company has resources in the public cloud that will be accessible via the Internet from users’ devices, you must consider how traffic will be handled. Consider using encryption while the data is in flight from users’ devices to the cloud provider. When users are accessing internal resources, you should also use data encryption.
The following table describes network connectivity options, and the advantages and disadvantages of each.
Microsoft Direct Access
Automatic Trigger VPN
Remote Desktop with VDI
After you define the design for remote network access, consider how user-owned devices will connect to your network while they are physically connected to it. Users who bring their devices to work will likely be using Wi-Fi capabilities to connect to corporate resources. You should consider using network segmentation (physical or logical) for users’ devices in order to isolate them. You can also segment the devices that will connect to the Wi-Fi network according to the platform they run. Also consider how to secure their communication and authorization while they are on-premises accessing corporate resources.
You can choose a physical segmentation on your wireless access point and network components (switches and routers) to isolate users who are connecting by using their own devices. You can also implement this type of segmentation by using Wi-Fi Profiles in Configuration Manager. A wide range of security settings is available, such as certificates for server validation and client authentication that have been provisioned by using Configuration Manager certificate profiles.
Wi-Fi network segmentation options
Logical segmentation (Wi-Fi profiles)
For more information about Wi-Fi Profiles in Configuration Manager, see Introduction to Wi-Fi Profiles in Configuration Manager.
Network location plays an important role for user and device considerations. You can leverage multi-factor access control in AD FS to enable per-application authorization policies, whereby you can permit or deny access based on user, device, and network location. See Manage Risk with Multi-Factor Access Control for more information about how to set up an environment to validate this capability.