locked
access denied trotz Administratorkonto? RRS feed

  • Frage

  • Erstmal - first post - und über Google überhaupt ein MS Forum zu finden gestaltete sich recht schwierig - von daher: falls ich hier falsch bin wäre ein Wink mit dem Zaunpfahl und einer Info, wo ich denn besser dran wäre, nicht verkehrt.

    Recht kurz: Via Telnet remote in ein Windows 7, Konto ist Mitglied der Administratoren-Gruppe. Bei Zugriff auf Benutzerverzeichnisse anderer Konten kommt trotzdem ein access denied. Ich hab mich schon immer schwer getan mit Windows' Rechteverwaltung, aber sollte ein Admin nicht ein Admin sein? Warum gibts ein access denied wenn ich als lokaler Administrator auf das Benutzerverzeichnis eines anderen Kontos (ebenfalls Admin) zugreifen will? Dafür sollte ich doch die nötigen Rechte haben. Ich hab auch versucht mit icacls für das Konto mit dem ich über Telnet angemeldet bin die nötigen Rechte (ich habe es erstmal nur mit Leserechten versucht) zu setzen - aber ebenfalls nur wieder access denied.

    Google liefert dazu nur irgendwas das man in der Registry was ändern muss da sonst ohne diese Änderung irgendwie das Rechte-System nicht ganz so funktioniert wie man es als Laie erwarten würde.

    Danke vorab für Hilfe.

    Sonntag, 8. März 2020 06:57

Antworten

  • Moin,

    es wäre schon hilfreich gewesen, Deine Frage in das richtige Subforum zu stecken (Windows 7 oder so). Andererseits ist im deutschen TechNet nicht so viel Bewegung, sie wird schon noch gefunden werden :-)

    Das Stichwort, das Dir fehlt, ist "User Account Control". Administrator ist zwar Administrator, muss aber vor gewissen Handlungen explizit bestätigen, dass er sie tatsächlich beabsichtigt. Dass Dir keine NTFS-Rechte fehlen, kannst Du verifizieren, indem Du, sofern die Firewall das zulässt, auf dieselben Verzeichnisse mittels \\<COMPUTERNAME>\C$\Users\<USERNAME> zugreifst - das wird nämlich funktionieren, denn hier zählen wirklich nur die Zugriffsrechte auf Filesystem-Ebene.

    Da man den UAC-Prompt in einer Telnet-Session tatsächlich nicht bekommt, müsstest Du UAC wohl tatsächlich abschalten, um das Gewünschte zu erreichen. Davon würde ich aber dringend abraten. Alternativ: Den Default-Administrator für die Geschichte verwenden, für den ist UAC vom Werk abgeschaltet.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Sonntag, 8. März 2020 08:23

Alle Antworten

  • Moin,

    es wäre schon hilfreich gewesen, Deine Frage in das richtige Subforum zu stecken (Windows 7 oder so). Andererseits ist im deutschen TechNet nicht so viel Bewegung, sie wird schon noch gefunden werden :-)

    Das Stichwort, das Dir fehlt, ist "User Account Control". Administrator ist zwar Administrator, muss aber vor gewissen Handlungen explizit bestätigen, dass er sie tatsächlich beabsichtigt. Dass Dir keine NTFS-Rechte fehlen, kannst Du verifizieren, indem Du, sofern die Firewall das zulässt, auf dieselben Verzeichnisse mittels \\<COMPUTERNAME>\C$\Users\<USERNAME> zugreifst - das wird nämlich funktionieren, denn hier zählen wirklich nur die Zugriffsrechte auf Filesystem-Ebene.

    Da man den UAC-Prompt in einer Telnet-Session tatsächlich nicht bekommt, müsstest Du UAC wohl tatsächlich abschalten, um das Gewünschte zu erreichen. Davon würde ich aber dringend abraten. Alternativ: Den Default-Administrator für die Geschichte verwenden, für den ist UAC vom Werk abgeschaltet.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Sonntag, 8. März 2020 08:23
  • 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.

    Sonntag, 8. März 2020 17:01
  • Windows unterscheidet da noch zwischen lokalen Admins (die aber nicht die rechte des internen Admins haben) sowie Domain-Admins. Diese Rechte sind ebenso getrennt zu beachten.
    Montag, 9. März 2020 09:37