Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den n\u00e4chsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu k\u00f6nnen.<\/p>\n
Ich fange mit einem „alten Schuh“ an, allerdings in einer etwas anderen Auspr\u00e4gung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passw\u00f6rtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschr\u00e4nken, d.h. also insbesondere auf die Verwendung von \u00e4\u00f6\u00fc\u00df<\/strong> und Sonderzeichen zu verzichten<\/strong>. Ich empfehle sogar, Kennw\u00f6rter etc. g\u00e4nzlich nur aus den klassischen Buchstaben A-Z<\/strong>, a-z<\/strong> und den Ziffern 0-9<\/strong> zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…<\/p>\n Wenn nun User Authentication<\/strong> gegen\u00fcber Active Directory<\/strong> im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD\/Windows-Kennw\u00f6rter<\/u><\/strong> festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein \u20ac-Zeichen<\/strong> in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach \u00c4nderung des AD\/Windows-Kennworts (ohne \u20ac-Zeichen) war die Einwahl erfolgreich!<\/p>\n Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD\/Windows-Kennwort vorkommen d\u00fcrfen, damit eine MUVPN-Einwahl \/ User Authentication erfolgreich ist:<\/p>\n !#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das „Leerzeichen“…<\/p>\n Diese Einschr\u00e4nkung d\u00fcrfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegen\u00fcber AD erfolgt!<\/p>\n