Hallo zusammen,

mein erster Beitrag hier, eine detaillierte Vorstellung gibt es an anderer Stelle gleich auch noch

Mal kurz ein paar schlanke Zeilen zu mir:

Ich heiße Dennis, bin 24 und befinde mich in der Ausbildung zum FISI.

Nun zu meinem Problem:

Wir haben auf einem virt. WinXP eine Bankensoftware für die Firma laufen, auf die 3 User Zugriff haben.

Die Software verlangt von jedem User einen Key, der als Datei auf A: abgelegt sein muss.

Mein Problem ist, dass alle 3 Key-Dateien gleichnamig sind und auch nicht umbenannt werden dürfen, und sie müssen zwingend auf A: abgelegt sein.

Nun dürfte klar sein, dass wenn ich die Key-Datei dreimal auf A: ablege, überschreiben sie sich... d.h. nur der User dessen Key-Datei als letztes eingepflegt wurde kann sich gegenüber der Software authentifizieren.

Meine Überlegung ist folgende:

Ich virtualisiere 3 Laufwerke, jeweils nur ein paar MB groß, und lege dort die Key-Datei separat für jeden Nutzer an.

Ist es möglich das Laufwerk bei Anmeldung des jeweiligen Users nicht nur zu mappen, sondern auch in A: umzubennen?

Ich würde mich freuen wenn sich der ein oder andere mal mit mir den Kopf zerbricht

Grüße,

Dennis

Nun ja - wenn es im Basisbetriebssystem (in diesem Falle das virtualisierte XP) kein Laufwerk mit dem Buchstaben A: gibt, ist es kein Problem, im Anmeldescript des jeweiligen Users ein Netzlaufwerk als Laufwerk A: zu mappen. Pro User dann eine entsprechend andere Freigabe und schon war's das.

Oder muss Laufwerk A: für das Betriebssystem als physikalisches Laufwerk erscheinen, damit die Banksoftware das erkennt?

Anderer Ansatz: nicht als Netzlaufwerk sondern mit "subst"

Skript für jeweiligen User:

User1: subst a: d:\keyordner\user1\key.xxx

User2: subst a: d:\keyordner\user2\key.xxx

User3: subst a: d:\keyordner\user3\key.xxx

Bearbeitet 17. August 201114 j von erax

Hallo zusammen,

@erax: Deine Idee war richtig, habe jetzt ein Anmelde-Script geschrieben (if-Abfrage, nach Erkennen des Nutzers wird mittels subst Laufwerk A: virtualisiert)

Leider hatte Eye-Q auch Recht, anscheinend kann die Software auf ein virtuelles A: nicht zugreifen

Ideen?

Danke!

Schonmal ein schönes Wochenende!

Grüße,

Dennis

andere Banksoftware.

Ne wie virtualisiert ihr denn?

Bei VMWare kann man z.B. das lokal A in die Virtuelle Umgebung durchschleifen.

Dann kann jeder User wieder wiegewohnt seine Diskette nutzen.

arbeiten die User gleichzeitig mit dem System?

Der Sinn dieser Key-Datei wird doch vermutlich die Authentifizierung dieser drei Mitarbeiter in der Banksoftware anhand ihrer Key-Dateien sein, oder?

Dann wäre es vom Sicherheitsaspekt sinnvoller, wenn alle drei Mitarbeiter jeweils einen USB-Stick bekommen mit der Key-Datei, der dann vor Benutzung der Software eingesteckt werden muss.

Dann ist da noch die Frage, wie der Client virtualisiert ist.

Da gibt es z.B. VMWare VDI, d.h. die Maschine läuft auf einem Server, wo sich dann die User per VDI-Client drauf verbinden, es kann aber auch sein, dass der per Windows Virtual PC auf einer Client-Maschine virtualisiert ist. Bevor wir das nicht eindeutig wissen, können wir relativ schlecht sagen, wie sich eine solche Konstellation sicher lösen lässt, vor allen Dingen in Hinsicht auf den Einwand von lupo49 gesehen.

Es wird mittels VMWare virtualisiert.

Die User arbeiten nicht gleichzeitig auf dem System, da mittels Remote Desktop Verbindung auf die Maschine zugegriffen wird.

Die Datei die abgelegt wird ist für die digitale Unterschrift der Zahlungsanweisungen nötig, deswegen ist auch der Sicherheitsaspekt nicht zu vernachlässigen.

...Du redest von dem HVBglobalTRXplus?

Es geht um Multicash Deutsche Bank...

...Multicash hatten wir gaaaanz viel früher im Einsatz, das Folgeprodukt war dann der GlobalTRXPlus. Genau da gab es Dein beschriebenes Problem, dass zur Authentifizierung ein LW A: oder LW B: erwartet wurde. Lösen konnte ich das mittels Windows 2003 Server (User griffen über Terminalservices zu) sowie einer entprechenden GPO, welche das Verzeichnis des Users, mit seiner Zertifikatsdatei, als LW B: einrichtete (unter Zuhilfenahme des PolicyMakers). Das wurde dann von der Software akzeptiert...

Hey!

Des Rätsels Lösung war so einfach, dass man den Wald vor lauter Bäumen nicht gesehen hat.

Lösung:

Alle 3 Dateien "mcSign.dat" wurden in A: abgelegt, allerdings leicht abgewandelt (mcSign_XX.dat, mcSign_YY.dat, mcSign_ZZ.dat)

dazu ein Logonscript mit Userabfrage. Wenn User "XX" sich anmeldet, wird die Datei "mcSign_XX.dat" automatisch umbenannt in "mcSign.dat" .

bei User "YY" und "ZZ" entsprechend.

Ein Logoutscript macht das ganze bei Abmeldung des Users wieder rückgängig, damit es zu keinen Kollisionen im Dateinamen kommt.

Danke für eure Hilfe!

Grüße,

Dennis

...oder so...;-)

oh, nicht umbenennen. Kopiere Sie doch einfach.

Dann hast du immer das "Original" noch.

Denn was passier z.B. wenn sich der User nicht ausloggt, sondern der Rechner z.B. abstürzt?

@Enno:

Die Originaldateien liegen sicher bei uns als Backup auf nem USB-Stick.

Es geht wirklich nur um die Bereitstellung für die aktuelle Session.

Für den Fall das der Server sich mal verabschiedet o.ä. ist ein "Backupscript" eingebaut, welches bei jedem Neustart die Dateien in die Originalkonfiguration zurücksetzt.

Erst danach läuft das Script mit dem Umbenennen der Datei an.

Die Originaldateien liegen sicher bei uns als Backup auf nem USB-Stick.

Ein USB Stick ist kein sicheres Speichermedium!

Das Prinzip mit den drei Dateien mit verschiedenen Namen ist wie bereits erwaehnt schon absolut Ok. Nur sollten die wo anders liegen. Das Logonscript muss dann nur vom Ursprungsort auf A: Kopieren, Umbenennen kann man gleichzeitig machen.

Copy D:\Test.TXT a:\SoSollsein.txt

Es gibt noch einen Befehl damit copy die Zieldatei automatisch ueberschreibt...

Und die Schluesseldateien unbedingt besser aufbewahren. Ich hab schon mehr Sticks und Disketten sterben sehen als mir lieb ist...

Das der USB-Stick kein sicheres Speichermedium ist, stimmt schon, aber es war auch eher damit gemeint "Nutzer XY kann damit nicht rumspielen".

Unsere Keydaten liegen zusätzlich nochmal in einem Backup bei der Bank, und wenn deren Server da was zerschießt...not my business

@FfFCMAD:

Danke für deine Idee, dass ist nochmal Feintuning, damit die Daten nicht permanent auf A: rumdümpeln...