In Microsoft Windows 2000 und Windows Server 2003 Active Directory-Domänen konnte bisher nur eine Passwort- bzw. Kontosperrungsrichtlinie, die in der Default Domain Policy angegeben wurde, für alle Benutzer in der Domäne angewendet werden. Wenn verschiedene Kennwort-und Kontosperrungsrichtlinien für unterschiedliche Gruppen von Benutzern eingesetzt werden sollten, musste man mehrere Domains hierfür vorsehen – eine eher kostspieliege Alternative.

Ab Windows Server 2008 (R2) können nun fein abgestimmte Kennwortrichtlinien angelegt werden, welche man auf unterschiedliche Gruppen von Benutzern innerhalb einer einzigen Domäne anwenden kann. Zum Beispiel, um die Sicherheit von privilegierten Admin-Accounts zu erhöhen, kann man nun strengere Einstellungen vornehmen, als für unprivilegierte Benutzer-Accounts.

Um fein abgestimmte (fine-granulare) Kennwortrichtlinien zu speichern, enthält Windows Server 2008 zwei neue Objektklassen im Active Directory Domain Services (AD DS)-Schema:

• Password Settings Container
• Password Settings

Wie und welche Möglichkeiten es ab Windows Server 2008 zur Erstellung der granularen Passwortrichtlinien gibt, möchte ich kurz in diesem Howto nahebringen. Folgende Möglichkeiten stehen ab Windows Server 2008 zur Verfügung.

• AD-PowerShell
• LDIFDE
• ADSI-Editor

Im folgenden Howto erkläre ich, Schritt für Schritt wie ein PSO (Password-Settings-Object) im ADSI-Editor angelegt wird, den Attributen des Objekts Werte zuweist und am Ende die angepasste Passwort-Richtlinie Benutzern bzw. Gruppen zuweist.

Zuerst startet Ihr den ADSI-Editor auf dem Domain Controller mit Administratorrechten und verbindet Euch.

Nach der Verbindung navigiert Ihr zu: DN=<domain> CN=System CN=Passwords Settings und erstellt per Rechtsklick ein neues Objekt. Im darauffolgenden Dialogfenster wählt Ihr: msDS-PasswordSettings aus und klickt auf weiter. Sollte der Common-Name “System” einmal nicht zu sehen sein, klickt Ihr auf “Ansicht->erweiterte Features anzeigen” und CN=System sollte als Auswahlmöglichkeit erscheinen.

Im ersten Dialogfenster legt Ihr den CN fest. Dieser wird später im Container CN=System CN=Password Settings angezeigt. Legt hier bitte einen eindeutigen Namen fest. Dies erleichtert Euch das Auseinanderhalten, falls Ihr mehrere granulare Passwortrichtlinien erstellen möchtet.

msDS-PasswordSettingsPrecedence

Unter PasswordSettingsPrecedence könnt Ihr einen Wert zwischen 0 und 65535 auswählen. Je kleiner der Wert, desto eher wird die Passwortrichtlinie später auf Eure Benutzer angewendet, falls mehrere Passwortrichtlinien auf ein und denselben Benutzer wirken sollten.

msDS-PasswordReversibleEncryptionEnabled

Holprig mit “Passwort-Rückwärts-Verschlüsselung-eingeschaltet” übersetzt, korrekt heißt es Kennwörter mit umkehrbarer Verschlüsselung speichern. Dieses Attribut nimmt einen booleschen Wert an. True bedeutet in diesem Fall, dass die Passwörter im Klartext gespeichert werden. Somit versteht sich von selbst, dass man aus Sicherheitsgründen an dieser Stelle den Wert “false” einzugeben hat.

msDS-PasswordHistoryLength

Dieses Attribut gibt an, wie lange sich Windows alte Passwörter merken soll. Das heißt, wenn Ihr Euch bei Windows anmeldet und zum Passwortwechsel aufgefordert werdet, dürft Ihr keines der alten Passwörter als neues Passwort verwenden. In unserem Fall sind es die letzten 24 Passwörter.

msDS-PasswordComplexityEnabled

Hiermit schaltet Ihr die Passwortkomplexität ein oder aus. Sollen Groß-/Kleinbuchstaben, Zahlen und Sonderzeichen gemischt verwendet werden oder nicht.

msDS-MinimumPasswordLength

Wie lang muss das Passwort mindestens sein!

msDS-MinimumPasswordAge

Wie alt muss das Passwort mindestens sein, damit es wieder geändert werden darf. Dabei wird eine Zeitangabe nach folgendem Format abgefragt: “Tage : Stunden : Minuten : Sekunden”. Achtet hierbei bitte darauf, dass einführende “0” eingeben wird. Ansonsten kann es sein, dass Ihr am Ende der Eingabe eine Fehlermeldung erhaltet, da ein Wert nicht dem korrekten Format entspricht.

msDS-MaximumPasswordAge

Wie alt darf das Passwort maximal sein, bevor es abläuft und geändert werden muss. Hierbei wird das gleiche Format wie bei “msDS-MinimumPasswordAge” verwendet.

msDS-Lockout-Threshold

Dieser Wert gibt an, nach wie viel Login-Fehlversuchen das Benutzerkonto gesperrt werden soll.

msDS-LockoutDuration

Dieses Attribut gibt an, wie lange ein Benutzerkonto nach Login-Fehlversuchen gesperrt bleiben soll, bis es automatisch wieder entsperrt wird. Format: “Tage : Stunden : Minuten : Sekunden” (z.B. für 30 Minuten: “00:00:30:00”)

Damit sind wir mit dem ersten Schritt, dem Anlegen einer granularen Passwortrichtlinie fertig und werden im zweiten Schritt diese Passwortrichtlinie einem Benutzer zuordnen.

Hier sehen wir, dass wir die granulare Passwortrichtlinie erstellt haben.

Per Doppelklickt oder Rechtsklick auf die Policy und dann auf “bearbeiten” öffnet sich das Kontextmenü, in dem alle Attribute aufgeführt werden, welche das PSO (Password Setting Object) aufnehmen kann.

Hier finden wir auch unsere Werte wieder, die wir hier auch noch nachbearbeiten könnten und das Attribut:

msDS-PSOAppliesTo

Mit diesem Attribut können wir festlegen, auf wen denn unsere Passwortrichtlinie wirken soll. Ich wähle dazu einfach meinen Benutzernamen in der Testumgebung aus und bestätige alles mit OK. Damit wirkt die Passwortrichtlinie auf mich, bei der nächsten Änderung meines Passwortes.

An dieser Stelle sehen wir, dass ich hinzugefügt wurde. Momentan steht an dieser Stelle zwar noch die SID, welche aber nach kurzer Zeit in meinen Namen aufgelöst wird.

Das war es zur Erstellung von granularen Passwortrichtlinien (fine-grained password policies) mit Hilfe des ADSI-Editors unter Windows Server 2008 R2.

Viel Grüße,
Patrick Jahn

Mit den “BSI-Empfehlungen zur Cyber-Sicherheit” veröffentlicht das Bundesamt für Sicherheit in der Informationstechnik Lösungsvorschläge und Handlungsempfehlungen zur Cyber-Sicherheit. Mit der BSI-Empfehlungen “Abwehr von DDoS-Angriffen” stellt das Bundesamt für Sicherheit in der Informationstechnik eine Checkliste, sowie geeignte Präventivmaßnahmen zum Schutz vor DDoS-Angriffen bereit.

Folgende Maßnahmen sind Bestandteil der BSI-Empfehlung:

• Serverhärtung
• Filterung nach Quelladressen – Blackholing
• Filterung nach Zieladressen – Sinkholing
• Filterung nach verschiedenen Kriterien
• DDoS-Mitigation Appliances
• Analyse des Netzwerkverkehrs
• Protokollierung

BSI-Empfehlungen zur Cyber-Sicherheit : BSI-E-CS 002 | Version 1.0, 01.02.2012

Stay secure,
Thomas Gronenwald

Hallo,

im ersten Teil hatte ich beschrieben, wie man den Firefox generell an seine Bedürfnisse anpassen kann. Heute möchten ich euch erklären, wie ihr das ganze als Applikation über den Citrix Streaming Profiler 6.5 erstellt.

Nach dem Start des Streaming Profilers werdet Ihr gebeten, ein Neues Profil anzulegen oder ein Profil zu öffnen, an dem Ihr nachträglich Änderungen vornehmen wollt.

Wichtig: Den Streaming Profiler solltet ihr auf einem neuen, frischen Betriebssystem ausführen. Ebenso sollte das Betriebssystem identisch zum Zielsystem sein.

Schritt 1: Wir legen ein neues Profil an.

Schritt 2: Der Assistent startet mit dem Hinweis, dass nach dem Beenden des Assistenten, das Profil auf einem App-Hub gespeichert wird. Den App-Hub kann man sich als Server vorstellen, wo die Profile liegen, die vom XenApp-Server z.B. zu den Clients gestreamt werden sollen. In diesem Fall ist es ein normaler Fileserver mit den entsprechenden Freigaben für den XenApp-Server.

Schritt 3: Festlegung des Profilnamens. Dieser wird später im XenApp-Server-Manager angezeigt, kann aber im Nachhinein auch noch geändert werden.

Schritt 4: Hier kann man einstellen, dass Benutzer die Möglichkeit haben die Profile zu ändern, in dem Sie die Anwendung updaten. Dies möchten wir nicht, also wird kein Haken im Feld “Benutzerupdates aktivieren” gesetzt.

Schritt 5: Legacy-Offline Plugins werden für unseren Fall nicht benötigt, daher bleibt auch hier das Feld für den Haken leer und wir klicken auf weiter.

Schritt 6: Interisolierungs-Kommunikation einrichten. Falls ihr Anwendungen streamen möchtet, die von anderen Anwendungen abhängig sind, dann könnt ihr diese hier angeben und nach Prioitäten von oben nach unten sortieren.

Schritt 7: Auf der Seite Betriebssystem und Sprache des Ziels festlegen wählen Sie die Clientkonfigurationen aus, die auf die Anwendung, die Sie installieren, zugreifen können. Sie müssen mindestens ein Zielbetriebssystem und eine Zielsprache auswählen.

Schritt 8: Wir wählen an diesem Punkt die erweiterte Installation, denn wir möchten unsere drei Dateien aus Teil I des Guide später in unser Profil einfügen.

Schritt 9: Als erstes wollen wir den Firefox installieren. Somit wählen wir die erste Option Installationsprogramm oder Befehlszeilenscript ausführen aus.

Schritt 10: Nun wählt wir die Anwendung aus, die installiert werden soll. Mozilla Firefox in der Version 10 mit den Befehlszeilenparametern “-ms”. Der Parameter “-ms” steht dafür, dass die Installationsroutine ohne Wizard abläuft und Ihr nicht immer auf weiter klicken wollt.

Schritt 11: Installationsprogramm ausführen. An dieser Stelle werden wir die Installation starten. Dies dauert ein paar Sekunden und Ihr könnt erst auf weiter klicken, wenn die Installation im Hintergrund abgeschlossen ist.

Schritt 12: Nächsten Schritt auswählen. Wir möchten gerne zusätzliche Installationen durchführen, denn wir möchten “Dateien und Ordner hinzufügen”

Schritt 13: Hier klicken wir Dateien und Ordner auswählen an.

Schritt 14: An dieser Stelle fügen wir nun, die Dateien “override.ini” und “mozilla.cfg”, die wir im ersten Teil des Guides bearbeitet haben, dem Standardordner des Mozilla Firefox hinzu. Wählt dazu auf der rechten Seite den entsprechenden Ordner aus (z.B. “C:\Program Files (x86)\Mozilla Firefox\”), markiert die beiden Dateien auf der linken Seite und klickt im Anschluss auf den grünen Pfeil!

Schritt 15: Analog zu Schritt 14 verfahren wir auch hier. Die Datei “local-settings.js” fügen wir dem Ordner: “C:\Program Files (x86)\Mozilla Firefox\defaults\pref\” hinzu.

Schritt 16: Nun haben wir alle Änderungen an unserem Profil vorgenommen und möchten die Installation abschließen.

Schritt 17: Hierzu führen wir die Anwendung einmal aus (Klick auf “Ausführen”), damit wir überprüfen können, ob die Änderungen auch den gewünschten Erfolg erzielen und das Profil im Nachgang mit den vorgenommenen Änderungen erstellt werden kann. Der Firefox sollte an dieser Stelle mit den Änderungen, die wir im Teil I des Guide vorgenommen hatten, starten.

Schritt 18: Die Anwendung, die wir später mit dem Citrix AppCenter veröffentlichen möchten, wählen wir jetzt aus –> Mozilla Firefox 10.

Schritt 19: Wir möchten keine Virtuelle Festplatte (VHD) erstellen, somit bleibt das Feld für den Haken leer.

Schritt 20: Das Profil wird auch nicht signiert, da keine Zertifizierungsstelle vorhanden ist.

Schritt 21: Am Ende wird uns noch einmal eine Zusammenfassung mit den Profildetails angezeigt. Falls wir weitere Änderungen vornehmen wollen, können wir an dieser Stelle letztmalig zurück gehen. Wir haben alles korrekt eingestellt und erstellen mit “Fertig stellen” unser Profil.

Linksammlung zu Citrix XenApp:

Wie funktioniert Applikationsvirtualisierung?
http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1683975

Ressources, Support, Downloads. Auf den Webseiten von Citrix gibt es zahlreiche Lektüre zum Thema Virtualisierung:
http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300372

Patrick Jahn

Hallo,

nachfolgend möchte ich euch heute kurz vorstellen, wie Ihr euren Mozilla Firefox 10 an eure Bedürfnisse anpassen könnt. Für den Fall, dass Ihr den Firefox per XenApp 6.0 über einen Server streamen möchtet, sollte der Firefox zum starten nicht lange nach Updates, Add-ons und der Startseite im Internet suchen, sondern sollte sich so schnell es geht beim User öffnen. Der Hintergrund ist eine besondere Kundenanforderung. Dort gibt es keine Möglichkeit das Internet zu nutzen. Firefox wird ausschließlich für interne Applikationen verwendet. Dazu unterbinden wir die unnötigen Abfragen, die vom Firefox ansonsten automatisch ins Internet gehen und für ungewollte Verzögerungen sorgen.

Dazu erstellen und modifizieren wir die folgenden drei Dateien, die am Ende in den entsprechenden Ordnern abzuspeichern sind:

• mozilla.cfg
• override.ini
• local-settings.js

Die Datei: mozilla.cfg

Speicherort (Beispiel): “C:\Program Files (x86)\Mozilla Firefox\”

Die “mozilla.cfg” enthält die Konfigurationseinstellungen, die wir dem Firefox beim Starten mitgeben möchten. Eine Komplettübersicht aller Einstellmöglichkeit beim Firefox könnt Ihr Euch ansehen, indem Ihr:

about:config

in die Adresszeile eingebt.

Einige Einstellmöglichkeiten möchte ich kurz und knapp beschreiben:

pref(“startup.homepage_override_url”,”about:blank”);
Sorgt dafür, dass die Starthomepage bei Änderungen nicht überschrieben wird.

pref(“startup.welcome_url”,”about:blank”);
Die Willkommensseite, die beim ersten Start geladen wird, möchten wir nicht angezeigt bekommen.

pref(“browser.startup.page”,0);
Für jeden weiteren Start ist die Startseite leer. Gleichzusetzen mit “about:blank”

pref(“browser.startup.homepage”,”about:blank”);
Dies ist die zu ladende Webseite, falls “browser.startup.page” auf 1 gesetzt ist. Somit ist dieser Eintrag optional, da “browser.startup.page” in unserem Fall den Wert 0 enthält.

pref(“browser.shell.checkDefaultBrowser”,false);
Unterbindet, dass Firefox beim Starten danach fragt, ob er als Standardbrowser eingerichtet werden soll.

pref(“app.update.auto”, false);
Deaktiviert die Möglichkeit, dass Firefox automatisch nach Anwendungs-Updates (andere Firefox-Versionen) sucht. Es gibt kein Internet beim Kunden, somit soll Firefox nicht im Internet danach suchen.

pref(“app.update.enabled”, false);
Deaktiviert allgemein, dass Firefox nach Updates suchen soll – auch nicht automatisch.

pref(“extensions.update.enabled”, false);
Es wird nach keinen Add-on-Updates gesucht.

pref(“browser.search.update”,false);
Firefox sucht hiermit auch keine Updates für die installierte Suchmaschine. (z.B. google)

Für eine komplette Übersicht aller Einstellungen, die Firefox bietet

• “about:config”

in die Adresszeile eingeben. Bitte beachtet, dass unkoordinierte Änderungen in dieser Konfiguration dazu führen, dass der Firefox nicht mehr einwandfrei funktioniert.

Auf den Seiten von http://kb.mozillazine.org könnt Ihr in der Suche einfach einen Konfigurationsparameter eingeben und findet dazu zahlreiche Informationen und Beschreibungen, was welche Änderung bewirkt.

Die Datei: override.ini

Speicherort (Beispiel): “C:\Program Files (x86)\Mozilla Firefox\”

Die “override.ini” muss erstellt werden (z.B. mit dem Notepad) und beinhaltet einen Eintrag, der die Abfrage beim Startvorgangs des Firefox unterbindet. Es handelt sich hierbei um die Abfrage nach dem Standardbrowser und ob eventuell Lesezeichen, Links, etc. importiert werden sollen. Die Abfrage unterbinden wir einfach mit den folgenden Codezeilen, die wir der Datei hinzufügen:

Die Datei: local-settings.js

Speicherort (Beispiel): “C:\Program Files (x86)\Mozilla Firefox\defaults\pref\”

Die “local-settings.js” müssen wir mit einem Editor erstellen (z.B. Notepad) und am Ende im Ordner “%Installationspfad von Firefox%\default\pref\”. Das könnte unter Windows in etwa so aussehen; “C:\Program Files (x86)\Mozilla Firefox\defaults\pref\”

Viele Grüße,
Patrick Jahn

Hallo,

viele Unternehmen (leider nicht alle!) haben die Zeichen der Zeit erkannt und setzen auf einen flächendeckenden Virenschutz – sowohl auf Client- als auch auf Serversystemen. In vielen Fällen wird der Virenschutz jedoch nicht nach Hersteller-Best Practices konfiguriert. So werden im ständigen Zugriff befindliche Systemdateien beim täglichen Scan oder im Echtzeitschutz mitgeprüft. Oft führen diese “Fehlkonfigurationen” zu unerwarteten Systemfehlern. Systeme reagieren nicht mehr oder arbeiten nur noch träge -wichtige IT- und Geschäftsprozesse arbeiten nicht mehr. In diesen Fällen empfiehlt es sich kritische Dateien und Dienste von dem täglichen Scan und dem Echtzeitschutz auszunehmen. Wichtig: Diese Dateien sollten jedoch trotzdem in festen Wartungsfenstern regelmäßig überprüft werden.

Microsoft hat vor kurzem eine sehr detailierte Liste für ihre Serversysteme veröffentlicht. Die Liste wird ständig aktualisiertund kann als RSS-Feed eingebunden werden.

Die Liste findet ihr unter:
http://social.technet.microsoft.com/wiki/contents/articles/953.aspx

Stay Secure,
Thomas Gronenwald

http://social.technet.microsoft.com/wiki/contents/articles/953.aspx

Wer kennt ihn nicht-diesen fiesen Computerwurm namens “Stuxnet” der, im Juni 2010 entdeckt, bis Ende des Jahres sein in (hauptsächlich iranischen) Industrieanlagen sein Unwesen trieb. Die Gefahr schien gebannt, doch wie Symantec berichtet, gibt es eine neue, und bessere, Variante des Wurms…der keiner mehr ist: W32.Duqu.

Aufgrund der Ähnlichkeit der Funktionsweise geht man davon aus, dass er den selben Author hat wie Stuxnet-oder zumindestens jemanden, der Zugriff auf Stuxnet’s Code hatte. Jedoch hat diese Variante keinen eigenen Verteilmechanismus, richtet keinen Schaden an sondern späht das betroffene System “nur” aus (Tastatureingaben und spezifische Systeminformationen). Aus derzeitiger Sicht mag dies nicht so schlimm sein. Jedoch geht man davon aus, dass diese Informationen für einen erneuten Angriff genutzt werden sollen.

Eine Infektion kann bei Windowssystemen, aufgrund des fehlenden Verteilmechnismus’, ausschließlich über Wechseldatenträger in Kombination mit vorhandenen Schwachstellen (Autostart, …) erfolgen. Diese sind auf den Zielrechnern (fokussiert wird hauptsächlich auf Industriesteuerungsanlagen) leider sehr häufig zu finden.

Während des Sammelns von Informationen macht der Schadcode externe Verbindungen auf, um die Daten (verschlüsselt) zu senden. Auch hierbei sei erwähnt, dass viele Produktionsanlagen direkte und vollgeroutete Internetanschlüsse besitzen.
Gegenmaßnahmen voerst:

• Deaktivierung Wechseldatenträger (USB, …)
• Überwachung Firewall auf ungewöhnlichen Verkeh (HTTP/S zu “206.xxx.xxx.97″)
• Deaktivierung Internetzugriff wenn nicht unbedingt benötigt
• Aktualisierung AntiVirus Signaturen

Update 19.10.2011, 12:10 Uhr:
Ein Lehrstück bei der Kombination von Überwindungsmaßnahmen. Wie Symantec schreibt, wurden Teile des Codes mit einem öffentlichen Zertifikat signiert (sog. “Code-Signing-Certificate”), welches von einem Symantec-Kunden gestohlen worden ist (wobei durch “stehlen” hat man das Passwort dafür ja auch nicht…). Solche Zertifikate braucht man, damit zum Beispiel Windowssysteme diese Software als vertrauenswürdig einstufen (und ausführen, selbst AV-Software springt dann nicht an). Symantec hat dieses Zertifikat zurückgezogen. Dies wiederrum hilft aber nichts-denn auf dem “Opfersystem” muß dies auch geschehen, entweder manuell oder durch ein Update. Für ersteres ist es notwendig zu wissen, um welches Zertifikat es sich handelt (das wird Symantec wohl kaum rausgeben) und für zweiteres gibt es eine Abhängig von Microsoft. Bleiben also die Maßnahmen, welche ich im Hauptartikel schon beschrieben habe.

Update 19.10.2011, 21:10 Uhr:
Symantec hat eigene Virendefinitionen entsprechend aktualisiert und ein Removal-Tool zur Verfügung gestellt (Kaspersky, Microsoft und Avira auch).

Hallo zusammen,

in Zusammenarbeit mit dem IT-Administrator Magazin hat gestern, nach dem ersten Workshop in Lingen, der zweite Workshop in Langenfeld zum Thema “Windows Server 2008 R2″ stattgefunden. An dieser Stelle gibt es nun wie versprochen alle Folien zum direkten Download.

Auf diesem Wege nochmals vielen Dank für die zahlreichen Teilnehmer und das positive Feedback.

  ITANet Workshop - AD Security - Die Folien (452,1 KiB, 425 hits)

  ITANet-Workshop - Key Management Service - Die Folien (291,5 KiB, 500 hits)

  ITANet-Workshop - AD-Exporte - Die Folien (965,4 KiB, 313 hits)

  ITANet-Workshop - AD-Exporte - Die Scripte (917,7 KiB, 166 hits)

Stay Secure,

Thomas Gronenwald
Sascha Giebelhausen

Heute nutzt so gut wie jeder Zertifikate – von E-Mail Verschlüsselung über Signierung bishin zur Dateiverschlüsselung, vieles ist möglich. Oft kommt es vor, dass innerhalb des Active Directories veröffentlichte Zertifikate nach Ablauf der Gültigkeit dort verbleiben. Sollte dann auch noch die alte Zertifikatsstelle nicht mehr erreichbar sein, können veröffentlichte Zertifikate auch nicht mehr von zentraler Stelle zurückgezogen werden.

Was auch beiläufig erwähnt werden muss ist, dass durch abgelaufene Zertifikate gegebenenfalls die Synchronisation des Exchange Offline Adressbuch fehlschlagen kann.

Je nach Benutzeranzahl gestaltet sich eine Bereinigung per Hand sehr mühselig. Damit jeder einen Überblick über die veröffentlichten und abgelaufenen Zertifikate erhält, habe ich ein PowerShell-Script zum Export dieser im Active Directory veröffentlichten Zertifikate geschrieben. Damit wird eine Auswertung über alle Benutzer der gewünschten Infrastruktur erstellt und eine Liste der veröffentlichten Zertifikate inklusive Ablaufdatum und Aussteller/Zertifikatsstelle generiert. Die Datensätze werden in der aktuellen Version in eine CSV-Datei exportiert, womit sie dann in Excel weiterverarbeitet und gefiltert werden können.

Das Script bitte vorab testen. Trotz sorgfälltiger Prüfung kann ich natürlich keine Haftung übernehmen.

  export_cert.ps1 (1,5 KiB, 218 hits)

Viel Spaß beim aufräumen.

Sascha Giebelhausen

Wenn im Netzwerk kein DDNS unterstützt wird oder es keine Zugriffsmöglichkeiten auf die DNS-Server gibt, muss den KMS-Clients manuell ein KMS-Host zugewiesen werden – hierdurch wird die automatische Erkennung von KMS auf einem KMS-Client deaktiviert.

So weist du einem KMS-Client manuell einen KMS-Host zu:

Step 1:
Anmeldung am KMS-Client.

Step 2:
Öffnen einer Eingabeaufforderung mit erhöhten Rechten.

Step 3:
Zuweisen eines KMS-Hosts mittels FQDN:

cscript \windows\system32\slmgr.vbs /skms <KMS_FQDN>:<Port>

Ebenso kann eine IPv4, IPv6 oder ein NETBIOS-Name verwendet werden.

Stay secure,
Thomas Gronenwald

Wie finde ich schnell und einfach alle Mitglieder meiner Gruppen heraus? Wer hat noch Administratorberechtigungen, dürfte diese aber streng genommen gar nicht mehr haben?

Oft steht man vor dem Problem, Gruppen und die dazugehörigen Mitglieder innerhalb des Active Directories auszuwerten. Abhilfe schafft hier das Tool “AD Group Members v1.1″ von Guillermo Musumeci.  Es ermöglicht Gruppen und Mitglieder zu exportieren (*.csv) – mittels Autofilter in Excel sind so schnell alle Mitglieder in den verschiedenen Gruppen dargestellt.

Many thanks to Guillermo, great work – well done!

Download AD Group Members v1.1

Stay secure,
Thomas Gronenwald