<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Echtes Avant on Michael’s Domain</title><link>https://jeltsch.org/de/tags/echtes-avant/</link><description>Recent content in Echtes Avant on Michael’s Domain</description><generator>Hugo</generator><language>de</language><copyright>Copyright © 2002 - 2026 Michael Jeltsch.</copyright><lastBuildDate>Fri, 24 Jul 2026 00:18:18 +0300</lastBuildDate><atom:link href="https://jeltsch.org/de/tags/echtes-avant/index.xml" rel="self" type="application/rss+xml"/><item><title>Kurs zur Proteinreinigung 2019</title><link>https://jeltsch.org/de/protein_purification_course_2019/</link><pubDate>Wed, 31 Jul 2019 00:00:00 +0000</pubDate><guid>https://jeltsch.org/de/protein_purification_course_2019/</guid><description>&lt;p&gt;Auch in diesem Dezember veranstalten wir wieder den DPBM-Kurs zur Proteinreinigung in unserem Labor. Sichern Sie sich Ihren Platz, denn dieser praxisorientierte Kurs ist sehr beliebt und es gibt nur 16 Plätze. Sie können Ihr eigenes Protein mitbringen, und wir passen das Kursprogramm individuell an Ihre Bedürfnisse an!Weitere Informationen: 
 &lt;a href="http://research.med.helsinki.fi/corefacilities/b3p/teaching.htmlRegistration" target="_blank" rel="noopener noreferrer nofollow"&gt;http://research.med.helsinki.fi/corefacilities/b3p/teaching.htmlRegistration&amp;nbsp;






 
 
 
 &lt;svg class="svg-inline--fa fas fa-up-right-from-square fa-2xs" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 512 512" overflow="visible"&gt;&lt;use href="#fas-up-right-from-square"&gt;&lt;/use&gt;&lt;/svg&gt;&lt;/a&gt;
: 
 &lt;a href="https://courses.helsinki.fi/en/dpbm-135/131042336" target="_blank" rel="noopener noreferrer nofollow"&gt;https://courses.helsinki.fi/en/dpbm-135/131042336&amp;nbsp;






 
 
 
 &lt;svg class="svg-inline--fa fas fa-up-right-from-square fa-2xs" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 512 512" overflow="visible"&gt;&lt;use href="#fas-up-right-from-square"&gt;&lt;/use&gt;&lt;/svg&gt;&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Unicorn 7-Benutzer-Einrichtung erfordert manuelle Intervention in einer Netzwerkbenutzer-Umgebung</title><link>https://jeltsch.org/de/unicorn_7_benutzer_einrichtung_erfordert_manuelle_intervention_in_einer_netzwerkbenutzer_umgebung/</link><pubDate>Fri, 17 Jun 2016 00:00:00 +0000</pubDate><guid>https://jeltsch.org/de/unicorn_7_benutzer_einrichtung_erfordert_manuelle_intervention_in_einer_netzwerkbenutzer_umgebung/</guid><description>&lt;p&gt;Unicorn, Äkta Avant, Äkta Explorer, GE Healthcare, Windows, Netzwerkauthentifizierung, Benutzereinrichtung, Methode, Ergebnis, Wissenschaft, Proteinreinigung Da wir unser Äkta Avant in einer Mehrbenutzerumgebung betreiben, müssen wir die Methoden und Ergebnisse der verschiedenen Benutzer voneinander trennen. Standardmäßig kann derzeit jeder Netzwerkbenutzer alle Methoden und Ergebnisse einsehen, die von einem anderen Netzwerkbenutzer auf dem Gerät erstellt wurden. Dies stellt ein erhebliches Datenschutz- und Sicherheitsrisiko dar, da ein böswilliger Benutzer Methoden und Ergebnisse löschen (oder schlimmer noch: verändern) könnte.Unser Äkta ist so eingerichtet, dass sich Benutzer mit ihrem Universitäts-Login und -Passwort über den regulären Windows-Netzwerkauthentifizierungsmechanismus am Unicorn-7-Computer anmelden können. Wenn sich jedoch mehrere Personen die Verantwortung für einen Durchlauf teilen, ist diese Konfiguration nicht mehr möglich, da sie sich gegenseitig ihre Passwörter mitteilen müssten. Daher haben wir ein lokales Konto eingerichtet, das von Benutzern genutzt werden kann, die sich die Bedienung des Äkta-Geräts teilen möchten. Nach der Anmeldung bei Windows müssen sich die Benutzer noch bei der Unicorn-7-Software anmelden, was sie mit ihrem Hochschul-Benutzernamen und -Passwort tun („Windows-Authentifizierung“). Bei dieser Konfiguration kann jeder Benutzer alle Methoden und Ergebnisse einsehen, was nicht akzeptabel ist. Beim Einrichten eines neuen Benutzers in Unicorn (unter „Zugriff &amp;gt; Ordner“) konnte genau festgelegt werden, auf welche Ordner dieser Benutzer Zugriff hatte, und der Benutzer sah nur seine eigenen Methoden und Ergebnisse. Da die Ordnerstruktur unter Unicorn 5 der Ordnerstruktur des Windows-Dateisystems entsprach, konnten Benutzer Methoden und Ergebnisse jederzeit von einem Ordner in einen anderen kopieren und sie so trotz der vom Unicorn-5-Programm festgelegten Einschränkungen verfügbar machen.Als ich zum ersten Mal las, dass Unicorn 7 die Windows-Netzwerkauthentifizierung unterstützt, hatte ich gehofft, dass wir die mühsame Benutzereinrichtung vermeiden könnten, die wir für jeden Benutzer auf dem Äkta Explorer durchführen mussten. Doch die Mühen gehen weiter, da die einmalige Einrichtung der Benutzerrechte für eine Gruppe uns keine Benutzerisolierung bietet.Erstens kann man in Unicorn 7 nicht den Zugriff einzelner Benutzer einschränken, sondern nur den Zugriff von Gruppen. Wir mussten für jeden Netzwerkbenutzer eine Zugriffsgruppe anlegen, den Netzwerkbenutzer dieser Gruppe hinzufügen, einen separaten Home-Ordner für die Gruppe erstellen und dann den Ordnerzugriff auf diesen Home-Ordner beschränken. Für eine Handvoll Benutzer waren Hunderte von Klicks erforderlich, da standardmäßig kein Zugriff auf irgendetwas besteht und jedes einzelne Kontrollkästchen für Berechtigungen – mit Ausnahme der Administratorrechte – aktiviert werden muss. In dieser Hinsicht ist Windows (und jedes andere Betriebssystem) weitaus intelligenter als Unicorn. Wenn sich ein Universitätsmitarbeiter an einem Rechner anmeldet, an dem er sich noch nie zuvor angemeldet hat, erstellt das System automatisch die gesamte erforderliche lokale Standardordnerstruktur und bindet den privaten Home-Ordner dieses Benutzers ein, ohne Zugriff auf alles zu gewähren, was andere Mitarbeiter auf diesem bestimmten Rechner bisher getan haben. Ich denke, das sollte auch bei Unicorn eine Option sein. Vielleicht gibt es diese Option ja und ich finde sie nur nicht? Ein weiterer großer Nachteil der oben beschriebenen Methode, jeden Benutzer in eine eigene Zugriffsgruppe zu ordnen, ist, dass die Anmeldung bei Unicorn zu einer echten Tortur wird: Zusätzlich zur Eingabe von Benutzername und Passwort muss der Benutzer die richtige Zugriffsgruppe auswählen, damit die Anmeldung erfolgreich ist. Und noch schlimmer: In unserer Konfiguration lässt es sich nicht vermeiden, dass jeder Universitätsmitarbeiter zwei Zugriffsgruppen angehört: einer manuell angelegten Zugriffsgruppe für jeden Benutzer zur Benutzertrennung und der „Standardgruppe“, die über die Windows-Netzwerkauthentifizierung funktioniert – vielleicht Kerberos? Wenn Benutzer also die Standardzugriffsgruppe wählen (die in unserem Fall „Users“ heißt), können sie sich zwar anmelden, sehen aber ihre Methoden und Ergebnisse nicht.Es gibt zwei Gründe, warum wir die Zugriffsgruppe „Users“ nicht löschen können: Zum einen ist dies eine Vorgabe der Fakultät, und zum anderen (und das haben wir versucht) können wir sie nicht mehr löschen, da bereits viele Personen Methoden angelegt und Ergebnisse generiert haben, während sie der Zugriffsgruppe „Users“ angehörten. Daher verhindert UNICORN, dass wir dieses Konto löschen können. Ich arbeite an diesem Problem: Ich sollte direkt auf die zugrunde liegende MS-SQL-Datenbank zugreifen können, um die Eigentumsrechte an den Methoden und Ergebnissen zu ändern. Allerdings war GE nicht gerade auskunftsfreudig, als ich nach der Handhabung von Zugriffsrechten fragte. Die Antwort lautete: Die Zugangsdaten für die Datenbank in einer eigenständigen UNICORN-Lösung sind verschlüsselt und nicht öffentlich zugänglich. Wenn Sie eine Enterprise-Lösung hätten (mit einer eigenen (SQL-Server-)Datenbank), hätten Sie die Kontrolle über die Zugangsdaten und könnten theoretisch die gewünschten Informationen extrahieren (das Format müssen Sie selbst herausfinden; es wird von uns nicht unterstützt). Sie können Ihre Lösung auf eine Enterprise-Version upgraden, wenn Sie möchten. Das klingt schlimmer, als es ist, da wir physischen Zugriff auf den MS-SQL-Server haben und das Extrahieren der Zugangsdaten nicht besonders schwierig zu sein scheint. Aber es kostet mich Zeit, die Schwachstelle zu finden, um „in unser eigenes System einzudringen“, und genau das ärgert mich. Laut Lisa Bromark von GE scheint das Update 7.0.2 dieses Problem jedoch zu beheben: UNICORN kann so konfiguriert werden, dass ein neues Datenbankpasswort verwendet wird. Es ist möglich, ein verschlüsseltes Passwort zu generieren oder ein bereits verschlüsseltes Passwort einzugeben. Dies geschieht durch Ausführen des UNICORN Service Tools nach der Installation von UNICORN.Allerdings ist es unglaublich schwierig, das Update zu bekommen (zumindest scheint es Wochen zu dauern). Die Verteilung erfolgt offenbar immer noch über optische Datenträger und per Post. Ich glaube, das letzte Mal, dass ich mir Software auf einer CD/DVD besorgt habe, ist mehr als 10 Jahre her. GE teilte mir jedoch mit, dass sie gerade dabei sind, die UNICORN-Software-Updates auf „elektronischen Vertrieb“ umzustellen. Willkommen im 21. Jahrhundert!&lt;/p&gt;</description></item><item><title>Die Benutzertrennung in Unicorn 7 erfordert manuelle Eingriffe in einer Netzwerkbenutzerumgebung</title><link>https://jeltsch.org/de/unicorn_7_user_separation_requires_manual_intervention_in_a_network_user_environment/</link><pubDate>Mon, 09 May 2016 00:00:00 +0000</pubDate><guid>https://jeltsch.org/de/unicorn_7_user_separation_requires_manual_intervention_in_a_network_user_environment/</guid><description>&lt;p&gt;Da wir unseren Äkta Avant in einer Mehrbenutzerumgebung betreiben, müssen wir die Methoden und Ergebnisse der verschiedenen Benutzer voneinander trennen. Standardmäßig kann derzeit jeder Netzwerkbenutzer alle Methoden und Ergebnisse einsehen, die von einem anderen Netzwerkbenutzer auf dem Gerät erstellt wurden. Dies stellt ein erhebliches Datenschutz- und Sicherheitsrisiko dar, da ein böswilliger Benutzer Methoden und Ergebnisse löschen (oder schlimmer noch: verändern) könnte.Unser Äkta ist so eingerichtet, dass sich Benutzer mit ihrem Universitäts-Login und -Passwort über den regulären Windows-Netzwerkauthentifizierungsmechanismus am Unicorn-7-Computer anmelden können. Wenn sich jedoch mehrere Personen die Verantwortung für einen Lauf teilen, ist diese Konfiguration nicht mehr möglich, da sie sich gegenseitig ihre Passwörter mitteilen müssten. Daher haben wir ein lokales Konto eingerichtet, das von Benutzern genutzt werden kann, die sich die Bedienung des Äkta-Geräts teilen möchten. Nach der Anmeldung bei Windows müssen sich die Benutzer noch bei der Unicorn-7-Software anmelden, was sie mit ihrem Hochschul-Benutzernamen und -Passwort tun („Windows-Authentifizierung“). Bei dieser Konfiguration kann jeder Benutzer alle Methoden und Ergebnisse einsehen, was nicht akzeptabel ist. Beim Einrichten eines neuen Benutzers in Unicorn (unter „Zugriff &amp;gt; Ordner“) konnte genau festgelegt werden, auf welche Ordner dieser Benutzer Zugriff hatte, und der Benutzer sah nur seine eigenen Methoden und Ergebnisse. Da die Ordnerstruktur unter Unicorn 5 der Ordnerstruktur des Windows-Dateisystems entsprach, konnten Benutzer Methoden und Ergebnisse jederzeit von einem Ordner in einen anderen kopieren und sie so trotz der vom Unicorn-5-Programm festgelegten Einschränkungen verfügbar machen.Als ich zum ersten Mal las, dass Unicorn 7 die Windows-Netzwerkauthentifizierung unterstützt, hatte ich gehofft, dass wir die mühsame Benutzereinrichtung vermeiden könnten, die wir für jeden Benutzer auf dem Äkta Explorer durchführen mussten. Doch die Mühen gehen weiter, da die einmalige Einrichtung der Benutzerrechte für eine Gruppe uns keine Benutzerisolierung bietet.Erstens kann man in Unicorn 7 nicht den Zugriff einzelner Benutzer einschränken, sondern nur den Zugriff von Gruppen. Wir mussten für jeden Netzwerkbenutzer eine Zugriffsgruppe anlegen, den Netzwerkbenutzer dieser Gruppe hinzufügen, einen separaten Home-Ordner für die Gruppe erstellen und dann den Ordnerzugriff auf diesen Home-Ordner beschränken. Für eine Handvoll Benutzer waren Hunderte von Klicks erforderlich, da standardmäßig kein Zugriff auf irgendetwas besteht und jedes einzelne Kontrollkästchen für Berechtigungen – mit Ausnahme der Administratorrechte – aktiviert werden muss. In dieser Hinsicht ist Windows (und jedes andere Betriebssystem) weitaus intelligenter als Unicorn. Wenn sich ein Universitätsmitarbeiter an einem Rechner anmeldet, an dem er sich zuvor noch nie angemeldet hat, erstellt das System automatisch die gesamte erforderliche lokale Standardordnerstruktur und bindet den privaten Home-Ordner dieses Benutzers ein, ohne Zugriff auf alles zu gewähren, was andere Mitarbeiter auf diesem bestimmten Rechner bisher getan haben. Ich denke, das sollte auch bei Unicorn eine Option sein. Vielleicht gibt es diese Option ja und ich finde sie nur nicht? Ein weiterer großer Nachteil der oben beschriebenen Methode, jeden Benutzer in eine eigene Zugriffsgruppe zu ordnen, ist, dass die Anmeldung bei Unicorn zu einer echten Tortur wird: Zusätzlich zur Eingabe von Benutzername und Passwort muss der Benutzer die richtige Zugriffsgruppe auswählen, damit die Anmeldung erfolgreich ist. Und noch schlimmer: In unserer Konfiguration lässt es sich nicht vermeiden, dass jeder Universitätsmitarbeiter zwei Zugriffsgruppen angehört: einer manuell angelegten Zugriffsgruppe für jeden Benutzer zur Benutzertrennung und der „Standardgruppe“, die über die Windows-Netzwerkauthentifizierung funktioniert – vielleicht Kerberos? Wenn Benutzer also die Standardzugriffsgruppe wählen (die in unserem Fall „Users“ heißt), können sie sich zwar anmelden, sehen aber ihre Methoden und Ergebnisse nicht.Es gibt zwei Gründe, warum wir die Zugriffsgruppe „Users“ nicht löschen können: Zum einen ist dies eine Vorgabe der Fakultät, und zum anderen (und das haben wir versucht) können wir sie nicht mehr löschen, da bereits viele Personen Methoden angelegt und Ergebnisse generiert haben, während sie der Zugriffsgruppe „Users“ angehörten. Daher verhindert UNICORN, dass wir dieses Konto löschen können. Ich arbeite an diesem Problem: Ich sollte direkt auf die zugrunde liegende MS-SQL-Datenbank zugreifen können, um die Eigentumsrechte an den Methoden und Ergebnissen zu ändern. Allerdings war GE nicht gerade auskunftsfreudig, als ich nach der Handhabung von Zugriffsrechten fragte. Die Antwort lautete: Die Zugangsdaten für die Datenbank in einer eigenständigen UNICORN-Lösung sind verschlüsselt und nicht öffentlich zugänglich. Wenn Sie eine Enterprise-Lösung hätten (mit einer eigenen (SQL-Server-)Datenbank), hätten Sie die Kontrolle über die Zugangsdaten und könnten theoretisch die gewünschten Informationen extrahieren (das Format müssen Sie selbst herausfinden; es wird von uns nicht unterstützt). Sie können Ihre Lösung auf eine Enterprise-Version upgraden, wenn Sie möchten. Das klingt schlimmer, als es ist, da wir physischen Zugriff auf den MS-SQL-Server haben und das Extrahieren der Zugangsdaten nicht besonders schwierig zu sein scheint. Aber es kostet mich Zeit, die Schwachstelle zu finden, um „in unser eigenes System einzudringen“, und genau das ärgert mich. Laut Lisa Bromark von GE scheint das Update 7.0.2 dieses Problem jedoch zu beheben: UNICORN kann so konfiguriert werden, dass ein neues Datenbankpasswort verwendet wird. Es ist möglich, ein verschlüsseltes Passwort zu generieren oder ein bereits verschlüsseltes Passwort einzugeben. Dies geschieht durch Ausführen des UNICORN Service Tools nach der Installation von UNICORN.Allerdings ist es unglaublich schwierig, das Update zu bekommen (zumindest scheint es Wochen zu dauern). Die Verteilung erfolgt offenbar immer noch über optische Datenträger und per Post. Ich glaube, das letzte Mal, dass ich mir Software auf einer CD/DVD besorgt habe, ist mehr als 10 Jahre her. GE teilte mir jedoch mit, dass sie gerade dabei sind, die UNICORN-Software-Updates auf „elektronischen Vertrieb“ umzustellen. Willkommen im 21. Jahrhundert!&lt;/p&gt;</description></item></channel></rss>