Windows AD - Debian Samba DC - Domain Trust - Probleme mit SMB Berechtigungen
Hallo zusammen,
ich habe ein kleines Problem und weiß aktuell nicht mehr wo ich suchen könnte.
Ich habe einen Domain Trust zwischen einem Windows Active Directory und einem Debian Samba DC hergestellt.
Jetzt habe ich in beiden Domains einen Fileserver und möchte beide Domains auf beide Fileserver zugreifen lassen.
Hierzu müssen einige Anpassungen an den Grupper durchgeführt werden.
In beiden Domains existieren Gruppen im Gruppenbereich Local und Global.
In den Global Gruppen sind meine Benutzer als Mitglieder gelistet.
In den Local Gruppen sind meine gleichnamigen Global Gruppen aus beiden Domains als Mitglieder gelistet.
Beispiel:
Windows=DomainA
Debian=DomainB
Global_Group_DomainA: User1_DomainA, User2_DomainA
Local_Group_DomainA: Global_Group_DomainA, Global_Group_DomainB
Global_Group_DomainB: User3_DomainB, User4_DomainB
Local_Group_DomainB: Global_Group_DomainA, Global_Group_DomainB
Auf meinem Debian SMB Share habe ich die Local_Group_DomainB für Berechtigungen eingetragen. Hier funktionieren die eingestellten Berechtigungen (rwx) wie geünscht. Beide Benutzer aus beiden Domains haben die richtigen Berechtigungen und können mit (r) nur lesen und mit (rw) lesen und schreiben.
Wenn ich das Ganze jetzt unter Windows teste, und in meiner Freigabe und Berechtigung die Gruppe Local_Group_DomainA eintrage, erhält mein Windows Benutzer die gewünschten Berechtigungen. Jedoch kann mein Debian Benutzer nicht einmal auf die Freigabe zugreifen. Dies ist erst möglich, wenn ich in der Freigabe und Berechtigung die Gruppe Local_Group_DomainB eintrage. Das ist jedoch nicht Sinn und Zweck der Sache und ich müsste bei meinem vorhandenen Fileserver alle Berechtigungen neu setzten. Das ist aktuell unmöglich.
Ich könnte mir Vorstellen, dass dies nicht nur bei SMB Freigaben auftritt.
Hat jemand eine Idee weshalb das für die Debian Freigabe funktioniert, und für meine Windows Freigabe nicht?
ich habe ein kleines Problem und weiß aktuell nicht mehr wo ich suchen könnte.
Ich habe einen Domain Trust zwischen einem Windows Active Directory und einem Debian Samba DC hergestellt.
Jetzt habe ich in beiden Domains einen Fileserver und möchte beide Domains auf beide Fileserver zugreifen lassen.
Hierzu müssen einige Anpassungen an den Grupper durchgeführt werden.
In beiden Domains existieren Gruppen im Gruppenbereich Local und Global.
In den Global Gruppen sind meine Benutzer als Mitglieder gelistet.
In den Local Gruppen sind meine gleichnamigen Global Gruppen aus beiden Domains als Mitglieder gelistet.
Beispiel:
Windows=DomainA
Debian=DomainB
Global_Group_DomainA: User1_DomainA, User2_DomainA
Local_Group_DomainA: Global_Group_DomainA, Global_Group_DomainB
Global_Group_DomainB: User3_DomainB, User4_DomainB
Local_Group_DomainB: Global_Group_DomainA, Global_Group_DomainB
Auf meinem Debian SMB Share habe ich die Local_Group_DomainB für Berechtigungen eingetragen. Hier funktionieren die eingestellten Berechtigungen (rwx) wie geünscht. Beide Benutzer aus beiden Domains haben die richtigen Berechtigungen und können mit (r) nur lesen und mit (rw) lesen und schreiben.
Wenn ich das Ganze jetzt unter Windows teste, und in meiner Freigabe und Berechtigung die Gruppe Local_Group_DomainA eintrage, erhält mein Windows Benutzer die gewünschten Berechtigungen. Jedoch kann mein Debian Benutzer nicht einmal auf die Freigabe zugreifen. Dies ist erst möglich, wenn ich in der Freigabe und Berechtigung die Gruppe Local_Group_DomainB eintrage. Das ist jedoch nicht Sinn und Zweck der Sache und ich müsste bei meinem vorhandenen Fileserver alle Berechtigungen neu setzten. Das ist aktuell unmöglich.
Ich könnte mir Vorstellen, dass dies nicht nur bei SMB Freigaben auftritt.
Hat jemand eine Idee weshalb das für die Debian Freigabe funktioniert, und für meine Windows Freigabe nicht?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 591692
Url: https://administrator.de/forum/windows-ad-debian-samba-dc-domain-trust-probleme-mit-smb-berechtigungen-591692.html
Ausgedruckt am: 21.04.2025 um 18:04 Uhr
13 Kommentare
Neuester Kommentar
Hi,
Domänenlokale Gruppen kann man nicht an Ressourcen von Mitgliedern anderer Domänen berechtigen. Selbst wenn man das irgendwie über die API und SID in die ACL eintragen kann, wird das nicht funktionieren.
Wenn das also bei Dir angeblich funktioniert, dann schau mal genau hin, ob Du Dich nicht selbst täuschst. Ob nicht irgendwas tatsächlich ganz anders ist, als Du annimmst.
E.
Edit:
Könnte es sein, dass Du tatsächlich die Gruppe Global_Group_DomainB eingetragen hast?
Zitat von @joe2017:
... Dies ist erst möglich, wenn ich in der Freigabe und Berechtigung die Gruppe Local_Group_DomainB eintrage.
Wenn das geht, dann ist da was grundsätzliches faul.... Dies ist erst möglich, wenn ich in der Freigabe und Berechtigung die Gruppe Local_Group_DomainB eintrage.
Domänenlokale Gruppen kann man nicht an Ressourcen von Mitgliedern anderer Domänen berechtigen. Selbst wenn man das irgendwie über die API und SID in die ACL eintragen kann, wird das nicht funktionieren.
Wenn das also bei Dir angeblich funktioniert, dann schau mal genau hin, ob Du Dich nicht selbst täuschst. Ob nicht irgendwas tatsächlich ganz anders ist, als Du annimmst.
E.
Edit:
Könnte es sein, dass Du tatsächlich die Gruppe Global_Group_DomainB eingetragen hast?
Zitat von @joe2017:
Wenn ich auf meinem Debian DC die Local_Group öffne, sehe ich unter Mitglieder den Global_Group Namen von meinem Samba DC. Den Global_Group Namen meines Windows AD bekomme ich nicht aufgelöst, sondern nur als SID angezeigt.
Vielleicht ist hier das Problem zu suchen.
Ja, mit Sicherheit.Wenn ich auf meinem Debian DC die Local_Group öffne, sehe ich unter Mitglieder den Global_Group Namen von meinem Samba DC. Den Global_Group Namen meines Windows AD bekomme ich nicht aufgelöst, sondern nur als SID angezeigt.
Vielleicht ist hier das Problem zu suchen.
Zitat von @joe2017:
Wie Du das mit der Gruppenverschachtelung meinst und den Berechtigungen über die domänenlokalen Gruppen - das ist klar. Das ist ja nichts besonderes.
Ich wollte Dich darauf hinweisen, dass das, was Du in Deiner Eingangsfrage geschrieben hast, technisch nicht möglich ist. Also kannst Du das so auch nicht gemacht haben. Lies einfach nochmal genau, was ich geschrieben habe.
Also meine Ordnerberechtigung habe ich mit Local_Group versehen.
Du hast meinen Hinweis nicht verstanden.Wie Du das mit der Gruppenverschachtelung meinst und den Berechtigungen über die domänenlokalen Gruppen - das ist klar. Das ist ja nichts besonderes.
Ich wollte Dich darauf hinweisen, dass das, was Du in Deiner Eingangsfrage geschrieben hast, technisch nicht möglich ist. Also kannst Du das so auch nicht gemacht haben. Lies einfach nochmal genau, was ich geschrieben habe.
Defacto ist es so, dass der Betrachter die SID's auflöst.
Wenn Du Dir also von einem Client aus mit dem Windows Explorer die ACL eines Objekts auf einem Server anschaust, dann muss der Client die SID's übersetzen können, nicht der Server.
Wenn Du direkt auf dem Samba Server die ACLs anschaust oder die Gruppenmitgliedschaft, dann muss der Samba Server die SID's übersetzen können.
Wenn Du Dir also von einem Client aus mit dem Windows Explorer die ACL eines Objekts auf einem Server anschaust, dann muss der Client die SID's übersetzen können, nicht der Server.
Wenn Du direkt auf dem Samba Server die ACLs anschaust oder die Gruppenmitgliedschaft, dann muss der Samba Server die SID's übersetzen können.
Zitat von @joe2017:
Ich habe gerade gesehen das hinter den SID´s unter (Active Directory-Domänendienste-Ordner) nicht DOMAIN-WINDOWS.NET steht, sondern DOMAIN-DEBIAN.NET/ForeignSecurityPrincipals
Was OK ist und entsteht z.B., wenn man Konten extern vertrauter Domänen in Gruppen der eigenen Domäne zum Mitglied macht. Und wenn ein Client eine SID nicht "echt" auflösen kann, dann greift er auf diese ForeignSecurityPrincipals zurück. Das sind quasi "Proxy"-Objekte.Ich habe gerade gesehen das hinter den SID´s unter (Active Directory-Domänendienste-Ordner) nicht DOMAIN-WINDOWS.NET steht, sondern DOMAIN-DEBIAN.NET/ForeignSecurityPrincipals