"Vorgang exportieren" und "Speichern unter" auch ohne lokale Administrationsrechte (am WTS)

[#1]

Hallo,  im Tool Datenprüfung gibt es zwei Bestands-organisatorisch wichtige Funktionen, die es so vergleichbar ja auch in vielen anderen DATEV-Programmen gibt:

a) Vorgang exportieren (im Vorgangs-Manager)

Das entspricht ungefähr der Funktion Bestandsmanager->Sichern in anderen Programmen.
Im Ergebnis wird ein ZIP-Archiv erstellt was auch ein Passwort beinhaltet.
Man kann solche exportierten Vorgänge damit auslagern, unabhängigen aber berechtigten Dritten inkl. DATEV im Bedarfsfall überlassen.

b) Speichern unter...
Das gibt es so z.B. auch in den Steuerprogrammen von DATEV, aber auch in anderen Tools.
Über diese Funktion kann der aktuelle Datenbestand neu unter andere Ordnungsbegriffen in der gleichen DB
gespeichert werden.


Und jetzt zum Problem und dazugehörigen "Idea" / Verbesserungsvorschlag:

Ganz unabhängig von den NuKo (ääh Benutzerrechteverwaltung) scheint das Programm auch dann wenn alles erlaubt ist auch in einer WTS-Umgebung und auch ganz unabhängig von den Rechten am gewählten Zielordner für den Vorgang immer lokale Adminrechte zu benötigen.   


Bei Vorgang exportieren erscheint diese Meldung, wenn man das ohne lokale Adminrechte (am WTS!) macht:




Bei Speichern unter folgt diese Meldung:

Das macht das Programm in diesem Punkt in größeren Umgebungen für Leute die wissen was sie tun unnötig umständlich.  Ohne Hilfe eines (Domänen-)Administrators kann man im Prinzip die o.g. Funktionen in der Praxis in einer Citrix-Terminalserverfarm mit dynamisch zugewiesenen WTS nicht mehr wirklich verwenden.

In Info-Dokument 9215780 wird das Ganze ebenso wie bei Supportanfragen unter dem Label "It's not a bug, it's a feature" verkauft, d.h. DATEV wünscht sich das an der Stelle so.  (?!?)

Der Lösungsvorschlag:  der Vorgang sollte vom Entwickler dahingehend untersucht werden, ob hier evtl. (WTS-kompatibilitätsverletztend ?) irgendwo auf einen dort nicht sinnvollen lokalen Pfad zwischengespeichert wird.  Dies sollte entsprechend so abgeändert werden, dass das "Cachen" z.B. in einem normalen Programmdatenpfad (im Netz üblicherweise irgendwo bei L: ) erfolgt (so wie es z.B. DATEV-Rechnungswesen auch macht).   

So wie ich das sehe ist es auch kein grundsätzliches WTS-Problem / wäre auch an einem lokalen Rechner so. Allerdings ist die Auswirkung an einem WTS oder in einer größeren Citrix-Umgebung in der Praxis gravierender. Einem Experten-Anwender mit einer "Oldschool"-Laptop-Lokalinstallation kann ich zur Not noch einen Extra-Zweituser mit rein lokalen Adminrechten geben.  Bei einem WTS oder einer ganzen WTS-Farm (Citrix & Co.) geht das eigentlich überhaupt nicht.  Von ASP / SmartIT nicht zu reden.

Es kann durchaus Sinn machen, dass in einer (größeren) Umgebung (mit und ohne WTS) Funktionen wie "Vorgang exportieren", "Vorgang importieren", "Speichern unter" und natürlich auch "Vorgang löschen" über Benutzerrechte nur auf bestimmte Personenkreise eingeschränkt werden. Dies ist bei größeren Umgebungen aber selten der WTS-IT-Administrator sondern ein fachlicher Keyuser.  Daher bietet es sich an, diese Funktion wenn überhaupt über die Benutzerrechteverwaltung von DATEV (früher NuKo) zu steuern und nicht über das Einfordern lokaler Adminrechte.


Grüße, Bernd Wettstein.

[#2]

Hallo @bernd_wettstein,

ich habe die benötigten Informationen eben erhalten. Die Daten eines Vorgangs werden in Datenprüfung in einer eigenen Datenbank verwaltet. In der aktuellen Sicherheitsarchitektur für Datenbanken ist es für Benutzer nicht möglich, die zu einem Vorgang gehörende Datenbank zu kopieren. Dies ist sowohl für den "Export eines Vorgangs" (Kopieren in eine ZIP-Datei) als auch für das "Speichern unter eines Vorgangs" (Kopieren in ein anderes Verzeichnis) erforderlich. Beides ist nur als Administrator möglich.

Viele Grüße,
Jochen Scheer
DATEV eG

[#3]

Hallo Herr @Jochen_Scheer ,  bei dieser Antwort bin ich jetzt allerdings noch mehr verwirrt als zuvor, denn:  welche(r) Security-Sicherheitsgesichtspunkt(e) sollen dies denn sein, die in den übrigen Datev-Programmen mit Mandanten-/Bestandsmanager (z.B. ReWe, APComfort, Lohn, Steuerprogramme, usw.) offenbar nicht gelten oder z.B. sogar über die Benutzerrechteverwaltung kanzleispezifisch geregelt werden können.

Konkret:  welcher Securityaspekt lässt die Funktionalität an Domänenadminrechte (und dann auch noch in einer WTS-Umgebung) koppeln? 

Wenn es die Folgewirkung eines temporären Zwischenspeicherns ist hatte ich ja schon Auswege - im Vergleich mit ansonsten gut funktionierenden Datev-Datenpfadkonzepten - dargestellt, die kein grundsätzliches Sicherheitsrisiko mehr darstellen.

Grüsse, Bernd Wettstein.

[#4]

@bernd_wettstein: Ich habe meinen Kommentar von Donnerstag aktualisiert.

Viele Grüße,
Jochen Scheer
DATEV eG

[#5]

Hallo Herr Scheer,  

vielen Dank für die Ergänzung.  Jetzt bin ich schon etwas schlauer, was Entwickler beim Zuarbeiten zu dieser Idea wohl verstanden haben.  Dies ist aber nicht zwangsläufig das, was der Anwender gemeint hat.  😉   Bei der Rückmeldung sieht man, dass ganz offensichtlich meine Ausführungen zum Thema "temporäres Zwischenspeichern" durch die Entwicklung bei der Bearbeitung bzw. Ablehnung der Idea nicht berücksichtigt wurden.  Es handelt sich offensichtlich eben nicht um ein sicherheitsrelevantes Problem in Sinne von Sicherheit der Daten, Sicherheit gegen unberechtigte Zugriffe oder Sicherheit im Sinne der Anwender, sondern um ein rein organisatorisches Problem wie das Programm Datenprüfung beim Vorgang exportieren Daten verlagert und zwischenspeichert.

Mein Beispiel, dass dies bei anderen Programmen der DATEV ja z.B. auch problemlos funktioniert zeigt, dass die Begründung keine tatsächliche ist.  Ebenso könnte ReWe statt auf L:\DATEV\DATEN\....\KRTEMP o.ä. beim Sichern Daten nicht dort, sondern im SQL-Server oder gar am WTS auf lokale Pfade wie C:\TEMP zwischenspeichern und wir hätten das identische Problem dort auch.   Deshalb sind die Entwickler dort den Weg gegangen, beim Sichern eines Bestandes aus der Datenbank heraus oder aber der Datenbank selbst eben eine Dump-Funktion zu implementieren,  die entweder serverseitig oder programmseitig so funktioniert, dass sie direkt im Userkontext auf berechtigte Pfade (eben z.B. L:\DATEN\DATEN\....\KRTEMP,  oder auf einen direkten Exportdatenpfad in L:\DATEV\DATEN\...\EXPORT o.ä. sichert oder sogar komplett dem Anwenderwunsch folgt und direkt in den Exportpfad speichert.

Die Lösung ist also nicht im sicherheitsrelevanten Kontext zu suchen, sondern einzig und alleine in der Methodik,  wie und in wessen Kontext das Programm bei angemeldetem User einen Datenabzug erstellt.     Hier würde es m.E. Sinn machen, sich auch mit anderen Programmbereichen der DATEV sich auszutauschen und die doch etwas eigene Methodik in DATEV Datenprüfung für "Vorgang Exportieren" mal mit "Bestand sichern" zu vergleichen.

Um das Thema endgültig aus der "Schleife" zu holen, in der wir uns hier offenbar verrannt haben:   dann möchte ich eben meine Idea anpassen und wünsche mir statt "Vorgang Exportieren" einen normalen Bestands-Manager wie in Bestandsdienste ReWe,  Lohn & Gehalt, Steuerprogrammen, AP Comfort, etc. pp. auch, wo es diese Probleme mit Sichern im Anwender- statt im Programmkontext eben gar nicht erst gibt.  😉

Ich wäre Ihnen dankbar, wenn die Idea unter diesem Kontext evtl. nochmal geprüft werden könnte. 

Viele Grüße & Danke für Ihre Geduld mit mir im Voraus  😇

Bernd Wettstein

[#6]

Hallo @bernd_wettstein,

ich habe den Status Ihrer absolut berechtigten Idee zu voreilig auf „abgelehnt“ gesetzt. Tatsächlich wird die derzeitige und von mir geschilderte Situation weiterhin auf Machbarkeit untersucht. Daher ändere ich den Status Ihrer Idee wieder auf „In Prüfung“.

Viele Grüße,
Jochen Scheer
DATEV eG

[#7]

Moin Herr Wettstein

Mir scheint dies eher ein Konfigurationsproblem darzustellen.

Wenn sie versuchen in einen für sie gesperrten Ordner zu exportieren, weigert sich Windows natürlich.

Eigentlich wird auch immer nach dem Speicherort nachgefragt. Was da als Default-Ordner eingetragen ist, muss nicht unbedingt richtig sein.

Ihr Beispiel für einen Default-Ordner ist nicht der einzige, wo ein No-Go als Speicherplatz vorgeschalgen wird.

Laufwerk L mit den Daten (und Datenbanken) sollten grundsätzlich als Speicherort ausgeschlossen werden - zumindest als Default-Speicherort. AUf Laufwerk L hat niemand außer dem Administrator etwas zu suchen!

Dass Datev das immer noch nicht berichtigt hat ...

Herr Scheer, das wäre meine Idee zur Verbesserung der Datev-Software. Und eine, die sicherheitsrelevant ist.

QJ

PS: Ich will nicht meckern, doch wer ist bloß auf die bekloppte Idee gekommen, auf Laufwerk L einen Defaultspeicherplatz (bei ISWL irgendwas, mir fällt gerade der Name nicht ein, werden grundsätzlich nur in einem Ordner unter L:\Datev\Daten\... die Ergebnisse abgelegt) zu definieren? Das ist Uraltwissen von Entwicklern, dass man dies nicht tut. Und Administratoren. Und der Menschenverstand sollte das auch schon sagen.

Nichts für ungut, ich fühle mich gerade in alte Win 98-Zeiten zurück versetzt. Ich denke, es gab kein Rückmeldung.

[#8]

Hallo @quantenjoe ,  

unabhängig von der durchaus DATEV-global diskussionswürdigen Wahl von Default-Pfaden für Exporte (bei ReWe führt dies auch regelmäßig schon aus Tradition und seit meiner eigenen Ausbildungszeit in den späten 90er schon immer wieder zu Problemen, wenn ausgerechnet dorthin Stapel exportiert werden 😉 -  ich denke, ich verstehe Sie da sehr gut  *g* 😉).

ich glaube oder bin mir zumindest nicht sicher, dass dies nicht unbedingt der Grund für die Probleme mit den nötigen lokalen Adminrechten ist.  Zumindest tritt das Problem in einer WTS-Umgebung ganz genauso auf, wenn der Exportpfad auf einen ganz normal userberechtigten Pfad (im WTS muss das zwangsläufig ja aus bekannten Gründen ein Netzlaufwerk sein) liegt, auch z.B. bei einem DATEV-fremden NAS-Pfad oder eben auch "Eigene Dateien" im Userprofil (in moderneren WTS-Umgebungen mit ganzen Citrix-Farmen gem. Whitepaper oftmals nicht mehr lokal). 

Aber:  der Hinweis lässt mir trotzdem keine Ruhe.  Ich denke und hoffe, dass nach meiner ausführlichen Analyse und Darstellung des Programmverhaltens die DATEV selbst das alles bereits vor Bearbeitung diverser Servicekontakte und auc dieser Idea längst durchgespielt hat.   Aber weil man niemals nie sagen darf werde ich das in Kürze (morgen/übermorgen) auch nochmal in unserer eigenen Citrx-WTS-Farm mit unserer IT durchspielen, in wie weit sich das Programmverhalten zwischen dem Export auf L:,  auf einem userberechtigten NAS-Pfad,  auf dem Userprofil oder auf dem lokalen durchgereichten Client-Pfaden ändert.    Ich würde wetten, dass dies alles kein Unterscheid ist, weil der "Fehler" (oder das bisher von der Entwicklung als "it's not a bug, it's a Feauture" wahrgenommene Programmverhalten in komplexeren WTS-Umgebungen 😉 ) - so zumindest von mir vermutet - eher in einem internen Zwischenspeichern auf Pfaden und Instanzen wo der Userkontext nicht berechtigt ist (aber auch nicht sinnvoll ist) auftritt,  aber man hat ja Pferde, Apotheken, usw. schon in ganz anderen Situationen gesehen....  😄

Ich melde mich, wie meine Tests in normalem Userkontext in einer - immerhin von DATEV selbst mitimplementierten komplexeren Citrix-Umgebung - verlaufen sind.

Viele Grüße, Bernd Wettstein.

[#9]

Hallo @Jochen_Scheer ,

danke.  Das macht Mut. 🙂    

Ich halte Sie auf jeden Fall auf dem Laufenden, wie sich das Programmverhalten bei verschiedensten Pfadvarianten - angeregt von den Ausführungen von @quantenjoe  - womöglich ändert (wobei ich immer noch oder zumindest bisher glaube, dass das vom Zielpfad im Userkontext unabhängig ist).  Ich bin sicher dass diese Tests Ihren Entwicklern bei der weiteren Beurteilung bzw. Realisierbarkeit dieser "Idea" hilfreich sind.

Viele Grüße, Bernd Wettstein.

[#10]

Hallo @quantenjoe , hallo @Jochen_Scheer,

ich habe nun wie angekündigt mal aller Varianten durchprobiert.  In unserer Terminalserverumgebung verhält sich das Programm DATEV Datenprüfung bei "Vorgang exportieren" auch bei verschiedenen Pfaden so:

Standard-Export-Pfad (voreingestellt):   im Userprofil in den Ordner \Dokumente\DATEV\Transfer\WPDiDa

Weitere Pfade die ich im Export-Ordner-Dialog jeweils durchprobiert habe:

- ein NAS-Netzlaufwerk außerhalb von L:  (\\windvsw1\...) mit ausreichenden Schreib-, Lese- und Löschrechten für den User

- dito nur das durchgereichte lokale Laufwerk vom Laptop,  dort auf C:\temp  (im Userkontext ausreichend Rechte)

- direkt ein neu angelegter Ordner auf L: (\\windvsw1\...) im Root (dort ausreichend Rechte im Userkontext)

*Überall* kommt es zu dem identischen Phänomen, dass der Export dort auch tatsächlich angefangen wird und Dateien abgelegt wird, dann aber mit der bekannten Fehlermeldung (wie im Eingangspost beschrieben) auftaucht.

@Jochen_Scheer:  ansonsten macht das Ganze den Eindruck auf mich, dass es eben eher nicht an der Konfiguration liegt / Sie konnten doch m.E. das von mir beschriebene Programmverhalten nachstellen, wenn ich recht erinnere?

@quantenjoe :
Daher die dann aber nun doch noch spannende Frage:  wenn das o.g. bei Ihnen alles so nicht passiert,  was ist an Ihrem System anders (lokale Adminrechte und Programm am lokalen Client statt WTS o.ä.?).   Oder wo ist mein Denkfehler was die Konfiguration angeht?

Grüße, Bernd Wettstein

[#11]

Hallo @bernd_wettstein,

richtig, die Konfiguration ist für den Export irrelevant. Die beim Exportversuch als Benutzer erscheinende Programm-Meldung gibt die Voraussetzung für den Export korrekt wieder.

Viele Grüße,
Jochen Scheer
DATEV eG