Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

This entry is part 4 of 4 in the series SSL leicht gemacht

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.

Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.

Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort “clientbasierte Zertifikats-Authentifizierung” kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).

Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.

Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL

1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr

5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.

Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register “Ihre Zertifikate” nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.

Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!

Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir um!

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

i-doit API create, update, delete

This entry is part 2 of 2 in the series i-doit API

Wie in meinem letzten Blogpost angekündigt, werde ich anhand eines Beispiels zeigen, wie man mittels der i-doit-API Daten erstellen, aktualisieren und löschen kann.
Ein großer Vorteil den man durch das Benutzen der i-doit-API hat, ist der, dass man nicht “wie üblich” mit SQL-Statements interne Verarbeitungsschritte innerhalb der Datenbank umgeht. Dadurch kann es nicht passieren, dass man durch z.B. einem UPDATE-Statement einen Datensatz so verändert, dass dieser fehlerhaft wird. Somit ist die Datenintegrität mit der API gewährleistet.

Zunächst sucht man sich das Objekt aus der CMDB heraus welches man verändern will (im folgenden Beispiel das Modell eines bestehenden Servers):

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.read", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL"}}' \
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Man erhält durch diese Anfrage folgende Antwort:

{
    "id": "1",
    "jsonrpc": "2.0",
    "result": []
}

Wie man sieht ist das result null. D.h. dieser Server/Objekt besitzt keinen Eintrag zu einem Modell bzw. Hersteller. Somit kann man nun ein neues Modell hinzufügen.

Zu beachten ist, dass im Voraus schon Modelle bzw. Hersteller in der CMDB angelegt wurden!

Die zu benutzende Methode ist cmdb.category.create:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.create", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "manufacturer": "random_manufacturer","title":"random_modelname","serial":"1234"}}}' \
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Sollte alles funktioniert haben, bekommt man folgenden Response zurück:

{
  "jsonrpc": "2.0",
  "result": {
    "id": "855",
    "message": "Category entry successfully created.",
    "success": true
  },
  "id": "1"
}

Hat man z.B. die Seriennummer falsch eingetragen und möchte diese verändern, kann man dies mit der Methode update durchführen.
cmdb.category.update

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.update", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "serial":"4321"}}' --header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Im Anschluss kann man überprüfen ob alle eingetragenen Daten stimmen, indem man wieder den Server ausliest (oberes Beispiel cmdb.category.read):

{
  "jsonrpc": "2.0",
  "result": [{
    "id": "855",
    "objID": "random_objectid",
    "manufacturer": {
      "id": "13",
      "title": "random_manufacturer",
      "const": null,
      "title_lang": "random_manufacturer"
    },
    "title": {
      "id": "3",
      "title": "random_modelname",
      "const": null,
      "title_lang": "random_modelname"
    },
    "productid": "",
    "service_tag": "",
    "serial": "4321",
    "firmware": "",
    "description": ""
  }],
  "id": "1"
}

Zum Schluss löschen wir den Server komplett mittels der Methode quickpurge (quickpurge muss in i-doit aktiviert sein!)
cmdb.category.quickpurge:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.quickpurge", \
"params":{ "apikey":"random_key","id":"random_objectid","\
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

 

{
  "jsonrpc": "2.0",
  "result": {
    "message": "Object(s) successfully purged",
    "success": true
  },
  "id": "1"
}

Quickpurge ist eine Methode bei denen die drei Löschschritte (archivieren, löschen, purge) automatisch hintereinander ausgeführt werden. Ansonsten müsste man der Methode cmdb.object.delete die verschiedenen Status in folgender Reihenfolge mitschicken:

{
  ...
  "status": "C__RECORD_STATUS__ARCHIVED"
  ...
}

{
  ...
  "status": "C__RECORD_STATUS__DELETED"
  ...
}

{
  ...
  "status": "C__RECORD_STATUS__PURGE"
  ...
}

Im nächsten Teil der Serien zeige ich wie man mit einem Ruby-Script all diese Schritte automatisiert durchführen kann.

Philipp Dorschner

Autor: Philipp Dorschner

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the roots" quasi!

Linux Netzwerkschnittstellen mit check_nwc_health überwachen

Quelle: 9gag.com

Olá!

Heute möchte ich euch zeigen wie ihr lokale Netzwerk Schnittstellen unter Linux ganz einfach mit dem Plugin check_nwc_health überwachen könnt. Für die Demonstration verwende ich eine VirtualBox Maschine mit CentOS Linux 7.5.1804 (Core) und Icinga 2.9.1.

Anmerkung: Zusätzliche Icinga 2 Plugins werden im besten Fall unter /usr/lib64/nagios/plugins/contrib installiert. Hierfür muss die Konstante PluginContribDir (/etc/icinga2/constants.conf) angepasst werden da diese per se auf /usr/lib64/nagios/plugins zeigt.

 

[root@centos7 ~]# mkdir -pv /var/lib64/nagios/plugins/contrib
[root@centos7 ~]# vi /etc/icinga2/constants.conf
- const PluginContribDir = "/usr/lib64/nagios/plugins"
+ const PluginContribDir = "/usr/lib64/nagios/plugins/contrib"

Dann kann es auch schon los gehen! Zunächst müssen fehlende Pakete installieren sowie das Plugin heruntergeladen und kompilieren werden:

[root@centos7 ~]# yum install -y perl-Net-SNMP perl-Data-Dumper perl-Module-Load
[root@centos7 ~]# cd /tmp
[root@centos7 tmp]# wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# tar -xvzf check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# cd check_nwc_health-7.2
[root@centos7 check_nwc_health-7.2]# ./configure \
  --libexecdir=/usr/lib64/nagios/plugins/contrib \ 
  --with-statesfiles-dir=/var/cache/icinga2 \ 
  --with-nagios-user=icinga \
  --with-nagios-group=icinga
[root@centos7 check_nwc_health-7.2]# make
[root@centos7 check_nwc_health-7.2]# make install

Nun sollte man das Plugin im Verzeichnis /usr/lib64/nagios/plugins/contrib vorfinden. Im Endeffekt waren das jetzt auch schon alle Schritte. Nun können wir folgende Befehle einfach ausführen:

[root@centos7 check_nwc_health-7.2]# cd /usr/lib64/nagios/plugins/contrib
[root@centos7 contrib]# sudo -u icinga ./check_nwc_health --hostname localhost --servertype linuxlocal --mode interface-health

Ausgabe

Schnittstelle eth0

OK - eth0 is up/up, interface eth0 usage is in:0.00% (0.06bit/s) out:0.00% (0.00bit/s), interface eth0 errors in:0.00/s out:0.00/s , interface eth0 discards in:0.00/s out:0.00/s , interface eth0 broadcast in:0.00% out:0.00%

Schnittstelle eth1

eth1 is up/up, interface eth1 usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface eth1 errors in:0.00/s out:0.00/s , interface eth1 discards in:0.00/s out:0.00/s , interface eth1 broadcast in:0.00% out:0.00%

Schnittstelle lo

lo is up/up, interface lo usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface lo errors in:0.00/s out:0.00/s , interface lo discards in:0.00/s out:0.00/s , interface lo broadcast in:0.00% out:0.00%

Performancedaten

'eth0_usage_in'=0%;80;90;0;100 'eth0_usage_out'=0%;80;90;0;100 'eth0_traffic_in'=0.06;0;0;0;0 'eth0_traffic_out'=0.00;0;0;0;0 'eth0_errors_in'=0;1;10;; 'eth0_errors_out'=0;1;10;; 'eth0_discards_in'=0;1;10;; 'eth0_discards_out'=0;1;10;; 'eth0_broadcast_in'=0%;10;20;0;100 'eth0_broadcast_out'=0%;10;20;0;100 'eth1_usage_in'=0%;80;90;0;100 'eth1_usage_out'=0%;80;90;0;100 'eth1_traffic_in'=0.00;0;0;0;0 'eth1_traffic_out'=0.00;0;0;0;0 'eth1_errors_in'=0;1;10;; 'eth1_errors_out'=0;1;10;; 'eth1_discards_in'=0;1;10;; 'eth1_discards_out'=0;1;10;; 'eth1_broadcast_in'=0%;10;20;0;100 'eth1_broadcast_out'=0%;10;20;0;100 'lo_usage_in'=0%;80;90;0;100 'lo_usage_out'=0%;80;90;0;100 'lo_traffic_in'=0.00;0;0;0;0 'lo_traffic_out'=0.00;0;0;0;0 'lo_errors_in'=0;1;10;; 'lo_errors_out'=0;1;10;; 'lo_discards_in'=0;1;10;; 'lo_discards_out'=0;1;10;; 'lo_broadcast_in'=0%;10;20;0;100 'lo_broadcast_out'=0%;10;20;0;100

Icinga Web 2

check_nwc_health hält noch viele andere Möglichkeiten bereit die vom Umfang her, aber den Rahmen dieses Blogposts sprengen würden. Daher würde ich euch gerne auf die Dokumentation verweisen. In diesen Sinne verabschiede ich mich auch schon wieder und wünsche euch viel Spaß beim implementieren und basteln 🙂

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

i-doit API

This entry is part 1 of 2 in the series i-doit API

Als IT-Dienstleister bieten wir nicht nur Web Services oder Schulungen, sondern unter anderem auch Hosting an. Im Hosting-Bereich ist eine umfassende und geordnete IT-Dokumentation zwingend erforderlich um ein reibungsloses Arbeiten zu ermöglichen.  Als Lösung wird eine sog. CMDB (Configuration Management Database) eingesetzt, welche nicht nur als eine Inventarisierungs-Datenbank dient, sondern auch die gegenseitigen Abhängigkeiten der Objekte verwaltet. I-doit ist eine solche CMDB.

Seit der i-doit Version 1.8 ist die API kein Bestandteil der Pro-Version mehr und wird als separates Modul ausgeliefert welches frei verfügbar ist. Infolge dessen hab ich ein Azubiprojekt bekommen bei dem man die Funktionsweise einer API kennenlernen kann. Ich zeige im ersten Teil der i-doit API Serie wie man einen Request  über den curl – Befehl versendet.

Hat man die API über die Web GUI von i-doit konfiguriert kann man über folgende URL, welche an die Basis-URL angehängt wird, zugreifen:

/src/jsonrpc.php

Die Programmierschnittstelle kann auf Daten der CMDB über das JSON-Format zugreifen, d.h. es werden JSON-RPC Requests per HTTP-Post an i-doit geschickt und als JSON-RPC Response (mit HTTP-Header application/json) zurückgegeben. Somit kann man entweder über den curl – Befehl oder über einen RESTClient (z.B. als Firefox-Addon) die API ansprechen.

Ein beispielhafter Aufbau eines Request könnte folgendermaßen aussehen :

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "cmdb.objects.read",
  "params": {
    "apikey": "random_key",
    "filter": {
      "type": "4"
    }
  }
}
  • jsonrpc – version: Da i-doit ausschließlich die Version 2.0 des RPC-Request untersützt
  • id: Ein optionaler skalarer Wert (True, False, String, Numer) welcher aber nicht Null sein darf. Lässt man diesen Parameter aus, so wird lediglich eine Mitteilung verschickt, sodass der Server keine Rückmeldung generiert
  • method: Die zu aufrufende Methode
  • params: Parameter welche an die Methode übergeben werden
curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.objects.read","params": \
{"apikey":"random_key","filter":{"type":"4"}}}' \
--header "Content-Type: application/json" \
https://example-idoit-web-gui.de/src/jsonrpc.php | python -m json.tool

Mit diesem Request lesen wir alle Objekte in der CMDB aus welche dem Typ 4 (Rack) entsprechen:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "cmdb_status": "6",
    "cmdb_status_title": "in operation",
    "created": "2018-01-05 11:32:13",
    "id": "33",
    "image": "https://example-idoit-web-gui.de/images/objecttypes/something.png",
    "status": "2",
    "sysid": "SYSID_[RANDOMNUMBER_3849274329]",
    "title": "RacknameXYZ",
    "type": "4",
    "type_group_title": "Infrastructure",
    "type_title": "Rack",
    "updated": "2018-01-11 13:38:09"
  },
  {
    ...
    ...
  }]
}

Um z.B. alle Informationen einer Kategorie eines Objektes auslesen zu können, benutzt man die Methode cmdb.category.read:

curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.category.read","params": \
{"apikey":"random_key","objID":"1234","category":"C__CATG__MODEL"}' \
--header "Content-Type: application/json" \
https://example-idoit-web-gui.de/src/jsonrpc.php | python -m json.tool

Response:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "description": "",
    "firmware": "",
    "id": "307",
    "manufacturer": {
      "const": null,
      "id": "5",
      "title": "Random_Manufacturer_Name",
      "title_lang": "Random_Manufacturer_Name"
    },
  "objID": "Uniqe-Object-ID",
  "productid": "",
  "serial": "1235265477457",
  "service_tag": "",
  "title": {
    "const": null,
    "id": "71",
    "title": "XYZ1234",
    "title_lang": "XYZ1234"
  }
  }]
}

Eine ausführliche Liste aller in i-doit benutzten Kategorien kann man unter folgendem URL-Anhang aufrufen:

https://example-idoit-web-gui.de/index.php?load=api_properties

Darüber hinaus kann man über die i-doit API nicht nur Daten aus einer CMDB herauslesen, sondern auch erstellen, aktualisieren oder löschen. Diese Methoden werde ich im Teil 2 dieser Serie abhandeln.

 

Quellen: i-doit Knowledge Base


 
Philipp Dorschner

Autor: Philipp Dorschner

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the roots" quasi!

Fresh from the shelf

Hi !

This week I will take a little look into three command line tools which I find very nice for daily use on a server where we have almost no interface except the command line.

The first tool I would like to bring to your attention is a file explorer for the command line.

Ranger

Ranger is a finder/explorer/nemo/nautilus replacement for the command line with a simple but straight forward file management approach. It uses the almost everywhere liked miller columns and i personally like it more than the midnight commander but that is a personal preference.
I also like the extensibility as an example you can extend ranger with poppler for pdf support or mutool whatever is available for your distro.

It can be easily installed and can be just started from it’s own directory so no big installation fuzz. Simply unpack and start ranger.
(more…)

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.