Windows Server – AutoLogin einrichten

Ich hatte nun schon mehrfach den Fall, für Testzwecke virt. (Trail-)Systeme zu nutzen. Dabei finde ich es einfacher, hierzu ein autom. Login einzusetzen. Zumal es einem ggf. auch erleichtet, wenn man eine VM mal mehrere Wochen nicht nutzt – dann allerdings die Zugangsdaten erstmal wieder erraten muss 😉

Für diesen Zweck gibt es 2 Möglichkeiten.

1.) Registryeinträge

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
„AutoAdminLogon“=“1“
„DefaultUserName“=“BENUTZER“
„DefaultPassword“=“KENNWORT“
„DefaultDomainName“=“DOMÄNE“

Wichtig! Beim Einsatz der Registrymethode wird das Passwort in Klartext abgelegt. Das solltet ihr aus Sicherheitsgründen berücksichtigen.

2.) Autologin (aus dem Microsoft Sysinternal)

Downloadlink:
https://docs.microsoft.com/en-us/sysinternals/downloads/autologon

Downloadlink komplette Sysinternals Suite:
https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

Viel Spass nun beim testen …

Windows 10 über die CommandLine (CMD) aktivieren

Es kann mal vorkommen, das Windows sich nicht über die Oberfläche aktivieren lässt.

Es gibt jedoch die Möglichkeit, dies über die Kommandzeile auch auszuführen.

Folgende 2 Schritte sind erforderlich:

Der erste Befehl hinterlegt den Windows 10 Product Key, der 2. erledigt die Aktivierung.

Beispiele:

Benutzerordner bei neu angelegten Benutzern entfernen (Nextcloud)

Bei Nextcloud (bei mir nun in Version 15) werden (standardmäßig) bei neu angelegten Benutzern ein paar Verzeichnisse sowie Dateien in den Benutzerordner kopiert.

Dies lässt sich verhindern bzw. anpassen.

Die Dateien dazu befinden sich in der nextCloud Installation im Ordner core/skeleton. Der Inhalt kann geändert oder gar gelöscht werden.

Viel Spass beim testen …

Nachtrag:
Der beschriebene Weg ist nicht korrekt bzw. zu empfehlen, da bei jedem Update von Nextcloud dieses Verzeichnis wieder mit den Standard-Dateien gefüllt wird ;-(

Stattdessen sollte in der Nextcloud Konfiguration (…/config/config.php) folgendes hinzugefügt werden:

DNS-Auflösung via (Open)VPN bei Windows 10 – Adapter-Priorisierung

Folgendes Problem hatte ich auch auf meinem eigenen Notebook:
Wird auf dem Notebook / PC mit Windows 10 eine VPN Verbindung aufgebaut, die einen TAP-Treiber verwendet (z.B. auch OpenVPN), werden zwar die hinterlegten DNS-Server gesetzt – aber nicht berücksichtigt.

Öffne eine (administrative!) CMD und führe den Befehl aus:
netsh int ip show interfaces

In der Spalte „Met“ (kurz für „Metric“) wird die Reihenfolge angezeigt.

Beispiel – aktuell hat meine VPN Verbindung die Metrik 35:

Ändere die Metrik in der GUI über „Netzwerk- und Freigabecenter“ -> „Adaptereinstellungen ändern“ -> TAP-Treiber -> „Erweitert“
Dort den Haken bei „Automatische Metrik“ entfernen und einen niedrigeren Wert eintragen (z.B. 15 oder 10) wie die anderen

Anschließend ist dieser in der Reihenfolge niedriger und wird priorisiert.

Zum Schluss muss die VPN Verbindung getrennt und wieder neu aufgebaut werden, damit die Änderungen greifen.

Viel Spass beim testen …

Windows Testversion verlängern per Kommandozeile

Microsoft ermöglicht es, die Windows Betriebssysteme für einen bestimmten Zeitraum ohne gültige Lizenz zu testen.
In meinem Falle handelt es sich um eine Testversion zu Windows Server 2012 R2.

Die Testversionen laufen nur für einen bestimmten Zeitraum – bei mir 180 Tage.
Danach ist normalerweise Schluss und man müsste die Testversion neu installieren oder eine Lizenz kaufen.
Es erscheint dann auch im Windows eine Meldung, das der Testzeitraum abgelaufen ist.

Jedoch lässt sich die Testlizenz auch verlängern 😉

Du brauchst nur eine Kommandozeile, welche mit Administratorrechten gestartet wurde.

Für die Verlängerung muss dann folgender Befehl eingegeben werden: slmgr -rearm

Das ganze wird mit einer Meldung bestätigt, nun ist ein Reboot fällig.

Nach dem Reboot sollte die Testversion von Windows erneut 180 Tage lang laufen.

 

Viel Spass beim testen …

Kein Netzwerk nach Upgrade auf Ubuntu 16.04 LTS

Hallo zusammen,

ein vorhandenen (virt.) Ubuntu Server wurde bereits problemlos von Release 12.04 auf Release 14.04 upgedated.

Nun wollte ich das System erneut von Release 14.04 auf 16.04 updaten. Das Update an sich verlief eigentlich problemlos – nur war anschließend kein Netzwerkzugriff mehr möglich.

Auch beim Systemboot wurde plötzlich gemeldet, das das Interface „eth0“ nicht mehr gefunden wurde.

Einen Blick in die Netzwerkconfig verriet nun auch das Problem.

In der bisherigen Konfiguration war das Netzwerk mit dem Interface „eth0“ verknüpft. Nach dem Upgrade heißt es jedoch nun (zumindest bei mir!) „ens160“.

OK, dann ändern wir das nun in der Configdatei.

Darin die Einträge abändern auf:

Anschließend noch das Netzwerk neu starten und schon hat das Linuxsystem wieder eine Verbindung …

 

Viel Spass nun beim testen …

StartCom stellt ab 2018 keine Zertifikate mehr aus …

In den vergangenen Jahren habe auch ich von StartCom die kostenlosen SSL Zertifikate genutzt – das Ende wurde jedoch schon Anfang des Jahres (leider) eingeläutet.

Nachdem seit Anfang 2017 bereits Mozilla im Browser Firefox den Zertifikaten von StartCom (und WoSign) nicht mehr vertraut wurden, zog einige Zeit später auch Google im Browser Chrome nach und entfernte auch in diesem die Rootzertifikate (RootCA’s) von StartCom, damit auch diesen nicht mehr vertraut wird. Mittlerweile vertraut auch Apple den Zertifikaten nicht mehr, welche nach dem 01.12.2016 ausgestellt wurden.

Grund hierzu waren Richtlinienvertröße bei den Zertifizierungsstellen.

Nun zog die Firma StartCom endgültig den Stecker und stellt ab 01.01.2018 keine Zertifikate mehr aus.

Die bisher ausgestellten Zertifikate behalten zunächst noch Ihre Gültigkeit, Verlängerungen werden ab Januar 2018 nicht mehr ausgeführt. Ab 2020 verlieren jedoch auch bis dann noch vorhandene Zertifikate die Gültigkeit.

Eine mögliche Alternative dazu wäre Let’s Encrypt

Link zur Abkündigung von StartCom

 

Viel Spass noch beim testen…

Windows 10 Client haben keinen Zugriff auf Netlogon des DCs

Nach längerer Inaktivität mal wieder ein kurzer Beitrag.

Wir haben nach einer Umstellung der Windows Domäne auf 2012 R2 das Problem,
das einige Windows 10 Pro Clients keinen Zugriff auf die Netlogon Freigabe des DCs hatten und „Zugriff verweigert“ meldeten.
Der Zugriff auf andere Freigaben klappte fehlerfrei, jedoch wurden keine Logon-Scripts mehr ausgeführt.

Nach der Befragung von Dr. Google kam der KB-Artikel https://support.microsoft.com/de-de/kb/3000483 heraus.
Durch dieses Update wurden sog. „Gehärtete UNC-Pfade“ eingeführt, welche Windows 10 nutzt.

Um einen schnellen Zugriff auf die Ressourcen zu gewährleisten kann man (als Beispiel) in der Default Domain Policy unter
Computerkonfiguration / Richtlinien / Administrative Vorlagen / Netzwerk / Netzwerkanbieter
=> die „Gehärtete UNC-Pfade“ deaktivieren.

Beispiel:

Viel Spass beim testen …

Ubuntu 14.04 LTS – SSH Anmeldung als root erlauben

Standardmäßig ist ein direkter root-Login per SSH an einem Ubuntu 14.04 LTS nicht möglich.

Um dies wieder zu (re-)aktivieren, müssen folgende Dinge ausgeführt werden.

1.) per normaler User anmelden und das Passwort für den root-User setzen

2.) Die ssh-Config bearbeiten

Folgende Zeile ändern:

3.) ssh Daemon neu starten

Nun sollte der SSH Zugriff als root möglich sein.

 

Hinweis: das standardmäßige Deaktivieren des root Zugriffes per SSH geschieht nicht durch Zufall -> dies hat Sicherheitsgründe!

Sei dir bitte daher im klaren, welches Risiko du (durch das ermöglichen des root Logins) damit eingehst.

 

Viel Spass nun beim testen …