Kategorie-Archiv: PowerShell

ActiveDirectory Rechte-Vererbung via Powershell einschalten

Veröffentlicht am von — 2 Kommentare ↓

Problem

active-directy-vererbung-einschaltenIm ActiveDirectory wurde die Vererbung von übergeordneten Rechten für Benutzer oder Computerobjekte ausgeschaltet. Obwohl es bestimmte Szenarien gibt, in denen eine solche Anpassung Sinn ergibt, führt das auslassen der Domänen-Rechtehirachie doch gerne auch zu schwer zu suchenden Fehlern.

Zum Beispiel:

  • ExchangeSynchronisationsfehler 86000C0A bei betroffenen Benutzern, obwohl OWA korrekt funktioniert
  • Dateisystems-Auflistung im Explorer schlängt mit 0x86000Cxx Fehlern Fehl
  • Fehler im Ereignisprotokoll von MSExchange ActiveSync mit dem Inhalt „Active directory Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0″.“

Das sind noch nicht alle Fehler, es gibt noch einige weitere. Oft auch im Zusammenhang mit BlackBerry Enterprise Servern oder -Services.

Lösung

Wenn nur ein Objekt betroffen ist: Im Benutzerobjekt auf dem Tab Sicherheit unten die „Vererbung aktivieren“ und die folgenden Meldung abnicken.

Für mehrere Objekte hilft ein kurzes PowerShell-Script. Am einfachsten ist die Anwendung, wenn man eine PowerShell ISE als Administrator ausführt (!) und das Script in den oberen Script-Teil einfügt:

Import-Module activedirectory
$OU = "OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD"
$Users=get-aduser -Filter * -SearchBase $OU
if ($Users -ne $null) {
foreach ($Entry in $Users) {
 [string]$dn = (Get-ADUser $Entry).DistinguishedName
 $user = [ADSI]”LDAP://$dn”
 $acl = $user.objectSecurity
 Write-Host "Pruefe Benutzer:" (Get-ADUser $Entry).SamAccountName
 if ($acl.AreAccessRulesProtected){
 Write-Host "Fixe Benutzer:" (Get-ADUser $Entry).SamAccountName
 $acl.SetAccessRuleProtection($false,$true)
 $inherited = $acl.AreAccessRulesProtected
 $user.commitchanges()
 }
 }
}
else {
Write-Host "Keine Benutzer in $OU gefunden"
}

Referenz: http://support.microsoft.com/kb/2579075 und http://www.techguy.at/active-directory-objekte-mittels-powershell-wiederherstellen/

Office365 „winmal.dat“ (TNEF) versand abschalten

Veröffentlicht am von — 2 Kommentare ↓

Problem

Einige Empfänger berichten, das Sie anstelle des gewünschten anhanges eine Datei namens „winmail.dat“ erhalten. Das betrifft vor allem ältere E-Mail-Programme, Apple-Mail und Systeme hinter älteren Firewalls/Mailfiltern.

Lösung

Man kann dem ausgehenden Connector des Office365 Exchange Online Dienstes das versenden des Microsoft TNEF-Formates vollständig abgewöhnen. Man stellt eine Verbindung zur Office365 Powershell her und konfiguriert die Einstellung mit dem Commandlet Set-RemoteDomain.

$Cred = Get-Credential
$shell = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $shell
Set-RemoteDomain Default -TNEFEnabled $false

Mit „Get-RemoteDomain |fl“ lassen sich die aktuellen Einstellungen für den Connector überprüfen. Die folgenden Einstellungen sind für den Parameter TNEFEnabled verfügbar:

  • $true: TNEF wird für alle Nachrichten verwendet
  • $false TNEF wird nie für Nachrichten verwendet
  • $null der Absender gibt die Einstellung vor (Standardeinstellung). Funktioniert TOTAL großartig, denn jeder Mensch weiss ja wie man in Outlook-Kontakten das TNEF-Format konfiguriert. </ironic mode=“off“>

Gezielt lässt sich die Einstellung für bestimmt Domains so setzen:

Set-RemoteDomain foo.bar -TNEFEnabled $false

Office365 Powershell Modul: „Sie benötigen Version 7.0 oder höher des Microsoft Online Serivices Anmeldeassistenten …“

Veröffentlicht am von — 2 Kommentare ↓

sie-benoetigen-version-7-oder-hoeher
Problem

Das Office365 (=Windows Azure) Powershell-Modul lässt sich nicht installieren, mit der Fehlermldung: „Sie benötigen VErsion 7.0 oder höher des Microsoft Online Services Anmeldeassistenten, wenn Sie das Windows Azure Active Directory-Modul für Windows PowerShell auf diesem Computer installieren möchten“. Die Systemvoraussetzugnen (Powershell, Online Services Sign-in Assistant) sind in der korrekten Version installiert.

Lösung

Die Deutsche Version des Windows Azure Active Directory Module for Windows PowerShell (AdministrationConfig-DE.msi) liegt zwar in der richtigen Version vor, das Setup setzt aber den Registry-Schlüssel dafür nicht richtig. Die englische Version macht das korrekt, die kann man aber als Deutsches Admin nicht ohne weiteres herunterladen.

Abhilfe schafft der korrekte Registry-Eintrag:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOIdentityCRL]
"MSOIDCRLVersion"="7.250.4551.0"

Dann läuft der Assistent durch. Nach der Installation kann der Wert wieder auf den Ursprünglichen zurückgesetzt werden (stand heute: 7.250.4209.0).

Powershell Sicherheitswarnung für PS1-Scripts trotz „unrestricted“ loswerden

Veröffentlicht am von — 4 Kommentare ↓

Das man an der Kommandozeile nahezu keine selbst- oder Fremdgebauten PS-Scripts ausführen kann hat sich mittlerweile herumgesprochen. Das kaum ein Admin seine kleinen Helferchen einzeln und bei jeder Änderung signieren wird ist ebeso offensichtlich.

Umso ärgerlicher, als das der Script-aktive Admin ab und an über den doppelten Boden der Powershell-Ausführungsverhinderung stolpert. Trotz der ExecutionPolicy ohne Restriktionen:

Set-ExecutionPolicy Unrestricted

gibt es doch weiterhin Scriptausführungsverhinderungen die sich in deutlich nicht-aussagekräftigen Fehlermeldung an der Kommandozeile und ISE bemerkbar machen:

powershell-ise-warnung

 

…  an der Shell:

PS C:scripts> .format-c.ps1
Sicherheitswarnung
Führen Sie ausschließlich vertrauenswürdige Skripts aus. Skripts aus dem Internet können zwar nützlich sein,
stellen jedoch auch eine potenzielle Gefahr für Ihren Computer dar. Möchten Sie "C:scriptsformat-c.ps1"
ausführen?
[N] Nicht ausführen  [M] Einmal ausführen  [H] Anhalten  [?] Hilfe (Standard ist "N"):

Automatisierungen jeder Art sind so offensichtlich undurchführbar und auch das deutlichste „Als Stapelverarbeitungsauftrag anmelden“ Recht verpufft an diesem Scriptverhüterli wirkungslos.

Lösung

Seit Windows 8 und dem zugehörigen Server 2012 gibt es im Dateisystem ein magisches Flag, das die (telepatisch festgestellte) Herkunft des Scripts als lokal oder „Siebter Kreis der Hölle“ markiert. Das Flag lässt sich mit einem Klick auf „Zulassen“ in den Dateieigenschaften wie für die lokale Ausführung erwartet zulassen.

powershell-ise-warnung-loesung

Selbstverständlich ist der Vorgang irreversibel, denn die telepatischen Fähigkeiten von Windows sind über jeden Zweifel erhaben. Die Anwesenheit des Flags lässt sich durch kopieren/einfügen beibehalten, durch Snippletkopiererei (ein TOTAL ungewöhnlicher Vorgang beim scripten) reproduzieren und nicht automatisiert beheben.