Sunday, 30 August 2020

Block apps from running on fully managed Android devices

My customer is using Microsoft Intune to manage Android devices (Samsung A51) which have been enrolled as "fully managed" devices. We have a device configuration profile in place to manage the device restriction settings. The customer also wants to block consumer and system apps that are pre-installed by the OEM and gave us a list of apps.

First I looked at a restricted apps policy. This is used to allow or prevent specific apps on devices. It is supported on Android and Samsung Knox Standard devices but is only available for "device administrator" management.


Next I decided to look at uninstall packages for the apps. I created packages for some of the apps based on their URL in the Google Play Store. Then I assigned the packages as Uninstall to the Android device group. This worked well but unfortunately, not all the apps were available in the Play Store, so this was an incomplete solution.

I found the answer with Android Enterprise system apps.


This allowed me to create the app packages using the Package Name, with no reference to the Play Store. Every Android app has a registered package name. You just have to be able to find it.

This search link will give you details on package names for all system apps pre-installed on many Samsung models. I found everything I needed and was able to create the uninstall packages.
  • Navigate to the Endpoint Manager admin center to create the apps.
  • Click Apps > All Apps > Add
  • For the App Type, look at the bottom option and choose Android Enterprise system app.

  • Click Select to commence the Add App wizard.

  • This is where you enter the app details. Pay particular attention to the Package name. It must be entered correctly. The tooltip tells us to contact the device manufacturer to get the system apps package name of the format com.example.app. Click Next to continue.
  • You only have two options on the Assignments page. To enable an app, assign the system app as Required. To disable an app, assign the system app as Uninstall. System apps cannot be assigned as available. Select the assignment groups and click Next.
  • Review and create the app.
I was able to prevent the apps in the table below from running and satisfy the customer requirement.

App

Package Name

Netflix

com.netflix.mediaclient

Galaxy Store

com.sec.android.app.samsungapps

Verizon Call Filter

com.vzw.ecid

Verizon Cloud

com.vcast.mediamanager

Verizon Digital Secure (Safe)

com.securityandprivacy.android.verizon.vms

My Verizon

com.vzw.hss.myverizon

AR Zone

com.ARZone.arzone

Bixby Voice 

com.samsung.android.bixby.agent

Bixby Voice Stub

com.samsung.android.bixby.agent.dummy

Bixby Home

com.samsung.android.app.spage

Bixby Service

com.samsung.android.bixby.service

Bixby Vision Framework

com.samsung.android.bixbyvision.framework

Game Launcher

com.yujimny.android.gamelauncher

Samsung Internet

com.sec.android.app.sbrowser


I hope this helps. Until next time....

Tuesday, 18 August 2020

CMG and VPN split tunnelling

Let's first consider some CMG scenarios. First and foremost we deploy a CMG to manage internet-based clients. However, when the CMG is in place it can also be used to alleviate traffic on the VPN, subject to configuration of VPN split tunnelling. It is important to note the distinction between internet-based clients and those using the VPN. They are both remote clients but ConfigMgr handles them differently. Clients using the VPN will be deemed to be on the Intranet because they can communicate with a domain controller and a management point. Otherwise they are deemed to be on the Internet. 

Scenario 1: 


No additional boundary/boundary group configuration - CMG can manage devices truly on the internet that are not connected via VPN. Policy and content requests will be directly to internet with no chance of using corporate network.


Scenario 2: 


Configure boundary group for VPN subnets and associate with CMG for policy and content - VPN devices will connect to CMG for policy and Cloud distribution point for content. These requests will be made through the corporate network unless the traffic is routed directly to internet. Split tunnelling configuration is required to implement.


So what do we need to add to the split tunnelling configuration? It's very straightforward if your VPN configuration supports URLs. You need entries for the CMG and the storage account. The URLs are easy to find.



You'll find the service name in the properties of the CMG in the ConfigMgr console. You can see that the example from my lab is https://gerryhcmg.emslab.ie



What about the storage account? You'll find that in the Azure portal. See the example from my lab https://gerryhcmg.blob.core.windows.net/


You can also see this information in the log files on a ConfigMgr client. I have a test client installing software over CMG.



You can see the CMG URL in the CAS.log file.



Have a look in the DataTransferService.log file for the URL of the storage account. You'll see a line like:


Modifying download source from https://gerryhcmg.emslab.ie:443/downloadrestservice.svc/getcontentxmlsecure?pid=GH100009&cid=CONTENT_4E6083C7-411E-4CAD-AF2C-2633F6A4DCAA.1&tid=GUID:6B6A5684-4D64-44D8-ACD7-1CB28AB77307&iss=MEM.HAMPSON.LOCAL&alg=1.2.840.113549.1.1.11&st=2020-08-18T08:32:19&et=2020-08-18T16:32:19 to https://gerryhcmg.blob.core.windows.net/content-gh100009/Content_4e6083c7-411e-4cad-af2c-2633f6a4dcaa.1 (pre download)


What do you do if your VPN does not support split tunnel configuration via URL? It will be necessary to use IP addresses and ranges

The IP address of the CMG will not be known until it is deployed.


Then you'll find it in the Azure portal. It's 52.174.178.234 in my lab.

The IP ranges for Azure storage are published by Microsoft in a json file. However, it can be challenging to extract the information needed for your region. A Microsoft PFE (Ken Wygant) has published a community script to extract this information.


https://pfe.tips/get-azure-ip-ranges-your-cloud-management-gateway/


It gives you a list of IP ranges like this (this example is for EastUS2 region).



Then you can configure your split tunnel.


Thanks to Bryan Dam and Sandy Zeng for helping me to figure this out on the MVP distribution list.


I hope this helps. Until next time.....


Sunday, 5 July 2020

CMG and multiple root certificates

I was deploying a Cloud Management Gateway on a customer site recently and encountered this problem. This was a PKI deployment so I was adding internal root and intermediate certificates in the Settings page of the CMG wizard. 



I tried to satisfy the customer requirements but I was unable to add a third root certificate and received this error:

"You can only add two trusted root CAs and four intermediate CAs". 

I found that this was a limitation with CMG in ConfigMgr version 1902. This limit has been removed from version 1906 and later. 

The solution was obvious - upgrade the site to a later version.

I hope this helps. Until next time...…... 

Sunday, 21 June 2020

Cloud Management Gateway and Azure tags


I encountered this problem recently while deploying a CMG for a customer. Perhaps there was a better way for me to solve it but I'll explain the problem and how I worked around it. 

I got this error when creating the CMG. On my first try I was creating the resource group in the wizard.


Error occurred when granting Contributor permission to the Azure AD app for resource group xxxxx. For more information, see SmsAdminUI.log".

The error wasn't clear to me. I knew that I was using a Global Administrator account, which was also an Owner of the Azure subscription.  I didn't really understand the problem until I looked at the logs.

In the Azure activity log I found this.


It told me that the resource I was creating was disallowed by an Azure policy that had been configured. The policy was called "Require a tag and it's value on resource" and meant that resources could not be created in the subscription without tags and their associated values. I found the same text in the SmsAdminUI.log file. That makes sense. It's good for housekeeping, right?

However, ConfigMgr couldn’t create the resource group as there was a policy in place enforcing Azure tags, which I couldn’t configure in the wizard. I figured that I should create the resource group manually and apply tags to it. However I got the exact same error when I re-ran the wizard.

I finally solved it and created the CMG by disabling the policy. Perhaps there was a more graceful way to solve it but it allowed me to continue.

Remember, in ConfigMgr, logs are your friend.

I hope this helps.

Until next time...........

Sunday, 17 May 2020

CMG token based authentication with ConfigMgr 2002

A few years ago we were first introduced to the Cloud Management Gateway. It was a revolutionary new feature allowing us to manage all supported ConfigMgr clients over the internet. At that time the solution required that you configure a PKI solution so that the clients could communicate with the management point over https. Microsoft recognised that this was challenging for some organizations so, from version 1806, Azure AD joined Windows 10 devices could communicate with the management point over http (as long as we enabled enhanced http).

However that still didn't suit all organizations. Some organizations weren't ready for PKI or Azure AD join implementations and still needed to manage Windows 7 devices. ConfigMgr 2002 was generally released last week and includes a real game-changer. We can now used token-based authentication for communication between internet clients and the management point over http. The amazing thing here is that we don't have to do anything additional on the management point or client. All this works out of the box when you upgrade the ConfigMgr site to version 2002. Remember you MUST actually upgrade the clients to 2002 as well.

There are two scenarios and we'll look at both.

  • clients that can register on the internal network
  • clients that are always internet-based
Internal network

This is easy. It just works out of the box. When you upgrade a client to 2002 it will immediately register with the management point.



In the ClientIDManagerStartup.log file you will see the client receiving it's self-prove token from the management point.


This is a ConfigMgr 2002 client on the intranet. You will see that it is not configured for PKI (otherwise you would see Client certificate: PKI). It uses a self-signed client certificate (and the self-prove token behind the scenes).


The client is not Azure AD joined.


Now the client roams to the internet. It pairs it's self-signed certificate with the management point-issued self-prove token to communicate with the CMG.


The client is now aware of the CMG.


In the CcmMessaging.log file we can see the client receiving a CCM token which allows the communication to continue.


In the ConfigMgr console we can now see that the client is being managed over the internet.

An important thing to note is that the client renews the token once a month and it is valid for 90 days.

Internet-based

What can we do with clients that are already internet-based? We won't be able to automatically upgrade the client to 2002 and the client won't be able to register with the management point immediately and get the self-prove token. In this case we can use the bulk registration token.

Navigate (as administrator) to the \bin\x64 folder of the ConfigMgr installation directory on the site server.


Run the tool by executing: 

BulkRegistrationTool.exe /new

The token is generated. Remember this token has a short-validity period so you should use it straight away.


Copy the token.


Now install the ConfigMgr client on the internet-based device using the additional /regtoken parameter. I've done it manually by copying the installation files to the device and executing this command:

ccmsetup.exe /mp:https://GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 CCMHOSTNAME=GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 SMSSiteCode=GER SMSMP=https://MEM.hampson.local /regtoken:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1XUldSbUtVQlZjNlJDSGpCTjQyZnhvZUdEMCJ9.eyJTQ0NNVG9rZW5DYXRlZ29yeSI6IlNDQ01QcmVBdXRoVG9rZW4iLCJBdXRob3JpdHkiOiJTQ0NNIiwiTGljZW5zZSI6IlNDQ00iLCJUeXBlIjoiQnVsa1JlZ2lzdHJhdGlvbiIsIlRlbmFudElkIjoiN0IwQzM4MDYtRDI4Qy00QTQ1LUFEQjItRkI5Rjk0QTQ2MkY4IiwiVW5pcXVlSWQiOiJlYTJmYzUxMC1hM2JlLTRjZWYtOTBiMC0yYTA1MTVjNGU0MGMiLCJpc3MiOiJ1cm46c2NjbTpvYXV0aDI6N2IwYzM4MDYtZDI4Yy00YTQ1LWFkYjItZmI5Zjk0YTQ2MmY4IiwiYXVkIjoidXJuOnNjY206c2VydmljZSIsImV4cCI6MTU4OTcwMTUxOCwibmJmIjoxNTg5NDQyMzE4fQ.Y-6s6_h18cnIZP8OPqdjpxQHUhg_4srICehX5xOfym5AcyQRC3wlN89PAByFD2gfp6QvV7gXX9H7oG198UGHhUuJrthAipSo4KNCSr8t7TcZwjR9awt720tErf9aiflBKnFibAYAGU9xBS3UYTetQ6XYpdh0XsCedsbh0-6ilj6KmP1qWBFIYNkBaL3oP_HJhX02de0wqeh-fWiTtdvbKnOxDrGetoCKsEVp3sJumprzWHZ6ZpRD3powG3AUOOSbAW96c_driDvzwC6x6hoWOo4GPEs-BaoJUdRzi1htY9IJB2X_drIQqLH8X0Ps6B5H5-KGH3gB0tJA45WwERuLxA


As before you will see the client getting it's CCM token from the CMG in the ClientIDManagerStartup.log file.


The client is installed.


In the ConfigMgr console we can see that the device is managed by the CMG over the internet.

There are obviously a few challenges in this scenario:

How does the remote user get the ConfigMgr 2002 client installation files?

I plan to use this scenario in production and I intend to copy the files and installation instructions to OneDrive to make available to users.

How can the user install the client if they are not a local administrator?

This one is more challenging. The users will need some assistance with elevated rights, possibly using screen-sharing software. This also highlights a great use case for a solution like Local Administrator Password Solution (LAPS).

I think this feature will be extremely useful so I hope this walkthrough was helpful.

Until next time......