none
Zugriff trotz Workgroup RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo zusammen.

    Vielleicht habe ich es nicht verstanden :=(

    Ich habe einen physikalischen Server auf dem eine Server 2012R2 installiert ist. Dieser Server fungiert als Domänen-Controller. Bis dahin alles gut.

    Gestern habe ich mir Tablet gekauft und wollte dort Software installieren. Wie das nun mal meist so ist, ist Betriebssystem vorinstalliert und muss nur noch "scharf" gemacht werden. Was dabei passiert sollte klar sein, auf jeden Fall befindet sich dieser Rechner danach nicht in der Domäne, sondern in der Arbeitsgruppe: WORKGROUP.

    Nun öffne ich den Explorer und dort die Netzwerkumgebung und siehe da - Es wird mir der Server mit aufgelistet. Soweit nicht das Problem. Aber jetzt: Ich kann auf alle freigegebenen Laufwerke der Servers und auf die dort vorhanden Dateien zugreifen. Das kann doch nicht sein!

    Danke für jede Hilfe

    Gruß Scotty

    Freitag, 12. Dezember 2014 05:58
    |

Alle Antworten

  • Discussion
    Anmelden
    1
    Anmelden
    > jetzt: Ich kann auf alle freigegebenen Laufwerke der Servers und auf die
    > dort vorhanden Dateien zugreifen. Das kann doch nicht sein!
     
    User/Kennwort auf dem Tab auch auf dem Server so vorhanden?
     
    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Freitag, 12. Dezember 2014 07:21
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Martin,

    ja.

    Gruß Scotty

    Freitag, 12. Dezember 2014 07:39
    |
  • Discussion
    Anmelden
    1
    Anmelden
    > ja.
     
    Und worüber wunderst Du Dich dann? NTLM-Authentifizierung mit
    User/Password :)
     
    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Freitag, 12. Dezember 2014 07:51
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hallo Martin,

    so heißt es hier:

    "Eine Domain ist ein lokaler Sicherheitsbereich mit zentraler Verwaltung der Ressourcen und stellt die administrative Grenze dar." (http://de.wikipedia.org/wiki/Domain_Controller)

    da es ein lokaler Sicherheitsbereich ist, so müsste die Maschine zumindest der Domäne beigetreten sein, oder vielleicht auch die Anmeldung an der Domäne stattfinden:

    Benutzer: Domainname/Benutzername

    Aber nicht einfach

    Benutzer: Benutzername

    Und genau das funktioniert.

    Gruß Scotty

    Samstag, 13. Dezember 2014 06:15
    |
  • Discussion
    Anmelden
    1
    Anmelden
    > vielleicht auch die Anmeldung an der Domäne stattfinden:
     
    Gleicher User, gleiches Kennwort -> gleicher Kennwort-Hash bei
    NTLM-Authentifizierung. Wo ist Dein Problem?
     
    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Montag, 15. Dezember 2014 12:30
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Martin,

    warum antwortest Du mir fast gleichem Wortlaut?

    Hasste Du meine Antwort auf Deine Antwort vom 12.12.2014 überhaupt gelesen?

    Gruß Scotty

    Mittwoch, 17. Dezember 2014 09:59
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Moin,

    in deinem Scenario greift ja auch nicht der Computer auf Ressourcen der Domäne zu, sondern der Benutzer. Wenn der sich gegenüber dem Domänencontroller authentifiziert, geht der erst mal davon aus, dass sich die Authentifizierung mit Benutzername/Kennwort auf das existierende Domänenkonto bezieht. Wenn die Kennwörter gleich lauten, geht von daher die Anmeldung durch.

    Zumindest für die von Martin bereits genannte Form der Authentifizierung.

    Viele Grüße
    Olaf

    Mittwoch, 17. Dezember 2014 11:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    mit dieser Antwort kann ich mich nicht zufrieden geben.

    Es kann doch nicht sein, das in einem Netzwerk uneingeschränkt eine Anmeldung gesucht wird und dann auf eine beliebigen nicht vorhersehbaren Account angewendet wird. Ich muss schon vorher angeben wo ich mich anmelden will. In einer Workgroup ist die von Euch beschriebene Anmeldung okay. Aber nicht wenn der Account von einem von einem DC gehandelt wird. Bei jeder kleinsten Änderungen auf einem Client der wirklich Mitglied der Domäne ist wird nach einem Benutzer und Password und Password gefragt. Und hier wo der Client nicht Mitglied der Domäne ist offenbart der Server eben mal so seine Freigaben? Nein, das kann und darf nicht sein. Ich will nicht ausschließen das ich irgendwo in der Verwaltung einen Fehler gemacht habe und dies zu dem Ergebnis führt, aber dann ist die Einstellung sicherlich "by Default".

    Für die Sicherheit wird alles getan und hier reicht es aus einen frisch aufgesetzten Client mit einem Netzwerk zu verbinden um dann einfach mit Benutzernamen und Password auf Resourcen zu greifen zu können?

    Wozu gibt es dann eine Domäne? Sie soll doch genau hier das Netzwerk begrenzen/ isolieren.

    Gruß Scotty

    Samstag, 20. Dezember 2014 05:23
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi,

    Am 20.12.2014 um 06:23 schrieb "Karsten Sosna":

    Es kann doch nicht sein, das in einem Netzwerk uneingeschränkt eine
    Anmeldung gesucht wird und dann auf eine beliebigen nicht
    vorhersehbaren Account angewendet wird.

    Der Workgroup Client übergibt keine "Ressourcenkennung" in form von
    "DeinPC\DeinBenutzer", der macht ganz stumpf "DeinBenutzer".

    solange dein DC NTLM erlaubt, wir er bei dieser Form der Anmeldung nur nach einem SamAccountName im AD suchen der "DeinBenutzer" heisst. Findet er ihn und das Passwort stimmt überein, bist du authentifiziert.
    Erst als Domänenmitglied wechselt er die Art der Authentifizierung.

    Der Fehler ist nicht die Art der Authentifizierung, das war halt früher so, sondern die gleichen Kennworte. Selbst MS ist nicht frei von NTLM, sie können es also nicht komplett abschalten.

    Network Security: Restrict NTLM: NTLM authentication in this domain
    http://technet.microsoft.com/en-us/library/jj852241%28v=ws.10%29.aspx

    Evtl. hast du auch das aktiv?
    Netzwerkzugriff: Die Verwendung von "Jeder"-Berechtigungen für anonyme Benutzer ermöglichen
    Das macht das System ein wenig "Windows 95" komplatibel, wird gern in Workgroups aktiviert.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Samstag, 20. Dezember 2014 10:24
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Mark,

    das bringt mich schon weiter.

    Die "Jeder"-Berechtigung habe ich gleich bei der Freigabe entfernt, daran konnte es also nicht liegen.

    Nun aber: Auf meinem Server ist die Netzwerksicherheit: Beschränkung von NTLM: NTLM-Authentifizierung in dieser Domäne => "Nicht definiert".

    Wenn ich das richtig sehe müsste ich das auf "Alle verweigern" umstellen. Sehe ich das richtig?

    Gruß Scotty

    Sonntag, 21. Dezember 2014 09:04
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi,

    Am 21.12.2014 um 10:04 schrieb "Karsten Sosna":

    Nun aber: Auf meinem Server ist die Netzwerksicherheit: Beschränkung
    von NTLM: NTLM-Authentifizierung in dieser Domäne => "Nicht
    definiert".

    Nicht definiert heisst nur, das es nicht IN DIESER RICHTLINIE durch eine Richtlinienkonfiguration gesteuert wird.
    Das bedeutet, der Wert könnte durch eine andere Richtlinie kontrolliert werden, in der der Wert gesetzt ist, oder es ist wirklich "garnicht" konfiguriert, dann gelten die Default Einstellungen des System die bei der Installation durch diese gesetzt werden.
    ... oder auch nicht, weil das System ein Standardverhalten hat, das nicht explizit konfiguriert sein muss :-)

    Wenn ich das richtig sehe müsste ich das auf "Alle verweigern"
    umstellen. Sehe ich das richtig?

    Probier das mal aus und schau was passiert. Komplett verweigern wird aber mit SQL und IIS Probleme machen, die nutzen NTLM (oder nutzten?)
    Jedenfalls findet man da Probleme im Netz, wenn NTLM deaktiviert ist.

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Montag, 22. Dezember 2014 12:02
    |
  • Discussion
    Anmelden
    1
    Anmelden
    >  > > jetzt: Ich kann auf alle freigegebenen Laufwerke der Servers und auf die
    >  > > dort vorhanden Dateien zugreifen. Das kann doch nicht sein!
     

    > > User/Kennwort auf dem Tab auch auf dem Server so vorhanden?

    > Ja.

    Darüber würde ich mal nachdenken. Der Server ist ja sogar DC. Ist der angesprochene User evtl. sogar Domain Administrator?

    Grundsätzlich würde ich NIE die gleiche Kombination USER/PW für lokale und Domänenkonten verwenden. Und auch nicht für lokale Client-Admins und lokale Server-Admins.

    Und selbst für die lokalen Client-Admin-Accounts ist es natürlich am sichersten, überall verschiedene Passworte zu verwenden, wenn auch aufwendig. -> Ein lokales PW ist leicht geknackt oder ausgelesen, wenn jemand physischen Zugang zu dem Computer hat (oder es wird einem Power User gegeben). -> Hat man eins, hat man alle, hat man Zugriff auf alle.. Wer kennt nicht die "lustigen Dinge", die man in Netzwerken auf den Clients anstellen kann, wenn das lokale Admin/PW überall gleich und einem bekannt ist.







    • Bearbeitet DevOn99 Dienstag, 23. Dezember 2014 07:44
    Dienstag, 23. Dezember 2014 07:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hi,

    Am 23.12.2014 um 08:26 schrieb DevOn99:

    Wer kennt nicht die "lustigen Dinge", die man in
    Netzwerken auf den Clients anstellen kann, wenn das lokale Admin/PW
    überall gleich und einem bekannt ist.

    weil es gerade so schön passt ...

    Local admin password management solution
    https://code.msdn.microsoft.com/windowsapps/Solution-for-management-of-ae44e789

    und warum:
    Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft, Version 1 and 2
    http://www.microsoft.com/en-us/download/details.aspx?id=36036

    Tschö
    Mark

    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 23. Dezember 2014 09:28
    |