Welcher Administrator kennt das Problem nicht – bei Feiertagen oder Ferien sollen für alle Mitarbeiter passende Abwesenheitsmeldungen erstellt werden.
Mit einem Exchange Server funktioniert das mehr oder weniger; Was aber wenn der Kunde oder das Unternehmen G Suite (vormals Google Apps for Work…) einsetzt?
Für einzelne Accounts kann diese Abwesenheitsnotiz zwar manuell gesetzt werden – sobald es aber mehr als 5 sind wird es mühsam.
Die Lösung für das Problem – der Google Apps Manager (kurz GAM).
Damit erhält der Administrator praktisch vollen Zugriff auf sämtliche administrativen Tätigkeiten von G Suite – zusammengefasst in einer handlichen Konsole.
Google Apps Manager / GAM installieren
Zuerst einmal muss die aktuellste Version von GAM heruntergeladen werden:
Die Installation anschliessend braucht etwas Zeit, da diverse Zugriffsberechtigungen gesetzt und aktualisiert werden müssen. Sämtliche nötigen Schritte sind aber sehr detailliert im Installationsprozess erklärt.
Abwesenheitsnotiz für Alle oder einzelne Benutzer setzen
Eine Übersicht über die verschiedenen Befehle von GAM findet man auch hier.
Für eine Abwesenheitsmeldung für sämtliche Benutzer kann man folgenden Befehl nutzen:
gam all users vacation on subject "Abwesenheit" message "Wir sind vom xxx bis xxx abwesend. In Notfällen erreichen Sie uns unter xxx"
Für einen einzelnen Benutzer kann die Abwesenheitsmeldung wie folgt gesetzt werden:
gam user [email protected] vacation on subject "Abwesenheit" message "Wir sind vom xxx bis xxx abwesend. In Notfällen erreichen Sie uns unter xxx"
Mit folgendem Befehl kann anschliessend überprüft werden, ob ein die Abwesenheitsmeldung für einen bestimmten Benutzer aktiv ist:
Windows 10 kennt neben Lokalen und Domänenbenutzern eine dritte Kontoart. Dabei wird ein Microsoftkonto zur Authentifzierung verwendet. Wie man dieses in einen lokalen Account umwandelt – in diesem Artikel.
Wieso umwandeln?
Zugegeben – die Idee mit dem Microsoftaccount ist interessant. Hat man mehrere Geräte (z.B. Notebook, PC) wird damit nur ein Account benötigt, wichtige Dateien und Einstellungen werden über „die Cloud“ synchronisiert.
Leider ist das in der Praxis nicht immer die beste Lösung. Insbesondere wenn das Gerät ohne Internet verwendet wird, kommt man mit einem Microsoftaccount schnell an seine Grenzen.
Auch das Handling ist mit einem Lokalen oder Domänenaccount meistens flexibler und einfacher.
Probleme beim Zurücksetzen mit einem Microsoftaccount
Hat man bei der Ersteinrichtung nur den Microsoftaccount angeben und kann sich z.B. nicht mehr ans korrekte Passwort erinnern, muss dieses über den Microsoftaccount zurückgesetzt werden.
Dabei werden einige Fragen zum Benutzer gestellt – die aber nur greifen wenn die angebenen Daten auch noch verfügbar sind. Hat man den Microsoftaccount mit „etwas Phantasie“ erstellt steht man vor einem Problem.
Mit folgendem Tipp klappt das Zurücksetzen bzw. Umwandeln in einen lokalen Account trotzdem.
Eingabeaufforderung auf Anmeldebildschirm
Ziel ist es, direkt am Anmeldeschirm auf die Eingabeaufforderung zuzugreifen. Standardmässig ist das natürlich nicht möglich.
Folgende Schritte müssen ausgeführt werden (z.B. mit Live-CD oder in Windowsreparaturmodus):
Unter C:\Windows\system32 die Datei Utilman.exe in Utilman.exe.old umbenennen.
Anschliessend die Datei cmd.exe kopieren und in Utilman.exe umbenennen.
Bei einem normalen Windowsaccount könnte man das Passwort nun direkt am Anmeldebildschirm über Klick auf Erleichterte Bedienung zurücksetzen.
Da es sich hier aber um einen cloudgebundenen Microsoftaccount handelt, wird bei einem solchen Versuch die Meldung „Vorgang kann nicht ausgeführt werden, da das angegebene Konto nicht autoritativ ist.“ erscheinen.
Daher gehen wir den Umweg über den lokalen Administratoraccount.
Dieser muss erstmal aktiviert werden:
net user administrator /active:yes
Dann können wir noch ein Passwort (1234…) vergeben:
net user administrator 1234
Anschliessend muss der Computer neugestartet werden.
Nach dem Login kann der Administrator am unteren Bildschirmrand ausgewählt und mit dem Passwort 1234 eingeloggt werden.
Ginge es nach den Mitteilungen in unseren SPAM-Ordnern, bekäme man nicht nur täglich unglaubliche Erbschaften sondern auch noch gleich die grosse Liebe frei Haus. Dass diese nicht immer ganz so einfach aufgibt und manchmal auch zur Brechstange greift zeigt folgender Artikel.
Teil 1: Liebe auf den ersten Blick
Alles Beginnt mit einem Mail das vielen bekannt vorkommen dürfte. Solche Mails erhalten wir täglich – sehen sie als offensichtlichen SPAM zum Glück aber praktisch nie.
Diese SPAM-Nachricht ist aber etwas anders; Zum einen erfolgt die Personalisierung der Nachricht nicht nur im Mail selbst (Hello…) sondern bereits in der Absenderadresse (…@bezeqint.net).
Welchen Vorteil sich der Spammer (= Evgeniya ;)) wohl davon erhofft?
Wirft man dann einen Blick in den E-Mailheader wird schnell klar, dass diese SPAM anscheinen tatsächlich über den Mailserver von Bezeqint.net (israelische Telekommunikationsgesellschaft) gesendet wurde. Der SPF-Fehler / Softfail hingegen zeigt, dass der Empfängerserver (in diesem Fall Google Apps) festgestellt hat, dass die Mailadresse beim Empfänger gar nicht existiert.
Return-Path: <[email protected]>
Received: from bzq-79-176-7-**.red.bezeqint.net (bzq-79-176-7-83.red.bezeqint.net. [79.176.7.**])
by mx.google.com with ESMTP id r2si8280383lar.102.2015.04.24.06.42.37
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) client-ip=79.176.7.**;
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) [email protected]
From: "Evgeniya" <[email protected]>
Dies hat folgende Punkte zur Folge:
Diese E-Mail wird als SPAM klassifiziert
Die Absenderdomain hat keine Konsequenzen zu befürchten (Blacklist…)
Das System funktioniert in diesem Fall fast perfekt;
Teil 2: Mit der Brechstange
Nachdem man Evgeniya in Teil 1 nicht weiter beachtet hat, geht man davon aus, dass sie sich anderweitig umgesehen hat.
Leider scheint sie aber von hartnäckiger Natur zu sein und versucht es nun anstelle von Blumen mit der Brechstange. Diverse Mitteilungen „Delivery Status Notification Failure“ (=Mail gleich unzustellbar) im Posteingang zeugen von ihrem hartnäckigen Werben…
Der Inhalt derselben ist identisch mit der ursprünglichen Nachricht – mit zwei Unterschieden:
Absender ist neu eine gefälschte Mailadresse der Domain aus Teil 1
Empfänger ist neu (=Teil der Mailadresse vor dem @)
Was hat Evgeniya versucht? Nun – nichts anderes als im Namen der ersten Mail weitere „Kunden“ anzulocken. Die Mailadresse, die dabei als Absender genutzt wird ([email protected]) exisitiert nicht und wird gefälscht (sog. Spoofing).
Es ist davon auszugehen, dass auch beim nächsten Empfänger als Absender wieder eine gefälschte Phantasieadresse des Vorgänger verwendet wird.
Das entsprechende Schema dazu dürfte bekannt vorkommen; ein typisches Schneeballsystem.
Spoofing alias Evgeniyas Way of Love…
Durch die Kombination von Spoofing und Spamming wird zwar die „Erfolgsquote“ von Evgeniya drastisch sinken, andererseits gibt es dafür keinen konkreten SPAM-Mailserver bzw. SPAM-Domain die man sperren könnte. Bei jedem Versand sind andere Domains und Mailserver betroffen…raffiniert, nicht?
Kollateralschäden
Problematisch an dieser Art von Spam + Spoof ist dabei nicht nur die verschmähte Liebe sondern v.a. dass durch das Spoofing leicht an sich unschuldige Dritte als Spammer gekennzeichnet werden können.
Wenn bei einer Domain keine korrekten SPF – Einträge gesetzt sind (d.h. der Empfänger kann nicht überprüfen ob die ensprechenden Mails auch vom authorisierten Absendern kommen) oder dies anderweitig überprüft wird (z.B. standardmässig mit Google Apps) wird der Absender bei ausreichender Anzahl an Beschwerden als Spammer markiert…
Um solche Fälle zu vermeiden empfiehlt sich dringend korrekte SPF-Records zu setzen. Einen entsprechenden Generator dazu gibt es etwa hier oder hier. Der so erstellte Eintrag muss anschliessend als TXT in den DNS-Einträgen der Domain hinterlegt werden.
Zwar braucht das etwas Zeit, langfristig macht man Evgeniya damit aber einen Strich durch die Rechnung…
Das Problem tritt auf, wenn vCenter Server oder einer der ESXi – Hosts nur über eine IP-Adresse verfügt bzw. der Hostname (FQDN) nicht sauber aufgelöst werden kann.(also z.B. 192.168.1.100 anstelle von vcenter.domain.local).
Für sämtliche ESXi – Hosts sowie den vCenter Server müssen (meistens manuell) ein statischer DNS A-Name Record sowie ein entsprechender Pointer erstellt werden!
Um einen Client einer Domäne hinzuzufügen muss man eine Reihe von Anforderungen erfüllten. Selbes Netzwerk, die richtigen DNS-Einstellungen,etc. Wie man dasselbe offline erledigen kann – hier die korrekten Schritte.
Vorgehen
Das Vorgehen ist schnell erklärt. Auf dem Domänencontroller führt man ein kleines Skript aus und generiert ein Textdokument. Dieses kann dann (z.B. per Mail) an den Client gesendet werden der sich damit dann offline an die Domäne anbinden kann.
Schritte auf dem Server / Domänencontroller
Eingabeaufforderung (CMD) öffnen und folgende Befehle eingeben:
