Kleine IT-Episoden & das wahre Leben
Im Standard veröffentlicht der Hersteller Microsoft jeden 2ten Dienstag im Monat seine Aktualisierungen. Durch diese Vorgabe entstehen folgende Termine für das Jahr 2023:
Viele kennen das Cmdlet Test-Connection oder Test-NetConnection um Verbindungen zu testen. Dort kann per -TcpPort bzw. -Port kann auch ein Port geprüft werden. Allerdings wird in beiden Varianten ein Ping vorausgesandt.
Es kann aber sein, dass die „Internet Control Message Protocol (ICMP) Echo Requests“ zu denen auch Pings gehören, in Firewalls gesperrt ist. Trotzdem möchte man aber vielleicht den direkten Port testen.
Dabei hilft das unten stehende Skript:
$destination = "192.168.2.1"
$port ="443"
$connection = new-object Net.Sockets.TcpClient
try{
$connection.Connect($destination, $port)
} catch {}
if($connection.Connected)
{
$connection.Close()
$object = [pscustomobject] @{
IP = $destination
TCPPort = $port
Result = $True }
Write-Output $object
}
else
{
$object = [pscustomobject] @{
IP = $destination
TCPPort = $port
Result = $False }
Write-Output $object
}
Write-Host $msgIm Rahmen des Patchdays des Monat Mai 2019 wird unter anderem ein Patch für die Sicherheitslücke CVE-2019-0708 mit der Überschrift „Remote Desktop Services Remote Code Execution Vulnerability“ für die gängigen Betriebssysteme Windows 7, Windows Server 2008 und 2008 R2 zur Verfügung gestellt. Betriebssysteme ab Windows 8 sowie Windows Server 2012 sind von dieser Thematik nicht betroffen.
Durch die Sicherheitslücke kann über eine präparierte RDP-Anfrage der Remote Desktop Dienst attackiert werden. Da keine Authentifizierung oder eine Interaktion durch einen Benutzer erforderlich ist, kann die Ausnutzung der Sicherheitslücke sehr „effektiv“ genutzt werden. Microsoft stuft die Lücke auf die selbe Kritikalität wie die Randsomware WannaCry.
Mit dem KB4500331 liefert allerdings der Hersteller Microsoft eine Aktualisierung für die Client-Betriebssysteme XP und Vista sowie das Server-Betriebssystem 2003 aus. Bei diesen beiden ist der Support bereits seit langer Zeit eingestellt.
Aus diesem Grund wird auch für die älteren Betriebssysteme eine Lösung angeboten und empfohlen diese zeitnah zu installieren. Die Patche können vom Microsoft Update-Katalog heruntergeladen werden. Die neueren Systeme erhalten das Update wie gewohnt über die Verteilung im Rahmen der Aktualisierungsszenarien.
Sollte Windows Vista als Client-Betriebssystem genutzt werden, kann der Patch des Server-Betriebssystems Windows Server 2008 heruntergeladen und installiert werden. Da diese die gleiche Architektur haben, ist dieser Austausch unproblematisch.
Nach einer Aktualisierung der Gruppenrichtlinien für Office 365 bekam ich eine Fehlermeldung, dass in der Datei „outlk16.admx“ in Zeile 6286 bei Zeichen 312 ein Problem besteht.
Bei der Analyse fiel mir auf, dass es einen Fehler in der ADMX-Datei unter der Nutzung der XML-Spezifikation gibt. Der Konfigurationsblock für „L_DisableOnlineModeAuthDiagnostics“ stand leider hinter dem Eintrag „</policies>“ Somit konnte dieser nicht verarbeitet werden.
Ich verschob den Textblock vor den Eintrag und die Gruppenrichtlinien waren wieder lesbar.
Das Problem tritt beim aktuell bereit stehenden Download durch den Hersteller Microsoft auf:
Administrative Template files (ADMX/ADML) and Office Customization Tool for Office 365 ProPlus, Office 2019, and Office 2016
Version: 4768.1000
Erscheinungsdatum: 18.01.2019
Außerdem muss dieses bei beiden Vorlage-Versionen (für 32 sowie 64-Bit) berücksichtigt werden.
Vor einer Umstellung oder auch einer Abschaltung eines Druckservers kann ein Audit der Druckdaten sinnvoll sein. Dabei wird ermittelt das Skript in den Parametern eines Zeitfensters, welcher Drucker wieviel Druckaufträge verarbeitet hat.
$Startzeit = "24.11.2018 00:00:00" $Endzeit = "24.11.2018 23:59:59" $ZentralDatei ="E:\Audit\Zentraldatei.csv" $Auswertung ="E:\Audit\Auswertung.csv" $Druckerliste = @() $Resultate = Get-WinEvent -FilterHashTable @{LogName="Microsoft-Windows-PrintService/Operational"; ID=307; StartTime=$Startzeit; EndTime=$Endzeit;} ForEach($Resultat in $Resultate){ $Datensatz = [xml]$Resultat.ToXml() $DatenDetails = New-Object -TypeName psobject -Property @{ Druckername = $Datensatz.Event.UserData.DocumentPrinted.Param5 Zeitstempel = $Resultat.TimeCreated } $Druckerliste += $DatenDetails } $Druckerliste | Export-Csv -LiteralPath $ZentralDatei -NoTypeInformation Import-Csv $ZentralDatei | Group-Object Druckername | Select-Object Name, Count | Sort-Object -Property name | Export-csv $Auswertung -NoTypeInformation
Das eingesetzte CMDlet „Get-WinEvent“ steht seit Windows Server 2008 R2 und späteren Betriebssystemen zur Verfügung.
Um die Daten zu erhalten, muss allerdings in der Ereignisanzeige das Log für „Microsoft \ Windows \ Printservices \ Operational“ aktiviert worden sein. Dieses sollte auch vorzeitig durchgeführt worden sein, um längere Zeiträume zu überwachen. Die Daten können nicht rückwirkend erstellt werden. Anbei die schnelle Umsetzung per PowerShell-Aufruf:
$EventLogging = Get-WinEvent -ListLog 'Microsoft-Windows-PrintService/Operational' $EventLogging.IsEnabled = $true $EventLogging.MaximumSizeInBytes = 1000000 $Eventlogging.LogMode = "Circular" $EventLogging.SaveChanges()
Mit diesem Befehlssatz wird das erforderliche Eintrag in der Ereignisanzeige aktiviert. Dabei wird ein 1 GigaByte großes Log erstellt. Wenn der Schwellwert erreicht ist, wird beim Hinzufügen eines neuen Ereignisses das Älteste entfernt.
In der Datei „Auswertung.csv“ stehen dann die Druckernamen sowie die Anzahl der Ausdrucke im Zeitraum ausgedruckt wurden.
Im Active Directory gibt es eine standardmäßige Gruppenrichtlinie für die Einstellungen der Kennwörter verwandt. Diese sind im Regelfall in der „Default Domain Policy“ verankert. Als Erweiterung der Konfigurationsmöglichkeit wurden die fein abgestimmten AD-Kennwortrichtlinien (Fine-grained Password Policy / FGPP) mit Windows Server 2008 eingeführt.
Mit dieser Methode ist es möglich verschiedene Kennwort-Parameter für Benutzer festzulegen. Die Einstellungen zur Aushandlung der Computer-Kennwörter wird weiterhin von der Standard-Richtlinie übernommen.
Da die Funktionalität entweder per Powershell oder ADSIEdit zur Verfügung oder bearbeitet werden muss, ist es für die Administration einfacher, dieses über eine AD-Gruppe zu verwaltet. Allerdings ist dabei auf eines zu achten: Es funktioniert nur mit einer globalen AD-Gruppe.
Alle anderen Gruppenformen werden bei der Zuordnung der Definition ignoriert. Wird eine Gruppe von der globalen Gruppe in eine andere Form überführt, greift automatisch die Standard-Richtlinie. Somit sollte man sich beim Einsatz von Gruppen für die Verwaltung der Benutzerzuordnung überlegt werden, ob die Gruppenform mit einem Skript oder einer Applikation überwacht wird.
Über den „Ressourcen-Manager für Dateiserver“ (File Server Resource Manager) können auf Windows Server 2008 sowie Windows Server 2012 verschiedene Funktionen konfiguriert werden. Dieses gilt unter anderem für eine Kontingentverwaltung (Quota management).
Damit können zum Beispiel Benutzerverzeichnisse auf eine Größe beschränkt werden. Es können entweder Ordner oder ganze Partitionen damit definiert werden. Auch lässt sich dieses über einen Prozess automatisieren, so dass bei einer Neuanlage eines Ordners direkt eine vorher festgelegte Einschränkung dort gilt. Dieses wird nur mit dem Dateisystem NTFS unterstützt.
Aufgrund von Anpassungen zwischen verschiedenen Vorlagen oder Einstellungen kann es passieren, dass die ausgewerteten Prozente nicht mehr stimmen. Nun muss man allerdings nicht das gesamte Regelwerk neu schreiben, sondern kann über einen Befehl die Ordner neu berechnen lassen.
dirquota quota scan /path:
Zum Beispiel greifen anschließend auch wieder Regelwerke, bei denen vorher schon der Trigger überschritten war.
Weitere Informationen: hier