Folgendes Szenario ist bei einem Kunden beobachtet worden: Zwei Memberserver wurden als File-Server für Windows und Linux eingesetzt. Die Berechtigungen wurden über POSIX ACLs gesetzt auf Basis von Gruppen gesetzt. Der Zugriff lokal und über NFS hat korrekt funktioniert, d.h. die Gruppenberechtigungen wurden richtig ausgewertet. Beim Zugriff über Samba war dies nicht der Fall. Auf keine der Freigaben konnte zugegriffen werden wenn der Benutzer nicht Eigentümer war oder für den Rest der Welt Rechte vergeben waren. Der Join-Status (net rpc testjoin) war ok und auch ein Neustart der Dienste (nscd, winbind und samba) hat das Problem nicht behoben. Ein erneuter Join (univention-join oder net join -U Administrator) hat daran ebenfalls nichts geändert. Es sollte hier geprüft werden, ob dieses Problem in einer Standardumgebung nachgestellt werden kann. Als Workaround wurde folgendes durchgeführt: - Die primäre Gruppe des Fileservers wurde auf eine Gruppe mit Windows-Attributen gesetzt. Dafür musste die sambaPrimaryGroupSID manuell angepasst werden - In der Samba-Konfiguration folgende Zeile ergänzen: passdb backend = ldapsam:"ldap://<FQDN eines DC Systems>" - winbind stoppen
Das ist jetzt bei einem zweiten Kunden nach dem Update aufgetreten.
Erneut aufgetreten: Ticket#: 2010011310000418
In /var/log/samba/log.winbindd-idmap findet man viele Meldungen der Art ldap_set_mapping_internals: Failed to add S-1-5-21-796845957-1547161642-839522115-187984 to 50811 mapping [gidNumber] ldap_set_mapping_internals: Error was: (NULL) (Already exists) wie auch z.B. hier http://forum.soft32.com/linux/Samba-Problem-LDAP-idmap-backend-ftopict491632.html beschrieben. Die SIDs sind dabei die von existierenden Gruppen, die sowohl am Gruppenobjekt, als auch unter cn=idmap,cn=univention ein Mapping zu einer gidNumber haben. (Beispieloutput an Ticket#: 2010011310000418) Nur scheint winbind diese Daten irgendwie nicht zu verwenden. Auch eine Anpassung der idmap Konfiguration durch setzen des Domänennamens in die UCR-Variable 'samba/idmap/domains' und Aufruf von 'net idmap secret DOMAENENNAME `</etc/machine.secret` brachte keine Verbesserung. Vorerst wurde auch in diesem Fall als Workaround die 'passdb backend' Zeile eingetragen und winbind gestoppt.
Die Doku zur idmap Konfiguration in Samba 3.3.x ist etwas sparsam: http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#IDMAPCONFIG http://www.samba.org/samba/docs/man/manpages-3/idmap_ldap.8.html http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#LDAPIDMAPSUFFIX Es gibt eine Darstellung der Unterschiede in den verschiedenen Samba-Versionen: http://samba.org/~obnox/presentations/sambaXP-2009/sambaxp-2009-talk-obnox-slides-paper.pdf
Sollten wir dann das ldap passdb Backend auf dem Memberserver wieder zum Default machen? Oder welchen Vorteil haben wir durch die Verwendung von winbind?
Stefan wies auf folgendes Statement in der smb.conf hin: -------------------------- idmap config (G) range = low - high Defines the available matching uid and gid range for which the backend is authoritative. Note that the range commonly matches the allocation range due to the fact that the same backend will store and retrieve SID/uid/gid mapping entries. winbind uses this parameter to find the backend that is authoritative for a unix ID to SID mapping, so it must be set for each individually configured domain, and it must be disjoint from the ranges set via idmap uid and idmap gid. In idmap_ldap(8) steht dazu: --------------------------- IDMAP OPTIONS range = low - high Defines the available matching uid and gid range for which the backend is authoritative. If the parameter is absent, Winbind fails over to use the "idmap uid" and "idmap gid" options from smb.conf.
Müsste man testen, diese Passage der Dokumentation wurde in der Tat mit dem Checkin des idmap-Konfigugurations-rewites für 3.3 eingefügt: http://www.mail-archive.com/samba-cvs@lists.samba.org/msg52021.html Andererseits sagt gerade das Changelog fpr 3.3.0: ------------------------------------------------- smb.conf changes ---------------- Parameter Name Description Default -------------- ----------- ------- cups connection timeout New 30 idmap config DOM:range Removed idmap domains Removed ------------------------------------------------ Also sollte man hier zum Test mal sowas Ähnliches wie die letzten vier Zeilen des folgenden Blocks mit einfügen: --------------------------------------------------------- ; idmap/winbind idmap backend = ldap:ldap://${ldap_server_name}/ ldap idmap suffix = cn=idmap,cn=univention idmap uid = 55000-64000 idmap gid = 55000-64000 idmap alloc backend = ldap idmap alloc config : ldap_user_dn = ${samba/user} idmap alloc config : ldap_url = ldap://${ldap_server_name}/ idmap config ${windows_domain} : ldap_user_dn = ${samba/user} idmap config ${windows_domain} : ldap_url = ldap://${ldap_server_name}/ idmap config ${windows_domain} : backend = ldap idmap config ${windows_domain} : range = 0 - 54999 --------------------------------------------------------- die letzten zwei Zeilen wären manuell einzufügen, die ldap_* Zeilen sollte das aktuelle Template schon selbst durch setzen von samba/idmap/domains=${windows_domain} schreiben. Damit die LDAP-Authentifikation klappt, muss man auch wieder net idmap secret ${windows_domain} `</etc/machine.secret` aufrufen, siehe Join-Script.
Ich glaube wir haben in unserer internen Umgebung das gleiche Problem, ggf. liegt das aber auch daran, dass wir zunächst auf die Beta-Version aktualisiert haben: stefan@omar:~$ ldapsearch -x sambaSID=S-1-5-21-3980132504-3533172963-4083691310-11055 dn gidNumber -LLL dn: cn=cvs,cn=groups,dc=knut,dc=univention,dc=de gidNumber: 1004 stefan@omar:~$ getent group cvs cvs:*:1004:[...] stefan@omar:~$ wbinfo -Y S-1-5-21-3980132504-3533172963-4083691310-11055 Could not convert sid S-1-5-21-3980132504-3533172963-4083691310-11055 to gid Vielleicht kannst du das dort auch nochmal prüfen.
Tests an einem lokalen Memberserver haben folgendes ergeben: 1. Für das Mapping SID -> Gruppen-Name ist anscheinend die Zeile passdb backend = ldapsam:"ldap://%s" % ucr.get('ldap/server/name') notwendig in smb.conf. Damit funktioniert dann die Auflösung mit 'net groupmap list', aber wbinfo -Y geht weiterhin nicht. root@omar:# net groupmap list ntgroup=test1234 [2010/02/04 15:22:05, 0] lib/smbldap_util.c:smbldap_search_domain_info(310) smbldap_search_domain_info: Adding domain info for OMAR failed with NT_STATUS_UNSUCCESSFUL test1234 (S-1-5-21-3980132504-3533172963-4083691310-3057) -> test1234 root@omar:# wbinfo -n test1234 # Name to SID geht immer S-1-5-21-3980132504-3533172963-4083691310-3057 Domain Group (2) root@omar:# wbinfo -Y S-1-5-21-3980132504-3533172963-4083691310-3057 Could not convert sid S-1-5-21-3980132504-3533172963-4083691310-3057 to gid 2. bei samba/debug/level='0 passdb:5 auth:4 winbind:10' sieht man in /var/log/samba/log.winbindd-idmap , dass idmap_ldap nach '(&(objectClass=sambaIdmapEntry) (sambaSID=S-1-5-21-3980132504-3533172963-4083691310-3057))' sucht, also nicht nach sambaGroupMapping Objekten. Schlussfolgerung ist erstmal, dass winbind 'normale' Gruppenobjekte nicht anschaut und daher auch mit 'wbinfo -Y' nichts zurückliefert. 3. In der UCS 2.3-0 standard Memberserver-Konfiguration scheint winbind/idmap_ldap für Gruppen, die es nicht auflösen kann neue sambaIdmapEntry Objekte mit neuer gidNumber unter cn=idmap,cn=univention anzulegen: root@omar:# wbinfo -Y S-1-5-21-3980132504-3533172963-4083691310-3055 55056 Wenn man die 'idmap config DOM : ' Zeilen zusätzlich einträgt (mit ldap_user_dn, ldap_url, backend, range und ggf. ldap_base_dn) scheint man das vermeiden zu können (DOM= UCR:windows/domain). 3.b) Dieses neue Mapping merkt sich winbind irgendwo, obwohl das sambaIdmapEntry Objekt und zusatzlich folgende Dateien gelöscht wurden: -rw------- 1 root root 28672 4. Feb 12:18 /var/cache/samba/winbindd_cache.tdb -rw------- 1 root root 12288 18. Feb 2009 /var/cache/samba/idmap_cache.tdb Empfehlungen: a) passdb backend Zeile eintragen. b) wbinfo -Y nur zum Debugging von Gruppen in Vertrauensstellungen nutzen c) damit nochmal Memberserver alleine und mit Vertrauensstellung testen d) untersuchen ob dabei weiter neue sambaIdmapEntry Objekte angelegt werden und ob zur Vermeidung die zusätzlichen 'idmap config DOM : ' Zeilen ausreichen.
Mit folgender Anpassung an der smb.conf scheint es zu funktionieren: > + idmap config UNIVENTION : backend = nss > + idmap config UNIVENTION : range = 1-54999 > + # winbind trusted domains only = yes > - winbind trusted domains only = yes idmap_nss (http://www.samba.org/samba/docs/man/manpages-3/idmap_nss.8.html) ist laut http://www.samba.org/~jerry/slides/sambaxp_idmapv4.pdf Ersatz für 'winbind trusted domains only', die mit 3.0.24 reingekommen ist (siehe Bug 8766). Vermutlich funktioniert die pre-3.0.24 Einstellung jetzt durch der den Konfigurations-Rewrite in 3.3.0 nicht mehr wie zuvor. Eine Verhaltensänderung, deren Auswirkung man prüfen sollte, ist, dass jetzt das Prefix mit ausgegeben wird: root@qamember:~# wbinfo -g [...] UNIVENTION+testgroup1 UNIVENTION+testgroup2 Akut an diesem Bug ist, dass winbind mit der UCS 2.3-0 Konfiguration sambaIdmapEntry Objekte mit neuer gidNumber für UCS Gruppen verteilt (3. Punkt von Kommentar #c9 oben) und sich dieses Mapping zusätzlich zum LDAP an bisher unbekannter Stelle cached (Punkt 3.b). Ein Workaroud für diesen Bug ist an Bug 17573 für UCS 2.3-1 implementiert.
Beim Test zu Bug 17591 fiel auf, dass das ggf. noch einfacher geht, ohne für windows/domain explizit ein idmap-Backend Konfiguration eintragen zu müssen: ; idmap/winbind idmap backend = nss # default backend idmap uid = 55000-64000 idmap gid = 55000-64000 idmap alloc backend = ldap idmap alloc config : ldap_user_dn = ${ldap_hostdn} idmap alloc config : ldap_url = ldap://${ldap_server_name} # winbind trusted domains only = yes
Workaround: Die durch Winbind verursachten Probleme bei dem Zugriff auf Freigeben mit Gruppenberechtigungen können umgangen werden indem die Samba-Konfiguration um folgende Zeile ergänzt und winbind angehalten wird: passdb backend = ldapsam:"ldap://ucs.ldap.server" Zu beachten ist, dass diese Konfiguration zu mehr LDAP-Anfragen gegen den angegebenen LDAP-Server führt. Damit die Anpassung bei Neugenerierung der smb.conf durch Univention Config Registry erhalten bleiben, sollten diese auch im entsprechenden Template (/etc/univention/templates/files/etc/samba/smb.conf.d/11univention-samba_ldap) vorgenommen werden.
Die Konfiguration wurde entsprechend Comment 7 angepasst. Damit greift winbind jetzt wieder authentifiziert auf LDAP zu, wenn es idmap-Einträge sucht. "wbinfo -Y" funktioniert damit wieder und Samba scheint dadurch dann auch Authentifikationen wieder besser hinzubekommen. Die an Comment 10 vorgeschlagene Umstellung auf idmap_nss ist für 2.3-2 zu groß und die an Comment 11 vorgeschlagene Konfiguration ist von Samba bisher nicht dokumentiert (es ist empfohlen immer ein schreibbares backend in 'idmap backend' anzugeben). Changelog: Zur Behebung von Problemen mit der Gewährung von Samba-Zugriffsberechtigungen bei Einsatz von winbind wurde die idmap-Konfiguration angepasst, sodass winbind jetzt wieder authentisierte Suchen im UCS-Verzeichnsdienst durchführen kann. Dazu wird die in \ucsCommand{\ucsBCindex{windows/domain}} eingetragene Domäne jetzt im Join-Script von \ucsName{univention-samba} ebenfalls in die \ucsUCRV{samba/idmap/domains} eingetragen. Nebenbei wird der Hostname des lokalen Systems wieder aus der Variable entfernt. Bei Bedarf lässt sich zusätzlich über die neue Familie von Univention Config Registry"=Variablen \ucsCommand{\ucsBCindex{samba/idmap/<DOMAIN>/range}} der Bereich der Posix IDs anpassen, die für das ID"=Mapping einer bestimmten Samba"=Domäne verwendet werden soll.
fixed in 2.3-2
Damit das auch nach /usr/lib/univention-server/server_password_change noch weiter funktioniert, habe ich dies jetzt zusätzlich in univention-server um die Zeilen erweitert, die dann das idmap secret für das alloc backend und die in samba/idmap/secret hinterlegten Domains auf das neue machine.secret setzen. Neu gebaut für UCS 2.3-2
Das Mapping funktioniert leider noch nicht mit den Paketen aus ucs2.3-2. 1) samba/idmap/domains gesetzt ; idmap/winbind idmap backend = ldap:ldap://qamaster.univention.qa ldap idmap suffix = cn=idmap,cn=univention idmap uid = 55000-64000 idmap gid = 55000-64000 idmap alloc backend = ldap idmap alloc config : ldap_user_dn = cn=qamember,cn=memberserver,cn=computers,dc=univention,dc=qa idmap alloc config : ldap_url = ldap://qamaster.univention.qa idmap config UNIVENTION : backend = ldap idmap config UNIVENTION : range = 1000-64000 idmap config UNIVENTION : ldap_user_dn = cn=qamember,cn=memberserver,cn=computers,dc=univention,dc=qa idmap config UNIVENTION : ldap_url = ldap://qamaster.univention.qa Falls es im LDAP unter cn=idmap kein Mapping für die Gruppe gibt, findet wbinfo kein mapping und es wird auch keines angelegt, damit bleibt es bei den Berechtigungsproblemen im Samba (keine Zugriff auf Ordner obwohl es per ACL auf Gruppenbasis funktionieren sollte). Achtung, falls die Primäre Gruppe des Benutzers die Gruppe aus den ACL's ist, funktioniert es, hier zum Test also in den ACL's ein Gruppe != Primäre Gruppe des Benutzers wählen Falls es ein unter cn=idmap Mapping gibt, wird dies verwendet und die Berechtigungsprobleme sind behoben, wenn die dortige gid gleich der gid aus dem Gruppenobjekt ist (da solche ID Mapping Objekt mit UCS 2.3-0 falsch möglicherweise falsch angelegt wurden, könnte es auch hier zu Problemen kommen) 2) samba/idmap/domains nicht gesetzt ; idmap/winbind idmap backend = ldap:ldap://qamaster.univention.qa ldap idmap suffix = cn=idmap,cn=univention idmap uid = 55000-64000 idmap gid = 55000-64000 idmap alloc backend = ldap idmap alloc config : ldap_user_dn = cn=qamember,cn=memberserver,cn=computers,dc=univention,dc=qa idmap alloc config : ldap_url = ldap://qamaster.univention.qa winbind trusted domains only = yes winbind nested groups = no Falls es kein Mapping unter cn=idmap gibt, wird eines angelegt, aber mit einer gid aus dem range, in meiner Testumgebung hatte die Gruppe Domain Users dann unter cn=idmap die gid 55045 (eigentlich 5001 am LDAP Objekt). Über Samba wird dann kann dann nicht auf den Ornder zugegriffen werden Falls es ein Mapping unter idmap gibt: Da in diesem Fall die Mappins nicht richtig ausgelesen werden, versucht winbind eines im ldap anzulegen, dies klappt aber nicht (da schon eines existiert) und es wird kein Mapping zurückgeben und es gibt wieder die Berechtigungsprobleme. Set DN sambaSID=S-1-5-21-29764662-496752969-2650431501-513,cn=idmap,cn=univention,dc=univention,dc=qa (S-1-5-21-29764662-496752969-2650431501-513 -> 55044) [2010/02/08 17:05:59, 5] lib/smbldap.c:smbldap_add(1501) smbldap_add: dn => [sambaSID=S-1-5-21-29764662-496752969-2650431501-513,cn=idmap,cn=univention,dc=univention,dc=qa] [2010/02/08 17:05:59, 10] lib/smbldap.c:smbldap_add(1521) Failed to add dn: sambaSID=S-1-5-21-29764662-496752969-2650431501-513,cn=idmap,cn=univention,dc=univention,dc=qa, error: 68 (Already exists) (unknown) [2010/02/08 17:05:59, 0] winbindd/idmap_ldap.c:idmap_ldap_set_mapping(1449) ldap_set_mapping_internals: Failed to add S-1-5-21-29764662-496752969-2650431501-513 to 55044 mapping [gidNumber] [2010/02/08 17:05:59, 0] winbindd/idmap_ldap.c:idmap_ldap_set_mapping(1451) ldap_set_mapping_internals: Error was: (NULL) (Already exists) [2010/02/08 17:05:59, 3] winbindd/idmap.c:idmap_new_mapping(719) Could not store the new mapping: NT_STATUS_UNSUCCESSFUL [2010/02/08 17:05:59, 10] winbindd/idmap_util.c:idmap_sid_to_gid(291) idmap_new_mapping failed: NT_STATUS_UNSUCCESSFUL [2010/02/08 17:05:59, 10] lib/gencache.c:gencache_set(131) Adding cache entry with key = IDMAP/SID2GID/S-1-5-21-29764662-496752969-2650431501-513; value = -1 and timeout = Mon Feb 8 17:07:59 2010 (120 seconds ahead) 3) Mit einem UCS 2.3 System und der dortgigen Konfiguration werden falsche Mapping Objekte unter cn=idmap angelegt. Dies könnte bei 1) zu Problemen führen. Um das Mapping auf dem lokalen System (member) zu löschen, habe ich folgendes verwendet: /etc/init.d/samba stop && /etc/init.d/winbind stop rm /var/run/samba/gencache.tdb rm /var/cache/samba/winbindd_cache.tdb /etc/init.d/samba start && /etc/init.d/winbind start
idmap_ldap sucht nur unter cn=idmap nach Objekten vom Typ sambaIdmapEntry. Für trusted domains ist das ok, aber nicht für die UCS-Samba-Domäne, da hier die sambaGroupMapping Objekte nicht berücksichtigt werden. ( http://lists.samba.org/archive/samba-technical/2007-February/051474.html ) Für windows/domain wird jetzt idmap_nss mit default range 1000-54999 verwendet. Der Posix-ID Bereich ist anpassbar über samba/idmap/$windows_domain/range. In samba/idmap/domains werden nur die Domänen eingetragen, für die idmap_ldap verwendet werden soll.
Wenn kein samba/idmap/domains gesetzt ist, sieht das smb.conf so aus: idmap backend = ldap:ldap://qamaster.univention.qa ldap idmap suffix = cn=idmap,cn=univention idmap uid = 55000-64000 idmap gid = 55000-64000 idmap alloc backend = ldap idmap alloc config : ldap_user_dn = cn=qamember,cn=memberserver,cn=computers,dc=univention,dc=qa idmap alloc config : ldap_url = ldap://qamaster.univention.qa winbind trusted domains only = yes winbind nested groups = no Kein nss vorhanden?
Das Template ist angepasst und das changelog ebenfalls: Zur Behebung von Problemen mit der Gewährung von Samba-Zugriffsberechtigungen bei Einsatz von winbind wurde die idmap-Konfiguration angepasst, sodass winbind jetzt Benutzer und Gruppen im UCS Verzeichnisdienst über den Name Service Switch (\emph{idmap_nss}) auflöst. Der Hostname des lokalen Systems wieder aus der \ucsUCRV{samba/idmap/domains} entfernt. Bei Bedarf lässt sich zusätzlich über die neue Familie von Univention Config Registry"=Variablen \ucsCommand{\ucsBCindex{samba/idmap/<DOMAIN>/range}} der Bereich der Posix IDs anpassen, die für das ID"=Mapping einer bestimmten Samba"=Domäne verwendet werden soll. Als neue Voreinstellung wird die \ucsUCRV{samba/winbind/trusted/domains/only} jetzt bei Neuinstallationen nicht mehr gesetzt und die entsprechende von Samba nicht mehr unterstützte Einstellung \emph{winbind trusted domains only} wird in \ucsURL{/etc/samba/smp.conf} nur noch verwendet, wenn die \ucsUCRV{} weiterhin auf \emph{yes} gesetzt ist. Das Script \ucsName{server_password_change} aktualisiert jetzt auch das für \emph{idmap_ldap} hinterlegte Maschinen"=Passwort.
Mit nss funktionieren die ACL's auch vom Windows (in gleicher Domäne). Das Problem mit trusted domains wird in bug#18291 weiter behandelt.
UCS 2.3-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".