15
Windows 10 deaktivierte den lokalen Admin - wie kann ich das unterbinden?
Hallo Forum,
das ist mir jetzt schon das wiederholte mal passiert:
nach jedem "versionswechsel" wird der administrator von windows (scheinbar) deaktiviert. was soll der scheiss und wie kann ich das unterbinden?
ich hab das problem, dass ein mitarbeiter -weiss der geier mit welcher intention der depp- sein passwort geändert hat und: der vollidiot kann sich nicht mehr daran erinnern.
das rücksetzen ist kein problem, nur bei dem (hat schon 3x sein ipad zerschossen und 3 unterschiedliche apple-id´s fabriziert und handy und ipad [firmeneingentum] auf privaten id´s auf den geräten laufen und: passwörter vergessen) ist es nervig.
ich predige ständig: nimmt nen zettel, rechts altes passwort, links neues notieren - dann im pc ändern und dabei sorgfalt walten lassen, langsam!
nun,
wie umgeht ihr diese zwangsdeaktivierung des admin´s durch M$? tipps? workaround? das laptop läuft ausschliesslich lokal, da adm und der chef denen privatbenutzung gestattet. es nicht an die domäne des unternehmens gebunden, der zugriff geht per rdp zum unternehmen.
gruss sepp
das ist mir jetzt schon das wiederholte mal passiert:
nach jedem "versionswechsel" wird der administrator von windows (scheinbar) deaktiviert. was soll der scheiss und wie kann ich das unterbinden?
ich hab das problem, dass ein mitarbeiter -weiss der geier mit welcher intention der depp- sein passwort geändert hat und: der vollidiot kann sich nicht mehr daran erinnern.
das rücksetzen ist kein problem, nur bei dem (hat schon 3x sein ipad zerschossen und 3 unterschiedliche apple-id´s fabriziert und handy und ipad [firmeneingentum] auf privaten id´s auf den geräten laufen und: passwörter vergessen) ist es nervig.
ich predige ständig: nimmt nen zettel, rechts altes passwort, links neues notieren - dann im pc ändern und dabei sorgfalt walten lassen, langsam!
nun,
wie umgeht ihr diese zwangsdeaktivierung des admin´s durch M$? tipps? workaround? das laptop läuft ausschliesslich lokal, da adm und der chef denen privatbenutzung gestattet. es nicht an die domäne des unternehmens gebunden, der zugriff geht per rdp zum unternehmen.
gruss sepp
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 331781
Url: https://administrator.de/contentid/331781
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
15 Kommentare
Neuester Kommentar
Hallo Sepp,
ich für meinen Teil hoffe mal, dass noch bessere Freitagsideen kommen!
Viele Grüße!
ich für meinen Teil hoffe mal, dass noch bessere Freitagsideen kommen!
Viele Grüße!
Hi.
Das wird mit Sicherheit nicht passieren, wenn "administrator" der einzige Admin ist. Stell doch einmal sicher, dass Du da nicht noch andere Admins hast. Domäne habt Ihr nicht?
Das wird mit Sicherheit nicht passieren, wenn "administrator" der einzige Admin ist. Stell doch einmal sicher, dass Du da nicht noch andere Admins hast. Domäne habt Ihr nicht?
Hallo,
administrator sollte per default deaktiviert sein, da die UID bekannt ist und als Einfallstor vor verschiedenste TOOLS
verwendet wird. Besser ist einen neuen Admin erzeugen und den default Admin deaktivert lassen.
Grüße Peter
administrator sollte per default deaktiviert sein, da die UID bekannt ist und als Einfallstor vor verschiedenste TOOLS
verwendet wird. Besser ist einen neuen Admin erzeugen und den default Admin deaktivert lassen.Grüße Peter
Zitat von @muftypeter:
Hallo,
administrator sollte per default deaktiviert sein, da die UID bekannt ist und als Einfallstor vor verschiedenste TOOLS verwendet wird. Besser ist einen neuen Admin erzeugen und den default Admin deaktivert lassen.
Grüße Peter
Hallo,
administrator sollte per default deaktiviert sein, da die UID bekannt ist und als Einfallstor vor verschiedenste TOOLS
verwendet wird. Besser ist einen neuen Admin erzeugen und den default Admin deaktivert lassen.Grüße Peter
Da kann ich Peter nur zustimmen! - Vorallem wird M$ dein neuen Admin der anders als Administrator heisst definitiv beim nächsten Update nicht wieder deaktivieren. (z.B. localadmin oder was auch immer...)
Grüsse & n schönen Freitag
KMUlife
hiho,
@muftypeter
es ist doch zunächst mal unerheblich, ob wer, wann wie mit tools darauf zugreifen kann.
ich hab ein problem und suche eine lösung.
@DerWoWusste
es gibt eine domäne, die adm´s arbeiten mit tunnel, der nur die rdp-verbindung zulässt. der tunnel muss auf dem laptop verbunden werden (bintec ipsec-client), am rdp ist die zwischenablage deaktiviert. daher dachten wir, wir lassen die domänenanmeldung bei adm´s aussenvor. bei anmeldungen im firmennetz, nutzen diese ein eigenen ip-bereich, der auch so abgeschottet ist, dass nur rdp verbindungen erlaubt sind.
das wir superdaus´, mit gemeingefährlichen halbwissen haben, die nicht wissen was sie tun, warum sie es tun (vermutlich war man auf schmuddelseiten oder hat sonst einen dreck gezogen). die netzwerke zuhause sind privat, es gibt keinen tunnel zur firma. wie erwähnt, nur via software.
was ich mit dem mit den ipads erlebt hab, ist schlicht weg -da fehlen mir die worte-
@muftypeter
es ist doch zunächst mal unerheblich, ob wer, wann wie mit tools darauf zugreifen kann.
ich hab ein problem und suche eine lösung.
@DerWoWusste
es gibt eine domäne, die adm´s arbeiten mit tunnel, der nur die rdp-verbindung zulässt. der tunnel muss auf dem laptop verbunden werden (bintec ipsec-client), am rdp ist die zwischenablage deaktiviert. daher dachten wir, wir lassen die domänenanmeldung bei adm´s aussenvor. bei anmeldungen im firmennetz, nutzen diese ein eigenen ip-bereich, der auch so abgeschottet ist, dass nur rdp verbindungen erlaubt sind.
das wir superdaus´, mit gemeingefährlichen halbwissen haben, die nicht wissen was sie tun, warum sie es tun (vermutlich war man auf schmuddelseiten oder hat sonst einen dreck gezogen). die netzwerke zuhause sind privat, es gibt keinen tunnel zur firma. wie erwähnt, nur via software.
was ich mit dem mit den ipads erlebt hab, ist schlicht weg -da fehlen mir die worte-
Moin,
hui, da ist aber wer schlecht gelaunt O.o
Also:
Den Administrator kannst du per GPO wieder aktivieren (bzw. deaktiviert lassen und einen "eigenen" Admin anlegen, wie schon angesprochen)
PS:
Mit sind Admins mit Helbwissen und 200 Puls viel unheimlicher als DAUs :P
Naja, ist eben Freitag
lg,
Slainte
hui, da ist aber wer schlecht gelaunt O.o
Also:
Den Administrator kannst du per GPO wieder aktivieren (bzw. deaktiviert lassen und einen "eigenen" Admin anlegen, wie schon angesprochen)
ich hab das problem, dass ein mitarbeiter [...] sein passwort geändert hat
Wo genau ist das Problem? Betriebt ihr den keine AD-Domäne in der der Client Mitglied ist? Dann haben doch zumindest die Dom-Admins Zugriffsrechte auf den Rechner. Abgesehen davon kannst du das User PW über das AD zurücksetzen.PS:
Mit sind Admins mit Helbwissen und 200 Puls viel unheimlicher als DAUs :P
Naja, ist eben Freitag
lg,
Slainte
1
Du hast nicht nachgesehen, ob es andere Admins gibt, oder? Wenn in der Domäne, kannst Du den Domänenadmin nutzen, um lokale Konten zu aktivieren oder Kennwörter lokaler K.'s zurückzusetzen.
Warum arbeiten Eure Kollegen mit lokalen Nutzern?
Warum arbeiten Eure Kollegen mit lokalen Nutzern?
Hallo Sepp,
vielen Dank für diesen Freitag.
Scheinbar ist auch deine Umschalttaste defekt.
vielen Dank für diesen Freitag.
Zitat von @seppmairhubr:
ich hab das problem, dass ein mitarbeiter -weiss der geier mit welcher intention der depp- sein passwort geändert hat
ich hab das problem, dass ein mitarbeiter -weiss der geier mit welcher intention der depp- sein passwort geändert hat
Scheinbar ist auch deine Umschalttaste defekt.
Zitat von @seppmairhubr:
ich predige ständig: nimmt nen zettel, rechts altes Passwort, links neues notieren - dann im pc ändern und dabei Sorgfalt walten lassen, langsam!
Das mit dem Zetteln ist eine Prima Lösung. Weiter so... Anstatt den Usern zu raten das Passwort überall nieder zuschreiben mach einen AutoLogin. Ist genau so gut.ich predige ständig: nimmt nen zettel, rechts altes Passwort, links neues notieren - dann im pc ändern und dabei Sorgfalt walten lassen, langsam!
"Das mit dem Zetteln ist eine Prima Lösung. Weiter so... Anstatt den Usern zu raten das Passwort überall nieder zuschreiben mach einen AutoLogin. Ist genau so gut."
Tja.... denkste ich mach das gerne? Aber es gibt dummerweise Mitarbeiter, die sich allen ### merken können, nur nicht ihr Passwort. Es dient als Hilfe zur Eingabe. Die Passwörter müssen alle 30 Tage bei der Domänenanmeldung (RDP-Zugriff u. Lokale PC IN der Zentrale und Filialen). Die bekommen es nicht auf die Kette es zu unfallfrei zu ändern. Als wir das 2013 einführten, war das nach den ersten 3-5 Mal jedes Mal eine Katastrophe.
Bevor irgendjemand meckert: ihr kennt doch die Workflows des Unternehmen nicht.
Ich gebe bei Frage immer gezielt Auskunft, hier wird gelabert (von einigen zumindest). Sagt doch einfach "NEIN" oder "JA". In diesem Fall war ich der Meinung, jemand wüsste ein Workaround.
Tja.... denkste ich mach das gerne? Aber es gibt dummerweise Mitarbeiter, die sich allen ### merken können, nur nicht ihr Passwort. Es dient als Hilfe zur Eingabe. Die Passwörter müssen alle 30 Tage bei der Domänenanmeldung (RDP-Zugriff u. Lokale PC IN der Zentrale und Filialen). Die bekommen es nicht auf die Kette es zu unfallfrei zu ändern. Als wir das 2013 einführten, war das nach den ersten 3-5 Mal jedes Mal eine Katastrophe.
Bevor irgendjemand meckert: ihr kennt doch die Workflows des Unternehmen nicht.
Ich gebe bei Frage immer gezielt Auskunft, hier wird gelabert (von einigen zumindest). Sagt doch einfach "NEIN" oder "JA". In diesem Fall war ich der Meinung, jemand wüsste ein Workaround.
@DerWoWusste:
Nein, es gibt keine anderen lokalen Benutzer. Wie gesagt, die Laptops hängen nicht in der Domäne. Der aktivierte lokale Admin wurde von M$ bei einem Versionsupdate deaktiviert. Es ist ja kein Problem, wenn ich das Laptop hier habe, kann ich das regeln. Mich nervt nur, das manche Besserwisser ihren Senf dazutun, statt zu schreiben "es gibt kein Workaround" oder "nein" oder ja".
Das Laptop wird mir zugeschickt. Ich habe lediglich eine Lösung gesucht, diese Deaktivierung zu unterbinden. Welche Absichten dahinter stecken, sollte jedem egal sein.
Es ist von der GL nicht gewünscht, die Laptops in die Domäne einzubinden. Wie erwähnt, das Laptop ist zur freien Benutzung für die Mitarbeiter freigegeben. Der Zugriff auf den TS erfolgt per RDP. Ich sah da auch nie ein Vorteil den Laptops eine Domäne zuzuweisen.
Gruss Sepp
Nein, es gibt keine anderen lokalen Benutzer. Wie gesagt, die Laptops hängen nicht in der Domäne. Der aktivierte lokale Admin wurde von M$ bei einem Versionsupdate deaktiviert. Es ist ja kein Problem, wenn ich das Laptop hier habe, kann ich das regeln. Mich nervt nur, das manche Besserwisser ihren Senf dazutun, statt zu schreiben "es gibt kein Workaround" oder "nein" oder ja".
Das Laptop wird mir zugeschickt. Ich habe lediglich eine Lösung gesucht, diese Deaktivierung zu unterbinden. Welche Absichten dahinter stecken, sollte jedem egal sein.
Warum arbeiten Eure Kollegen mit lokalen Nutzern?
Gruss Sepp
Zitat von @seppmairhubr:
Ich gebe bei Frage immer gezielt Auskunft, hier wird gelabert (von einigen zumindest). Sagt doch einfach "NEIN" oder "JA". In diesem Fall war ich der Meinung, jemand wüsste ein Workaround.
Ich gebe bei Frage immer gezielt Auskunft, hier wird gelabert (von einigen zumindest). Sagt doch einfach "NEIN" oder "JA". In diesem Fall war ich der Meinung, jemand wüsste ein Workaround.
"JA" würde ich machen. Aber wenn jemand sich bei der Erstellung des Post´s seinen Emotionen frei hingibt habe ich keine Lust zu helfen. Da erfreue ich mich lieber am Freitag.
Sorry, hier habe ich mich evtl. etwas ungenau ausgedrückt.
Hacker suchen geziehlt nach der UID des Administrators, umbenennen bringt also nichts. Aus diesem Grund wird MS das Problem noch öfters erzeugen.
Die Lösung ist also einfach einen neuen User zu erzeugen, der kann dann auch wieder administrator heissen und den lässt MS dann auch in Ruhe.
Grüße Peter
Hacker suchen geziehlt nach der UID des Administrators, umbenennen bringt also nichts. Aus diesem Grund wird MS das Problem noch öfters erzeugen.
Die Lösung ist also einfach einen neuen User zu erzeugen, der kann dann auch wieder administrator heissen und den lässt MS dann auch in Ruhe.
Grüße Peter
@Neffe2
ich würde für meinen teil einfach nicht´s schreiben. da scheint deinerseits ein unmittelbares mitteilungsbedürfnis zu schlummern.
ja, ok... vollmond kommt
ich würde für meinen teil einfach nicht´s schreiben. da scheint deinerseits ein unmittelbares mitteilungsbedürfnis zu schlummern.
ja, ok... vollmond kommt
hallo peter,
ich hab das auch immer so gemacht, hier wollte man es explizit so. wes´ brot mir zahlt, des´ lied ich sing...
aber, das is ne idee. man sieht eben manchmal vor lauter bäumen kein wald.
gruss sepp
ich hab das auch immer so gemacht, hier wollte man es explizit so. wes´ brot mir zahlt, des´ lied ich sing...
aber, das is ne idee. man sieht eben manchmal vor lauter bäumen kein wald.
gruss sepp
Zitat von @muftypeter:
Sorry, hier habe ich mich evtl. etwas ungenau ausgedrückt.
Hacker suchen geziehlt nach der UID des Administrators, umbenennen bringt also nichts. Aus diesem Grund wird MS das Problem noch öfters erzeugen.
Die Lösung ist also einfach einen neuen User zu erzeugen, der kann dann auch wieder administrator heissen und den lässt MS dann auch in Ruhe.
Grüße Peter
Sorry, hier habe ich mich evtl. etwas ungenau ausgedrückt.
Hacker suchen geziehlt nach der UID des Administrators, umbenennen bringt also nichts. Aus diesem Grund wird MS das Problem noch öfters erzeugen.
Die Lösung ist also einfach einen neuen User zu erzeugen, der kann dann auch wieder administrator heissen und den lässt MS dann auch in Ruhe.
Grüße Peter
Sei mir nicht böse, aber zu glauben das hacker nach nur nach der einen UID suchen ist naiv. Sehr naiv. Der Login auf Windows System (egal ob nun über UI, Auth über Powershell, Dienste o.ä) funktioniert in der Regel immer über den Klarnamen des Benutzers und eben nicht über seine UID. Da Microsoft es verhindern wollte, dass jeder Account auf dieser Welt den gleichen Administrator Benutzer hat, haben sie diesen deaktiviert. Die Taktik ist vergleichbar mit dem deaktiverten root Login auf manchen Unix Systemen.
Du hast durch deine "Taktik" nur eins geschafft: Die potentielle Sicherheit über Board geworfen und die Möglichkeit eröffnet, wieder über den Administrator-Benutzername wieder zu versuchen auf das System zu kommen. Das einzige wovon du jetzt profitierst: Die Hacker wissen ja dass "Administrator" in der Regel deaktiviert ist, und suchen erstmal nach anderen Benutzern. Wenn die allerdingd registrieren dass das wieder dein Main Benutzer ist - tja ...
Eigentlich könnte man auch mit logischem Denken dahinter kommen: Wenn die UID das Problem wäre bei den Angriffen, dann hätte Microsoft auch über einen Mechanismus einen zufällig generierte UID erzeugen können sobald der Benutzer angelegt ist. Es hat schon seinen Grund, warum der Administrator Account deaktiviert und nicht gelöscht ist. Mit der Logik könnte man auch unter Unix- Systemen den root Login wieder aktivieren!
Ich möchte nicht sagen dass die UID-Argumentation tendeziell immer falsch ist, sie passt allerdings eher auf Systeme wie z. B. Content Management Systeme die aus dem Web erreichbar sind. Wo ist der Unterschied? Die meisten Management Systeme haben eine öffentliche Benutzerausgabe worüber du über das testen von UID's in Kombination mit dem entsprechend http-Links schnell an den Benutzernamen des Administrator kommen könnest! Das geht bei Windows Systemen so aber nicht und deshalb ist die Argumentation hier eben auch nicht zutreffend.
