Sind E-Mails von „[email protected]“ Spam oder Betrug?

„Aus gegebenem Anlass“ dieser Artikel zu E-Mails. Viele Admins bekommen von Ihren Anwenderchen schon mal anfragen, ob eine Mail „echt“ sei. Grundsätzliche finden wir das gut, denn besser einmal zu viel gefragt als einmal zu viel geklickt 👍

Da kommen plötzlich E-Mails zu einer „Domainvalidierung“ von der Domain „domainvalidierung.de“:

Von: Domainvalidierung <[email protected]>
Betreff: Domain-Inhaber Validierung / Contact Validation

Die Mail sieht in etwa so aus:

(for the english version please see below)

Sehr geehrte NAME,

aufgrund der Richtlinien der Internet-Verwaltungsorganisation ICANN sind wir verpflichtet, die Korrektheit der Inhaber-Kontakten bei der Registrierungen von Domains unter allen generischen Domain-Endungen zu überprüfen und Ihre E-Mail-Adresse als Domain-Inhaber zu validieren.

Wir möchten Sie daher bitten, mit Aufruf des folgenden Links die Korrektheit Ihrer Kontakt-E-Mail-Adresse zu bestätigen:
https://www.domainvalidierung.de/0123123123132abc12312313/

In Ihrem Fall erfolgt diese Validierung unter anderem für die folgende
Domain: EXAMPLE.com

Sofern Sie noch weitere Domains mit einer generischen Endung auf dieselbe Inhaber-E-Mail-Adresse bestellt haben, so werden diese durch die Bestätigung des oben aufgeführten Links ebenfalls automatisch validiert.

Wichtiger Hinweis: Wenn Sie Ihre E-Mail-Adresse nicht bis zum
DATUM bestätigen, werden gemäß den ICANN-Richtlinien alle neuen Domain-Registrierungen, die diese E-Mail-Adresse als Inhaber-Kontakt verwenden, bis zur Bestätigung der E-Mail-Adresse diskonnektiert.
Solche Domains bleiben dann zwar registriert, sind jedoch technisch nicht mehr erreichbar. Eine Rekonnektierung ist dann jederzeit über den Aufruf des o.g. Links möglich. Eine Angabe Ihrer Kundendaten oder sonstiger persönlicher Informationen ist für die Validierung nicht erforderlich.

(...)

Lösung

Diese Mail kommt tatsächlich von der Domain-Verwaltungsorganisation ICANN. Sofern die DKIM/SPF-Angaben im Header natürlich fehlerfrei sind. Den Anweisungen also bitte folgen!

Seit 2014 etwa achtet die Organisation genauer auf die Einhaltung der Richtlinien für generische Domainendungen (com/net/org/info …). Dazu werden regelmäßig einmal im Jahr diese Bestätigungsmails verschickt.

Das Fehlen einer erreichbaren Emailadresse kann Probleme mit sich bringen. Der Domaininhaber verstößt mit einer nicht erreichbaren Emailadresse nämlich gegen die Vergaberichtlinien der Domainvergabestellen. Diese erfordern „stets aktuelle Inhaberdaten“.

tldr; ist echt, bitte klicken.

PowerShell: Seriennummer („BiosSeralNumber“) als Windows Computernamen übernehmen

„Aus gegebenem Anlass“ schon wieder ein PowerShell Script. Mit leichtem Schmunzeln, denn die Zeit der Tippfehler ist in der IT noch nicht vorbei 😉

„Seral“ ohne „i“ (hier mit wenig hilfreichem Inhalt)

Ein Kunde möchte die Seriennummer seiner neuen Computer als Windows-Computernamen im AD verwendet wissen. Während einer „normalen“ Installation oder auch einer Cloud-Installation (ohne Autopilot) wird der Computername abgefragt, aber niemand kennt seine Seriennummer – und Menschen tendieren gerne mal zu äußerst seltsamen Namen. Daher führt der einfachste Weg zu Lösung über ein Script das die Namensvergabe automatisch nachträglich erledigt.

Das funktioniert nur richtig, wenn die Computer eine Seriennummer imn BIOS (EFI) hinterlegt haben. Ist das Feld leer, gibt Windows „To Be Filled by O.E.M.“ zurück und das Script setzt eine 10-Stellige Zufallszahl ein.

In diesem Fall soll(t)en alle Computer „CMP-<Serial>“ heissen und es gibt nur Clients von HP und Lenovo (mit gefülltem Serial-Feld). Selbige nutzen allerdings unterschiedlich lange Seriennummer, daher kürzen wir diese ein.

Lösung

Hier ist das kommentierte Script. Via Intune oder GPO ausgeführt bekommt so jeder PC nach dem nächsten Start seinen einmaligen Namen.

# Prefix festlegen
# - Achtung, der "Computername" hat maximal 15 Zeichen.
 $prefix = "CMP-"

# Serial holen
# - Achtung, KEIN Tippfehler, die Property heisst "BiosSeralNumber"
 $serial = Get-ComputerInfo | Select-Object BiosSeralNumber
 $serial = $serial.BiosSeralNumber

# Kürzen (auf die ersten 10 Stellen)
 $serial = $serial.substring(0, 10)

# leerzeichen entfernen
 $serial = $serial.replace(' ','')

# Wenn leer, Warnung ausgeben und Random-Nummer verwenden
 if ($serial -like "*ToBeFill*") {
   $serial = Get-Random -Minimum 100000000 -Maximum 9999999999
   Write-Warning "No Serial found, using Random Number '$serial' instead."

 }

# Namen zusammenbauen (und anzeigen)
 $computername = $prefix + $serial
 Write-Host Henceforth you shall be known as: $computername

# Computer umbenennen
 Rename-Computer -NewName $computername -Force -ErrorAction SilentlyContinue

Bilder an der PowerShell mit Guetzli komprimieren (rekursiv)

Mit der Kompression von JPGs mit dem Guetzli-Algorithmus spart man ganz ordentlich Platz auf der Platte, ohne Qualität zu verlieren.

Je nach Bild (und Quelle) sind gut und gerne 30-60% Ersparniss drin. Manche (Handy-)Kamera legt JPGs nämlich quasi unkomprimiert ab.

Ein kleines Bulk-Kompress-Script für die bash shell hatten wir hier ja schon. Aus aktuellem Anlass, hier die schnelle PowerShell-Variante (ohne Parameterfehler):

mach-huetzli.ps1 <Ordner>

param (
    [string]$path = (split-path -parent $MyInvocation.MyCommand.Definition)
)

# PFAD zum Guetzli Binary
$guetzli = "C:\PFAD ZU GUETZLI\guetzli_windows_x86-64.exe"

Get-ChildItem -Path $path -recurse -Include @("*.png","*.jpeg","*.jpg") | % {
    $in = $_.FullName
    $out = $in.Replace($_.Extension, '.compressed.jpg')
    write-host "Processing $out" -ForegroundColor Green

    & $guetzli --quality 85 `"$in`" `"$out`"
} 

PowerShell: Computer nach Betriebssystem aus dem Active Directory auflisten

Server nach Betriebssystem auflisten

Und wieder ein schneller PowerShell Schnipsel, den man als Admin häufiger mal brauchen kann.

Alle aktiven Computer nach Betriebssystem auflisten, oder auch nur alle Maschienen mit einer bestimmten Version ausgeben:

Get-ADComputer -Filter 'operatingsystem -like "Windows Server 2022*" -and enabled -eq "true"' -Properties Name,Operatingsystem,OperatingSystemVersion,IPv4Addres
s | ft Na*,Op*,IPv4*

Die ft Pipe am Ende sorgt nur für eine lesbare Ausgabe, weil Get-ADComputer sonst immer den vollständigen DN ausgibt.

Die Abfrage kann man so sehr schnell anpassen. Zum Beispiel für eine Ausgaben von ausschliesslich Client-PCs (-notlike "*server*"):

Get-ADComputer -Filter 'operatingsystem -notlike "*server*" -and enabled -eq "true"' -Properties Name,Operatingsystem,OperatingSystemVersion,IPv4Addres
s | ft Na*,Op*,IPv4*

PIN zurücksetzen Fehler“CAA2000B“ auf AzureAD „registered“ Geräten nach Office 365 Installation

Man registriert sein Windows-Gerät, auch den Home-PC, automatisch ins Microsot 365 AzureAD eines Unternehmens, indem man nach einer Office 365 Installation den Haken bei „Verwaltung meines Gerätes durch meine Organisation zulassen“ nicht entfernt. Alternativ kann man auch links unten auf den „unsichtbaren“ Button „Nein, nur bei dieser App anmelden“ klicken.

Wenn man sein Gerät registiert hat taucht es auch nach wenigen Cloudmomenten im AzureAD Device Manager auf:

Und bekommt von dort einige Richtlinien. Vor allem die Sicherheitsrichtlinien greifen dann auf dem Gerät – machmal ist das bei „Privat-PCs“ etwas überraschend.

Fehler CAA2000B (AADSTS500014)

Standardmäßig tritt beim zurücksetzen der Windows-Hello PIN auf dem PC nach dem Azure AD Registrierungsvorgang dieser Fehler auf:

Es ist ein Problem aufgetreten

wir konnten sie nicht anmelden. Falls dieser Fehler weiterhin besteht, wenden Sie sich an den Systemadministrator, und geben Sie den Fehlercode an: CAA2000B.

Das liegt daran, das der Administrator die „App“ die die Zugangs-PIN ändern will erst zu „seinem“ Azure AD hinzufügen und bestötigen muss.

Lösung

1. Die PIN-Reset Web-App „Service“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent

2. Die PIN-Reset Web-App „Client“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:

https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent

2. Im folgenden Assistenten in BEIDEN Fällen die App „Microsoft Pin Reset Service Production“ (Client und Service) bestätigen:

„Microsoft PIN Reste Service Production“ für Windows Hello erlauben

Ob das geklappt hat kann man danach sofort im Microsoft Entra Admin Center überprüfen:

  1. Ins AzureAD einloggen via https://entra.microsoft.com/
  2. Azure Active Directory > Anwendungen > Unternehmensanwendungen > Alle Anwendungen > „PIN“ suchen

Es sollten dort nun zwei Apps auftauchen:

Und schon (nach dem nächsten Neustart mit Internet) funktioniert das PIN-Ändern wieder wie vorher.

Wenn der Vorgang trotzdem noch fehlschlägt, hilft oft ein Blick in das Cloud App Security Dashboard für Anwendungen; möglicherweise hat hier anderer Admin das OAUTH dieser Apps vielleicht blockiert …