Netzlaufwerkzugriff auf TS-251 von Win10

  • Hallo liebes Forum,
    Ich habe folgendes Problem:
    Ich nutze ein QNAP TS-251. Dort sind verschiedene Benutzer angelegt.
    Zugegriffen wird auf die vorhandenen Daten über Windows 10 Rechner die über Microsoft Azure Active Directory angemeldet werden.
    Der Zugriff erfolgt per Einbindung als Netzlaufwerk.
    Alles funktionierte ohne Probleme, bis ein neuer Benutzer mit Administratorenrechten angelegt wurde.
    Daraufhin hatte nur noch dieser Zugriff auf die Dateien, bei den anderen Usern gab Windows ein "Zugriff verweigert" aus.
    Im Verbindungsprotokoll des QNAP steht hingegen:
    Verbindungstyp: "Samba"
    Genutzte Ressource:" - "
    Aktion: "Login OK".
    Der Zugriff per Weboberfläche funktioniert.
    Windows würde ich ausschließen, da ich vom selben PC, wo der eine Zugriff funktioniert, nach dem Trennen des Laufwerks beim Versuch des Neuverbindens mit einem der anderen Benutzer ebenfalls keinen Zugriff bekomme.


    Nach dem Löschen und Neuanlegens eines der alten Benutzer hatte dieser wieder wie gehabt Zugriff.
    Dies funktionierte jedoch bei den weiteren Nutzern leider nicht.


    Der Übersicht halber noch einmal die Eckdaten:
    QNAP TS-251 mit Firmware-Version 4.2.1 Build 20160601.
    Rechnerbetriebssystem: Win10
    Anmeldung am Rechner per Microsoft Azure Active Directory


    Da Microsoft Azure über Office365 genutzt wird, ist nach meiner Recherche eine direkte Verknüpfung von Azure AD und QNAP leider nicht möglich.



    Falls weitere Informationen benötigt werden, reiche ich diese selbstverständlich gerne nach.


    Vielen Dank und viele Grüße


    Slipe

    Einmal editiert, zuletzt von Slipe () aus folgendem Grund: Azure -> Azure AD

  • Puh so eine Fehlermeldung habe ich auch schon mal gesehen, allerdings nicht in dieser Geräte konstellation.


    Win10 gab es damals noch nicht und mit QNAP hatte die Sache damals auch nichts zu tun. Ich würde mal Richtigung Active Directory suchen.


    Die Lösung weiß ich leider nicht mehr, dürfte bei mir gut und gern 3 Jahre her sein, dass ich diese Fehlermeldung gesehen habe. Ich hatte damals aber viel mit Activ Directory zu tun, daher würde ich in diese Richtung suchen. QNAP kann natürlich nicht ganz ausgeschlossen werden, so weit ich mich erinnere hatten wir schlicht keine QNAPs im Einsatz.

  • Hast du folgendes eingestellt im NAS?


    Systemsteuerung (des NAS) > Netzwerkdienst > Win/Mac/NFS > Erweiterte Option > Höchste SMB-Version SMB 3.0 ??


    Da war irgendwas mit Win10 und SMB 3.0

  • Die SMB-Einstellungen sollten hier nicht das Problem sein. Da ein Azure-AD mit in der Konstellation drin ist, würde ich eher vermuten, dass die Authentifizierung nicht stimmt. Was steht den in den Protokollen drin, mit welchen Benutzernamen die Clients sich authentifizieren?
    Das Problem ist, dass sich in Verbindung mit einer AD-Mitgliedschaft die User-IDs "ändern" bzw. der Domänenname als Prefix vorne dran steht. Und je nach dem, mit welchem Verfahren dein NAS seine User authentifiziert, ist der Domain-Prefix entweder Teil des Benutzernamens oder nicht. Wenn er es ist, aber nicht sein dürfte, oder sein müsste, aber nicht ist, dann meldet sich aus der Sicht des NAS der falsche Benutzer am System an und wird folglich abgelehnt.

  • Danke schon mal für eure Antworten!


    Also SMB 3.0 ist eingestellt. Vorher funktionierte es ja aber.


    Azure wird lediglich zur Anmeldung auf dem Rechner benutzt. Wenn meine Recherchen soweit stimmen, kann ich Azure-AD vom Office 365 nicht als Authentifizierung nutzen, sondern müsste das über einen eigenen Server mit entsprechender IP laufen lassen.
    Mit meinem Account und dann ohne Eingabe weiterer Daten funktioniert es. Bei meinen Kollegen halt leider nicht.


    Benutzername stimmt sowohl mit den Azure- als auch den im QNAP hinterlegten Daten überein.

  • Was heißt "vorher funktionierte es ja aber"? Wann vorher? Vor der Azure-Cloud-Domäne? Vor dem Setzen des SMB 3.0-Hakens?


    Wenn der Client Mitglied der Domäne "home" ist, dann lautet der vollständige Benutzername des Benutzers "mike" entweder "home\mike" oder "mike@cloud". Dem Authentifizierungsverfahren NTLM (das bei SMBv1 und SMBv2 zumindest als Fallback eingesetzt wird, bei SMBv3 bin ich mir nicht sicher) ist die Domäne herzlich egal. Es übermittelt und authentifiziert "mike", nicht "home\mike" oder "mike@home". Wird per Kerberos authentifiziert (was zwischen deinem NAS und den Clients höchstwahrscheinlich nicht der Fall ist, sehr wohl aber zwischen den Clients und dem Azure-AD), dann heißt "mike" eigentlich "mike@home". Und das ist jemand anderes als "mike". Allerdings ist das bei SMBv1, SMBv2 und SMBv3 gleich. Aber es gibt einen Unterschied zwischen SMBv1/SMBv2 und SMBv3 der hier relevant sein könnte: SMBv3 kann die Daten bei der Übertragung verschlüsseln. Dabei ist es enorm wichtig, dass beide Seiten mit dem gleichen Benutzernamen arbeiten.


    Meine Vermutung ist: da dein NAS kein Mitglied der Azure-Domäne und auch sonst keiner Domäne ist, heißt der exemplarische User "mike" bei deinem NAS einfach nur "mike". Der "mike" der Azure-Domäne (die ich jetzt mal "azure_ad" nenne) heißt aber nicht nur "mike", sondern "azure_ad\mike" bzw. "mike@azure_ad". Wenn sich NAS und Client unterhalten, scheitert die Kerberos-Authentifizierung, man fällt auf NTLM zurück und da klappt es, weil die Domäne egal ist. Wenn nun aber ein Client (oder das NAS) den Rückfall auf NTLM verhindert / verbietet, dann kommt keine Benutzerauthentifizierung zu Stande.


    Und wie immer bei Windows kann man so etwas über die Registry (und damit über ein AD) beeinflussen. Wenn ein Client den Rückfall auf NTLM unter SMBv3 verhindert, der andere aber zulässt, klappt beim Einen und beim Anderen nicht.


    Schlussendlich gibt es mehrere Gründe, weshalb das nicht funktioniert. Du musst mehr Daten liefern, um das Problem zu lösen.
    Daher, als nächster Schritt: Was sagen die Protokolle deines NAS dazu? Und was heißt "vorher funktionierte es ja aber"? Wann vorher? Vor der Azure-Cloud-Domäne? Vor dem Setzen des SMB 3.0-Hakens?

  • Hey pocytac,
    sorry dass ich mich da wohl nicht klar ausgedrückt habe.
    Die gesamte Kombination aus Rechnern und QNAP, auch mit dem Einsatz des Azure-AD, bestand schon bevor das Problem auftrat.
    Im Azure und im QNAP ist die selbe Domäne gewählt, gerade damit dieses Problem nicht auftritt. Sprich beide Benutzernamen sind beispielsweise slipe@slipeweb.de
    Außer dem Anlegen eines neuen Benutzers hat sich dort nichts geändert. Lediglich der Servereigene Virenscanner wurde eingerichtet. Um diesen auszuschließen wurde dieser dann aber wieder deaktiviert.
    Zuvor konnten die anderen User auch über ihre eigenen Rechner per W-Lan auf die Daten des QNAP zugreifen. Dazu wurde unter Windows einfach "Verbindung mit anderen Anmeldeinformationen herstellen" und dann die entsprechenden Azur/QNAP Daten benutzt. Auch dies funktioniert seit dem nicht mehr. Der WebZugriff hingegen funktioniert, weswegen QNAP Benutzernamen (und damit die Domäne) und das Passwort zu erkennen scheint. Nur ist dies auf Dauer eben nicht praktikabel.


    Welche Protokolle genau meinst du? Das Systemverbindungsprotokoll? Das gibt die oben gemachten Angaben. Bei mir, der ich Zugriff auf die Daten habe, steht erst:
    Verbindungstyp: "Samba"
    Genutzte Ressource:" - "
    Aktion: "Login OK".
    und danach entsprechend:
    Verbindungstyp: "Samba"
    Genutzte Ressource:" Benutzerdaten "
    Aktion: "Read".


    Benutzernamen sind die passenden, auch mit der Domäne (sprich @domäne.de)

  • Hallo Slipe,


    okay, dann war ich auf dem Holzweg. Wobei deine folgende Ausführung trotzdem danach klingt, dass da mit der Authentifizierung etwas nicht passt.
    Was meinst du mit "im Azure und im QNAP ist die selbe Domäne gewählt"? Ist das NAS Mitglied in der Azure-Domäne? Oder heißen die Domänen nur gleich?

  • Hallo pocytac,
    Danke für deine Mühen.
    Also beide Domänen heißen einfach gleich, damit beim Verbinden keine neuen Anmeldeinformationen übergeben werden müssen.


    Ich habe nun auch eine Rückmeldung vom Support bekommen und dieser guckt sich das ganze mal per Teamviewer an. Vielleicht bin ich danach dann schlauer ;D

  • Der Domänenname spielt eine untergeordnete Rolle und ist mehr für das Auffinden der PCs eine Rolle (DNS), da bei der Anmeldung an einer Domäne die SID eine Rolle spielt bzw. bei der Anmeldung an einer AD-Domäne bekommt der PC/Benutzer ein Identifikations-Ticket (der eine Zeit lang gültig ist) und muss sich an der nächsten Domäne erneut anmelden.


    Unterschiedliche Domänen = unterschiedliche Namen

  • Hallo Slipe,


    habe genau die gleiche Konfiguration wie du und das gleiche Problem!!!!


    Hast du eine Lösung dafür bekommen?


    Danke schon mal für jede Info.


    Joerg