Archive for: ‘Mai 2010’
New MacBook Pro: extend your battery life
When I installed gfxCardStatus, it showed me that my MacBook used the NVIDIA GPU all the time. But I didn't know why. The only applications running where Safari, Lotus Notes, Skype and TweetDeck. The most recent version of gfxCardStatus has a real helpful new feature. The "Dependent process list" shows which process forces the use of the NVIDIA GPU. In my case it was Skype. And I was not aware why Skype would need that much grafic power. I looked into the Preferences and deactivated the Skype video functionality, which I'm using very rarely. After a restart of Skype gfxCardStatus reported, that my MacBook now uses the Intel GPU. I'm really looking forward how long my battery will last now.
Sicherheitslcke oder beabsichtigte Funktion?
Sicherheitsbeauftragte sollten das nachfolgend beschriebene Systemverhalten von Lotus Domino zum Anlass nehmen, ihre Betriebsvorgaben zu berprfen, um im Bedarfsfall auch einzelnen Administratoren umgehend den Zugriff auf die Serverinfrastruktur entziehen zu knnen! \”Bug\” oder \”Works as designed\” – meine Einschtzung ist klar: Es ist ein Fehler wenn Benutzer auf Server zugreifen knnen, obwohl sie in der \”Deny-Access-Liste\” verzeichnet sind.
Ausgangssituation:
Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zhlten u.A.:
- Einrichtung einer speziellen \”Admin\” OU zur Registrierung von User.IDs fr Administratoren: Benutzer erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen \”*/ADMIN/MMI\”
- Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhngig sind (die man verlieren knnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument lscht).
- Anwendung dieser Strategie u.A. Auch fr das \”Full Access Administration\” Feld im Serverdokument
Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlsst.
Lschung des ausscheidenden Administrators:
Im Rahmen der Lschung eines Benutzers (so auch der des Administrators (zertifiziert mit der \”Admin\” OU) ist dieser u.A. in die \”Deny-access-Liste\” aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Auftrge abgearbeitet wurden und sein Benutzername in der \”Deny-access-Liste\” eingetragen war), immer noch Zugriff auf alle Server.
Die nhere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im \”Full Access\” Feld aller Server) den Eintrag in der \”Deny-List\” ignoriert. Htte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so htte AdminP durch die Lschung dem Administrator die Berechtigung entzogen.
Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: \”Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld \”Vollzugriff\” des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus ber den entsprechenden Menpunkt aktivieren\”).
Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder \”Full-Access\” und \”Deny-Access\” des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwgungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen knnen, dessen Umsetzung fraglich ist und dauern kann. Fr die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen knnen.
Dringende Empfehlung fr aktuelle Domino Konfigurationen:
1. Die Verwendung von separaten OUs fr Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2. Um derart registrierte Administratoren hnlich schnell vom Serverzugriffen auszuschlieen wie normale Benutzer drfen diese nicht ber wildcard-Notation im \”Full-Access\” des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe lscht)
In jedem Fall heit das, Vor- und Nachteile abzuwgen und die Serverkonfigurationen berprfen/ndern, bis IBM in einem dem kommenden Release zuerst die \”Deny-Access-Liste\” eines Servers auswertet, bevor man durch Prfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.
Sicherheitslücke oder beabsichtigte Funktion?
Ausgangssituation:
Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
- Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs für Administratoren: Benutzer erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
- Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
- Anwendung dieser Strategie u.A. Auch für das "Full Access Administration" Feld im Serverdokument
Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.
Löschung des ausscheidenden Administrators:
Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.
Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.
Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus über den entsprechenden Menüpunkt aktivieren").
Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.
Dringende Empfehlung für aktuelle Domino Konfigurationen:
1. Die Verwendung von separaten OUs für Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2. Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschließen wie normale Benutzer dürfen diese nicht über wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)
In jedem Fall heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.
SicherheitslĂĽcke oder beabsichtigte Funktion?
Ausgangssituation:
Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
- Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs fĂĽr Administratoren: Benutzer erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
- Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
- Anwendung dieser Strategie u.A. Auch fĂĽr das "Full Access Administration" Feld im Serverdokument
Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.
Löschung des ausscheidenden Administrators:
Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.
Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.
Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus ĂĽber den entsprechenden MenĂĽpunkt aktivieren").
Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.
Dringende Empfehlung fĂĽr aktuelle Domino Konfigurationen:
1. Die Verwendung von separaten OUs fĂĽr Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2. Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschließen wie normale Benutzer dürfen diese nicht über wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)
In jedem Fall heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.
Sicherheitslücke oder beabsichtigte Funktion?
Ausgangssituation:
Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
- Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs für Administratoren: Benutzer erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
- Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
- Anwendung dieser Strategie u.A. Auch für das "Full Access Administration" Feld im Serverdokument
Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.
Löschung des ausscheidenden Administrators:
Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.
Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.
Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus über den entsprechenden Menüpunkt aktivieren").
Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.
Dringende Empfehlung für aktuelle Domino Konfigurationen:
1. Die Verwendung von separaten OUs für Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2. Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschließen wie normale Benutzer dürfen diese nicht über wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)
In jedem Fall heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.
Was macht denn das Feld "$RespondedTo" und woher stammt es?
Zur Untersttzung spezifischer Mailfunktionen steuern Datenbankeigenschaften die Generierung von Feldern im Mailkontext. Diese Datenbankeigenschaften knnen jedoch in gemeinsam genutzten Datenbanken zu unerwnschten Nebeneffekten fhren.
Um um in Mailfiles Spaltensymbole anzeigen zu knnen, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingefhrt worden
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld \”RespondedTo\” setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o..). hnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthlt das Feld den Wert \”2\” statt \”1\”).
In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten fhrt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.
Was macht denn das Feld “$RespondedTo” und woher stammt es?
Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").
In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten führt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.
Was macht denn das Feld “$RespondedTo” und woher stammt es?
Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").
In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten führt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.
Was macht denn das Feld “$RespondedTo” und woher stammt es?
Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").
In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten fĂĽhrt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.