Dez 102014
 

Heute habe an meinem Rechner (Windows 7 Ultimate 64-Bit) alle Updates eingespielt. Und wieder mal lernt man, dass man den Patchen von Microsoft nicht blind vertrauen soll.
NAch der Installation muss man als Administrator alle Tools die mit der mmc.exe gestartet werden zusätzlich bestätigen. Richtig. Bin ich ganz mit Euch Microsoft, aber das System so zu verbiegen, dass Software wie VirtualBox nicht mehr startet, finde ich etwas daneben. Vielleicht solltet Ihr Euer Qualitätsmanagement noch einmal überdenken!
Denn dank dieses Patches habe ich einen halben Tag nach dem Problem gesucht.

Ich rate als jedem, der die Patche vom 08.12.2014 installieren will, den Patch KB3004394 nicht zu installieren. Dies betrifft wohl nur Windows 7 Ultimate.

Okt 012014
 

Seit kurzem habe ich wieder das Problem das mir Orgamax nicht das Guthaben von der Poststelle anzeigt.
orgmax_poststelle_guthaben

Das wäre im Prinzip nicht schlimm, aber dadurch wird die Kommunikation von Orgamax zur Poststelle komplett beeinträchtig. Es lassen sich nur einfach keine Briefe mehr versenden. Ich habe Kaspersky deaktivert um zu schauen ob mir die Internet Security irgendetwas blockt. Nur hat dies auch keinen Erfolg gebracht. Plötzlich tauchte aber ein Fenster von Kaspersky (Versuch zur Verwendung einer anfälligen Version des SSL-Protokolls) auf:
orgmax_poststelle_kaspersky

Jetzt wurde mein Suchzwang aktiviert und ich habe mich durch die Einstellungen von Kasperky Internet Security 2015 gewühlt. Und siehe da…
Unter „Einstellungen => Erweitert => Netzwerk (Netzwerkeinstellungen) => Erweiterte Einstellungen“ war ein Haken für SSL 2.0-Protokoll aktiviert.
orgmax_poststelle_kaspersky_einstellungen

Nach deaktivieren dieses Hakens funkitoniert Orgamax wieder wie gewohnt. So wie ich im Internet gelesen habe, haben auch andere Softwareprodukte massive Probleme mit dieser Einstellung.
Ich hoffe ich kann mit der Veröffentlichung auch anderen helfen.

Aug 222014
 

Immer wieder kommen Intern Anfragen, ob man nicht bestimmt Sachen unter Windows überwachen kann. Das mir es viel einfacher fällt in Perl ein Plugin zu schreiben habe ich nun einen Weg gesucht diese Perl Plugins in Windows zu betreiben, ohne Perl zu installieren. Und es geht! Dazu benötigt man nur „Strawberry Perl for windows“ (Zur Webseite).
Hier kann man seinen Perlcode ohne Probleme in eine Exe-Datei umwandeln und unter Windows nutzen.

Teilweise muss man ein paar Anpassungen bzgl der Eingabe (Umlaute machen manchmal Ärger) manchen, aber das ist die Mühe wert.

Die Installation von Strwaberry Perl ist sehr einfach gehalten. Anschließend startet man den „CPAN Client“ und installiert dort erst einmal folgende Pakete:

Nun kann man die Command Line starten. Sie ist wie eine DOS-Box und man bewegt sich mit den typischen Windowsbefehlen auf andere Laufwerke und in Unterverzeichnisse. Will man jetzt ein Perl Script in eine Exe-Datei umwandeln, wechselt man in das Verzeichnis wo das Script liegt und führt dort folgenden Befehl aus

Jetzt dauert es einen kleinen Augenblick und schon ist die Datei fertig. Wenn beim Ausführen der Exe-Datei Fehler auftreten dass ein Modul fehlt, dann installiert ihr das über den „CPAN Client“ nach und kompiliert die Exe-Datei noch einmal.

Das war es schon. Und so einfach bekommt man spezielle Plugins für Windows.

Apr 302013
 

Wie ich schon im letzten Beiträg erwähnt habe, stelle ich heute den Beitrag ein, sich mit Adiscon LogAnalyzer per LDAP-Login an einem Windows AD anzumelden. Wie man den zentralen RsysLog installiert wird auf vielen Seiten sehr gut erklärt. Von daher möchte ich darauf nicht mehr eingehen. Als Vorbereitung sollten die entsprechenden Windowsuser schon in einer separaten Security-Group eingetragen sein. In meinem Beispiel wurde eine Security Gruppe „SysLogServerAccess“ dafür angelegt. Als zweites legt einen AD-Benutzer an, den Ihr nur für die Verbinbung vom Webserver zum AD nutzt. Dieser Benutzer sollte auch keine Adminrechte besitzen. In meinem Beispiel nenne ich den Benutzer „SysLogServerUser“. Die letzteVorbereitung wäre einen MySQL-Benutzer anzulegen, der Zugriff auf die Datenbank von RSysLog (SysLog) und auf die Datenbank des Loganalyzer (loganalyzer) besitzt.
Nun kann es losgehen…

Die aktuellste Version des Loganalyzer laden wir von der Seite http://loganalyzer.adiscon.com/ herunter.
Entpackt das Paket in ein temporäres Verezichnis (z.B /tmp/). Nach dem entpacken findet Ihr ein Verzeichnis „src“ und „contrib„. Den Inhalt beider Verzeichnisse kopiert Ihr dann in das Verzeichnis wo Ihr den Webspace eingerichtet habt.
Zuerst werden die beiden Dateien „configure.sh“ und „secure.sh“ mit

ausführbar gemacht. Mit dem Ausführen von

wird eine leere „config.php“ erstellt.
Verbindet Euch jetzt auf den URL des Loganalyzer.
Bei der Installation ist fast alles selbsterklärend. Deswegen gehe ich nur auf die Steps 2,3 und 7 ein:
loganalyzer_step2
Hier soll schon am Anfang darauf geachtet werden, daß die „config.php“ beschreibbar ist.
loganalyzer_step3

In der Sektion „User Database Options“ werden nun der Datenbankbenutzer eingetargen den wir vorher schon angelegt hatte:

  • Enable User Database => (yes)
  • Database Host => (localhost)
  • Database Port => (3306)
  • Database Name => (loganalyzer)
  • Table prefix => (logcon_)
  • Database User => (loganalyzer)
  • Database Password => (MySQL Passwort)

Die LDAP-Einstellungen sind nun mit am wichtigsten:

  • Require user to be logged in => (yes)
  • Authentication method => (LDAP)
  • LDAP Server Hostname/IP => (IP-Adresse des Domaincontroller)
  • LDAP Port, default 389 (636 for SSL) => (389)
  • Base DN for LDAP Search => (OU=Abteilung,DC=domain,DC=tld)
  • Basic Search filter => (&(objectClass=User)(memberOf=CN=SysLogServerAccess,OU=Groups,DC=domain,DC=tld)(!(userAccountControl:1.2.840.113556.1.4.804:=2)))
  • LDAP Username attribute => (sAMAccountName)
  • Privilegied user used to LDAP queries => (CN=SysLogServerUser,OU=Abteilung,DC=domain,DC=tld)
  • Password of the privilegied user => (SysLogServerUser Passwort)
  • Default administrative LDAP Username => (Ein LDAP Benutzername)

Bei diesen Einstellungen achtet darauf, daß der Eintrag von „Basic Search filter“ komplett mit den Klammer kopiert wird! In der Regel werden alle Benutzer in der Gruppe „Users“ angelegt. Wir haben alle Benutzer in eine OU „Abteilung“ verschoben. Was auch wichtig ist: Verwechselt nicht „Default administrative LDAP Username“ mit dem neu angelegten AD Benutzer für die Abfrage der AD. Tragt hier Euren eigenen Login ein. Dieser erhält gleichzeig auch von Anfang an Adminrechte.
Die folgende Schritte erklären sich wieder von selbst. Wichtig ist noch einmal der Schritt 7:
loganalyzer_step7

  • Name of the Source => (RsSysLog)
  • Source Type => (MySQL Native)
  • Select View => (SysLog Fields)
  • Table type => (MonitorWare)
  • Database Host => (localhost)
  • Database Name => (Syslog)
  • Database Tablename => (SystemEvents)
  • Database User => (loganalyzer)
  • Database Password => (MySQL Passwort)
  • Enable Row Counting => (no)

Ich denke bei diesen Einstellungen brauche ich nicht viel zu erklären. Achtet halt nur drauf das Ihr die Daten richtig eintragt. Nach dem Klick auf „next“ sollte die Installation abgeschlossen sein.

Versucht Euch nun mit Eurem AD-Benutzerdaten an dem Webinterface anzumelden. Wichtig ist natürlich das der Benutzer auch in der Gruppe „SysLogServerAccess“ eingetragen ist!

 

Apr 272013
 

Es gibt einige Anleitungen im Netz wo sich zu diesem Thema geäussert wird. Aber eine kurze Anleitung und die auch noch noch funktioniert ist mir auf die schnelle leider keine unter gekommen.
Nun stelle ich mal meine Notizen dazu Online und hoffe das auch andere damit was anfangen können..
Der Grund für diese Authentifizierung war ein Single-Sign-On für unseren zentralen SysLog-Server. Dort wurde eine Weboberfläche (Loganalyzer: http://loganalyzer.adiscon.com) installiert und wir möchten natürlich nicht das dort jeder Zugriff hat. Auch der Loganalyzer besitzt auch eine LDAP-Authentifizierung, die ich aber erst später funktionstüchtig auf Gruppenbasis ans laufen gekommen habe. Dazu schreibe ich später einen separaten Beitrag.

Als erstes sollte man die Vorbereitungen auf dem AD-Controller durchführen. Dazu habe ich eine extra Sicherheitsgruppe unter der OU „Groups“ erstellt (in diesem Beispiel nenne ich sie „AccessGroup“).
Anschließend weisse ich die entsprechenden Benutzer dieser Gruppe zu.
Weiter geht es mit einem extra Benutzer der nur für die LDAP-Anbindung genutzt wird (nehmt bitte keinen Amdinistrator).

Jetzt können wir das Modul für den Apache installieren

Nun muss das Modul noch aktiviert werden und der Apache einmal durchgestartet werden

Als letztes braucht man nur noch in der Apache Konfiguration die entsprechende Authentifizierung aktivieren

Bei uns liegen alle Benutzer in einer OU und nicht mehr unter „Users“. Deswegen erscheint auch hier die OU „Abteilung“. Jetzt noch einmal einen Restart des Apache Webservers durchführen.
Nun sollte das Verzeichnis durch eine LDAP-Authentifizierung geschützt sein. Funktioniert die Anmeldung nicht dann erhöht einfach den LogLevel in der Apache Konfiguration:

Jetzt sieht man genau wo das Problem besteht.

Dez 052012
 

Nun habe ich geschlagene 3 Tage mit einem Rechner, auf dem Windows 7 Prof. 64-Bit installiert ist, rumexperimentiert, weil kein Remote Zugriff auf die darauf installierte MSSQL-Instanz möglich war. Auf dem Rechner, der als Server dient, ist die Software CENTROFactura installiert. Sogar der Support wusste sich keinen Rat mehr. Und der Support war wirklich super! Das muss man einfach mal erwähnen.
Beim Testen habe ich die Internet Security deaktiviert und sogar noch zusätzlich die entsprechenden MSSQL-Ports geöffnet. Nur bin ich nicht zu dem Ziel gekommen eine Verbindung aufzubauen.
Heute habe ich dann in dem Forum von Kaspersky folgenden Thread gefunden: http://forum.kaspersky.com/index.php?showtopic=243400

Und es ist kaum zu glauben… Nach der Deinstallation war die MSSQL-Instanz auf dem Rechner von aussen erreichbar und die Clients von CENTROFactura können auf den Server zugreifen.

Mai 092011
 

Mein Favorit in Sachen Editor ist immer noch Notepad++… Leider hatte ich seit Windows 7 64-Bit Probleme Dateien über das Kontexmenü (Edit with Notepad++) direkt zu öffnen…

Immer wieder tauschte dieser Fehler auf:

notepad_Fehler1

Nun bin ich endlich auf die Lösung gestossen…

Am einfachsten ist es sich einen eigenen RegKey zu erstellen.

Dazu öffnet man einfach Registry-Editor und legt unter dem  Pfad „HKEY_CLASSES_ROOT*shell“ einen Schlüssel mit dem Namen „OpenWithNotepad„.

notepad_Fehler_reg_1

Unter diesen Schlüssel erstellt man dann einen Schlüssel „command„…

notepad_Fehler_reg_2

Nun trägt man im ersten Schlüssel (OpenWithNotepad) für den „Standard“ folgenden Wert ein: Bearbeiten mit Notepad++

Als nächstes erstellt man eine neue Zeichenfolge „icon“ mit dem Wert „kompletter Pfad zur notepad++.exe“ (C:Program Files (x86)Notepad++notepad++.exe).

Unter dem Sub-Schlüssel (command) wird der „Standard“ mit dem Wert „kompletter Pfad zur notepad++.exe“ %1 („C:Program Files (x86)Notepad++notepad++.exe“ %1) gefüllt.

Jetzt sollte schon im Kontext-Menü der Punkt „Bearbeiten mit Notepad++“ erscheinen und die Dateien lassen sich wie gewohnt darüber öffenen.

Wer vorher schon verschiedene Dateien fest mit dem Notepad++ verknüpft hat sucht einfach im Registry-Editor nach „notepad++.exe“ und löscht diesen Schlüssel auch.

notepad_Fehler_reg_3

Nach dem löschen den Schlüssels „HKEY_CLASSES_ROOT*shellexContextMenuHandlersNotepad++64“ wird auch das letzte Überbleibsel der Installation entfernt.

Durch das Fortsetzen der Benutzung dieser Seite, stimmst du der Benutzung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen", um Ihnen das beste Surferlebnis möglich zu geben. Wenn Sie diese Website ohne Änderung Ihrer Cookie-Einstellungen zu verwenden fortzufahren, oder klicken Sie auf "Akzeptieren" unten, dann erklären Sie sich mit diesen.

Schließen