Autor: Nico Dorn

Sonicwall TZ600 / TZ350 / TZ100 / NSA250 / NSA2650

Start – Konfiguration

Im Default haben die meisten Sonicwall auf X0 192.168.168.168 als IP hinterlegt.

Einige Sonic’s haben eine „MGMT“-Netzwerk-Schnittstelle, die auf 192.168.1.254 eingerichtet ist.

Zum Einrichten empfehle ich die „MGMT“-Schnittstelle und vergebe entsprechend der Vorgaben eine passende IP auf meinem PC (z.B. 192.168.1.100)

Danach kann man im Prinzip mit dem Assistenzen die Sonic vorkonfigurieren lassen. Ich empfehle dies auch zu tun und das Regelwerk und alle Einstellungen manuell neu zu setzten. Das Importieren von Konfigurationen von Vorgängermodellen ist nicht immer Zielführend und kann Probleme verursachen, die man sich nicht erklären kann!

Die Default Zugangsdaten sind:

User: admin
Password: password

SafeMode

Wer eine Sonic über ein Upgrade erworben hat, wo die alte Sonic auch im Account durch die neue ersetzt wird, der hat das Problem, dass er die Lizenzen aktivieren muss und die Restlaufzeit der alten Sonic mit auf die neue übertragen wird. Hierbei fällt der lizenzierte Schutz der alten Sonic weg und sollte man Probleme mit der neuen Konfiguration und der neuen Sonic haben, dann kann man zwar die alte Sonic wieder hernehmen, aber die lizenzierten Services wie Gateway Antivirus etc. laufen dann nicht mehr.

Sprich die Firewall macht nur nach NAT und Firewallregelwerk.

Man kann beim Upgrade zwar auch sagen jetzt noch nicht die Lizenzen übertragen, hat aber eine zeitliche Frist in dem die Lizenzen übertragen werden müssen, bzw. automatisch übertragen werden.

Daher rate ich dazu die neue Firewall in aller Ruhe einzurichten und das mit neuster Firmware beginnend. Wenn jedoch die Sonic noch nicht registriert wurde, kann man auch im Default keine andere Firmware installieren.

Um dies bewerkstelligt zu bekommen, muss die Sonic im SafeMode starten. Hierbei pickst man mit einer aufgebogenen Büroklammer in das Reset-Loch für ca. 20 Sekunden. Die Sonic startet neu und der SafeMode  ist aktiviert. Die LED neben dem Schraubenschlüssel leuchtet gelb. Jetzt kann man sich (nur) über die „MGMT“-Schnittstelle auf die Sonic verbinden und sieht eine andere Übersicht als sonst. Hier ist es aber möglich die neuste Firmware einzuspielen.

QNAP – keinen Zugriff auf netlogon / sysvol vom Netzwerk aus

Kein Zugriff auf netlogon

Nachdem ein Qnap als DC eingerichtet wurde und die Clients sich mit der Domain verbinden können, habe ich festgestellt, dass die Clients unter Windows 10 nicht auf netlogon kommen.

Die Berichtigungen auf der Qnap waren alle korrekt und auch die Zugangsdaten waren zweifellos richtig.

Es erscheint ständig die Zugangsabfrage und die Anmeldungen schlagen immer fehl.

Lösung:

Auf dem Client der der Domain angehört muss über gpedit.msc die gehärteten UNC-Pfade aktiviert werden.

    • CMD als Admin öffnen
    • gpedit.msc eingeben und mit Enter bestätigen
    • zu „Computer –> Administrative Vorlagen –> Netzwerk –> Netzwerkanbieter –> Gehärtete UNC-Pfade“ wechseln und aktivieren und im linken Bereich auf den Button „Anzeigen“ klicken
    • Im Feld „Wertname“ muss der DC als Computername oder iP-Eingetragen eingetragen werden (\\meinDCServer oder \\192.168.1.100)
    • Im Feld „Wert“ wird folgenden eingegeben:
      RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
    • Alles bestätigen und gpedit beenden

Diese Lösung funktioniert auch mit Clients die nicht der Domain angehören, aber dennoch Zugriff auf das Domain-Netzwerk haben.

Office 365 – Azur AD Sync/ Azure ADConnect

Azure AD Connect einrichten

Vorwort

Ich dachte erst AD Connect funktioniert nur, wenn man in seiner lokalen Domain auch einen echten Domainnamen verwendet, aber hier wurde ich damals seitens der Telekom wohl falsch informiert.

Heute nehme ich an (ohne es nochmal getestet zu haben), dass man auch eine lokale AD, die sich zum Beispiel test.local nennt, nach Office 365 synchronisieren kann. In diesem Fall sollten die User in der Cloud nur als Loginname und xxx.onmicrosoft.com enden.

Hat man bereits eine Domain in Office 365 hinterlegt, so kann man in der lokalen AD beim User unter „userPrincipalName“ die echte E-Mail-Adresse eingeben und der User wird dann auch mit dieser Einstellung in der Cloud aufgelistet.

Die Synchronisierung ist zeit gesteuert und erfolgt aus meiner Sicht nicht immer in einem festen Rhythmus. So kann eine lokale AD-Änderung einige Zeit benötigen, bis diese in der Cloud zu erkennen ist.

Anleitung

Azure AD Sync bzw . AD Connect ist hilfreich, wenn man eine eigene lokale Domain pflegt und die User von dort in Office 365 anlegen möchte.

Hierfür muss „AD Connect“ auf dem lokalen AD installiert und eingerichtet werden.

Bevor man damit beginnt, empfehle ich eine Gruppe namens „ADSyncOfficeUsers“ anzulegen und in diese Gruppe nur die User hinzuzufügen, welche mit Office 365 synchronisiert werden sollen.

Beim installieren von „AD Connect“ würde ich NIE die Express-Einstellungen verwenden! Wer das macht, synchronisiert seine ganze Lokale Domain mit allen Benutzern, Gruppen und Geräten nach Office 365 und das wäre mir zu viel.

Beim Einrichten muss man den Dialogen folgen und seine Domain (Verzeichnis) hinzufügen. Danach wählt man aus was synchronisiert werden soll, hier habe ich mich bewusst nur für „Users“ entschieden und im nächsten Schritt auch auf die oben angelegte neue Gruppe den Filter beschränkt. So werden nur die User mit Office 365 synchronisiert, welche auch in dieser Gruppe aufgeführt werden.

Beim Einstellen kann man festlegen wie sich Authentifiziert werden soll, hier habe ich nur die Kennworthash-Funktion aktiviert. Hierbei wird das Passwort des Users verschlüsselt an Office 365 übergeben. Meldet sich nun jemand an Office 365 an, dann wird nur der verschlüsselte Teil verglichen. Es erfolgt kein echtes Anmelden an die lokale Domain. Wer das möchte kann dies aber auch so einrichten, aber so muss ständig bei jeder Anmeldung die lokale Domain bzw. die Anmelde-Prozesse von extern erreichbar sein.

ACHTUNG:

Das Kennwort-/Gruppen-Rückschreiben funktioniert nur, wenn man die passende Azure P1 oder P2 Lizenz für jeden User wo das möglich sein soll hat.

Sobald das Setup erfolgreich zu Ende gebracht wurde, werden in Office 365 alle User aus der Gruppe „ADSyncOfficeUsers“ aufgelistet und haben das Kennwort aus der lokalen Domain. Man kann das Kennwort in Office 365 ändern, aber es wird immer wieder mit dem Kennwort aus der lokalen AD überschrieben.

Ordnet man lokale Gruppen zur neue Gruppe „ADSyncOfficeUsers“ hinzu, so werden auch diese Gruppen als „E-Mail aktivierte Sicherheitsgruppe“ in der Cloud angelegt. Die Gruppe kann aber nur über die lokale AD bearbeitet werden.

Nachdem die User in der Cloud angelegt wurden, weißt man diesen noch die passenden Lizenzen zu und der User kann mit Office 365 anfangen zu arbeiten.

Umfasst die zugewiesene Lizenz auch Exchange Online, so wird auch gleich ein E-Mail-Postfach eingerichtet.

Normalerweise soll man so erstellte Users in Office 365 nicht löschen können, aber irgendwie klappte das bei mir dennoch.

Richtig wäre wohl der Weg, den User aus der lokalen Gruppe „ADSyncOfficeUsers“ zu entfernen. Der User wird auf der Seite von Office 365 gelöscht und ist für 30 Tage dort noch zu finden. Den User kann man nun in Office 365 wiederherstellen und schon ist der User nur noch in der Cloud.

Verhalten

Synchronisiert man aus der lokalen AD die User zu Office 365, so werden bestimmte Merkmale dort übergeben und überschrieben. Werden diese Merkmale in Office 365 geändert, so können diese Merkmale beim nächsten Durchlauf durch die Einstellungen der lokalen AD überschreiben werden.

z.B. Ein User wird in der lokalen AD gesperrt -> in Office 365 wird dieser nun ebenso für den Login gesperrt. Ändert man dieses Einstellung in Office 365, so hält diese Einstellung nicht lange an und wird von der lokalen AD wieder als gesperrt Überschrieben.

Im Default wird der „userPrincipalName“ vom lokalen AD zur Cloud synchronisiert. Dieser Eintrag enthält in der Regel die E-Mail-Adresse zusammengesetzt aus dem User- und  lokalen Domainnamen. Dieser Name wird, wenn diese Domain in Office 365 bereits hinzugefügt wurde, als Loginname für die Cloud verwendet. Existiert diese Domain aber nicht, so wird nur der Benutzername + des Tenant-Domainnamen xxx.onmicrosoft.com verwendet.

Erweiterte Einrichtungen

Da User-Eigenschaften über AD Connect aus der lokalen Domain stammen, kann man bestimmte Eigenschaften zum User in der Cloud nicht ändern. Man muss diese Änderungen in der lokalen Domain umsetzen und diese werden dann zur Cloud synchronisiert.

Aliases Einrichten

In lokaler Domain in den User-Eigenschaften über Attribut-Editor das Attribut „proxyAdresses“ aufrufen und durch „smpt:[zusätzlicherAliases]@meineDomain.de“ erweitern.

Office 365 – Das Erstellen von Gruppen für Mitglieder einschränken

Das Erstellen von Gruppen für Mitglieder einschränken

Mitunter kann es sinnvoll sein, dass wirklich nur der Admin des Tenantes oder nur bestimmte Benutzer neue Gruppen wie für Teams, Planer oder SharePoint einrichten dürfen.

Hierfür erstellt man eine Gruppe „Groups Creators“ und über ein kleines PowerShell-Script wird allen normalen Mitgliedern nun das GroupCreators-Recht entzogen und nur für die neu erstellte Gruppe und Globalen-Admins erlaubt.

Wer das testen möchte, kann sich danach mit einem normalen Benutzer anmelden und wird unter „Planer“ diesen Hinweis sehen:

Quelle:

https://docs.microsoft.com/de-de/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide

Office 365 – Einrichten – Teams

Leider können wir Sie nicht anmelden.

AADSTS7000112: Application ‚5e3ce6c0-xxxx-xxxx-8d4b-75ee78xxxx'(Microsoft Teams Web Client) is disabled.

Lösung:

Die Teams Web Client Anmeldung ist vermutlich deaktiviert.

Über das Microsoft 365 Admin Center navigiert man zu Azure Active Directory und dort zu Unternehmensanwendungen.

Nun Filtert man die Anwendungen nach „Microsoft-Anwendungen“ und dem Status „Deaktiviert“. In der Liste sollte nun „Microsoft Teams Web Client“ erscheinen. Darauf klicken und folgende Einstellungen vornehmen:

  • Unter Verwalten -> Eigenschaften -> „Aktiviert für die Benutzeranmeldung“ auf „JA“ stellen und das ganze Speichern.

Danach klappt auch die Anmeldung

 

Office 365 – Einrichten (nur für Admins)

Hier entsteht erstmal nur ein grober Leitfaden zur Einrichtung.

    • mit globalen Admin-Konto (*.onmicrosoft.com) anmelden
    • eine vorhandene Domain einrichten/ Hinzufügen, über dessen dann z.B. Mails versendet werden können. Theoretisch kann man aber auch die Domain-Adresse seines Tenants zum Mailen nutzen, aber wer auf Coperate Identity wert legt, nutzt seine eigene Domain.
    • Self-Service-Passwort-Reset einrichten und neue Benutzer auffordern sich dafür zu registrieren.
      Einrichtung erfolgt über „Azure Active Directory Admin Center“
      Die Code-Eingaben zur Verifizierung müssen recht schnell erfolgen, da sonst der Code abläuft und der Prozess wiederholt werden muss.
      In jedem Fall sollte dies für den Admin eingerichtet werden.
      Ich empfehle eine Sicherheitsgruppe „SSPR-Group“ anzulegen und alle die dann in dieser Gruppe sind, müssen sich für diesen Service Zwangs-registrieren, sobald Sie sich das erste mal anmelden wollen.
      SSPR macht nur Sinn, wenn man die Benutzerpflege direkt am Tenat durchführt. Nutzt man AD Connect zum synchronisieren seiner lokalen Domain-User und hat keinen passenden Azure AD Premium P1 oder P2 Plan, dann funktioniert das mit den SSPR nicht.
    • Zwei-Faktoren-Authentifizierung einrichten z.B. mit Handynummer oder Authenticator-App.
      Kann sein dass es erst später einzurichten geht, wenn Benutzer angelegt wurden.
      https://docs.microsoft.com/de-de/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide
    • Unter „Office 365 Security & Compliance“ Sicherheits-, Aufbewahrungsregeln für das Mailing etc festlegen.
      „Bedrohungsmanagement“ -> DKIM,
    • Bei Bedarf Azur AD Sync einrichten. Hierbei werden die Benutzer und Passwörter aus einer vorhandenen lokalen Domain synchronisiert. Auf Server-Seite müssen entsprechende Ports und Programme installiert werden, damit die Kommunikation mit der Cloud funktionieren kann.
      Alternativ kann man auch eigene Benutzer getrennt von der Domain anlegen und Verwalten. Aber ein späterer Wechsel zu Azur AD Sync ist schwierig bis nicht möglich.
      Wichtig: Wenn Mailpostfächer aus alten Exchange-Servern migriert werden müssen, dürfen für die zu migrierenden Benutzer/ Postfächer noch keine Benutzerkonten angelegt sein!
    • Das Erstellen von Gruppen für alle Mitglieder einschränken
      https://docs.microsoft.com/de-de/microsoft-365/solutions/manage-creation-of-groups?view=o365-worldwide
    • Wenn alle Benutzer angelegt oder aus der lokalen AD synchronisiert worden sind, dann kann die Sprache und Zeitzone der User via PowerShell zentral eingerichtet werde. Macht man dies nicht und loggt sich der User nicht/ nie in OWA ein, so werden in Outlook die Ordner mit englischer Bezeichnung (Inbox, Trash etc.) angezeigt. Dies kann zu Problemen führen, wenn man aus alten Beständen Mails in Outlook importieren muss.
$cred = Get-Credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential

$cred -Authentication Basic -AllowRedirection Import-PSSession $session

Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Get-MailboxRegionalConfiguration

Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"} | Set-MailboxRegionalConfiguration -Language "de-DE" -DateFormat "dd.MM.yyyy" -TimeFormat "HH:mm" -TimeZone "W. Europe Standard Time" -LocalizeDefaultFolderName
    • dfsadfsdaaf

 

Einstellungs-App über CommandLine öffnen

Windows Version

Windows 10, Windows Server 2016, Windows Server 2019

Befehle mit Win+R

Win+R öffnet das „Ausführen“-Fenster und in diesem können gezielte Befehle eingesetzt werden.

Einstellungs-App

  • ms-settings:start
  • ms-settings:network
  • ms-settings:windowsupdate

Explorer

  • control /name Microsoft.FolderOptions

Befehle über CommandLine

Öffnet die cmd.exe und gebt dort die Befehle ein.

  • ipconfig
  • ipconfig /flushdns

Windows Registry Ändern, Verwalten, Löschen

Hinweis

Durch das eigene Editieren der Registry könnt Ihr Euer Windows komplett zerschießen! Macht nur etwas wovon Ihr was versteht oder Testet auf einer virtuellen Maschine und setzt Euch vorher einen Prüfpunkt.

Reg-Einträge hinzufügen

Durch das Erstellen einer *.reg-Datei z.B. mit dem Editor kann man die Registry von Windows verwalten.

Erstellt Euch hierzu z.B. mit dem Editor eine „TestReg.txt“ und schreibt in dieser folgenden Code rein:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\_meine Test Software]
"Testeintrag"="de-DE,de;q=0.5"
"TestdWord"=dword:00000000

Wenn Ihr diese Datei speichert und als „TestReg.reg“ umbenennt, dann könnt Ihr diese Datei mit einem Doppelklick ausführen lassen.

Windows erstellt nun in der Registry (regedit.exe) einen Schlüssel (Ordner) unterhalb von „HKEY_CURRENT_USER\SOFTWARE“. In diesem Schlüssel (Ordner) befinden sich nun zwei Einträge.

Reg-Einträge ändern

Wenn Ihr nun via Reg-Datei einen bestimmten Wert für einen Eintrag setzen wollt, dann muss man nur diesen z.B. bei „Testeintrag“ abändern.
Oder Ihr ändert den DWord-Wert von 0 auf 1

Ändert Eure Reg-Datei wie folgt und schaut Euch das Ergebnis in der Registry an:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\_meine Test Software]
"Testeintrag"="mein geänderter Wert"
"TestdWord"=dword:00000001

Reg-Eintrag löschen

Eintrag in einem Reg-Schlüssel löschen

Wollt Ihr von einem Schlüssel einen bestimmten Wert löschen, dann muss als Wert für diesen Eintrag ein „-“ eingesetzt werden. Hierbei ist es egal ab der Eintrag eine Zeichenkette oder DWord oder so ist.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\_meine Test Software]
"Testeintrag"="mein geänderter Wert"
"TestdWord"=-

Kompletten Reg-Schlüssel löschen

Soll ein kompletter Schlüssel mit all seinen Einträgen gelscht werden, dann muss vor dem zu löschenden Schlüssel ein „-“ vorangestellt werden.

Probiert es aus und ändert wieder Eure Reg-Datei wie folgt:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\SOFTWARE\_meine Test Software]

Hinweis

Durch das eigene Editieren der Registry könnt Ihr Euer Windows komplett zerschießen! Macht nur etwas wovon Ihr was versteht oder Testet auf einer virtuellen Maschine und setzt Euch vorher einen Prüfpunkt.

Hyper-V startet virtuelle Maschine nicht – Fehlercode: 32788

Problem

Fehler beim Versuch, die ausgewählten virtuellen Computer zu starten. Der Status von „xxx“ konnte nicht geändert werden.

Fehler beim Vorgang. Fehlercode: „32788“.

Lösung

  • prüft den RAM des Hyper-V-Host
  • schaut in der Konfiguration des virtuellen Computers auf dessen Netzwerkkonfiguration

    Ursache

Ich denke ich hatte mal den virtuellen Computer von einer anderen Maschine Importiert und auf der neuen Maschine gab es den damals angelegten virtuellen Switch nicht.

Windows Server Sicherung – schwerer Aufnahmefehler in „wbadmin.msc“

Problem

Die App/Dienst „Windows Server Sicherung“ konnte nicht mehr gestartet werden und es wurde ein schwerer Aufnahmefehler in „wbadmin.msc“ angezeigt.

Im Ereignisprotokoll standen mehrere Einträge mit Fehler in Quelle VSS und den Ereignis-ID’s 13, 12292 und 8228

Volumenschattenkopie-Dienst-Informationen: Der COM-Server mit CLSID {463948d2-035d-4d1d-9bfc-473fece07dab} und dem Namen "HWPRV" kann nicht gestartet werden. [0x8000401a, Der Serverprozess konnte nicht gestartet werden, da die konfigurierte Identität falsch ist. Überprüfen Sie Benutzernamen und Kennwort.

Mein Problem tratt nach einem Upgrade von Windows Server 2016 auf Windows Server 2019 auf.

Analyse

Bekannte DISM-Befehle haben nichts ungewöhliches gemeldet und auch nichts bewirkt/ repariert.

# Komponentenspeicher untersuchen mit DISM
dism.exe /online /Cleanup-Image /AnalyzeComponentStore

# Komponentenspeicher bereinigen
dism.exe /online /Cleanup-Image /StartComponentCleanup

# Analyse und Reparatur
dism /Online /Cleanup-Image /ScanHealth
dism /Online /Cleanup-Image /CheckHealth
dism /Online /Cleanup-Image /RestoreHealth
dism /Online /Cleanup-Image /RestoreHealth /Source:WIM:X:\Sources\Install.wim:1 /LimitAccess

Eine Lösung lag nicht auf der Hand und ich habe lange gerätselt.

Lösung

Nahe liegend war die Lösung nicht wirklich, aber es klappt mit dem zurücksetzen des Sicherheitskatalogs.

Öffnet CMD als Admin und gebt den nachfolgenden Befehl ein und bestätigt die Frage mit „Ja“. Es wird der aktuelle Sicherungskatalog gelöscht und ein neuer Sicherungssatz angelegt. Danach öffnet sich bei mir die App „Windows Server Sicherung“ (wbadmin.msc) wieder und ich konnte ein manuelles Backup erstellen.