Ich habe mir vorher die möglichen Bereiche angesehen, konnte aber nichts passenderes finden - ist ähnlich (ironie) gut (/ironie) sortiert wie die Google Suchergebnisse: Gibt man nur "microsoft forums" ein landet man entweder bei answers.ms.com
oder social.ms.com - möchte nicht abwertend klingen, aber beides völlig nutzlos. Anyway - nvm.
Stichwort UAC: War zwar ne gute Idee, da das aber so ziemlich jeder aushebelt (Standardvorgehen war seit Vista, und ist heute immer noch, den Installer mit dem nötigen Manifest ausstatten und während der Installation die ACL auf "vollzugriff für alle"
zu setzen) und der Standard-User es eh entweder ohne Sinn und Verstand "wegklickt" (oder sich die Mühe macht bei Google zu suchen wie man es abschaltet) hat sich MS meiner Ansicht nach damit selbst ein Ei gegen das Schienbein genagelt. Der normale
Windows-User will sich halt nicht mit irgendwelchen Rechten auseinander setzen - es soll einfach funktionieren ohne Rücksicht auf Verluste (Sicherheit). Und am Ende kommt dann genau sowas raus, dass man halt versucht hat, dass Rechte-System von Unix zu kopieren
- und ist dabei maßlos gescheitert. "Auf den Boden der Tatsachen"? Nein, 90 Grad senkrecht freier fall!
Back to topic: Der Einfachheit halber gehe ich beim Aufsetzen so vor: Nach dem zweiten Neustart und Abschluss des Setup wird ja automatisch in den gerade angelegten Nutzer gewechselt. Bevor ich auch nur irgendeinen Chipset-Treiber installiere: Computerverwaltung
> Benutzer > Admin frei machen und aktuellen Nutzer direkt löschen - damit wird, da Admin kein Kennwort hat, nach dem ersten sauberen reboot direkt in den Admin-Account angemeldet (Zugriff auf Nutzerverwaltung über Computerverwaltung möglich da Ultimate).
Dann wird halt nach dem reboot noch der remote-Nutzer hinzugeführt und eine allgemeine share eingerichtet auf die der remote-Account Rechte bekommt. Damit nun beim reboot das Login nicht nervt wird es noch schnell mit netplwiz stillgelegt. TLDR: "Administrator"
hat kein Kennwort - und da eine Anmeldung (via Telnet, Zugriff auf share, "runas") mit "leerem" Kennwort (noch so ne "tolle" MS Bezeichnung - entweder man hat ein Kennwort oder nicht - sowas wie "leere" Kennwörter gibt
es nicht) nun mal nicht zulässig ist.
Sicher, EINE Möglichkeit wäre jetzt einfach dem Admin-Konto ein Kennwort zu geben und der Telnet-Client Guppe hinzuzufügen, damit ich mich direkt mit diesem Konto via Telnet anmelden kann - ist aber nun mal nicht mein Ziel. Hab grad noch mal schnell Google
gefragt und es wieder gefunden: "Configure Telnet Server to Allow Administrator Access by using Password Authentication" (auch schön - obwohl der Link auch wieder auf ms.com zurückverweist muss man erstmal einen geprüften Account haben weil es halt
trotzdem immer noch ein Link ist - *much WOW*) - aber mal ganz ehrlich: DAS kanns doch auch nicht sein, dass ich bewusst Sicherheitsfeatures aushebeln muss nur damit ich etwas machen kann, was unter Unix seit den 70ern Standard ist.
Ja, natürlich ist es einfacher, die nötigen Daten vorher in die share zu packen - dann kann ich diese auch direkt auf meiner Linux-SoC mounten und muss mich nicht mal via Telnet anmelden - aber schon doof wenn die Daten in einem Thunderbird-Profil in AppData
und sonst nur in einem Umschlag auf dem Schreibtisch liegen und man es vorher nicht für nötig befunden hat, diese "weitreichend" Zugänglich zu machen weil man es vorher nie brauchte.
Ich hab meine Situation jetzt vorläufig so gelöst, dass ich mir einfach die nötigen Daten in ein simples Text-File auf dem Linux-SoC gepackt hab - da komm ich von überall einfach via SSH ran - und kann mich zur Not mit sudo (root) über alles hinwegsetzen
- so wie ich es auch eigentlich von einem Admin unter Windows erwarte. Danke dennoch für die Erklärung. Ich werd dann vermutlich in Zukunft bei Neu-Aufsetzen von Windows-Systemen entsprechend anders vorgehen, um die nötigen Logins durch simple Kennwörter zu
haben - damit diese eben nicht "leer" sind.
