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?
Das sieht nach SIDs aus, also den AD-internen IDs, mit denen die tatsächliche Berechtigung stattfindet (u.a. damit man Benutzernamen nachträglich ändern kann). In den ACL-Tabellen im Dateisystem werden immer nur diese SIDs gespeichert. Dass du unter Windows normale Benutzernamen siehst, liegt daran, dass diese SIDs (wenn möglich) in Benutzernamen aufgelöst werden. Es gibt viele Gründe, weshalb das nicht klappt.
Ich würde sagen: Wie sieht's denn aus, wenn du mit einem Windows-Client auf die Freigabe schaust? Und gibt es überhaupt Fehler, die damit im Zusammenhang stehen könnten, zum Beispiel Zugriffsprobleme?
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?
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.
