Christian/ Dezember 25, 2022/ Allgemein

Nach dem wir nun den MicroMDM Service am laufen haben, damit nun schon enrollment Profile anpassen können und unsere ersten Devices dem MDM hinzugefügt haben, benötigen wir nun noch einen Webhook-Server um den vollen Umfang eines MDMs nutzen zu können – insbesondere das installieren von weiteren Profilen.  

Ich habe mich für den MDMDirector entschieden, welchen ich in meinem Falle auf dem selben Server laufen lasse. Natürlich kann man diesen auch auf einen dedizierten Device installieren…

Installieren und Konfigurieren der Abhängigkeiten

Der MDMDirector benötigt folgende Pakete:

  • Redis
  • PostgresSQL

Redis installieren

  • apt -y install redis-server -y
  • ggf. anpassen: vi /etc/redis/redis.conf
appendonly yes 
appendfilename "appendonly.aof"

Anschließend aktivieren und starten:

  • systemctl enable –now redis-server.service
  • systemctl restart redis-server

PostgreSQL installieren

  • apt install postgresql postgresql-contrib -y
  • systemctl status postgresql

Nun müssen wir noch einen Webhook User in der Datenbank anlegen, ein Passwort setzen und die Formatierung anpassen: su – postgres createuser webhook createdb webhook -O webhook psql

ALTER USER webhook WITH password 'DB_PASSWORD'; 
ALTER USER webhook SET client_encoding='UTF8'; 
ALTER DATABASE webhook SET client_encoding='UTF8'; 
SET client_encoding='utf-8'; exit

MDMDirector installieren

Als erstes installieren wir wie bei MicroMDM die Applikation von meinem Debian (/usr/bin)

Damit können wir im terminal selbst dass erstmal den Service starten – hierzu müssen nur einige Parameter noch entsprechend und sinnvoll angepasst werden:

mdmdirector \
   -micromdmapikey 'SECRETTOKEN'  \
   -micromdmurl https://MDM.DOMAIN.TLD  \
   -password 'MDMDirector_PASSWORD' \
   -port 8000 \
   -db-host "localhost" \
   -db-name "webhook" \
   -db-username "webhook" \
   -db-password "DB_PASSWORD" \
   -db-port 5432 \
   -redis-host "localhost" \
   -redis-port 6379 \
   -cert /etc/ssl/CERT.p12 \
   -key-password "P12_PASSWORD" \
   -sign \
   -loglevel "info" 
Sollte der Service damit laufen, können wir im mit dem mdmcli in einer zweiten Terminal Session einige Befehle absetzen. Den Output sollten von MDMDirectory sollten wir dann in dem Fenster sehen, in dem wir den obigen Befehl abgesetzt haben.

MDMDirector als Service Deamon 

Damit wir nicht ständig eine Terminal-Session offen halten müssen, empfiehlt es sich ähnlich wie bei MicroMDM einen Service zu definieren. Dies machen wir wie nachfolgend (PS: Ihr könnt dabei die Parameter vom vorherigen Abschnitt entsprechend übernehmen.

Erstellen eines Service

  • vi /etc/systemd/system/mdmdirector.service
[Unit]
Description=MDMDirector - opinionated orchestrator for MicroMDM
Documentation=https://github.com/mdmdirector/mdmdirector
After=network.target

[Service]
User=mdm
ExecStart=/usr/bin/mdmdirector \
    -micromdmapikey 'SECRETTOKEN'  \
    -micromdmurl https://MDM.DOMAIN.TLD  \
    -password 'MDMDirector_PASSWORD' \
    -port 8000 \
    -db-host "localhost" \
    -db-name "webhook" \
    -db-username "webhook" \
    -db-password "DB_PASSWORD" \
    -db-port 5432 \
    -redis-host "localhost" \
    -redis-port 6379 \
    -cert /etc/ssl/CERT.p12 \
    -key-password "P12_PASSWORD" \
    -sign \
    -loglevel "info" 
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enable des Service

  • systemctl daemon-reload
  • systemctl enable mdmdirector.service && systemctl start mdmdirector.service

Service Handling

  • systemctl start mdmdirector.service
  • systemctl restart mdmdirector.service
  • systemctl status mdmdirector.service

Service Logs

  • journalctl -u mdmdirector.service -f

MicroMDM Webhook hinterlegen

Damit MicroMDM mit dem MDMDirectory kommunizieren kann, müssen wir noch folgenden Parameter ergänzen (im Service von MicroMDM)

Bitte beachtet dabei, dass der Webholk-Server von MDMDirectory out-of-the-box nur unverschlüsselt läuft (http). Solltet ihr diesen auf einen dedizierten Server laufen lassen und nicht auf dem selben (localhost) empfiehlt es sich, die Session via TLS zu verschlüsseln (https). Dazu benötigt Ihr aber dann einen zusätzlichen reverse Proxy auf dem Server (z.B. apache oder nginx) für diesen Anwendungsfall.

Share this Post