Modern Device Management is a new feature in BigFix 10 that leverages several new technologies to deliver a new management capability for Windows 10 and Macintosh computers. The Modern Device Management allows you to perform a limited number of management operations on Windows 10 and Macintosh clients that do not have the BigFix client installed. You can also easily deploy the BigFix client to devices that have enrolled with the modern device management server to enable the full range of BigFix systems management tools.
The modern device manager utilizes some new technologies you may not be familiar with or may have only limited familiarity with. The primary difference between the MDM web server and previous BigFix web interfaces is the use of Docker containers. Containerization is a new way of thinking about application development and deployment. A container runs on top of a regular OS install but runs within its own protected memory, storage, and networking space. This allows you to safely run several different applications on a single OS instance which reduces resource usage compared to deploying each application on a virtual machine that has its own operating system. In this case (unless you’re deploying a very large MDM infrastructure and have some support from HCL) the major benefits of containerization are not leveraged. HCL requires a specific OS with specific dependencies so the docker container must reside on top of a specialized VM; however, the use of Docker in development points to some exciting possibilities down the road. The BigFix Root Server, in particular, is designed in such a way that each process (gather, filldb, gatherdb, web server) could be separated into specific containers. Along with container orchestration schemes like Kubernetes, a containerized BigFix delivered on cloud hardware would be nearly infinitely scalable. BUT that’s just speculation. Right now, we’ve got one containerized application to deploy.
*** Disclaimer: Your BigFix environment must be running version 10 ***
Contact BFX Global Services for your One-Stop Full-Service BigFix Experts
We provide Health Checks, Upgrades, Deployments, & Troubleshooting
The first step is deploying a Red Hat Enterprise Linux 7 virtual machine. Some guides suggest using a GUI install of RHEL but that is unnecessary for this deployment and adds a great deal of overhead. Generally, if you’re going to be running a headless web application it is best to use a non-GUI installation. If you do not have an RHEL 7 template or VM already deployed follow these instructions (this assumes a virtualization solution – these are generally geared toward VMware but should be replicable on KVM, Virtualbox, or any other virtualization solution).
1. Obtain as RHEL 7 iso. If you do not have an enterprise license you can apply for a developer license (developer.redhat.com). If you are using a developer RHEL 7 license you cannot use the MDM server in production.
2. Allocate at least 50GB of storage for the virtual machine. A minimum of 1 core and 1GB of memory will run the application but you may want to dedicate more hardware to ensure it performs properly.
3. You can use the text-based installer or the GUI installer. The simplest way to install is to use the guided partition scheme and install the minimal installation. You will need to set a root password and should create at least one user.
4. After the installation is complete you will have a text-based login screen. Because we are using the minimal install sudo is not installed by default. Generally, when performing *nix system administration you should not use the root account—instead, you should use a regular user account with sudo. For this non-production server, we will use the root account to simplify operations.
5. Log in as the root account with the password you set above.
6. You will notice the command prompt ends with a #. That signifies that you are executing commands as the root user. A regular user will see a $. The root user has full permissions to the entire system so you can damage the system if you issue improper commands.
7. First, we need to activate a subscription and update the system to the most recent package versions.
a. First, we need to register the server with RedHat. You will need to have your RedHat account information available (if you set up a developer account that will be sufficient). To register the server, enter the following command: subscription-manager register You will need to enter your account credentials. After the command completes successfully the system is registered.
b. Second, we’ll need to attach that subscription to the system. You can automatically attach subscriptions by appending –auto-attach to the registration command as well. The command to attach is: subscription-manager attach
c. Finally, we’ll need to update the package list and the installed packages with the following command: yum update && yum upgrade -y The -y option tells the package manager to apply the updates without prompting.
8. Then we’ll need to install the dependencies.
a. First, we install Docker with the following command: yum install -y docker
b. Second, we install docker-compose: yum install -y docker-compose
c. Both of these commands will generate a list of required dependencies to install the requested packages. The - Y flag tells the package manager to automatically install the packages without prompting.
d. The RHEL version of docker-compose does not install all of its files where BigFix expects. To ensure the Fixlet will become relevant we will create a symbolic link: ln -s /usr/bin/docker-compose /usr/local/bin/docker-compose
e. Some instructions online use the Docker releases directly from Docker. The version RedHat packages is sufficient for this installation and in most cases, it is best to use the packaged version from your distribution vendor.
9. Finally, we need to install the BigFix Client.
a. First, we’ll need to get the masthead for your BigFix installation. We can easily get it from your root server or any relay with the following command: wget http://ROOT_SERVER_OR_RELAY:52311/masthead.afxm
b. Second, we’ll need to create a directory for the masthead: mkdir -p /etc/opt/BESClient
c. Next, we will need to copy the masthead to the directory we just created: cp masthead.afxm /etc/opt/BESClient/actionsite.afxm Be sure to use the correct filename – the Linux client is looking for that exact file and will not start if it is not present.
d. Next, we’ll download the client from HCL (you MUST be running BigFix 10 to deploy an MDM server): wget http://software.bigfix.com/download/bes/100/BESAgent-10.0.0.133-rhe6.x86_64.rpm
e. Finally we’ll install the BigFix client: yum install ./BESAgent-10.0.0.133-rhe6.x86_64.rpm
10. After we install the BigFix client and the server is visible in BigFix we should see task #4003 in the BESUEM site as relevant for the server.
11. The fixlet display will have several fields we need to fill out:
12. To install the MDM component, we will need to have multiple different certificates. It is best to use a trusted root certificate for a production MDM server because incoming clients may not trust certificates specific to your environment. If you have a preferred certificate vendor or a wildcard certificate you can use those. You can also use a self-signed certificate; however, Let’s Encrypt provides free certificates and it is fairly easy to use. One significant drawback of Let’s Encrypt certificates is that they are only issued for three months. Because of this drawback Let’s Encrypt certificates are not appropriate for a production environment unless you intend to consistently update the certificate. Keeping the certificate up to date is beyond the scope of this article.
13. To issue certificates from Let’s Encrypt you will need to have the Certbot application installed on your MDM server, port 80 open to your MDM server and an external DNS record created for the name you have assigned to your MDM server (this does not have to be the internal DNS name – it can be whatever you like). Opening and external port and creating an external name are beyond the scope of this article as the process will be different for every environment.
14. Installing Certbot is simple. Just use the following command: yum install -y Certbot
15. After Certbot is installed you can use the following command to issue a certificate: "certbot certonly". You will need to supply some information about your organization, an email address, and the fully qualified domain name for the server. This should be the external DNS name you used above. If everything works properly you will be issued a valid certificate and the certificate, PKI chain and private key will be saved to /etc/letsencrypt/live/FQDN/
16. Next, we need to generate keys to authenticate the MDM server to BigFix. We’ll do this using the BigFix administration tool. You will need to have your BigFix private key and password for this step.
17. Log on to the BigFix root server. Use the command prompt or terminal to navigate to the directory the BigFix server is installed in (C:\Program Files (x86)\BigFix Enterprise\BES Server is the default on Windows).
18. Use the following command to generate the plugin certificates: besadmin.exe /generateplugincertificates /certificatespath:<storage location> /commonname:FQDN
19. Once you have generated all of the certificates you will have the data to enter in the fields above. For the Organization Name enter an appropriate text string for your organization. For the User facing hostname enter the FQDN from above. For LDAP URL enter ldaps://LDAP_DIRECTORY_SERVER:636 For the Base DN enter the base distinguished name for your LDAP directory (example: DC=example, DC=com) For the LDAP Bind User enter a user in the directory with appropriate permissions to access the parts of your directory that contain the users and groups that should be able to use the MDM server. This can be the same account you use for BigFix LDAP binds. For the LDAP Bind Password enter the password for the user account above. For the MDM Server TLS Key Password enter any value. For the MDM Server TLS Certificate content paste in all of the text in the file /etc/letsencrypt/live/FQDN/cert.pem For the MDM Server TLS Key content paste in all of the text in the file /etc/letsencrypt/live/FQDN/privkey.pem For the MDM Server Certificate Authority content paste all of the text in the file ca.cert.pem that was generated on the BigFix root server above. For the MDM Server Certificate content paste all of the text in the file server.cert.pem that was generated on the BigFix root server above. For the MDM Server Key content paste all of the text in the file server.key that was generated on the BigFix root server above.
20. Once you have entered all of that data click on the take action button and target the MDM server with that action. The BigFix Client will pick up this task and deploy the MDM application.
21. Once complete you can navigate to the MDM server in your browser and you should see the following:
In another article, we’ll take you through enrolling a system using the MDM server, what management commands can be issued, and how to deploy the BigFix client to systems that have enrolled through the MDM server.
Contact BFX Global Services for your One-Stop Full-Service BigFix Experts
Visit us at www.bfxglobalservices.com