This process sets up a simple BYOD management policy for Android Devices.
Planning Ahead.
Turning on Mobile Device Management for school accounts requires some pre-planning. The results can be quite invasive especially if your users are already using school accounts for syncing data to the personal devices.
Because you will be updating personal devices there needs to be a dialog between students and staff informing them of the policy change prior to the setting the options. This will give users the opportunity to remove an organisational account if they don’t intend to accept management on their mobile.
The most important advice is to test out the configuration on a limited set of users before applying to a wider group.
For these reasons identify a Google sub-organisation that contains a test user account or create one for the purpose and only apply policies to this sub-OU during the testing phase.
Wireless Configuration.
In a school environment it’s sometimes preferable, but not essential to set up a wireless channel (SSID) specifically for BYOD. Depending on the capabilities of the wireless system, this would allow the school to deliver a security profile more suited to BYOD as well as restricting access to internal resources and provide options with respect to tracking and reporting.
The first step is to create a wireless config that can be delivered to the personal device as part of the management profile.
Creating a Wireless Profile.
Sign into the admin console and navigate to
An example is shown above. Details will vary for your implementation. One important point is to select Mobile Devices as the platform. This ensure that the policy will only apply to managed mobile devices and not other devices such as Chromebooks.
You need to select the by user option in the Apply Network section. Although mobile devices are visible within the console they are not part of the OU policy tree. Therefore the policy is applied to the user account and not the device and as a consequence will affect every mobile device accessed by the user using the school Google account.
Trying to select the devices option generates the error:
Mobile devices cannot be selected when network type is set to Devices.
If you plan to use the same SSID as Chromebooks or other devices it’s recommended to set up a new profile with the same Service Set IDentifier but with a different Name. It’s possible to reuse an existing entry if all the details suit your BYOD deployment but the type would have be User which is unlikely as the recommendation for most Chromebook deployments is Device.
The end result should look something like this.
Turning on Device Management.
Sign into the admin console and navigate to
Set the options as shown below.
The key item is Manage Android devices. This is the toggle for turning device management ON and OFF at the highest level. While it’s set to OFF no action occurs.
Controlling Device Access.
As an option it’s possible to ‘quarantine’ devices so that administrator approval is required before access to the network is granted. This is policy decision rather than a technical requirement.
Access can controlled at a sub-OU level so user level admin approval is only useful if some other benefit results; such as the acceptance of a UAP.
Actions on the User Device.
Once the Manage Android devices is set the policy will be applied when the user attempts to access a Google resource using a school organisational account on any Android device. The first action is the automatic installation of the Google Device Management app and a notification to the user. The user will see the message below.
The dialog provides the user with a list of the policies to be applied and and an option to accept or reject the policy set.
If the policy is dismissed certain actions will be blocked. For instance if the policy is rejected by the user they will be unable to sync data to the device from GMail or Drive regardless of whether this action is allowed by the user policy.
The device must meet all the policy requirements before protected resources are available.
In the situation below the Device Configuration app explains that the user must update passwords before services are activated.
The user is free to remove the policy at any stage but will not be able to access Google services using an organisation account on this device until it’s re-installed. In our example uninstalling the Device Policy app will also delete the wireless profile and as a consequence deny access to the school network.
Console Management.
Once the policy is accepted the device is associated with the user account and becomes visible on the administrator console. The wireless configuration is installed as part of the package.
To view the device details sign into the admin console and navigate to :-
To approve or deny a new device, select the device using the check box and then either APPROVE or BLOCK the device from the option on the menu bar.
Note: The search option doesn't cover the status field. This view has its own dedicated section.
The Remote Wipe function forces a factory reset of the device. All local data is removed and the device is removed from control. Status moves to Device Wiped. The record will remain on the console until deleted.
The Delete option simply removes the administrative record from the console. When the device next syncs it will be treated as an new device and record recreated.
If the option to record local application has been selected these are shown as an appended list but are limited to Google related installs, not 3rd party apps.
One useful function is the ability to manage all of these activities from your mobile device (below).
The Google Admin app has a well developed section that will allow you select a device and then view the information with the block, wipe, delete and approve options.
Other Policies.
This simple example delivers a wireless configuration with default policy settings, however the GSuite console has the ability to set addditional policies at a sub-OU level. The Manage Android Device policy must be ON for the relevant sub-OU for the options to be editable.
The licence free options are listed below with a suitable setting for BYOD.
Device password strength.
Minimum password length.
Number of invalid passwords allowed before the device is wiped.
Number of recently expired passwords that are blocked.
Number of days before a device password expires.
Number of idle minutes before a device automatically locks.
Note: The procedure for placing other platforms under control varies slightly although the approach is exactly the same. The Windows Mobile requirement is documented here with IOS to follow.The objective is to allow users to add their personal mobiles onto the network in a controlled and secure manner without any physical involvement from the IT team and without having any knowledge of passwords or keys. Once enrolled the administrator will have the right to remove and ban devices from the network as well as being able to match personal devices with user accounts for reporting purposes.
Planning Ahead.
Turning on Mobile Device Management for school accounts requires some pre-planning. The results can be quite invasive especially if your users are already using school accounts for syncing data to the personal devices.
Because you will be updating personal devices there needs to be a dialog between students and staff informing them of the policy change prior to the setting the options. This will give users the opportunity to remove an organisational account if they don’t intend to accept management on their mobile.
The most important advice is to test out the configuration on a limited set of users before applying to a wider group.
For these reasons identify a Google sub-organisation that contains a test user account or create one for the purpose and only apply policies to this sub-OU during the testing phase.
Note: This is where Google policy management becomes a little inflexible It’s not possible to create a group and apply a policy to just those members or create a single policy object and ‘pin’ it to a number of sub-OU’s in the way you can with a Microsoft GPO. The user objects are already in a fixed structure and testing a student account and a staff account at this stage probably means setting the policy in two places. However better that than setting it at a higher level before testing has completed.The policy will grant access to the internet via the school's wifi network. This is a privilege which should be subject to an acceptable use policy (AUP) agreed by all parties.
Wireless Configuration.
In a school environment it’s sometimes preferable, but not essential to set up a wireless channel (SSID) specifically for BYOD. Depending on the capabilities of the wireless system, this would allow the school to deliver a security profile more suited to BYOD as well as restricting access to internal resources and provide options with respect to tracking and reporting.
The first step is to create a wireless config that can be delivered to the personal device as part of the management profile.
Creating a Wireless Profile.
Sign into the admin console and navigate to
Device Management → Network → Wi-Fi Add Wi-FiYou can set this policy at any appropriate level in the OU tree. Restrictions within the policy limit it's function to personal Mobile Devices.
An example is shown above. Details will vary for your implementation. One important point is to select Mobile Devices as the platform. This ensure that the policy will only apply to managed mobile devices and not other devices such as Chromebooks.
You need to select the by user option in the Apply Network section. Although mobile devices are visible within the console they are not part of the OU policy tree. Therefore the policy is applied to the user account and not the device and as a consequence will affect every mobile device accessed by the user using the school Google account.
Trying to select the devices option generates the error:
Mobile devices cannot be selected when network type is set to Devices.
If you plan to use the same SSID as Chromebooks or other devices it’s recommended to set up a new profile with the same Service Set IDentifier but with a different Name. It’s possible to reuse an existing entry if all the details suit your BYOD deployment but the type would have be User which is unlikely as the recommendation for most Chromebook deployments is Device.
The end result should look something like this.
Turning on Device Management.
Sign into the admin console and navigate to
Device Management → Setup → Mobile ManagementOnly highlight the sub-OU that contains the user accounts that you wish to place under control at this stage.
Set the options as shown below.
The key item is Manage Android devices. This is the toggle for turning device management ON and OFF at the highest level. While it’s set to OFF no action occurs.
Controlling Device Access.
As an option it’s possible to ‘quarantine’ devices so that administrator approval is required before access to the network is granted. This is policy decision rather than a technical requirement.
Access can controlled at a sub-OU level so user level admin approval is only useful if some other benefit results; such as the acceptance of a UAP.
Actions on the User Device.
Once the Manage Android devices is set the policy will be applied when the user attempts to access a Google resource using a school organisational account on any Android device. The first action is the automatic installation of the Google Device Management app and a notification to the user. The user will see the message below.
The dialog provides the user with a list of the policies to be applied and and an option to accept or reject the policy set.
If the policy is dismissed certain actions will be blocked. For instance if the policy is rejected by the user they will be unable to sync data to the device from GMail or Drive regardless of whether this action is allowed by the user policy.
The device must meet all the policy requirements before protected resources are available.
In the situation below the Device Configuration app explains that the user must update passwords before services are activated.
The user is free to remove the policy at any stage but will not be able to access Google services using an organisation account on this device until it’s re-installed. In our example uninstalling the Device Policy app will also delete the wireless profile and as a consequence deny access to the school network.
Console Management.
Once the policy is accepted the device is associated with the user account and becomes visible on the administrator console. The wireless configuration is installed as part of the package.
To view the device details sign into the admin console and navigate to :-
Device Management → Select the Mobile devices pane.This displays a searchable list of all personal devices currently under control with the final column showing a status. If the Approval required policy has been selected this will show Pending for all new devices.
To approve or deny a new device, select the device using the check box and then either APPROVE or BLOCK the device from the option on the menu bar.
Note: The search option doesn't cover the status field. This view has its own dedicated section.
Device Management → Mobile Devices → Device ActivationThe Wipe Account function removes the organisation user account profile from the device. All user passwords and locally cached data are deleted. The device remains under control and allocated to the same user account. Status moves to Account Wiped.
The Remote Wipe function forces a factory reset of the device. All local data is removed and the device is removed from control. Status moves to Device Wiped. The record will remain on the console until deleted.
The Delete option simply removes the administrative record from the console. When the device next syncs it will be treated as an new device and record recreated.
Note: Wiping the account, deleting the record and then registering under another account will update the Name field.Details on the device can be displayed by selecting the device name.
If the option to record local application has been selected these are shown as an appended list but are limited to Google related installs, not 3rd party apps.
One useful function is the ability to manage all of these activities from your mobile device (below).
The Google Admin app has a well developed section that will allow you select a device and then view the information with the block, wipe, delete and approve options.
Other Policies.
This simple example delivers a wireless configuration with default policy settings, however the GSuite console has the ability to set addditional policies at a sub-OU level. The Manage Android Device policy must be ON for the relevant sub-OU for the options to be editable.
The licence free options are listed below with a suitable setting for BYOD.
Device Management → Password Settings.
| Password Settings | Require users to set a password | OFF |
Device password strength.
Minimum password length.
Number of invalid passwords allowed before the device is wiped.
Number of recently expired passwords that are blocked.
Number of days before a device password expires.
Number of idle minutes before a device automatically locks.
Device Management → Android Settings.
| Application Auditing | Enables application auditing in the personal profile. | ON |
| Auto Account Wipe | Wipes Device if Sync is missed | OFF |
| Notifications | Allow notification details on lock screen | ON |
| Screen widgets | Allow lock screen widgets | ON |
| User Remote Wipe on Android | Allow user to remote wipe device from Android Device Manager | ON |
Device Management → Advanced Settings.
| Compromised devices | Block Compromised devices | ON |
| Encryption | Require device encryption. | OFF |
| Camera | Allow Camera | ON |
No comments:
Post a Comment