Results for category "Sicherheit"

34 Articles

Using L2TP in Ubuntu 12.04 Precise Penguin

For our new company I want to provide VPN access through L2TP in addition to PPTP.

After I had installed network-manager-strongswan the configuration dialogue of network-manager crashed. Being not the only one having this problem I installed the 1.3.0 build of network-manager-strongswan and now I can configure my L2TP connection as expected:


wget http://launchpadlibrarian.net/108979339/network-manager-strongswan_1.3.0-0ubuntu1_amd64.deb
sudo dpkg -i  network-manager-strongswan_1.3.0-0ubuntu1_amd64.deb

How-To: Queue in Astaros pop3proxy flushen/löschen

Hin und wieder kann es vorkommen, dass der pop3proxy von Astaro die eingehenden E-Mails “verschluckt”. Grund dafür ist der Spamassassin, der im Hintergrund läuft und bei bestimmten E-Mails eine extrem hohe Prozessorlast verursacht. Das Verhalten habe ich jetzt einige Male bei E-Mails beobachtet, die über die Bugtraq-Mailingliste gesendet werden. Nun kam es bei uns dazu, dass eine der E-Mails überhaupt nicht gescannt werden konnte: Spamassassin lief in einer Endlosschleife und blockierte den kompletten pop3proxy.

Die einfache Möglichkeit wäre jetzt gewesen, dass man die E-Mails direkt auf dem Mail-Server über eine Web-GUI oder einen passenden Client löscht – allerdings setzen wir Prefetching für POP3 ein, so dass die E-Mails immer noch auf der Firewall lagen und beim Aktivieren/Deaktivieren des Prefetchings nicht gelöscht wurden. Den Mail-Manager (http://firewall/mm) konnte ich ebenfalls nicht benutzen, da er in unserer Astaro-Version (aktueller Stand zum heutigen Datum) nicht zum Backend verbinden konnte – warum auch immer.

Um dieses Problem zu beheben, muss folgendes gemacht werden:

  • POP3-Proxy auf der Astaro deaktivieren
  • Mit SSH auf die Firewall schalten
  • # su
  • # psql -h db_host.local -U postgres pop3
  • psql# DELETE FROM messages;
  • exit
  • POP3-Proxy auf der Astaro wieder aktivieren

Gut, dass die E-Mails in einer stupiden PostgreSQL-Datenbank liegen, dass machte die Sache am Ende nämlich doch noch echt einfach 😉

Server Name Indication (SNI) unter Apache 2.0.63 (Windows)

Heute kam bei uns in der Firma wieder das Thema Zertifikate zu sprechen. Unsere momentane Umgebung auf dem auch dieser Blog gehostet ist, ist ein Windows-System, auf dem Apache 2.0.63 läuft. Einige der Subdomains sind über SSL zugänglich, allerdings besteht bei SSL das generelle Problem, dass pro IP-Adresse nur ein SSL-Zertifikat benutzt werden darf. Wenn man mehrere Subdomains als virtuelle Hosts betreibt (https://v1.ecw.de, https://v2.ecw.de u.s.w.) wird immer nur das Zertifikat des ersten VHosts benutzt (im Beispiel das Zertifikat von https://v1.ecw.de).

Seit einiger Zeit bietet das Unternehmen StartCom kostenlose Zertifikate an. Das CA-Zertifikat von StartCom ist in den aktuellen Browsern sowie im Zertifikate-Speicher von Windows verfügbar. Leider besteht nicht die Möglichkeit, ein kostenloses Wildcard-Zertifikat zu erhalten. StartCom teilt nur Zertifikate vom Typ C1 und nicht C2 kostenlos aus.

Mit dem Wildcard-Zertifikat wäre es möglich gewesen, dass alle VHosts unter https://*ecw.de sich ein Zertifikat teilen. Die andere Möglichkeit, für jede Domain ein eigenes Zertifikat einzurichten, entfällt aus den bereits genannten Gründen: pro IP nur ein Zertifikat.

Seit 2003 existiert die RFC 3456, in der Server Name Indication (SNI) definiert wird. Damit ist es möglich, pro IP-Adresse mehrere Zertifikate zu benutzen. Leider implementieren bis jetzt nur wenige Webserver SNI nativ.

Als ich im Internet nach dem Thema googelte, wurde ich in Wolfs Blog fündig. Er beschrieb die Implementierung und Kompilierung von SNI unter Apache 2.2.xx. Durch seine Ausführungen war ich mehr als motiviert und hatte nun den Plan, SNI unter Apache 2.0.63 und Windows zum Laufen zu bringen.

Durch meine letzten Tätigkeiten beim mod_auth_ldap-Patch hatte ich noch die Sourcen von Apache 2.0.63 auf der Festplatte und sammelte nun die benötigten Dateien zusammen:

Nachdem ich die beiden Backport-Patches in meine Sourcen eingespielt hatte, musste ich noch die Lib-Pfade für die OpenSSL-Dateien einpassen und außerdem das zlib-Verzeichnis inkludieren, da OpenSSL irgendwie auf zlib referenzierte.

Die Kompilierung verlief danach ohne Probleme und ich machte mich an das Deployen der Dateien. Wichtig dabei war, das auf dem Server folgende neue Dateien kamen:

  • openssl.exe aus Wolfs-SSL-Package nach Apache2/bin
  • libeay32.dll und ssleay32.dll aus Wolfs-SSL-Package nach Apache2/bin bzw. %SYSTEM32%
  • Release/libhttpd.dll aus dem Apache-Kompiliat nach Apache2/bin
  • modules/ssl/Release/mod_ssl.so nach Apache2/modules

Das Starten des Apaches schlug beim ersten Mal fehl, da ich die libhttpd.dll vergessen hatte zu kopieren. Diese wird aber benötigt, da der Backport von ap_vhost_iterate_given_conn auf diese Library abzielt.
Danach fuhr der Apache normal hoch, ich richtete nun in aller Kürze zwei Virtuelle Hosts in meiner httpd.conf ein und erzeugte zwei Self Signed Certificates. Das Ergebnis war mehr als erfreulich, denn soweit funktionierte alles.
Der nächste Schritt wird für mich sein, dass ich nun unsere Zertifikate von der StartCom-CA signieren lasse.

[download id=”2″]

Erstellen eines Active Directory-Benutzers mit Nur-Leserechten

Vor einigen Tagen berichtete ich über das Active Directory-Authentifizierungsproblem bei SMTP-Benutzern auf unserer Astaro-Firewall. Nachdem der Support von Astaro sich die Logs auf der Firewall näher angeschaut hatte, bekamen wir folgenden Tip: Der von uns vorgesehene Benutzer besaß im Active Directory zu wenig Rechte.
Normalerweise wird in Applikationen, z.B. bei mod_ldap für Apache, eine Suchanfrage für einen Benutzer gestartet, in dem überprüft wird, ob eine Gruppe oder eine OU den Benutzer enthält. Außerdem geschieht oft das Binding über den zu autorisierenden Benutzer.
Die Software der Astaro-Firewall geht einen etwas anderen Weg: Der Benutzer wird am Active Directory authentifiziert, danach wird geschaut, ob der Benutzer im Attribut memberOf Mitglied der Gruppe ist.

Unser obiger Benutzer – der Einfachheit halber LDAP-Account genannt – war als normaler Domänen-Benutzer im Active Directory eingetragen und konnte somit Anfragen auf OUs oder Gruppen stellen, aber eben nicht das memberOf-Attribut von speziellen Benutzern auslesen.
Mit Hilfe der Aussage des Supports wiesen wir dem LDAP-Account zum Test im Active Directory die Gruppe “Domänen-Administratoren” zu und siehe da: Die Authentifizierung beim SMTP-Relaying funktioniert.

Nun wollten wir aus Sicherheitsgründen aber natürlich nicht, dass der Benutzer weiterhin mit der Rolle des Domänen-Administrators in der Domäne agierte. Der LDAP-Account sollte nur lesend auf die Attribute von Benutzern zugreifen können.

Damit dieses Vorhaben gelingt, muss die MMC ADSI Edit aufgerufen werden. Falls diese nicht installiert ist, muss sie von der Windows Server 2000/2003-CD aus dem Verzeichnis Support Tools nachinstalliert werden.

Nun wählt man die OU aus, in der dem LDAP-Account Leserechte gewährt werden sollen.

Auswahl der OU

Auswahl der OU

Danach muss im Tab Sicherheit mit einem Klick auf Hinzufügen der LDAP-Account dieser OU hinzugefügt werden.

Sicherheitseinstellungen für diese OU

Sicherheitseinstellungen für diese OU

Auswahl des Benutzers

Auswahl des Benutzers

Der LDAP-Account erscheint nun in der Liste der Gruppen- oder Benutzernamen.

Benutzer, nachdem dieser der OU zugewiesen wurde

Benutzer, nachdem dieser der OU zugewiesen wurde

Mit einem Klick auf Erweitert, Auswahl des LDAP-Accounts und nochmaligen Klick auf Bearbeiten wird dem Benutzer das Recht Berechtigungen lesen entzogen. Weiterhin war das Recht Inhalt auflisten für unsere Anforderungen nicht nötig.

Erweiterte Sicherheitseinstellungen

Erweiterte Sicherheitseinstellungen

Spezielle Berechtigungen setzen

Spezielle Berechtigungen setzen

Nach diesen Änderungen konnte nun der Benutzer LDAP-Account auf das memberOf-Attribut zugreifen.

Spam the NSA

Bomben-Stimmung nach einer fast geheimen Attacke auf den König.

Ich liebe Schach.

Bitte senden an: noreply@att.com

Edith: Nach Absenden des Blog-Eintrags ist mein Browser abgestürzt. Zufälle gibt’s…

Microsoft Tag – 2D Barcode – Protokollanalyse und Sicherheit

Marc berichtete gestern über Microsoft Tag. Tag ist ein 2D-Barcode, der mittels 4 verschiedenen Farben und deren Kombinationen einen Hash bildet.
Mit der Kamera des Handys wird der Tag aufgenommen und dann an einen Microsoft-Server geschickt. Dieser überprüft, ob der Hash registriert ist und liefert an den Client zurück, ob dieser Hash existiert. Hinter einem Hash kann sich ein Link, ein Freitext, eine Telefonnummer oder eine vCard verbergen.
Wenn der Hash existiert, werden eben diese Informationen zurückgesendet. Das Prinzip ist also ganz simpel.
Mir stellte sich nun die Frage, wohin gehen denn überhaupt die Daten und was wird an den Client gesendet?

Zur Überprüfung schloss ich mein HTC Touch Diamond mittels USB-Kabel an den PC an, startete Wireshark und schaute mir die Verbindungen an.
Sobald das Handy eine Anfrage an den Server stellt, wird an rs.tag.microsoft.com über TCP/80 (normales HTTP) ein GET-Request gesendet. Der GET-Request sieht folgendermaßen aus

GET /6FADWESYVPYSPHHQ5TMKHGSWF3ODWWRP.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8F013hNEWheA%24&PL=zqMa3C48QBs_4fI9cRZKGpvix1XhvxuqEQ1eFlqKqwlbXzl%2BgvWxM7zTaq0xRFcdWuneeC5VRGuYitVRubwb1kswVAc19dpoJDZEf5HpqlbHvw7WPzpVYibwvX02LygEnOXbXbTbeM04VzICWva2GVdYXXKekdxPvL8evEZbJG5Xi8t9PUlVHOL_yS_dsXi2XT5cejeRsGArLzVpkvjcPLyyG6csBzoOTeHuKiZLTnKYgLcyxqMQvDQtIQ5J6rYFW19SZ4r1

rs.tag.microsoft.com liefert danach dann

<PAYLOAD><NAME>Deine</NAME><PIN>0</PIN><DATA>r6QEsUVaVGZOm9MVWDszHo_0vTzeonHOUytWESKQ3gVLLjl5kfK5IsvFGaJYLDsDGqrrMzErE1C3rNcrtKwYrE1J</DATA></PAYLOAD>

zurück.

Um etwas strukturierter an die Sache zu gehen, hier die Tests mit den einzelnen Typen.

Dialer

Request:

GET /7KDWMBOYE474DQA7PMH5KVDLDK4SGSZJ.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8F01ahPoWheA%24&PL=tr8e2zMtRBU68uguaBwhGIz43Bv8ujayaxlTASP4zA8jQz15n%2BS1PbnAcL4oTjwfTfPFZDNOQ3PinthGwM580DMsUAAo5N5mISVebIjjwVTQpRXKIiFSelzksGpPXU8C5PnfWqnKfMM9RCgRQ_zdG0BCRm6DittXxqsTqz8pQ2gvl896IFhREufs0zzEuxO0SiRHZiqKt3hROzh%2B64q7OsSuH6AxFj4ASPL0OT9BJXCPmqwu27gXpE45LBkwmNEDI0NWYJfk

Response:

<PAYLOAD><NAME>Dialer</NAME><PIN>0</PIN><DATA>r6QEsUVaVGZOm9MVWDszHo_0vTzKymK1QjZaFzWG3RpKMy9onPusWcm3GKpCPVd5TvK9biFaSXqGgLRSycY$</DATA></PAYLOAD>

vCard (ohne Passwort)

Request:

GET /DYMDUQZA5HDH3KXOEV7X5DPS7S4U2ZSN.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8FE1lhPwWheA%24&PL=utsO1EIiWgwg8OM9CRszE46boA79tyW5aQpEF1LpqREvJy127uurJKPCe61JSS4UT%2BW5fDJDSHjgjc9Qsd8Zzj9IQA9Z68B_OydVf%2Bnk01_Ss2nSIyxZcV73p3w%2BTCoc6J3PVdjFYtonRiMCIvvPEEJUOnaCh9BcxLgEvU44JnYj8991UVdPC_3u2C%2BlvAG_SDI7fiuHvHNTKC9ompveJMjKD69AGSAZUvD_Kl5GN3uNjNA22rUcr0wqOw9BibQdLydGb%2Bbr

Response:

<PAYLOAD><NAME>vCard unprotected</NAME><PIN>0</PIN><DATA>r6QEsUVaVGZOm9MVWDszHo_0vzrHpAndKDpLHSSHyAZULyRvgP+wN7DHcbFDPjsFOoTMGCswJXWBifsdzb0Pp1A4Sw9CjLRFaC8oCJezj3z7niaDZBR7HS2o_1FiZXxun5PHapHbEKVEKUZpKunHdUo9OxjV2KUqwdIJ3F0zIn43lNINNhJ0aO6Ryj7FrQqgWChJEU3WlwFeK1obio6qQKjLetIqMxw_S4bRfUogOAXwx+M8y7cErTw+XAA27sQbUCU4coD_0wSelQ2CYw8rIxrjiFxUKCIOhY63Rd_EcqJaMTs$</DATA></PAYLOAD>

URL

Request:

GET /7JGMIVQUKMNDPCW5ET5CRG4JP4KB35LK.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8FE1mhNkWheA%24&PL=sNsc3yQ5RQU%2B9IVKZBI5d%2B6Q2HmepDnPZWwqF1zsxQclJz99iPC0Lb3GHdokQCRwL%2B7BClFOSA7s66FQv9p12DVIUgQ_8N92JSMzCITt2TuyuBGkQCFZB1KRyXwwSUYK4p3dXr7efdM5QkV1T_LFdCJfQgDhitAqyN5qvUA9SmAp881%2BN0xQAuPqvljItQvbKDlDCEiKvAVfTkFolJ6yMsLKHaQmAj8QTPSZXTNPPR_th6hAubgc2UBMVQ9PjNgLJSdUZIDw

Response:

Location: http://wap.ecw.de

Hier eine kurze Anmerkung: Bei einer URL wird im HTTP-Header ein Location-Feld zurückgeliefert. Sobald der Tag mit der Software geladen wurde und Microsoft die Antwort liefert, wird der Standard-Browser des Handys aufgerufen – ohne Nachfrage! Sicherheitstechnisch äußerst bedenklich – man stelle sich nur mal vor, dass man z.B. eine Bank mit einer falschen URL taggt. Der Benutzer nimmt das Tag auf, der Browser öffnet sich und der Nutzer sieht die gefälschte Bank-Seite.

vCard (mit Passwort)

Request:

GET /KV4PWBAKHRXTHEGERKNRYY3YKY4PIMYZ.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8FE1shOYWheA%24&PL=u6Ad3j4pJwMiiPcxZAsqBO2GzWTuvHS7FghEEkeI3g4uXD58kuDWK6G6b6EkWTcDLPjUCSFXN3qfj89VpL5u0T4zUwUl4L1wOV9Bc4T0ykixrgSnMDgmcyH1p3krLV0D6ebcX6TOH9UlPjcOT%2BvWByFJVwORk69eu7oEuFtZUWkiiMx_LVwyBP%2BWzCPIrBioKy9WCziTw3EsKi9tj_qpO8mxHKU8El0WUIjrJjNWLmzukb1DyaFjrTMoOwpU6MMCLlxVZZrg

Response:

<PAYLOAD><NAME>vCard protected</NAME><PIN>1</PIN><DATA>s61ur1A7XGooj8JqXDc9HIPlxTnMvxujU1pdGjOKug5IJk5xlZ64O9bTYM5HMjUHNpW2GyArNwv66e0a2rB9r0wxIRFX7bxJDjs5d5O_gX73j1yAbw9pY1bI6VZ1aA5mg5qtdIS6GKkiPVcWLuXJd0YsQRvew7dUurIf20o+UHYrnbgTI3N8ZIiF20HBoQSiVDkzEkbNhX8lS0wcnYPYSLTCEMw_UhQzLZLAAk4sNgf81pk_wKwW00deSgch47YTTCxSbJWe2wj4gRz9ZwMlIRby8l9fMzBw_u6hQsjJAKpGOFE$</DATA></PAYLOAD>

Freitext
Request:

GET /I6YA3RA6VSFCYMAO5AI7XYQAZKBJNJZD.aspx?Level=1&VID=1%2B71&TH=_%2BxrkrK8FE1vhN4WheA%24&PL=pKQToEA4JxxD7IQ6exQsDI2Iwh3ipma9bA9VGUCIqQsxWDAC7PHWNMDeHKo7RjELTPbbdS1MSHzliN5eo74Z1CE3XXtb8b1vWDsyeJvrzEDRoAvbPCNZdVvytnIsLSoG9uLSIdrfH8pEWkQFUPTQD0FHWH%2BdiNBYwb0Vs1xZJmw9jMIBU00yG57yvyjXsx6gSyFZdzSIvHdWLT5miPrePta1EttCA10JMeyYLSxJKGSOn7I_xbocq0kvKgFT6LQHMVhbG%2BTx

Response:

<PAYLOAD><NAME>Free Text</NAME><PIN>0</PIN><DATA>r6QEsUVaVGZOm9MVWDszHo_0vTzeonHOUytWESKQ3gVLLjl5kfK5IsvFGaJYLDsPHq_pOTExB1i37Mo4z70FoCc$</DATA></PAYLOAD>

Anmerkungen
Die zu ladende Datei (….aspx) und der GET-Parameter “TH” ergeben eventuell die ID. Ich habe zwei verschiedene Schnappschüsse des FreeText-Tags gemacht und jedesmal war die ASP-Seite und der TH-Parameter identisch. Der PL-Parameter änderte sich hingegen. Liefert Microsoft da eventuell irgendwelche GPS-Koordinaten mit? Ich kann leider die Daten nicht entschlüsseln – die Strings scheinen zwar Base64-codiert zu sein. Ein Encoding brachte aber kein verwertbares Ergebnis.

Vielleicht kann irgendwer mit diesen Erkenntnissen etwas anfangen. Viel interessanter fände ich es, wenn man seinen eigenen Tag-Provider hinterlegen könnte und wenn das Protokoll vor allem offen und standardisiert wäre.

Btw: Mit Hilfe des Tags könnte man z.B. eine Türklingel für das Eingangsschild der Wohnung realisieren: Tag an das Namensschild, Gast ent-taggt das Foto, Windows Live ruft eine URL auf dem Home-Server des Gastgebers auf. Das dahinter-hinterliegende Script startet den Musik-Player… Eigentlich ganz cool 🙂

HTC Touch Diamond / WPA2 / PEAP / Windows Server 2003

Szenario: HTC Touch Diamond über WPA2 AES mit Hilfe von RADIUS/IAS an das Firmen-Netzwerk anbinden.

Nicht nur ich, sondern auch andere Personen haben das Problem, dass der Wifi-Manager im HTC Touch Diamond bei ausgewähltem PEAP meldet, dass man ein persönliches Sicherheitszertifikat benötigt.
Im Internet gibt es einige Hinweise, dass man entweder ValidateServerCert auf “0” setzen soll -so habe ich es vor einigen Tagen auch in diesem Blog geschrieben- oder aber, dass man Securew2 benutzt.
Beides reichte bei unserem Netzwerk nicht aus. Deshalb hier eine kurze Anleitung, wie es funktioniert.

Zuerst muss auf dem Domänen-Controller – bei uns ist das ein Windows Server 2003 R2 – das Server-Zertifikat exportiert werden. Microsoft stellt dazu unter http://www.microsoft.com/downloads/details.aspx?FamilyID=6123EB55-6590-4643-8E7F-11C177104DE2&displaylang=en das Tool SslChainSaver zur Verfügung. Dies muss auf der Kommandozeile aufgerufen werden:

sslchainsaver $DOMAENENCONTROLLER

Man erhält nun zwei XML-Dateien und einige Zertifikate. Das Windows Mobile 6-Zertifikat ($DOMAENENCONTROLLER.wm6.xml) muss in _setup.xml umbenannt und danach zu einer CAB gepackt werden:

makecab _setup.xml domaene_rootcert.wm6.cab

Die domaene_rootcert.wm6.cab muss auf das HTC Touch Diamond kopiert und installiert werden. Unter Einstellungen > System > Sicherheitszertifikate sollte nun die Zertifizierungsstelle erscheinen.

Als nächstes folgt der Export des Benutzerzertifikats nach PCKS#12. Auch hier gibt es wieder viele Anleitungen wie man das macht: Unter Windows Server 2003 die MMC starten, das Zertifizierungsstellen-Snap-In laden (muss mit dem Domänen-Controller verbunden werden) und dann unter Ausgestellte Zertifikate den Benutzer auswählen, Details > In Datei kopieren und PKCS#12 auswählen. Aus welchen Gründen auch immer war die PCKS#12-Option bei unserem Server deaktiviert.

Deshalb gilt nun folgendes: Auf einem Client-Computer den Internet Explorer starten und die Adresse http://$DOMAENENCONTROLLER/certsrv aufrufen und sich mit seinem Benutzernamen und Passwort authentifizieren. Nun muss ein neues Benutzer-Sicherheitszertifikat im PCKS#10-Stil angefordert werden. Dieses muss nach der Erzeugung in der Zertifizierungsstelle logischerweise auch im IE installiert werden.

Danach kann man im IE 8 unter Extras > Internetoptionen > Inhalt > Zertifikate > Eigene Zertifikate sein eben gerade erstelltes Zertifikat auswählen und dieses als PCKS#12 exportieren.
Die exportierte Datei muss ebenfalls auf das HTC Touch Diamond kopiert und danach mit einem Doppelklick installiert werden.

Nun kann die WLAN-Verbindung über PEAP und ohne Securew2 erfolgen.

network-manager-pptp unter Ubuntu 8.10

Nach dem Update auf Ubuntu 8.10 letzten Monat gingen meine VPN-Verbindungen über den Jordan. Ich also eben gerade meine Verbindung zum Firmennetzwerk neu eingerichtet und siehe da: Es funktioniert nicht.

In /var/log/syslog war Folgendes zu lesen:

Nov 24 17:12:32 laptop kernel: [ 1034.472477] PPP generic driver version 2.4.2
Nov 24 17:12:32 laptop modprobe: WARNING: Not loading blacklisted module ipv6
Nov 24 17:12:32 laptop pppd[7594]: pppd 2.4.4 started by root, uid 0
Nov 24 17:12:32 laptop pppd[7594]: Using interface ppp0
Nov 24 17:12:32 laptop pppd[7594]: Connect: ppp0 &amp;lt;--&amp;gt; /dev/pts/1
Nov 24 17:12:32 laptop pptp[7603]: nm-pptp-service-7589 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Nov 24 17:12:32 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 5120).
Nov 24 17:12:34 laptop pppd[7594]: MS-CHAP authentication failed:
Nov 24 17:12:34 laptop pppd[7594]: CHAP authentication failed
Nov 24 17:12:34 laptop pppd[7594]: Connection terminated.
Nov 24 17:12:34 laptop NetworkManager: &amp;lt;info&amp;gt;  VPN plugin failed: 1

Sehr ungewöhnlich – Meine Zugangsdaten (Benutzername, Passwort und Domäne) waren im NetworkManager definitiv korrekt eingetragen.
Ich aktivierte in /etc/ppp/options die Definition “debug” und sah im syslog

Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoReq id=0x0 magic=0x6fbd7073]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoReq id=0x0 magic=0xf9418ec]
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoRep id=0x0 magic=0x6fbd7073]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Challenge id=0x9a &amp;lt;d25f15a6a126b77cba1ea38f32f093c6&amp;gt;, name = "pptp"]
Nov 24 17:34:26 laptop pppd[9661]: sent [CHAP Response id=0x9a &amp;lt;729e199b9717cc49aeacbf4f5f0fe79800000000000000002d555861ec2b61ebb1442f3519018527ad5879336be6323f00&amp;gt;, name = "$DOMAIN\\$BENUTZERNAME"]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoRep id=0x0 magic=0xf9418ec]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Failure id=0x9a ""]
Nov 24 17:34:26 laptop pppd[9661]: MS-CHAP authentication failed:
Nov 24 17:34:26 laptop pppd[9661]: CHAP authentication failed
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP TermReq id=0x3 "Authentication failed"]
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermAck id=0x3]

Wichtig ist die CHAP-Response: Aus welchen Gründen auch immer werden die Backslashes doppelt escapt – was zur Folge hatte, dass unsere Firewall die Authentifizierung am IAS mit $DOMAIN\$BENUTZERNAME durchführte. Völliger Mumpitz.

Deshalb änderte ich NetworkManager die Einträge so, dass ich die Domäne leer ließ und als Benutzernamen $BENUTZERNAME@$DOMAIN festlegte. Somit funktionierte es dann auch.

WPA & PEAP unter Windows Mobile 6.1 ohne Serverzertifikate

Um unter Windows Mobile 6.1 eine Verbindung mit einem WPA-gesichtern WLAN Verbindung aufzunehmen, das PEAP ohne Server-/Clientzertifikate benutzt, muss folgendes gemacht werden:

Auf dem Handy/PDA einen Registry-Editor installieren, z.B. von http://www.phm.lu/products/.
Danach dann unter HKEY_LOCAL_MACHINECommEAPExtension25 den DWORD-Eintrag ValidateServerCert auf “0” setzen. Sollte der Eintrag nicht existieren, muss er hinzugefügt werden.