Office365 Kennwörter niemals ablaufen lassen

Veröffentlicht am von — Keine Kommentare ↓

Die Vorgabe von Microsoft in Office365 ein maximales Kennwortalter von 90 Tagen als Standardwert für alle Benutzer (obligatorisch) zu verwenden ist zwar an sich recht sicher (wir erinnern uns an die secure computing plattform maxime „secure by default„), aber auch deutlich unkomfortabel. Vor allem in Netzwerken mit bisher eher laxen Sicherheitsvorkehrungen schürt man damit dem Cloud-Unmut. Selbstverständlich lässt Micosoft auch keine Änderung an diesen Vorgaben via GUI zu.

Kennwörter niemals ablaufen lassen

  1. Herunterladen und installieren der Office 365-Cmdlets (und der connect-Tools, falls notwendig)
  2. Powershell starten, Module importieren, verbinden und Kennwörter nicht ablaufen lassen:
import-module MSOnline
Connect-MsolService
Get-MsolUser | Set-MsolUser -PasswordNeverExpires $True

Herausfinden, ob ein Kennwort so eingerichtet ist, dass es nie abläuft

Get-MSOLUser -UserPrincipalName <user ID> | Select PasswordNeverExpires

Oder gleich für alle Benutzer anzeigen:

Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires

Ein Kennwort so einrichten, dass es abläuft

Set-MsolUser -UserPrincipalName -PasswordNeverExpires $false

Oder gleich für alle
Um die Kennwörter aller Benutzer in einem Unternehmen so festzulegen, dass sie ablaufen, führen Sie folgendes Cmdlet aus:

Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $false

Exchange 2010 bestehendes (nicht selbstsigniertes) Zertifikat verlängern

Veröffentlicht am von — 4 Kommentare ↓

Die Verlängerung eines bestehenden öffentlichen Zertifikates unter Exchange 2010 (SP2) ist ohne Änderung des Privaten Schlüssels interessanter als gedacht. Das Erstellen einer neuen Zertifikatsanforderung oder einer Verlängerungsanforderung ist in der EMC kein Problem (Serverkonfiguration -> oben Server auswählen -> unten rechte MT auf das ablaufende Zertifikate und ‚erneuern‘ auswählen), aber was tun wenn man schon ein Zertifikat besitzt, das die Zertifizierungsstelle direkt verlängert? Diese liefert das Zertifikat in der Regel als DER (respektive PEM) aus und man muss dieses „nur“ noch in den Exchange importieren.

Exchange den Request nach dem „Abschließen der Anforderung“ immer noch als solchen an und lässt es auch nicht zu, diesem Zertifikate zuzuordnen, weil der Private Schlüssel fehlt:

Was man in der MMC -> Snap-In hinzufügen -> Zertifikate -> Lokales Computerkonto auch sehen kann:

Die EMC scheint an dieser Stelle ihre eigenen Voraussetzungen für eine erfolgreiche Zertifikatsverlängerung eines bestehenden Zertifikates ohne Änderungen nicht zu erfüllen. Di zugehörigen Anleitungen und TechNet Artikel verweisen immer auf „New-ExchangeCertificate“, das aber einen neuen Request oder gleich ein selbstsigniertes Zertifikat erstellen möchte. Exchange 2010 bestehendes (nicht selbstsigniertes) Zertifikat verlängern weiterlesen→

Windows LiveMail – Updatefehler (Adminrechte für das Update/ Deinstallation)

Veröffentlicht am von — Keine Kommentare ↓

LiveMail erzeugt manchmla Fehler, das nicht ausreichend Rechte für das Update oder die Deinstallation vorhanden wären

Lösung:

Nach der Neuinstallation sollte der Postfachinhalt und alle Kontoeinstellungenwieder zur Verfügung stehen, denn das LiveMail-Profil und der Anwendungsdatenordner (%APPDATA%…..) wird normalerweise nicht entfernt.

Exchange 2007/2010 „INSUFF_ACCESS_RIGHTS“

Veröffentlicht am von — 7 Kommentare ↓

Beim Verschieben eines Postfaches unter Exchange 2007/2010 oder beim Delegieren eines „Senden-als“ Rechtes in der Management Console (EMC) kann es vorkommen das eine Fehlermeldung wie diese auftaucht:

Fehler:
Fehler bei Active Directory-Vorgang mit dc.foo.ba. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus.
Active Directory-Antwort: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
. Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte.

Wie der Fehler sagt, gibt es nicht die passenden Rechte. Andrs als man im ersten Moment vermuten mag, liegen die Send-As Rechte und deren Kollegen immer noch im ACE (Access Control Entry) im ActiveDirectory. In der Regel hat ein Domänen-Admin diese Rechte auch; manches mal hat das Objekt diese aber nicht (mehr) geerbt.

Lösung: Erben der Rechte im Objekt wieder einschalten.

Active Directory und Benutzer (mit erweiterten Eigenschaften) -> Benutzer suchen -> Rechtsklick auf Eigenschaften -> Tab „Sicherheit“ -> „Erweitert“ -> „Vererbbare Berechtigungen des übergeordneten Objektes einschließen“ einschalten. Fertig.

Ab jetzt klappts auch wieder mit delegierten Rechten und dergleichen.