faq-o-matic.net » Sicherheit

Konfigurationsempfehlungen vom BSI für Windows 7

Helge Klein — Wed, 18 Jan 2012 05:00:37 +0000

Das Bundesamt für Sicherheit in der Informationstechnik hat kürzlich eine Anleitung zur sicheren Konfiguration von Windows 7 veröffentlicht. Das Dokument mit dem Titel Anleitung zur Installation und Minimierung eines Arbeitsplatz-PCs mit Windows 7 enthält sehr detaillierte Angaben darüber, welche Einstellungen gesetzt werden sollten, damit ein PC mit Windows 7 sicher betrieben werden kann. Dabei gehen die Autoren recht weit und empfehlen zum Beispiel, den Serverdienst zu deaktivieren, wodurch unter anderem administrative Freigaben wie C$ nicht mehr zur Verfügung stehen. Auch das Löschen der Auslagerungsdatei beim Herunterfahren könnte für Unmut sorgen, verzögert es doch jeden Neustart um mehrere Minuten.

Unabhängig davon macht das BSI viele sinnvolle Vorschläge, die jedoch auch als ebensolche angesehen werden sollten, und keinesfalls als "Vorgaben" zu interpretieren sind. Wie auch die Autoren schreiben, ist jede Einstellung auf Sinnhaftigkeit für die eigene Situation und Kompatibilität mit vorhandenen Anwendungen zu prüfen.

Die Empfehlungen sind sorgsam recherchiert. Einige kleine Fehlerchen konnte ich dennoch finden:

Seite 66, "Datenausführungsverhinderung"
Es wird empfohlen, DEP für alle Programme und Dienste einzuschalten. Dies kann jedoch zu Fehlfunktionen bei manchen Programmen führen und erfordert gründliches Testen.
Seite 75, "Neue Drucker automatisch in Active-Directory veröffentlichen"
Es wird empfohlen, dies zu deaktivierten. Die Einstellung ist jedoch für Windows 7 ohnehin nicht wirksam.
Seite 75, "Installation von Druckern, die Kernelmodustreiber verwenden, nicht zulassen"
Es wird empfohlen, dies zu deaktivierten. Die Einstellung ist jedoch für Windows 7 ohnehin nicht wirksam.

Alles in allem ein sinnvolles Dokument, dessen Lektüre für jeden auf Sicherheit bedachten Administrator selbstverständlich sein sollte. Es ist übrigens das erste Dokument des BSI zu Windows 7. Bislang musste sich, wer Empfehlungen des BSI befolgen wollte, mit dessen Informationen zu Windows Vista behelfen.

Kennwörter selbst zurücksetzen

Norbert Fehlauer — Mon, 07 Nov 2011 05:40:00 +0000

Welcher Admin kennt nicht die Anrufe von Benutzern, die ihr Kennwort vergessen haben? Kommt das seltener als 1-2 mal pro Tag vor, ist alles noch einfach zu handhaben. Wie verhält sich so etwas aber bei tausenden von Benutzern, die möglicherweise nur peripher mitbekommen, dass das Kennwort überhaupt abläuft? Oder bei Nutzern, die sich nicht täglich an einem Windows PC anmelden, der über den Ablauf von Kennworten informiert? Oder bei Nutzern, die einmalig bei Ersteingabe das Kennwort im Mailprogramm oder Browser abspeichern und deswegen bis zum Ablauf des Kennwortes keine Notwendigkeit haben, sich an das Kennwort zu erinnern?

Dann hat man entweder regelrechte Sprechstunden für vergessliche Nutzer (an die sich diese natürlich nicht halten), eine Passwort-Hotline oder man beschafft eine entsprechende Password Self Service Software.

Password Self Service kennt man üblicherweise entweder von diversen Webmailanbietern wie Hotmail oder auch von Webforen. Bei letzteren bekommt man im Allgemeinen sein neues Kennwort an die Emailadresse gesandt, mit der man sich registriert hat. Das ist bei einer Lösung mit Exchangepostfächern natürlich wenig hilfreich, da man das Passwort für das Active Directory Konto auch für den Zugriff auf das Postfach benötigt. Genau darauf hat man aber keinen Zugriff, da man sein Kennwort vergessen hat. Eine andere Lösung sind sogenannte Frage und Antwort Modi, bei denen sich der Benutzer aus diversen Fragen eine oder mehrere aussucht und dazu entsprechende Antworten vergibt, die nur er kennt. Bspw: “Wie ist der Name Ihres ersten Haustieres?” oder “Wie lautet der Mädchenname Ihrer Mutter?”

Nach der Eingabe der korrekten Antworten kann man sich ein neues Kennwort vergeben und damit wieder anmelden.

Eine Lösung für Password Self Service bietet Sysop Tools mit Password Reset Pro für Active Directory.

Wie genau funktioniert das also?

Damit ein nicht authentifizierter Nutzer (er hat ja schliesslich sein Kennwort vergessen), ein neues Kennwort vergeben kann, benötigt er eine Möglichkeit sich gegenüber dem System zu legitimieren. Dies kann in Password Reset Pro über zwei Modi erfolgen.

Profile Enrollment Mode
Active Directory Data Mode

Zusätzlich gibt es einen dritten Modus „Domain Authentication only“, mit dem Benutzer ihr Kennwort ändern können. Ein Zurücksetzen eines vergessenen Passwortes ist hiermit allerdings nicht möglich, weswegen dieser Modus im Artikel nicht weiter berücksichtigt wird.

Profile Enrollment Mode

Im Profile Enrollment Mode muß sich der Anwender einmalig eine Kombination aus vorgebenem Bild und frei definierbaren Sicherheits-Wort wählen. Über beide Informationen wird dann ein Hash gebildet und verschlüsselt im Active Directory gespeichert. Mit Hilfe dieser Kombination ist es ihm möglich, das vergessene Passwort zurückzusetzen. Natürlich kann der Administrator auch Worte und User ausschließen. Bspw. sind Worte die das gewählte Bild bezeichnen dann doch zu einfach. Administrative Accounts können ebenfalls ausgeklammert werden.

Abbildung 1: Einstellungen des Sicherheits-Wortes

Sobald der Nutzer die Webseite von Password Reset aufruft, kann er sich „einschreiben“. Hierzu muß er sich mit seinem Nutzernamen und seinem (nicht vergessenem Kennwort) identifizieren. Er wählt aus den angezeigten Bildern eines aus, und gelangt so zum zweiten Schritt.

Abbildung 2: Gewähltes Bild anklicken

Hier wählt er ein Wort, welches nur den Bedingungen aus Abbildung 1 entsprechen muss. Danach ist der Einschreibevorgang abgeschlossen.

Kommentare, dass sich die Nutzer die Kombination von Bild und frei wählbarem Wort ebenfalls nicht merken können sind verständlich. Aber anscheinend fällt es vielen Nutzern doch einfacher, als sich ein ein komplexes Kennwort allein zu merken.

Abbildung 3: Sicherheits-Wort eingeben

Abbildung 4: AD Passwort zurücksetzen

Info: Alle Daten werden innerhalb des Active Directory gespeichert. Es sind keine zusätzlichen Datenbanken wie SQL o.ä. notwendig. Beim „Enrollment“ generiert der Masterservice mit den beiden Komponenten (Bild und Sicherheits-Wort) einen AES-256 verschlüsselten „logischen Zeiger“. Dieser Zeiger wird im Attribut „altSecurityIdentities“ des Benutzerobjekts im Active Directory gespeichert. Dieses Attribut existiert in jedem Active Directory und ist für solche Zwecke vorgesehen:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675221(v=vs.85).aspx

Abbildung 5: Eingeschriebener AD-Benutzeraccount

Wie erwähnt, ist hierzu ein einmaliges Einschreiben aller Nutzer notwendig, damit obige Methode funktioniert. Password Reset Pro stellt dem Administrator hierzu eine Konsole zur Verfügung, in welcher erkennbar ist, wie viele seiner Nutzer bereits eingeschrieben sind. Säumige Nutzer können per Emailvorlage über die Notwendigkeit zum Einschreiben informiert werden.

Über den Stand des Enrollments wird der Administrator mit täglichen Reports oder durch einen Blick in die Report-Konsole unterrichtet.

Active Directory Data Mode

Im Active Directory Data Mode ist das Einschreiben (Pre-Enrollment) nicht notwendig. Der Administrator legt entsprechende Attribute im Administrationstool fest, auf deren Basis die Frage(n) gestellt werden soll(en). Beispielsweise kann in einem AD-Attribut die Information über Telefonnummer oder Büro gespeichert werden. Dem Nutzer werden im Webportal die Fragen „Wie lautet Ihre dienstliche Telefonnummer? und „In welchem Bürogebäude sitzen Sie?“ präsentiert und er muss alle korrekt beantworten. Die Antworten werden dann mit den Werten im entsprechenden AD-Attribut verglichen und als korrekt oder fehlerhaft gewertet. Es sind alle verfügbaren AD-Attribute möglich. Das Active Directory hält jedoch viele Attribute für Domänenbenutzer lesbar bereit. Deswegen sollte man sich im Klaren darüber sein, sein, dass zwar keine Vorbereitung durch den Nutzer erforderlich ist, aber dass es durchaus Nutzer mit genügend „Elan“ gibt, die Kennworte anderer Nutzer auf Basis „freiverfügbarer“ Informationen zurücksetzen.

Technische Informationen zu Password Reset Pro

Password Reset Pro besteht aus den zwei Komponenten Webportal und Masterservice. Beide können entweder auf einem Server installiert werden ("single tier"), oder getrennt als sogenannte "two tier" Installation. Das Webportal bietet die Schnittstelle, welche der vergessliche Benutzer zu Gesicht bekommt. Der Masterservice ist die Komponente, welche die eigentliche Änderung im Active Directory vornimmt. Dieser Dienst benötigt entsprechend delegierte Rechte im AD, um die Kennworte der Nutzer zurücksetzen zu können. Die Verwendung von Domänenadminrechten ist nicht empfohlen.

Getestet wurde die Version 3.1.67, welche sowohl als 32- als auch 64-bit Applikation installiert werden kann. Allerdings sind Installationen derzeit nur auf englischsprachigem Betriebssystem möglich. Der Hersteller SysOp Tools hat aber Internationalisierung angekündigt (s. geplante Features).

Die Installation ist einfach zu erledigen, und wird vom Hersteller mit einer ausführlichen englischsprachigen Anleitung unterstützt.

http://www.sysoptools.com/support.aspx?tbc=0

Geplante Features

Natürlich gibt es auch Funktionen, die sich derzeit noch nicht im Produkt befinden, aber vom Hersteller bereits angekündigt wurden. Hierzu gehören u.a.

Mobile Device Zugriff – Passwortänderungen und –entsperrungen vom iPhone, Windows Mobile, iPad, BlackBerry aus.
Windows Vista, Windows 7 and Server 2008 Self Service Integration im Anmeldefenster
Sharepoint-Plugin zum Anzeigen der Restlaufzeit des Passwortes
Mehrsprachige Weboberfläche des Portals

Fazit

Das Programm erweist sich als erstaunlich einfach und praktisch im Alltag, und wird jedem Administrator, der die oben beschriebene Ausgangssituation kennt, eine Menge an Telefonanrufen ersparen. Mein bisheriger Kontakt mit dem Produktsupport über Email erfolgte schnell und unkompliziert (notwendig geworden wegen der Installation auf einem deutschsprachigen System). Wie der Punkt „geplante Features“ zeigt, ist trotzdem noch jede Menge Potenzial, welches in zukünftigen Veröffentlichungen realisiert werden sollen.

Die Lizenzkosten bewegen sich in einem Rahmen vergleichbarer Lösungen anderer Hersteller. Über die Webseite des Herstellers kann ein Angebot angefordert werden.

Dynamische Objekte in AD: Unbekannt und gefährlich

Nils Kaczenski — Mon, 10 Oct 2011 04:37:00 +0000

Es ist weithin unbekannt, dass Active Directory bereits seit Windows Server 2003 eine Funktion unterstützt, mit der sich “Dynamic Objects” erzeugen lassen. Diese Microsoft-Erfindung ist als RFC auch für andere Verzeichnisdienste spezifiziert:

[RFC 2589 - Lightweight Directory Access Protocol (v3): Extension (RFC2589)]
http://www.faqs.org/rfcs/rfc2589.html

Dynamische Objekte decken spezielle Anforderungen ab, in denen Einträge in einem LDAP-Verzeichnisdienst nur für kurze, nicht immer vorhersagbare Zeiträume existieren dürfen. Ein dynamisches Objekt erhält bei seiner Erzeugung einen TTL-Eintrag (Time to Live), nach dessen Ablauf es automatisch verschwindet. Im Gegensatz zu normalen Löschvorgängen geschieht dies nicht ausdrücklich, sondern von selbst – und das entfernte Objekt wird im Fall von Active Directory nicht in einen “Tombstone” verwandelt, es hinterlässt also keine Spuren im Verzeichnis. Stattdessen ist jeder Domänencontroller selbst dafür zuständig, das abgelaufene Objekt einfach sang- und klanglos zu löschen.

Die TTL eines dynamischen Objekts kann während seiner Lebenszeit verlängert werden. Dies können Applikationen nutzen, um die Gültigkeit eines Eintrags bei Bedarf zu verlängern. Tatsächlich ist der eigentliche Einsatzzweck von Dynamic Objects auch ihre Nutzung durch Applikationen. Es steckt allerdings einiges dahinter, was einige Quellen näher beleuchten.

Auf Florian Frommherz’ Blog gibt es einen Artikel, der das Konzept von Dynamic Objects auf Benutzerobjekte anwendet. Zwar ist es eigentlich nicht dafür entworfen worden, aber es funktioniert tatsächlich.

[Florian’s Blog » Creating dynamic objects with Active Directory]
http://www.frickelsoft.net/blog/?p=282

Ein anderer Blog-Eintrag eines Microsoft-Mitarbeiters beschreibt, warum die ursprüngliche Implementierung in Windows Server 2003 fehlerhaft war und warum sie mit dem Service Pack 1 geändert wurde. Diese Änderung hat in der Folge dazu geführt, dass einzelne Drittanbieter-Applikationen nicht mehr funktionierten, doch aus der Argumentation wird deutlich, warum sich dies nicht vermeiden ließ.

[When is it "by design" -- a tale of a dynamicObject ( yet another post SP1 change ) - Spat's WebLog (Steve Patrick)]
http://blogs.msdn.com/b/spatdsg/archive/2006/06/14/630435.aspx

In einigen Vorträgen der Security-MVP Paula Januszkiewicz aus Warschau ist zu sehen, wie gefährlich die fehlerhafte ursprüngliche Implementierung von Dynamic Objects war. Sie ließ sich für Angriffe verwenden, die kaum rechtzeitig zu erkennen und noch schwieriger abzuwenden waren.

[entryTTL Demo from TechEd North America 2011 - Paula's Security Blog]
http://blogs.technet.com/b/plwit/archive/2011/05/23/entryttl-demo-from-teched-north-america-2011.aspx

[10 Deadly Sins of Administrators about Windows Security (engl.) | TechDay@ice:2011]
http://technet.microsoft.com/de-de/edge/10-deadly-sins-of-administrators-about-windows-security-engl-techday-ice-2011

IIR IT Admin Tech Talk 2011: Die Folien

Nils Kaczenski — Wed, 28 Sep 2011 04:53:00 +0000

Hier sind die Folien meiner beiden Vorträge beim IIR IT Admin Tech Talk 2011 zu Best Practice für Hyper-V und zur Sicherheit in VM-Umgebungen.

Note: There is a file embedded within this post, please visit this post to download the file. Note: There is a file embedded within this post, please visit this post to download the file.

SetACL Studio ist verfügbar

Nils Kaczenski — Fri, 09 Sep 2011 08:57:12 +0000

Vor einigen Tagen hat Helge Klein, Autor des Berechtigungs-Werkzeugs SetACL, sein neues Produkt SetACL Studio fertig gestellt und veröffentlicht. Die Software erlaubt eine sehr umfassende und leistungsfähige Steuerung und Verwaltung von Berechtigungen in (nahezu) allen wichtigen Bereichen eines Windows-Systems: NTFS, Freigaben, Drucker, Registry, WMI …

Einen Überblick über SetACL Studio findet ihr (noch aus der Betaphase) bei uns:

[faq-o-matic.net » SetACL Studio – Die Beta ist da]
http://www.faq-o-matic.net/2011/08/08/setacl-studio-die-beta-ist-da/

… und natürlich aktuell bei Helge selbst:

[SetACL Studio | Helge Klein | Home of SetACL]
http://helgeklein.com/setacl-studio/

Sichere Kennwörter

Nils Kaczenski — Thu, 11 Aug 2011 04:36:00 +0000

Der Cartoon-Dienst xkcd.com von Randall Munroe hat dieser Tage eine wunderschöne Illustration gebracht, wie man sichere Kennwörter aufbaut.

Zwar ist dem wenig hinzuzufügen, aber wer es etwas elaborierter mag, sei trotzdem auf Jesper Johanssons hervorragende Artikelreihe zu Kennwortsätzen hingewiesen:

[The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3]
http://technet.microsoft.com/en-us/library/cc512613.aspx

[The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3]
http://technet.microsoft.com/en-us/library/cc512609.aspx

[The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3]
http://technet.microsoft.com/en-us/library/cc512624.aspx

Oder auf deutsch:

[Die Grundsatzdiskussion: Kennwort oder Kennwort-Sätze]
http://www.microsoft.com/germany/technet/sicherheit/newsletter/kennwoerter.mspx

[Die Grundsatzdiskussion: Kennwort-Sätze oder Kennwörter - Analyse]
http://www.microsoft.com/germany/technet/sicherheit/newsletter/kennwoerter2.mspx

[Die Grundsatzdiskussion: Kennwort-Sätze oder Kennwörter - Fazit]
http://www.microsoft.com/germany/technet/sicherheit/newsletter/kennwoerter3.mspx

Und als Ergänzung:

[Security Watch: The Most Misunderstood Windows Security Setting of All Time]
http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx

ILO-Board und HP System Management Homepage mit Zertifikaten einer eigenen CA versorgen

Bent Schrader — Mon, 02 May 2011 04:54:00 +0000

Dieser Beitrag erschien zuerst auf Bents Blog.

Wer die Microsoft Zertifikatdienste installiert hat, benutzt diese für die unterschiedlichsten Zwecke. Ob zur Verschlüsselung des IP-Verkehrs zwischen Domänencontrollern oder -servern, für die Verwendung von Benutzer-Zertifikaten zur VPN-Einwahl oder beispielsweise um für interne Webserver eigene Zertifikate (SSL Zertifikat) bereitzustellen.

In meinem Fall benötige ich oftmals letztere Variante, um Zertifikate für die Insight Lights Out Boards (ILO) oder die HP System Management Homepage von Hewlett Packard Servern bereitzustellen. Diese lassen sich leider nicht (wie Computer- oder Benutzerzertifikate) automatisch via Gruppenrichtlinien verteilen, sondern müssen manuell erstellt werden.

Selbstverständlich lassen sich die Funktionen eines ILO-Boards (Steuerung des Servers und Remote-Konsole) oder der System Management Homepage auch ohne interne Zertifikate nutzen, allerdings müssen die Adressen bzw. Webseiten im Browser manuell zu den vertrauenswürdigen Seiten hinzugefügt und/oder die selbst erstellten Zertifikate importiert werden. Die Administration innerhalb einer Domäne ist allerdings recht unflexibel, da dieser Vorgang an unterschiedlichen Arbeitsstationen oder Servern manuell wiederholt werden muss.

Der folgende Leitfaden beschreibt, wie man die integrierten Microsoft Zertifikatdienste für die Ausstellung der benötigten Webserver-Zertifikate für die Hewlett-Packard Funktionen verwendet.

Voraussetzungen

Das beschriebene Verfahren für die Nutzung von Zertifikaten mit einer eigenen Microsoft Zertifizierungsstelle setzt voraus, das zunächst eine Domäne bzw. Organisation vorhanden und DNS eingerichtet ist und natürlich ordnungsgemäß funktioniert. Für eine einfache Remote-Verwaltung ist der Einsatz eines DHCP-Servers von Vorteil.

Für die Ausstellung der benötigten Webserver-Zertifikate genügt bereits die Windows Server Standard Edition. Die integrierte Webserver-Zertifikatvorlage lässt sich zwar nicht verändern und ist fest auf 2 Jahre Gültigkeit eingestellt – dies sollte aber ausreichend sein. Bei der Enterprise Edition ist dieser Zeitraum nicht nur änderbar, es ist hier weiterhin möglich, eigene Zertifikatvorlagen zu erstellen.

Bei einer ordnungsgemäß eingerichteten Zertifizierungsstelle von Microsoft (Windows Server 2003 oder 2008) wird immer neben der MMC Zertifizierungsstelle eine Webseite (IIS-integriert) eingerichtet, über die verschiedene Konfigurationsmöglichkeiten via Browser abrufbar sind:

Anforderung eines Zertifikats
Anzeige des Status ausstehender Zertifikate
Download des Zertifizierungsstellenzertifikats, Kette oder Sperrliste

Die Webseite ist über die Adresse http:///certsrv erreichbar und wird für die folgenden Schritte benötigt.

Einrichtung

Wird ein neuer HP Server im Netzwerk integriert, so wird nach der Verkabelung des ILO-Boards, selbiges automatisch eine IP-Adresse via DHCP beziehen. In der MMC für DHCP findet man diese IP-Adresse unter dem folgenden Namen:

ILO.

Um nun die initiale Konfiguration des ILO vorzunehmen, verbindet man sich mit einem Browser auf diese IP-Adresse. (HTTP-Verbindungen [Port 80] werden dabei immer automatisch auf HTTPS [Port 443] umgeleitet.) Hier erhält man sofort folgende, bekannte Browser-Warnung:

Nach dem Fortsetzen warnt der Internet Explorer (aber auch andere Browser) durch die farblich rot markierte Adresszeile, dass das initial selbst ausgestellte Zertifikat der aufgerufenen Seite nicht gültig ist:

Die erste Anmeldung erfolgt immer als Benutzer Administrator mit einem mitgelieferten, Server-abhängigen Default-Passwort. In der Verwaltung des ILO-Boards kann man nun (bei Bedarf) die Netzwerkkonfiguration (IP-Adresse, DNS etc.) ändern, neue Benutzer definieren bzw. ändern und den Namen des ILO festlegen. Für mich hat es sich bewährt, als Namensschema den eigentlichen Servernamen zu integrieren:

ilo-

Dies ermöglicht später eine sehr einfache Zuordnung von ILO-Board zu Server und umgekehrt. In der Verwaltung des ILO wechselt man nun unter Administration, Security, SSL Certificate in die Certificate Administration.

Seit der ILO Firmware Version 2.05 (ILO2) ist es möglich, das als Domain Name (wird später in der URL verwendet) der Short Name oder der FQDN im Zertifikat verwendet werden soll (bisher immer nur Short Name). Danach kann im Schritt 2 ein sogenannter “Certificate Request“ erzeugt werden. Dieser ist Base64 kodiert und im PKCS #10 Format – weitere Informationen zu den Public Key Cryptography Standards im folgenden Link.

Diesen Request kopiert man in die Zwischenablage und öffnet parallel die Webseite der internen Zertifizierungsstelle im Browser:

http:///certsrv

Hier wählt man die Aufgabe “Ein Zertifikat anfordern“, im zweiten Schritt die Option “erweiterte Zertifikatanforderung” und danach den Link auf die Zertifikatanforderung, die eine Base64-codierte oder PKCS10-Datei verwendet. Hier kopiert man den Inhalt der Zwischenablage in das Feld “Gespeicherte Anforderung” und wählt als Zertifikatvorlage “Webserver” aus:

Nach der Einsendung der Anforderung kann das ausgestellte Zertifikat (werden Zertifikate nicht automatisch durch die Zertifizierungsstelle ausgestellt, muss der Administrator dies manuell tun) als Base64-codierte Datei herunterladen:

Diese Datei (certnew.cer) öffnet man mit einem Editor (meine erste Wahl ist hier nach wie vor NotePad++) und kopiert den Inhalt wiederum in die Zwischenablage. Im Anschluss wechselt man wieder in das Browser-Fenster des ILO-Boards und fügt den Inhalt der Zwischenablage im Schritt 3 “Import Certificate” im Feld X.509 Certificate Data ein:

Nach der Bestätigung des erfolgreichen Zertifikatimports muss das ILO-Board neu gestartet werden und präsentiert sich anschließend im Browser mit folgender Adressleiste:

Der Vollständigkeit halber geschieht das allerdings nur unter folgenden Bedingungen:

der richtige Name wird in der URL verwendet (Short Name vs. FQDN)
das Zertifikat der Stammzertifizierungsstelle (Root-CA) befindet sich in den Vertrauenswürdigen Stammzertifizierungsstellen auf dem Computer (Automatisierung via Gruppenrichtlinien: Computerkonfiguration, Sicherheitseinstellungen, Richtlinien öffentlicher Schlüssel/Vertrauenswürdige Stammzertifizierungsstellen)

Die Einbindung eines integrierten Webserver-Zertifikates für die HP System Management Homepage (SMH) erfolgt ähnlich. Nach der Installation der Software (im HP ProLiant Support Pack enthalten) im Betriebssystem ist die SMH im Browser über

https://:2381

erreichbar. Nach erfolgreicher Authentifizierung ist die Erstellung einer Zertifikatanforderung über Settings, Security, Local Server Certificate erreichbar:

Bevor die eigentliche Zertifikatanforderung erstellt wird, hat der Administrator die Möglichkeit, im Feld “Alternative Names” weitere Servernamen (mit Semikolon getrennt) einzugeben, die im Zertifikat berücksichtigt werden sollen. (Ohne weitere Namen wird der Short Name verwendet, hier kann zusätzlich der FQDN eingetragen werden.)

Die Zertifikatanforderung wird von der SMH immer als Datei req_cr.prm im Ordner C:\hp\sslshare abgelegt. Der Inhalt dieser Datei liegt ebenfalls im Format PKCS #10 vor und ist Base64-codiert. Die Einreichung der Anforderung innerhalb der Microsoft Zertifikatdienste ist identisch mit der oben beschriebenen Vorgehensweise. Allerdings muss das so erstellte Zertifikat für die SMH als Zertifikatskette (certnew.p7b) im Format PKCS #7 Base64-codiert gespeichert werden:

Der Inhalt dieser Datei kann nun innerhalb der SMH importiert werden:

Wird der erfolgreiche Import des Zertifikats von der SMH gemeldet, muss der Dienst im Anschluss neu gestartet werden:

Auch hier wird nun im Browser das neue Zertifikat als vertrauenswürdig interpretiert, solange sich das Root-CA-Zertifikat in den vertrauenswürdigen Stammzertifizierungsstellen befindet.

Fazit

Die Erstellung von Webserver-Zertifikaten (SSL) für ILO-Boards oder die HP System Management Homepage innerhalb einer Windows Domäne mit installierten Microsoft Zertifikatdiensten ist keine Zauberei und relativ schnell umgesetzt. Die Zertifikatdienste sind kostenlos, relativ schnell installiert (Anleitungen existieren im Internet), integrativ (Gruppenrichtlinien) und lassen sich für viele weitere Szenarien (Verschlüsselung von Dateisystemen, Benutzerzertifikate für VPN Einwahl) sinnvoll nutzen.

Vorsicht Falle! Vererbung im AD

Ralf Wigand — Thu, 24 Mar 2011 07:38:22 +0000

Im Active Directory kann man ja, wie allseits bekannt, auf OUs etc. auch Rechte vergeben. Und natürlich lassen sich diese Rechte auch vererben an darunter liegende Objekte. Dass diese Vererbung nicht immer ganz einleuchtend ist, zeigt folgendes Beispiel:

Eine OU=Deutschland, darunter eine OU=Bayern und darunter eine OU=Franken. Dazu noch eine Gruppe CN=Bayrisch,OU=Deutschland und eine Gruppe CN=Hessisch,OU=Deutschland. Alles klar? Wir haben also zwei Gruppen, "Bayrisch” und “Hessisch”, und eine OU Bayern mit einer Unter-OU Franken.

Aufgabenstellung: In der OU Bayern sollen nur Mitglieder der Gruppe “Bayrisch” lesen dürfen.

Erster Ansatz: Für die OU Bayern der Gruppe “Authentifizierte Benutzer” das Leserecht verweigern und Mitgliedern der Gruppe ”Bayrisch” das Leserecht gewähren. Ausprobieren – Fehler! Warum?

Alle Mitglieder der Gruppe “Bayrisch” sind ja automatisch auch Mitglied der Gruppe “Authentifizierte Benutzer”. Betrachtet man die Rechte auf der OU Bayern, dann steht da also für ein Mitglied der Gruppe “Bayrisch” ein “Verweigern” (wegen “Authentifizierte Benutzer) und ein “Lesen” (weil “Bayrisch”). Verweigern schlägt Lesen, also darf keiner mehr lesen.

Zweiter Ansatz: Für die Gruppe “Authentifizierte Benutzer” das Leserecht auf der OU Bayern entfernen (also nur löschen, nicht verweigern anklicken!) und für die Gruppe “Bayrisch” hinzufügen, vererbt nach unten. Ausprobieren – Geht, aber…

Schaut man sich die Unter-OU Franken an, dann sieht man, dass dort zwar wie erwartet die Gruppe “Bayrisch” Leserechte hat (vererbt von oben), aber die “Authentifizierten Benutzer” auch noch. Wir haben das Leserecht ja nur an der OU Bayern entfernt, nicht an den darunter liegenden OUs. Das Leserecht für “Authentifizierte Benutzer” wird beim Anlegen der OU dieser direkt zugewiesen, d. h. nicht vererbt. Nutzt man einen LDAP Browser (LDP oder ADSIEdit oder ähnliches) und gibt als Basis direkt die Franken-OU an, dann sieht man wieder alle Inhalte.

Also ist es auch nicht damit getan, an einer obersten OU das Recht zu löschen, da es nicht vererbt wird und somit nicht bei darunter liegenden OUs entfernt wird.

Dritter Ansatz: Eigentlich ist es den Bayern egal, wer in der OU lesen darf, solange es bloß nicht die Hessen sind. Also wäre ein möglicher Ausweg, auf die OU Bayern der Gruppe “Hessisch” (und allen anderen unerwünschten) einfach das Leserecht zu verweigern, und natürlich vererbt auf alle darunter liegenden Objekte! Gesagt – getan. Ausprobieren – Fehler!

Auf der OU Bayern sieht man jetzt ein Leserecht für “Authentifizierte Benutzer” und ein Verweigern für die Gruppe “Hessisch”. Ein Hesse darf somit nicht lesen, und das ist auch tatsächlich so. Aber…

Auf der Unter-OU Franken sieht man diese Rechte ebenfalls, allerdings darf hier ein Hesse nach wie vor lesen (zumindest mit LDP)! Überrascht? Fein!

Wie kommt das? Überschreibt ein “Verweigern” nicht immer ein “Erlauben”? Offenbar nicht.

Active Directory unterscheidet zwischen direkt zugewiesenen Rechten und vererbten Rechten. Die Reihenfolge der Überprüfung ist:

direkt zugewiesenes Verweigern?
direkt zugewiesenes Erlauben?
vererbtes Verweigern?
vererbtes Erlauben?

Sobald eine Bedingung zutrifft, wird die Abarbeitung beendet und der Zugriff gewährt bzw. verweigert. Die Liste wird also nicht immer vollständig durchgearbeitet.

Zurück zur OU Franken und die Reihenfolge Schritt für Schritt durchgehen:

direkt zugewiesenes Verweigern? Nein, keines vorhanden. Das “Verweigern” für die Gruppe “Hessisch” ist ein vererbtes Recht!
direkt zugewiesenes Erlauben? Ja! Das Leserecht für “Authentifizierte Benutzer” wird, wie oben erwähnt, beim Erstellen einer OU dieser direkt zugewiesen. Da ein Mitglied der Gruppe “Hessisch” aber stets auch Mitglied der Gruppe “Authentifizierte Benutzer” ist, greift hier dieses Recht.
Hier würde der Gruppe “Hessisch” zwar das Lesen verweigert, die Abarbeitung wurde aber nach Punkt 2 schon abgebrochen. Somit kommt dieses Recht gar nicht zum Tragen.

Interessanterweise verweigert ein ADSIEdit in diesem Fall auch das Lesen auf die Franken-OU, auch wenn man den DN der OU direkt angibt. Der LDP (und andere LDAP-Browser) zeigen die OU und den Inhalt aber an, wenn man den direkten Pfad angibt…

Wie macht man es jetzt richtig? Die korrekte (Consultant)-Antwort lautet: Kommt drauf an…

Da das Leserecht für “Authentifizierte Benutzer” bei jeder neu angelegten OU direkt zugewiesen wird, bleibt einem beim geschilderten Szenario nicht viel anderes übrig, als entweder auf allen OUs und Unter-OUs die Gruppe "Authentifizierte Benutzer" rauszulöschen (nicht Verweigern!), und alle Gruppen, die Zugriff benötigen, hinzuzufügen (wobei letzteres auf der obersten OU reicht, da dies problemlos nach unten vererbt werden kann). Taucht dieses Szenario öfter auf, dann kann man auch im AD-Schema die Standard-Sicherheitseinstellungen für eine neu angelegte OU verändern und dort die “Authentifizierten Benutzer” rausnehmen. Aber Vorsicht: Das gilt für ALLE neuen OUs im gesamten Forest! Sicherheitseinstellungen an bestehenden OUs werden dadurch nicht verändert.

Windows-Gruppen richtig nutzen

Nils Kaczenski — Mon, 07 Mar 2011 05:52:00 +0000

Bereits seit der ersten Version von Windows NT kennt Microsofts professionelles Betriebssystem Benutzergruppen, die es nutzt, um Rechte und Privilegien innerhalb des Systems sowie Zugriffsrechte auf Objekte (z.B. Dateien) zu erteilen. Die Grundidee dabei ist, dass es erheblich einfacher ist, ein bestimmtes Recht einer Gruppe zuzuteilen und in diese Gruppe dann Benutzerkonten als Mitglieder aufzunehmen. Jedes Mitglied einer Gruppe erhält so die Berechtigungen, die für die Gruppe gelten. Dabei kann jeder Benutzer einer (nahezu) beliebigen Anzahl von Gruppen angehören.

In der Praxis stellt man aber immer wieder fest, dass viele Admins unsicher sind, wie sie Gruppen sinnvoll einsetzen können. Das liegt vor allem daran, dass das Gruppenkonzept im Detail erheblich komplexer ist als in der kurzen Darstellung oben. Dieser Artikel fasst daher einige Grundlagen und Empfehlungen zusammen.

So viele Arten von Gruppen!

Das größte Verständnisproblem entsteht durch die hohe Anzahl verschiedener Gruppentypen, die Windows bereithält. Diese Gruppen verhalten sich in bestimmten Zusammenhängen unterschiedlich, daher kommt nicht jeder Gruppentyp für jeden Zweck in Frage. Hier eine kurze Einordnung auf Basis der Technik seit Windows 2000 (als Active Directory eingeführt wurde).

Lokale Gruppen

Jeder Windows-Rechner verfügt über lokale Gruppen, die teilweise bereits vordefiniert sind, die man aber auch selbst erzeugen kann. Solche lokalen Gruppen existieren und wirken ausschließlich auf dem jeweiligen Computer und haben keine Auswirkung auf andere Rechner. Auch ein Ex- und Import solcher Gruppen ist nicht möglich.

Welche Gruppen es lokal gibt, kann man in der Kommandozeile feststellen mit:


net localgroup

Die Mitglieder einer bestimmten Gruppe bekommt man angezeigt, wenn man deren Namen an das obige Kommando anhängt. Je nachdem, welche Software auf einem System installiert ist, kann es durchaus eine große Anzahl solcher lokalen Gruppen geben. Manuell legt man lokale Gruppen eher selten an, aber je nach Anforderung kann auch das bisweilen vorkommen.

Drei vordefinierte Gruppen verdienen nähere Erwähnung, weil es sie auf jedem Windows-System gibt und weil sie im gesamten Rechtesystem eine tragende Rolle spielen:

Administratoren
Wer dieser Gruppe angehört, verfügt über volle Verwaltungsrechte auf dem Rechner. Ein Mitglied der “Administratoren” kann jede Systemeinstellung verändern, Software jeder Art installieren und entfernen und sich Rechte und Berechtigungen an jedem Objekt und jeder Datei verschaffen. Zwar ist es durchaus möglich, in den Berechtigungseinstellungen etwa einer Datei den Administratoren den Zugriff zu verweigern, aber als Mitglied der “Administratoren” kann ein Benutzer das immer rückgängig machen.

Höhere Rechte als “Administrator” kann man in einem Windows-System nicht haben. Auch eine Anmeldung als “Domänen-Administrator” oder als “Organisations-Administrator” verschafft einem lokal keine Zugriffe, die man als “Administrator” nicht hätte! (Zwar vermuten sehr viele Admins, dass dies so sei, aber das ist nur ein Mythos.)
Benutzer
Um einen Rechner überhaupt verwenden zu dürfen, muss man der Gruppe “Benutzer” angehören. Dafür sorgt Windows automatisch, wenn man lokale Benutzerkonten erzeugt, weil es diese gleich in die Gruppe “Benutzer” aufnimmt. In einer Windows-Domäne wird die Gruppe “Domänen-Benutzer” auf jedem Rechner in die jeweils lokalen “Benutzer”-Gruppen aufgenommen: Nur dadurch ist es möglich, dass man sich mit einem Domänen-Benutzerkonto (standardmäßig) an jeden Rechner der Domäne anmelden kann.
Hauptbenutzer
Diese Gruppe verfügt auf einem lokalen Computer bis einschließlich Windows XP über erweiterte Berechtigungen. Seit Windows Vista ist die Gruppe zwar noch vorhanden, aber sie verfügt nicht mehr über Sonderrechte.

Mitglieder der “Hauptbenutzer” können bis Windows XP sehr viele Dinge im System verändern und haben weitgehende Schreibrechte. Dadurch entstehen erhebliche Sicherheitsprobleme, denn mit wenig Aufwand ist es einem Hauptbenutzer in der Praxis möglich, sich zum vollwertigen “Administrator” zu machen. Daher ist von der Nutzung dieser Gruppe erheblich abzuraten!

Domänenlokale Gruppen

Im englischen Original heißt dieser Gruppentyp “Domain Local Group”, in der deutschen Windows-Oberfläche ist üblicherweise von “Gruppe der lokalen Domäne” die Rede.

Es handelt sich dabei um Gruppen, die in Active Directory gespeichert sind und auf allen Rechnern derselben Domäne zur Erteilung von Berechtigungen genutzt werden können. Domänenlokale Gruppen können auch Mitglieder aus anderen Domänen aufnehmen, zu denen eine Vertrauensstellung besteht (Forest-interne Vertrauensstellung oder auch externe Vertrauensstellung); als Mitglieder lassen sich Benutzer- oder Gruppenkonten auswählen. Da dieser Gruppentyp nur in der eigenen Domäne sichtbar ist, eignet er sich zur Verwaltung von Zugriffen auf Ressourcen (z.B. Dateiserver, Druckserver, Datenbanken usw.) in der lokalen Domäne – daher der Name.

Das Windows-Gruppenkonzept sieht vor, dass man vorwiegend diesen Gruppentyp einsetzt, um in der eigenen Domäne Berechtigungen zu verwalten. Die Logik dahinter: Eine Domäne fasst üblicherweise die Ressourcen eines “Hoheitsbereichs” zusammen, und wer diesen Hoheitsbereich verwaltet, soll auch Kontrolle über die Zugriffsrechte haben. Gleichzeitig soll es aber möglich sein, auch Anwendern aus anderen, vertrauten Domänen die Nutzung einzelner Daten und Dienste zu gestatten, daher kann man in Gruppen dieser Art eben auch Konten der anderen Domänen aufnehmen. Das macht die Rechteverwaltung sehr effizient, weil man für ein bestimmtes Zugriffsrecht nur eine einzige Gruppe pflegen und berechtigen muss.

“Builtin”-Gruppen

Einen Sonderfall unter den Domänenlokalen Gruppen stellen die Gruppen im AD-Container “Builtin” dar. Hierbei handelt es sich um die Lokalen Gruppen der Domänencontroller – eigentlich sind es also gar keine Domänenlokalen Gruppen, sondern Lokale Gruppen, und daher sind sie auch nur direkt auf den Domänencontrollern sichtbar und nutzbar.

Die Builtin-Gruppen dienen dazu, Berechtigungen zu verwalten, die nur direkt auf den Domänencontrollern gelten. Wer etwa Mitglied der Gruppe “Builtin\Sicherungsoperatoren” ist, darf ein Backup aller Domänencontroller ausführen – aber kein Backup anderer Computer. Es ist dabei nicht möglich, diese Berechtigung auf einzelne Domänencontroller einzugrenzen, sondern sie gelten immer auf allen DCs.

Es ist wichtig zu wissen, dass die Builtin-Gruppen ausschließlich auf Domänencontrollern gelten. In allen alltäglichen Verwaltungsaufgaben kann man den ganzen Container “Builtin” daher praktisch ignorieren, weil die Berechtigungsverwaltung für DCs eher keine Standardaufgabe ist.

Globale Gruppen

Die Globalen Gruppen sind ebenfalls in Active Directory gespeichert. Im Unterschied zu den Domänenlokalen Gruppen können sie nur Mitglieder aus der eigenen Domäne enthalten, aber keine Konten aus anderen Domänen. Dafür sind diese Gruppen aber in anderen, vertrauten Domänen sichtbar und können dort Berechtigungen erhalten oder auch in Domänenlokale Gruppen dieser anderen Domäne aufgenommen werden.

Prinzipiell ist dieser Gruppentyp dazu gedacht, Benutzerkonten nach logischen Kriterien zusammenzufassen, also etwa nach Abteilung oder nach Funktion.

Vordefinierte Gruppen dieses Typs umfassen die Domänen-Admins und die Domänen-Benutzer. Üblicherweise legt man eine größere Menge dieser Gruppen manuell an, um organisatorische Anforderungen abzudecken.

Universalgruppen

In der deutschen Windows-Oberfläche nennt sich dieser Gruppentyp “Universell”. Gruppen dieser Art können Mitglieder aus allen Domänen des Forests aufnehmen (aber nicht aus externen vertrauten Domänen!) und sind in allen Domänen des Forests sichtbar.

Damit eignet sich dieser Gruppentyp in Multi-Domänen-Forests dazu, Benutzer domänenübergreifend zusammenzufassen und ihnen in beliebigen Domänen des Forests Berechtigungen zu erteilen. Nun könnte man meinen, dieser Gruppentyp sei damit ja auch der flexibelste und deshalb nur noch mit dieser Sorte arbeiten. Davon ist aber abzuraten: Einerseits erzeugen diese Gruppen einen gewissen Overhead, denn im Unterschied zu den anderen Typen speichert Active Directory sie nicht innerhalb der Domäne, sondern im Global Catalog. Andererseits ist dieser Gruppentyp in großen Umgebungen mit mehr als einer Domäne schwer abzugrenzen – eben deshalb, weil er Mitglieder aus allen Domänen enthalten und gleichzeitig in allen Domänen Berechtigungen haben kann. Eine solche Gruppe zu verändern, ist daher immer ein planungs- und analyseintensiver Schritt.

Seit Exchange 2007 allerdings haben Universalgruppen eine besondere Funktion: Exchange akzeptiert nur Gruppen dieses Typs als Verteilergruppen (jedenfalls wenn man sie neu anlegt). Der Grund dafür liegt wiederum in Multi-Domänen-Forests, in denen nur die Mitglieder von Universalgruppen mit Sicherheit in jeder Teildomäne des Forests auflösbar sind.

Zu den vordefinierten Gruppen dieses Typs gehören die “Organisations-Admins” (englisch: “Enterprise Admins”) und die “Schema-Admins”.

Pseudo-Gruppen

Neben diesen “normalen” Gruppen, die man (zum größten Teil) manuell erzeugen kann und deren Mitgliedschaft durch die Administratoren ausdrücklich gepflegt wird, gibt es noch einen weiteren, völlig anderen Gruppentyp. Die Pseudo-Gruppen (oft auch als “Systemgruppen” bezeichnet) werden ausschließlich vom Betriebssystem verwaltet, eine manuelle Änderung der Mitgliedschaft ist nicht möglich. In den meisten Fällen entscheidet die Art, wie ein Anwender sich anmeldet, über die Mitgliedschaft. An solche Gruppen werden innerhalb des Betriebssystems, aber durchaus auch an anderen Stellen, Berechtigungen für spezielle Zwecke vergeben.

Einige Beispiele:

Authentifizierte Benutzer: Diese Gruppe enthält immer die Anwender, die aktuell gültig an einem System angemeldet sind. Seit Windows XP, Service Pack 2, ist sie funktional identisch mit der Gruppe “Jeder”. Nicht enthalten sind anonyme Anwender, die ohne Anmeldung auf einen Dienst zugreifen, beispielsweise bei einem Webserver.
Interaktiv: In dieser Gruppe sind alle Benutzer Mitglied, die sich direkt lokal (= “interaktiv”) an ein System angemeldet haben. Dadurch lassen sich die momentanen lokalen Benutzer eines Systems zur Berechtigungsvergabe identifizieren. Nicht enthalten sind Benutzer, die über das Netzwerk einen Dienst nutzen (z.B. beim Zugriff auf einen Dateiserver).
Netzwerk: Zu dieser Gruppe zählen angemeldete Benutzer, die nur über das Netzwerk auf einen Dienst zugreifen. Nicht enthalten sind lokal angemeldete Anwender.
Ersteller/Besitzer: Dies ist eigentlich keine Gruppe, sondern ein Platzhalter für Berechtigungen. Darüber lässt sich festlegen, dass der Benutzer, der ein Objekt (z.B. eine Datei) erzeugt hat, bestimmte Rechte an diesem Objekt erhalten soll.
Selbst: Auch dies ist eigentlich keine Gruppe, sondern ebenfalls ein Platzhalter, der aber nur in Active-Directory-Berechtigungen auftaucht. Mit diesem Platzhalter lassen sich Berechtigungen für den Fall verwalten, dass ein Konto auf sein eigenes AD-Objekt zugreift. Öffnet also etwa die Benutzerin “Ute” im AD-Verwaltungsprogramm das Userobjekt “Ute”, dann greift für sie die Berechtigung “Selbst”, denn es ist ja ihr eigenes Objekt. Diesen Kniff nutzt Active Directory für ein paar Standardberechtigungen; so kann z.B. jeder Anwender standardmäßig seine eigene Telefonnummer in Active Directory bearbeiten.

An vielen Stellen erkennt man solche Gruppen an dem Präfix “NT-AUTORITÄT”.

Wie Berechtigungen funktionieren

Windows verwaltet alle Berechtigungen auf der Basis von Security Identifiers (SID). Jedes Sicherheitsobjekt – also jedes Benutzer-, Computer- oder Gruppenkonto – hat einen solchen eindeutigen SID, der sich niemals ändert. Auf diese Weise ist es möglich, ein Objekt umzubenennen, ohne dass es seine Berechtigungen verliert.

Bei der Anmeldung ans System erhält jeder Benutzer ein “Access Token”, das u.a. seinen eigenen SID und die SIDs aller Gruppen enthält, in denen er Mitglied ist. Dieses Access Token bildet dann seinen Berechtigungsausweis für alle Zugriffe. Da es nur bei der Anmeldung erzeugt wird, sind alle Änderungen an Gruppenmitgliedschaften, die während der laufenden Arbeitssitzung erfolgen, wirkungslos. Erst bei der nächsten Anmeldung wird ein neues Access Token erzeugt, das die dann gültigen Mitgliedschaften umfasst.

Versucht der Anwender, auf bestimmte Daten zuzugreifen, so überträgt Windows im Hintergrund die genaue Zugriffs-Anforderung und das Access Token an den jeweiligen Dienst. Der Dienst prüft dann die Berechtigungen des Objekts (niedergelegt in der “Access Control List”, ACL), ob für eine oder mehrere SIDs im Access Token des Benutzers die passenden Rechte hinterlegt sind. Nur wenn die Zugriffs-Anforderung durch die vorhandenen Berechtigungen genau erfüllt werden kann, gibt der Dienst den Zugriff frei, anderenfalls verweigert er ihn (Alles-oder-nichts-Prinzip). Fordert ein Anwender also etwa einen Schreib- und Lesezugriff an, aber seine Berechtigungen erlauben nur den Lesezugriff, dann kann er gar nicht auf das Objekt zugreifen. (In der Praxis merkt man das manchmal nicht, weil eine Applikation in diesem Fall einen erneuten Zugriff nur zum Lesen versuchen könnte.)

Um sich das Access Token anzusehen, kann man das Kommandozeilentoll “whoami” nutzen, das seit Windows Vista immer installiert ist (in früheren Versionen kann man es aus den Support Tools nachinstallieren). Die effektiven Gruppenmitgliedschaften sieht man etwa mit:


whoami /groups

Alle Einträge des Tokens (einschließlich des Benutzer-SID und der Privilegien auf dem eigenen System) zeigt:


whoami /all

Das A-G-DL-P-Prinzip

Das Gruppenkonzept von Windows und Active Directory wurde nach einem bestimmten Prinzip entworfen, das es Administratoren auch in komplexen Umgebungen erlauben soll, Berechtigungen auf Ressourcen strukturiert und effizient zu verwalten. Dabei orientiert sich Windows an einem rollenbasierten Zugriffsmodell (und zwar schon seit 1993 – viele andere Hersteller haben dieses Modell erst vor Kurzem für sich entdeckt).

Das Prinzip ist bekannt als das “A-G-DL-P-Prinzip”:

Accounts (Benutzerkonten)
go in Global Groups (Globale Gruppen)
nested in Domain Local Groups (Domänenlokale Gruppen)
that are granted Permissions (Berechtigungen)

Das Konzept wird oft missverstanden, daher soll ein Beispiel helfen.

Das A-G-DL-P-Prinzip der Gruppen- und Rechteverwaltung

Links finden sich die Accounts der Anwender. Diese sind nach logischen Kriterien in Globalen Gruppen zusammengefasst, die hier die Zugehörigkeit zu einer Abteilung, aber auch die Funktion in einem bestimmten Projekt widerspiegeln.
Ganz rechts finden sich die Ressourcen, für die die Zugriffsrechte verwaltet werden sollen: Die CRM-Datenbank (Zugriff erforderlich für den Vertrieb), ein Drucker (Zugriff für alle möglich) und eine bestimmte Projekt-Datei (Leserechte für die Technik und voller Zugriff für die Projektleitung).
Der Kniff ist nun: Die DL-Gruppen erzeugt man passend zu den jeweiligen Zugriffsrechten, idealerweise mit sprechenden Namen. Da es für die CRM-Datenbank und den Drucker in diesem Fall nur jeweils ein unterschiedenes Recht gibt, reicht jeweils eine Gruppe aus. Für die Projektdatei sind aber zwei Zugriffsarten zu unterscheiden, daher gibt es für jedes Recht eine eigene Gruppe.
Nur diese DL-Gruppen erhalten nun die passenden Berechtigungen. Die Berechtigungsliste (ACL) bleibt dadurch sehr kurz und muss nach diesem Konzept nie wieder verändert werden.
Als Letztes erfolgt die Zuweisung der Globalen Gruppen zu den jeweiligen Domänenlokalen Gruppen, und zwar abhängig davon, welches Zugriffsrecht die Gruppe haben soll.

Ein noch deutlicheres Beispiel aus der Praxis: Eine komplexere Applikation (nennen wir sie “App-L”) soll für den Zugriff auf einem Terminalserver mit Berechtigungen versehen werden. Zu der Applikation gehören die Programmdateien, eine Datenbank und eine Freigabe auf einem Dateiserver. Die Mitglieder des Vetriebs und des Vorstands sollen diese Applikation nutzen können.

Zunächst richtet man eine Domänenlokale Gruppe für die Zugriffsberechtigungen ein. Nennen wir sie “DL-App-L-Benutzer”.
Diese Gruppe (und nur diese!) erhält die Lese- und Ausführungsberechtigung für die Programmdateien auf dem Terminalserver. Ebenso erhält diese Gruppe Zugriffsrechte für die Datenbank und für die Dateifreigabe.

Mit diesem Schritt sind alle Berechtigungen vollständig und endgültig bearbeitet!
In die Gruppe “DL-App-L-Benutzer” nimmt man nun die beiden Globalen Gruppen “G-Vertrieb” und “G-Vorstand” auf.

Aufgrund dieses Modells haben künftig alle Mitglieder der Gruppen “G-Vertrieb” oder “G-Vorstand” die nötigen Rechte, um mit der Applikation “App-L” zu arbeiten. Die Berechtigungen muss man nun nie wieder anpassen, auch wenn neue Vertriebsmitarbeiter hinzukommen oder Vorstandsmitglieder das Unternehmen verlassen: Es reicht aus, die Mitgliedschaft in den beiden Globalen Gruppen zu pflegen.

Best Practice und Grenzen

Die Gruppen- und Berechtigungsverwaltung nach dem A-G-DL-P-Prinzip erfordert umfangreiche Analyse und Planung. Wer sie aber beherzigt, wird mit einem sehr gut wartbaren Berechtigungskonzept belohnt, das darüber hinaus sehr einfach zu dokumentieren ist. Zumindest für zentrale und komplexe Ressourcen ist die Anwendung dieses Modells sehr zu empfehlen. Auch in Migrationen hat sich das Prinzip sehr bewährt, weil es nur wenige Änderungen erfordert, wenn sich Systeme oder Domänen mal ändern.

In der Alltagsadministration gibt es oft “sofortige” Zugriffs-Anforderungen, die sich nach dem Konzept nicht schnell umsetzen lassen. Wo man hier die Grenze zieht, muss man selbst entscheiden. Die Erfahrung zeigt aber, dass die Ad-hoc-Verwaltung sehr schnell zu einem ausufernden Geflecht von Berechtigungen führt, das kaum noch nachvollziehbar ist.

Ein Nachteil des Konzepts tritt in sehr großen Umgebungen zutage, denn dort führt es schnell zu einer sehr großen Zahl von Gruppen und von Gruppenmitgliedschaften. Da das Access Token in seiner Größe begrenzt ist, kann ein Benutzer nicht gleichzeitig in mehr als ca. 1015 Gruppen Mitglied sein (vgl. Knowledge-Base-Artikel 328889). Hier können Variationen des Konzepts evtl. helfen. Eine andere Methode in solchen Umgebungen besteht darin, eigene Domänen für Anwender- und Ressourcenobjekte zu erzeugen. In diesem Fall “leben” die Domänenlokalen Gruppen in der Ressourcen-Domäne und blähen das Access Token innerhalb der Anwenderdomäne nicht über Gebühr auf.

Remote Wipe unter Windows Phone 7

Nils Kaczenski — Wed, 02 Mar 2011 05:32:00 +0000

In Verbindung mit einem Exchange-Mailkonto unterstützt Windows Phone 7 das “Remote Wipe”, also einen Löschbefehl aus der Ferne. Das ist notwendig, wenn man sein Telefon verloren hat oder es gestohlen wurde: In diesem Fall hilft der Löschbefehl, persönliche Daten und Firmengeheimnisse vor unbefugten Lesern zu bewahren. Die meisten anderen Smartphones, die sich per “Exchange ActiveSync” mit Exchange verbinden, beherrschen dies mittlerweile ebenfalls. Windows Phone 7 kann dies auch in Verbindung mit einem Hotmail-Konto, das sich dem Telefon gegenüber wie ein Exchange-Account verhält.

Eine solche Funktion probiert man auf einem produktiv genutzten Smartphone natürlich eher ungern aus. Da ich gerade ein Leihgerät hatte, das ich zurückgeben musste, stand dem aber nichts im Wege – zumal in diesem Fall ja ohnehin alle Daten von dem Gerät verschwinden müssen.

Seit einiger Zeit ist die “Remote Wipe”-Funktion, die anfangs nur von Exchange-Administratoren aufgerufen werden konnte, auch dem Anwender direkt zugänglich. Dazu nutzt man Outlook Web App, wo sich unter den “Optionen” der Eintrag “Telefon” findet. Dort wiederum ist für alle verbundenen Smartphones der Befehl “Gerätzurücksetzung” in der Befehlsleiste aufgeführt. (Achtung: Hier nicht den Befehl “Löschen” nutzen – dieser trennt die Verbindung zwischen Exchange und Smartphone, sendet aber keinen Löschbefehl!)

Nach einer Rückfrage schickt Exchange dann den Löschbefehl an das Telefon. Dieses setzt sich dann zurück, was der Anwender daran sieht, dass das Telefon unvermittelt neu startet. Nach dem Neustart befindet sich das Gerät (zumindest im Fall von Windows Phone 7) wieder im Lieferzustand und durchläuft die Prozedur, die es auch beim allerersten Einschalten aufruft.

In den OWA-Optionen stellt sich die Situation jetzt so dar:

Es empfiehlt sich nun, das Telefon aus dem Exchange-Postfach zu löschen. Auch dies kann der Anwender selbst tun:

Entfernt man das Smartphone nicht, so wird es beim nächsten Versuch, die Synchronisierung mit Exchange neu aufzurufen, gleich erneut das “Remote Wipe” ausgeführt.

Zurück in der Mailbox, sieht der Anwender eine Bestätigungsmail über den Vorgang:

Vorsichtshalber weise ich darauf hin, dass Daten von einem Flash-Speicher (ein solcher steckt ja in jedem Smartphone) gar nicht vollständig gelöscht werden können. Windows Phone 7 erlaubt aber keinen Zugriff auf die gelöschten Daten, und selbst wenn man die Speicherkarte entfernt, nutzt das nichts: Sie ist gerätespezifisch verschlüsselt, man kann also außerhalb des Geräts nicht auf die Daten zugreifen. Gleichwohl bleibt ein Risiko, das alle Smartphone-Typen gleichermaßen betrifft.

faq-o-matic.net » Sicherheit

Konfigurationsempfehlungen vom BSI für Windows 7

Verwandte Beiträge:

Kennwörter selbst zurücksetzen

Wie genau funktioniert das also?

Profile Enrollment Mode

Active Directory Data Mode

Technische Informationen zu Password Reset Pro

Geplante Features

Fazit

Verwandte Beiträge:

Dynamische Objekte in AD: Unbekannt und gefährlich

Verwandte Beiträge:

IIR IT Admin Tech Talk 2011: Die Folien

Verwandte Beiträge:

SetACL Studio ist verfügbar

Verwandte Beiträge:

Sichere Kennwörter

Verwandte Beiträge:

ILO-Board und HP System Management Homepage mit Zertifikaten einer eigenen CA versorgen

Voraussetzungen

Einrichtung

Fazit

Verwandte Beiträge:

Vorsicht Falle! Vererbung im AD

Verwandte Beiträge:

Windows-Gruppen richtig nutzen

So viele Arten von Gruppen!

Lokale Gruppen

Domänenlokale Gruppen

“Builtin”-Gruppen

Globale Gruppen

Universalgruppen

Pseudo-Gruppen

Wie Berechtigungen funktionieren

Das A-G-DL-P-Prinzip

Best Practice und Grenzen

Verwandte Beiträge:

Remote Wipe unter Windows Phone 7

Verwandte Beiträge: