Bereinigung eines Verzeichnisses funktioniert nicht mehr

Hast du dir schonmal einen detailierten Purge Bericht angesehen?

MSGMAILNAMES ?

Hallo Kingcopy,

der Purging Report wird per E-Mail an der Postmaster als Textdatei verschickt.

Michael

Zitat

Hallo Kingcopy,

der Purging Report wird per E-Mail an der Postmaster als Textdatei verschickt.

Michael

So einfach ist das leider nicht - damit der Report verschickt wird, muss das explizit eingeschaltet werden.

Du musst in der David.ini einen Eintrag machen, wo du die E-Mail Adresse angibst an die der Purging Report gesendet werden soll:

MSGMAILNAMES = <E-Mail Adresse>

Danach den Service Layer neustarten.

In diesem Knowledge Base Artikel ist das noch mal genau beschrieben: Q-109.958

Der Fehler ist absolut nicht neu.

Fast jede zweite Woche stelle ich ähnliche Probleme bei meinen Bestandskunden fest:
Alle im David-Infocenter vorhandenen Einträge sind gelöscht.
Trotzdem sind auf Windows-Ebene tausende verwaiste Dateien zu finden.

Erfolgversprechende Maßnahme, wenn meine Bestandskunden solche bleiben sollen:
Ich befasse mich intensiver mit Microsoft Exchange.

Mein Partnervertrag mit Tobit.Software endet im Mai. Ich kann generell keine Empfehlung mehr für Tobit-Produkte geben, da mir seit Jahresanfang 2014 die schon seit mehr als zwei Jahren bestehenden massiven Datenschutz-Verstöße des Herstellers bekannt sind. Der gesetzlichen Verpflichtung, bekannte Datenschutz-Probleme den Kunden mitzuteilen, ist die Tobit.Software AG nicht nachgekommen.
Solange diese Datenschutzprobleme nicht behoben sind widerspricht es meiner Berufsehre als Ingenieur und Sachverständiger, für die betroffenen Produkte eine Empfehlung zu geben.

Von mehreren David-Nutzern wurde ich nach Details zu den oben angesprochenen Datenschutz-Probleme befragt.

Die Informationen wurden mir erstmals in KW 49-2013 und dann detailliert in KW 01-2014 zugetragen, und dies von Seiten Dritter, die weder Mitarbeiter noch Partner der Tobit.Software AG sind.
Es haben ergo Personen Zugang zu Informationen erhalten, die nicht für sie bestimmt sind.
Die Sicherheits-Interessen meiner Bestandskunden, zu denen Industriebetriebe gehören, muss ich absolut ernst nehmen.
Damit ausreichende Sicherheitsmaßnahmen getroffen werden können erfolgt an dieser Stelle eine Veröffentlichung der am 16.3.2014 bestehenden gravierenden Sicherheitslücken:

1) Der Link bringt zu JEDER Site-ID das vom Hersteller im Lizenzschlüssel vergebene Kennwort CCCCC
AAAAA und BBBBB stehen dabei für die ersten beiden Blöcke des Lizenzschlüssels. Der dritte Block CCCCC wird als Ergebnis des Linkaufrufs geliefert.

Link 1 funktioniert auch bei djukebox-Systemen. Deren Passwort ist bis dato gemäß Support-Mitteilung gar nicht änderbar. Mir liegen die Reklamation eines djukebox-Bestandskunden vor, bei dem die eingetragenen Bankdaten von Seiten bislang unbekannter Dritter geändert wurden.
Ob die einfache Anzeige des vom Hersteller vergebenen Passworts auch für die Software-Produkte chayns und Radio.fx zutrifft ist noch zu prüfen.

2) Mit dem Link erhält JEDER, der Kenntnis von der Site-ID hat, das vom Nutzer der Lizenz GEÄNDERTE Kennwort. CCCCC steht dabei für das vom Hersteller vergebene Passwort. Das vom Lizenznehmer geänderte Passwort befindet sich unverschlüsselt (!) im Quelltext des oberen Teils der nach Aufrufs des Links angezeigten Seite. Dieses Passwort ist am einfachsten durch Eingabe des Suchstrings LOGIN zu finden. (Zur Anzeige des Quelltextes genügt die im Internet Explorer enthaltene Funktion "Quellcode anzeigen". Der Funktionsaufruf ist nach Drücken der rechten Maustaste möglich. Die Funktion befindet sich etwas unterhalb der Mitte des Auswahlliste). - Die nach Link-Aufruf erscheinende Seite läuft nicht auf den David-Servern der Lizenznehmer, sondern unverschlüsselt und ungesichert als Shadow der root-Seite der David.Administrator-Einträge der Kunden ohne deren Genehmigung auf den Servern der Tobit.Software AG. Eine Information darüber in den Datenschutz-Hinweisen des Herstellers fehlt nach heutigem Kenntnisstand.

Die Site-ID des Installation wird auf JEDEM David-Client innerhalb einer Netzwerks angezeigt. Dazu gehören auch David-Clients, die nur Remote via TCP mit einem David-Server verbunden sind.

Aus dem heutigen (16.03.2014) bestehenden Ist-Zustand ergeben enorme Risiken für die Lizenznehmer. Dazu eine kleine Auswahl:

A) Mit Kenntnis der Site-ID und des zugehörigen Passworts ist jede Bankverbindung und jede Kreditkarten-Information, die IM TSSM hinterlegt wurde, für Unbefugte in unverschlüsselter Klarschrift lesbar. Diese Daten können an anderer Stelle - zum Beispiel für Bestellungen übers Internet - missbraucht werden.

B) Erfolgten Einträge von Nutzern im TSSM (Tobit Software Sitemanagement, so kann jeder Beliebige deren Namen und die Funktion im Unternehmen einsehen.

C) Es können ohne Wissen und Zustimmung des Lizenznehmers von Unbefugten Änderungen der mit der Tobit.Software AG bestehenden oder nicht bestehenden Verträge vorgenommen werden. Insbesondere betrifft das die Verwaltung der SiteCare-Verträge, da für deren Abschluss oder Änderung lediglich die Kenntnis der Site-ID und des zugehörigen Passworts nötig ist. Auch innerhalb von Netzwerken mit mehreren tausend David-Clients ist die Site-ID überall sichtbar.

D) David-Virenschutz und der Message Identifikation Service können von Angreifern abgeschaltet werden. Dann lässt sich bequem beispielsweise ein Trojaner installieren. Anschließend werden die beiden Dienste wieder eingeschaltet. Weder der David Lizenznehmer noch sein Administrator kann das rechtzeitig erkennen und gegensteuern.

E) Die vollständigen Startlizenzen sind online über den Menüpunkt Lizenzen sichtbar. Daher sind sie auch kopierbar und können daher beispielsweise auf den Servern eines Spam-Versenders eingesetzt werden.

F) Die Fachhändler-Zuordnung jeder Lizenz von Tobit.Software kann ohne Wissen und Zustimmung des Lizenznehmers auf einen anderen Fachhändler übertragen werden. Die einzig erforderliche Information ist die Site-ID, denn das zugehörige Passwort ergibt sich aus obigen Links.
Genau die unerlaubte Änderung Fachhändler-Zuordnung ist mir bei einem wichtigen Bestandskunden passiert. Nach einem erfolgtem David-Update wurde mir zunächst die Provisionszahlung verweigert mit dem Hinweis, diese Lizenz sei zum Zeitpunkt des Updates ja gar nicht in meinem Kundenbestand gewesen. Der Nachweis war in diesem Fall sehr einfach, da ich bei diesem Kunden nicht nur die Betreuung, sondern auch die Urlaubsvertretung des Administrators mache.

E) Die Sicherheitsfunktion, wonach nur der ausdrücklich Befugte wie Administrator oder Geschäftsführer eines Unternehmens einen kostenpflichtigen Vorgang auslösen dürfen, ist vollständig ausgehebelt.

Die Missstände sind gemäß Zeugen dem Management der Tobit.Software AG bereits seit über zwei Jahren bekannt. Sie wurden gemäß erhaltener telefonischer Information damals schon hier im David-Forum diskutiert, aber leider kann ich die zugehörigen Einträge nicht finden. -
Eine Behebung dieser Datenschutz-Probleme ist in nun mehr als zwei Jahren bis dato absolut NICHT erfolgt.

Was ist nun zu tun? Nun, da gehen die Meinungen etwas auseinander. Ich empfehle momentan folgendes:
I) Es sollten so wenig Informationen wie möglich ins TSSM eingetragen werden.
II) Da MIS und Virenschutz von david zu leicht auszuhebeln sind empfehle ich den Einsatz von Spam- und Virenschutz-Systemen von Drittanbietern. Selbige sind darauf zu prüfen, ob Sie Viren abfangen, obwohl der Empfang über den Grabbing-Server als Dienst läuft. Mit Einsatz des Systeme von Drittanbietern ist es überflüssig, Bank- oder Kreditkarten-Daten ins TSSM einzutragen.
III) Der Status online abschließbarer Verträge über David-Virenschutz, MIS und SiteCare sollte beim gegenwärtigen Stand der Dinge mindestens monatlich überprüft werden. Auch der Status des Translation Service sollte gelegentlich überprüft werden, da dessen Nutzung auf "anderer Leutes Kosten" für Unbefugte verlockend ist.
IV) Sollte das Update eines Produkts von Tobit.Software nur möglich sein, wenn dazu Kreditkarten- oder Bankdaten online im TSSM oder bei david.tobit.net zu hinterlegen sind, dann sollte beim heutigen Stand wegen mangelhafter Datensicherheit darauf verzichtet werden. Die Gefahr des Missbrauchs dieser sensiblen Daten durch Cyber-Kriminelle ist zu hoch.
V) Der Status einer korrekten Fachhändler-Zuordnung sollte spätestens alle zwei Monate überprüft werden.
VI) Port 267 sollte in der Firewall geschlossen werden, damit remote keine ungenehmigte Nutzung von Backline Features erfolgen kann.

Last but not least: Jedwede Remote-Verbindung zu einem David-Server sollte am besten nur noch über registrierte VPN-Verbindungen erfolgen. Alles andere, auch der Weg über den SSL-verschlüsselten Port 443, erscheint nicht mehr ausreichend sicher. Es sollten dabei Server-seitig VPN-Router eingesetzt werden, die ein Ausschließen nicht mehr gewünschter VPN-Clients ermöglichen. (Letzteres ist zum Beispiel nach Geräte-Diebstahl oder bei Ausscheiden eines Mitarbeiters aus dem Betrieb wichtig).

@Altair:
Bitte immer erst in Ruhe lesen sowie verstehen und erst dann meckern. -
Ich bin über den Status der Sicherheitsprobleme erst Anfang Januar 2014 informiert worden.
Wäre ich früher darüber informiert gewesen, dann hätte ein Düsseldorfer Arbeitgeberverband letztes Jahr auf Microsoft Exchange umgestellt statt ein David-Update zu erwerben.

@Kamil:
Die Äußerungen stimmen.
Ich bin bereit, mich diesbezüglich in einem Gerichtsverfahren vereidigen zu lassen.
Die Identität der Informanten unterliegt allerdings dem Zeugenschutz.

Was die Weitergabe der Informationen an Journalisten angeht, so gilt der alte Leitsatz für Führungskräfte:
"Es gibt nichts Gutes, es sei den Du tust es."

Was die Funktion der Links angeht, so ist diese mit beliebiger Site-ID prüfbar.
Übrigens funktioniert die Passwortausgabe auch bei einer chayns-Lizenz.

Für das nachfolgende Beispiel habe ich eine reale chayns-Lizenz mit der Site-ID 64389-16130 ausgewählt.
Zur Dokumentation sind die mittels david Bild-Funktion erzeugten Bilder einschließlich des automatisch erzeugten Zeitstempels hier hineinkopiert.
Die david Bild-Funktion wurde innerhalb einer Minute nach Bildausgabe durch die Links angewendet.

Die Eingabe von liefert zum Zeitpunkt der Dokumentation den vollständigen Lizenzkey mit Passwort auch bei chayns:

[Blockierte Grafik: http://www.antons.de/public/picchayns.jpg] 
.

http://dvadmin.tobit.com/dvp.asp?p=6438916130BKNSA
liefert leider auch hier im Quelltext in den Zeilen 250 und 258 der angezeigten Seite das geänderte Passwort in Klarschrift, obwohl zu chayns nirgends von einem zugehörigen David Administrator berichtet wird.
[Blockierte Grafik: http://www.antons.de/public/ossochayns.jpg] 
Und nicht nur das - ein Klick auf Tobit Software Site Management genügt für alles Weitere.
Schade übrigens, dass das Passwort immer noch nicht Case-sensitive ist.
Sicherheitstechnisch orientiert sich die Vorgabe hier zu sehr an der Qualifikation von Kindern statt am Bedarf von Firmen.

Ich schätze, dass david, djukebox und chayns zusammen gerechnet, mehr als eine halbe Million Lizenzen von den Sicherheitsproblemen betroffen sind.
Dabei sind alte David-Version eingerechnet. - Bei jeder djukebox steht die Site-ID ab Werk auf der Rückseite.

Die Anwendung des Links bei Radio.fx führt übrigens zum gleichen Ergebnis.
Das ist bei EInzelplatz-Installation aber belanglos, da der vollständige Lizenzkey ohnehin unter Datei / Einstellungen / System jederzeit sichtbar ist.

Abschließend bleibt zu erwähnen, dass meine via Partner-Kommunikationssystem im Dezember 2013 und Januar 2014 wiederholt erfolgte Anfrage nach Benennung des Datenschutzbeauftragten der Tobit.Software AG nicht zu einem Resultat führte. Der Inhalt der statt dessen Antworten erweckte bei mir den Eindruck, dass entweder ein solcher Datenschutzbeauftragter nicht existiert oder dass er in seiner Arbeit massiv behindert wird.

Hallo kingcopy,
richten Sie Ihr Augenmerk bitte einmal auf das Verzeichnis. Dort steht ...\user\28\...

In den letzten elf Jahren beginnen die von david und Vorgänger-Versionen benutzten User-Verzeichnisse stets mit \10..., aber nicht mit 28. Und sie sind achtstellig, nicht aber zweistellig. Die kurze Länge des Verzeichnisnamens kann bedeuten, dass die User-Verzeichnisse händisch manipuliert wurden. Stammt - um das zu beurteilen fehlen mir einige Informationen - der kurze Verzeichnisname noch aus der Anfangszeit der David-Systeme, dann ist ein frühes Update nicht korrekt gelaufen.

Beide Varianten führen zu einem inkonsistenten Filesystem.

Natürlich könnte auch jemand mehr als 28 neue Verzeichnisse (die Zählung erfolgt hexadezimal) unterhalb von Servername\Benutzer angelegt haben. Aber bei richtiger Vergabe der Zugriffsrechte und ausreichender Sorgfalt des System-Verantwortlichen kann das nicht passieren. Es kommen also wohl nur die ersten beiden Varianten als Ursache in Betracht.

bei mir kommt nur das hier im anhang ...

@Tskasa & dertampon:
Der Lizenzkey ist echt. Ich habe ihn lediglich verschenkt.
Es handelt sich nicht um eine david-, sondern um eine chayns-Lizenz.
Findet jemand das aktuell für diese Site-ID geltende Passwort heraus, so darf er via club.tobit.com seine Bankdaten der Kontoverwaltung der Site-ID hinzufügen. (Bitte aus ausreichende Konto-Deckung achten). -

Seit gestern Nachmittag funktioniert Link 1 nicht mehr.
Damit kehrt bis auf weiteres erst mal Ruhe ein.
Hoffentlich hält sie eine Weile an.

Ohne Zweifel: Es war nie Verboten im User Verzeichnis eigene gemeinsame oder Sortierte Ordner anzulegen.
Denn mit einem solchen Verbot würden Entwickler und Supporter ja den Kunden unzulässig bevormunden.

Aber ratsam war es auch noch nie, die Struktur unterhalb von User so wie geschehen zu erweitern.