Dieser lange Eintrag bezieht sich auf sehr spezifische Probleme die meine bestehende Leserschaft hoffentlich nicht betrifft, aber möglicherweise verirrt sich ja jemand in einer ähnlichen Lage über ein Google-Resultat hier hin
Offene Netzwerkports können ein grosses Sicherheitsrisiko darstellen - Während man sich mit NAT und Firewalls ganz gut von den Gefahren im Internet schützen kann, hat ein privates Notebook mit Viren direkten Zugang zu allen Clients.
In unserem Betrieb hat man sich daher entschieden flächendeckend 802.1X auszurollen. Alle "unsere" PCs erhalten ein eigenes Zertifikat und authentisieren sich damit bei jeder Verbindung am Switch, Geräte ohne gültiges Zertifikat werden direkt in ein Guest-VLAN geworfen wo sie von unserer Infrastruktur grösstenteils isoliert sind. Als sehr Novell-lastiger Betrieb wurde auch dies mit einer Lösung der Firma
cryptovision bei uns im eDirectory integriert.
Auf dem Papier sieht die Lösung einfach aus: Eine Software wird über
Novell ZENworks lokal auf unseren PCs ausgeführt, diese beantragt ein Zertifikat (welches im eDirectory gespeichert und mit dem Workstation-Objekt verknüpft wird) und sichert dieses im lokalen Zertifikatsspeicher. Da wir unsere Zertifikate selbst signieren muss auch noch unser Root-Zertifikat auf die Kisten, aber das geht ja auch prima über ZEN. Dies lässt man einfach so lange laufen bis alle PCs ein Zertifikat bezogen haben, danach kann man 802.1X aktivieren.
Im Testbetrieb tauchten dann die ersten Probleme auf: Aus diversen Gründen kam es vor dass viele PCs auch ungültige Zertifikate besassen. Laut den Dokumentationen sollte Windows zwar selbst immer das korrekte aussuchen bzw. alle testen, in der Praxis bedeutet dies bei uns aber dass der PC irgendwann nicht mehr ans Netz kommt. Bei einer vierstelligen Anzahl an Clients wird auch ein "seltenes" Problem zu einem grossen Problem.
Wir mussten also irgendwie automatisch die falschen Zertifikate loswerden bevor es die Clients aus dem Netz haut. Schnell bin ich auf das geniale Tool
certmgr.exe von Microsoft gestossen, dies wird kostenlos mit der Platform SDK zur Verfügung gestellt. Das Löschen eines Zertifikats lässt sich mit einem simplen Kommando auslösen:
certmgr.exe -s -del -c -n "CN_DES_ZERTIFIKATS" -r localmachine my
Leider musste ich nach dieser Entdeckung feststellen dass wir nicht wie anfänglich angenommen nur ein falsches Zertifikat im Umlauf haben, sondern völlig unterschiedliche die sich auch nicht mehr mit Textvergleichen der CNs etc. identifizieren lassen. Schlussendlich endete das ganze in einem C-Programm nach folgendem Schema:
- Das zum PC zugehörige Workstation-Objekt im eDirectory wird aus der lokalen ZEN-Konfiguration ausgelesen:
HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Workstation Manager\Identification\Workstation Object
- Mit Hilfe der
Novell Cldap Libraries liest die Software direkt aus dem eDirectory die Seriennummern aller Zertifikate die mit diesem Client verknüpft sind aus. Die Verknüpfung zu den Zertifikats-Objekten läuft in diesem Fall über das cryptovision-Attribut
cvRepositoryReference. Da die Seriennummer bereits Bestandteil des Objekts ist kann das Auslesen dieser Objekte ausgelassen werden.
- Mit certmgr.exe werden alle lokalen Zertifikate ausgelesen:
certmgr.exe -c -s -r localmachine my
- Die Liste der lokalen Zertifikate wird anhand der Seriennummern mit der Liste im Workstation-Objekt verglichen - Alle Zertifikate die im eDirectory nicht existieren können gar nicht funktionieren und werden gelöscht:
certmgr.exe -del -c -sha1 "SHA1_THUMBPRINT" -s -r localmachine my
Da der ganze Quellcode sehr stark auf unsere Umgebung angepasst ist kann ich diesen hier nicht veröffentlichen, wer jedoch genauere Details oder kleine Code-Ausschnitte möchte kann sich gerne per E-Mail (salami (at) salami.li) bei mir melden.
Das akuteste Problem liess sich mit dieser Lösung bei uns massiv eingrenzen. Eine weitere Frage blieb aber offen: Wie bekommen wir einen neuen PC ohne Zertifikat an unser Netz, wenn die Voraussetzung um ein Zertifikat zu beziehen eine Verbindung mit unserem Netzwerk ist? Ein Netzport ohne 802.1X im Büro liegt auf der Hand, ist in unserem Betrieb aber als einzige Lösung unpraktikabel, da wir unsere Clients über viele Gebäude verstreut haben.
Für die Erstinstallation, für welche wir momentan noch
Norton Ghost verwenden, ist die Lösung einfach: Auf dem Image ist bereits ein gültiges Zertifikat vorinstalliert. Nachdem man einen PC mit einem solchen Image aufsetzt kommt er mit diesem temporären Zertifikat an unser Netz und bezieht dort ein eigenes - Das "falsche" Zertifikat wird anschliessend von meiner Software automatisch wieder gelöscht.
Für alle anderen Fälle musste aber auch eine Lösung her, wir verwenden dazu persönliche Zertifikate auf einem USB-Stick. Obwohl sich diese natürlich problemlos manuell installieren lassen, Automatisierung ist doch einfach toll, was wir mit einer batch-Datei vornehmen:
- Ein VB-Script deaktiviert die LAN-Verbindung um nach der späteren Reaktivierung die erneute Autorisierung am Switch auszlösen:
cscript togglelan.vbs
Das Script stammt aus einem Forum dessen URL ich leider nicht mehr finde, einzige Anpassungen in meiner Version sind die Bezeichnungen in Deutsch. Alternativ kann man natürlich auch einfach das Netzkabel ausziehen...
- Mit dem schon bekannten certmgr.exe wird unser Root-Zertifikat in den entsprechenden Store hinzugefügt:
certmgr -add -v -c "root.cer" -s -r localmachine root
- Ein paar Registry-Keys nehmen die nötige 802.1x Konfiguration an der Netzverbindung vor. Da diese nicht aus meiner Arbeit stammen kann ich diese hier leider nicht veröffentlichen.
- Nun fehlt nur noch das persönliche Workstation-Zertifikat. In unserem Fall liegen diese nur als PFX Datei vor, damit kann certmgr leider nicht umgehen. Abhilfe schafft hier das Sample-Script "cstore.vbs" aus der
CAPICOM SDK. Die nötige capicom.dll haben wir direkt auf dem USB-Stick, diese muss aber zuerst noch registriert werden:
regsvr32.exe /s capicom.dll
- Mit dem erwähnten Script lässt sich das Zertifikat importieren:
cscript cstore.vbs Import -l LM zertifikat.pfx passwort
- Nun muss die DLL-Registrierung wieder aufgehoben werden, da wir die DLL mit dem Stick wieder entfernen:
regsvr32.exe /s /u capicom.dll
- Ein erneuter Aufruf von
togglelan.vbs aktiviert die LAN-Verbindung wieder:
cscript togglelan.vbs
Hat alles geklappt ist man danach sofort wieder am Firmennetz, wo die Cryptovision-Software ein eigenes Zertifikat beziehen kann und mein Tool anschliessend das persönliche Zertifikat wieder entfernt.
Wer mit ähnlichen Problemen konfrontiert ist und weitere Tips beisteuern oder Fragen stellen möchte, darf sich gerne über das Kommentar-Feld oder per E-Mail (salami (at) salami.li) melden