Moin Liste, ich habe da ein kleines Problem: ich habe einen M$ 2003 Server und möchte von einem betagten Linux Server auf einen Share zugreifen. Der Share soll nur für einen Gruppe zugänglich sein. Nun ist es so, dass auf beiden Maschinen NICHT die gleichen User vorhanden sind. Meine Idee (welche auch bei älteren M$ Systemem funktioniert), ich lasse den 2003 Server die Authentifikation übernehmen: [global] workgroup = linuxnet os level = 2 security = server password server = server-ms guest account = ftp encrypt passwords = yes printing = BSD printcap name = /etc/printcap socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY wins support = no character set = ISO8859-15 client code page = 850 username map = /usr/samba/usermap.txt [freigabe] comment = freigabe-verzeichnis path = /home/freigabe browseable = no guest ok = no valid users = @zugelassen writeable = yes create mask = 0666 ---------------------------------------------------- usermap.txt zugelassen = @kleine root = administrator Administrator ---------------------------------------------------- Das Problem ist ...es funktioniert nicht ... Er meint es wäre ein falscher Benutzername/oder Passwort eingegeben. Welche Samba-Version muss ich einsetzten damit es funktioniert ?? Ist was an der Konfiguration verkehrt ?? Gruss Stefan ########################################## # Teile Dein Wissen, denn das ist ein Weg # Unsterblichkeit zu erlangen (Dalai Lama) # ;o)
Hallo auch, also da Du wohl bis jetzt noch gar keine Antwort bekommen hast, sag ich mal was - aber ansich bin ich recht Ahnungslos und wollte mich deswegen zurückhalten ;-) Am Donnerstag, 16. Februar 2006 13:18 schrieb Stefan Klemz:
ich habe einen M$ 2003 Server und möchte von einem betagten Linux Server auf einen Share zugreifen. Der Share soll nur für einen Gruppe zugänglich sein. Nun ist es so, dass auf beiden Maschinen NICHT die gleichen User vorhanden sind. Meine Idee (welche auch bei älteren M$ Systemem funktioniert), ich lasse den 2003 Server die Authentifikation übernehmen: Ich verstehe jetzt nicht ganz wie Du dir das Vorstellst, aber für mich klingt das wie eine Anbindung von Samba an das ADS von W2k3 - wenn Du das willst ist schon mal diese Zeile falsch: security = server Das sollte doch so aussehehen: security = ADS ABER du redest von nem "betagten Linux Server"; und das mit der Anbindung an eine ADS geht erst ab Samba 3 (soweit ich weiß).
Also sollte es sich wirklich um die Anbindung an ein ADS handeln, dann kann ich vielleicht weiter helfen; ich mußte nämlich völlig ohne Vorahnung sowas vor zwei Wochen realisieren - und im Nachhinein war es auch recht einfach. Das Problem war lediglich, dass in den Docus und HowTos irgendwie die Namensgebung der Umgebung nie so 100% beschrieben war - aber da ist es extrem wichtig an manchen stellen GROSS und an anderen klein zu schreiben; dann ist es wichtig Rechnername und Domänenname auseinander zu halten, in den Beispielen war das meist gleich - in meiner realität aber nicht ;-) Ein Link der mir geholfen hatte war: http://us2.samba.org/samba/docs/man/Samba-Guide/unixclients.html Und dann hab ich noch so einiges an Brainstorming Notizen, z.B. hab ich lange gesucht, bis ich rausfand, dass die resolve.conf unbedingt richtig angepast werden muß. Oder es stand nirgens, dass es durchaus Minuten dauern kann, bis winbind richtig läuft. Na viel Glück und vielleicht konnte ich ja ein wenig helfen Gruß Torben
Moin Torben, Danke für Deine Antwort. Du bist tatsächlich der einzige der sowas schon gemacht hat - oder anderen wollen nicht antworten ;o) Die betagten Linux Server sind SuSE Linux 7.2/8.2 ... was aber erstmal nicht so schlimm ist. Ich probiere mal aus Samba auf den "alten" Kisten zu übersetzen. Mußtest Du mit Kerberos und/oder LDAP auf Deinen Linux Maschinen arbeiten?? Hast Du eventuell eine Beispiel smb.conf für mich ?? Würde mir ne' Menge Arbeit abnehmen. Besten Dank Stefan
Hi zusammen, Hi Stefan nochmal vorweg: Ich mußte es ans laufen bekommen - und ich hab es ans laufen bekommen. ABER Erfahrung hab ich nicht wirklich, und der derzeitige Betrieb zeigt auch noch ein paar Performance-Probleme; allerdings nicht nur im Samba bereich, sondern auch auf dem ADS-Server - diese Probleme gab es vor der anbindung nicht, sind aber sicher noch zu beseitigen. Ich gehe jetzt kurz auf deine Fragen ein, und schreib unten mal alles "am Stück" was ich so in erinnerung habe (oder mitgeschrieben habe). Vielleicht hilft es ja irgendwann auch wem anders - irgendwann will ich eh ein (mein) HowTo draus machen weil ich es noch schlecht documentiert finde. Ich bitte aber auch alle um Anmerkungen/Ergänzungen, dann bekommen wir vielleicht zusammen was richtig Hilfreiches hin ;-) Am Mittwoch, 22. Februar 2006 09:52 schrieb Stefan Klemz:
Die betagten Linux Server sind SuSE Linux 7.2/8.2 ... was aber erstmal nicht so schlimm ist. Ich probiere mal aus Samba auf den "alten" Kisten zu übersetzen. Also ich würde glaube ich auf der "betagten" Hardware lieber ein aktuelles Linux aufspielen - aber ok, das ist ja nicht immer möglich. Fakt ist: es muß mind. Samba 3 sein. Und das Samba muß mit etlichen "unterstützungen" Kompiliert sein. Ich hatte dazu zwar ne Liste und auch wie man es testet, aber entweder ist die auf der Kopie gewesen, die jetzt mein Kollege hat, oder unter diesem Link: http://us2.samba.org/samba/docs/man/Samba-Guide/unixclients.html der aber jetzt gerade / oder nicht mehr erreichbar ist. ABER: wir hatten SuSE 10.0 (Kauf-CD-Version) und da waren alle Voraussetzungen gegeben.
Mußtest Du mit Kerberos und/oder LDAP auf Deinen Linux Maschinen arbeiten?? Ein klares JEIN - also ich mußte in der Conf von Kerberos was anpassen, mehr unten.
Hast Du eventuell eine Beispiel smb.conf für mich ?? Jo hab ich, aber dann einfach mal alles der Reihe nach ;-)
Also jetzt mein "Brainstorming" das mal ein "HowTo" werden will: 1) Grundsätzlich sind folgende Dateien zu bearbeiten: /etc/samba/smb.conf /etc/nsswitch.conf /etc/pam.d/samba /etc/resolve.conf /etc/krb5.conf 1.1) /etc/samba/smb.conf Änderungen fanden nur in der Global-Section statt, alle weiteren Freigaben haben wir für die Tests komplett entfernt und NUR mit einer Freigabe gearbeitet. Hier das Listing: [global] unix charset = LOCALE workgroup = DRBRP netbios name = FS01 comment = Fileserver realm = DRBRP.LOCAL server string = Samba security = ADS username map = /etc/samba/smbusers log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 50 printcap name = CUPS ldap ssl = no idmap uid = 10000-20000 idmap gid = 10000-20000 # aus Docu, aber meldet Fehler: template primary group = "Domain Users" template shell = /bin/bash winbind separator = + printing = cups # Naechste beiden wurden manchmal Empfolen, aber geht auch ohne: # password server = * # encrypt passwords = yes [daten] comment = Userdaten path = /home/daten read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ Anmerkung/Erklärungen dazu: - Unsere Workgroup hieß "DRBRP", die GROSSSCHREIBUNG schien wichtig - Rechnername (bzw. gewünschter NetBiosName) war "FS01" (FileServer01) - Super-Wichtig ist die richtige angabe von realm, dieser Name muß mit den Angaben in der /etc/krb5.conf und der ADS-Konfiguration harmonieren! - security muss ADS sein, ansonsten geht nichts mit der anbindung - da in vielen Docus "password server" und "encrypt passwords" als bedingung genannt wurde, sind sie mit aufgelistet. Ging bei uns aber ohne. Die smb.conf kann so getestet werden: testparm /etc/samba/smb.conf Dabei muß nicht jeder Fehler schlimm sein (z.B. aus unser Conf wird 'winbind separator = +' beanstandet, macht aber Laut Docu Sinn) 1.2) /etc/nsswitch.conf Wir haben die Einträge zu "passwd" und "group" Auskommentiert und folgende darunter geschrieben: --- snip --- # passwd: compat # group: compat passwd: files winbind shadow: files winbind group: files winbind --- snip --- (Ob der group Eintrag unbedingt nötig ist, ist fraglich - ich behaupte ja) 1.3) /etc/pam.d/samba Die Orginal-Datei wurde wie folgt ergänzt: #%PAM-1.0 auth include common-auth account include common-account password include common-password session include common-session # ab hier dazugeschrieben Auth required pam_unix.so Auth required /lib/security/pam_securetty.so Auth required /lib/security/pam_nologin.so Auth sufficient /lib/security/pam_winbind.so Auth required /lib/security/pam_pwd.so use_first_pass shadow nullok Account required /lib/security/pam_winbind.so Erklärungen dazu hab ich keine, hab ich hier so gefunden und es klappte: http://lists.suse.com/archive/suse-linux/2004-Sep/2913.html 1.4) /etc/resolve.conf Ein nicht zu unterschätzender Teil - wird die resolve.conf nicht angepast, klappt nichts; auch wenn der Rest sonst völlig in Ordnung ist. So sah sie bei uns aus: nameserver 192.168.115.1 search drbrp.local Dabei ist 192.168.115.1 die IP des Servers mit dem ADS und drbrp.local der Name (die Domäne) des ADS. Hier ist wieder so eine Namensfalle, sprich es muß mit den Angaben in der smb.conf (Workgroup und realm) harmonieren und mit den Angaben in /etc/krb5.conf Aber hier scheint kleinschreibung Pflicht ;-) 1.5) /etc/krb5.conf So ein weiteres Rätsel was ich hier gemacht habe, hab es so ähnlich gefunden und es klappt. Fakt ist hier wird die GROSSschreibung noch mal super WICHTIG!!! Geändert/Angepast wurde eigendlich nur die drei Bereiche libdefaults, realms, domain_realms. Wieder muß die harmonierung mit Vorgenannten Files und dem ADS sichergestellt sein. [libdefaults] default_realm = DRBRP.LOCAL [realms] DRBRP.LOCAL = { kdc = 192.168.115.1 } [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log [domain_realms] .DRBRP.LOCAL = DRBRP.LOCAL [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 try_first_pass = true } 2) ggf. alte Files Löschen (besser ist das): rm /etc/samba/secrets.tdb rm /var/lib/samba/*.tdb Wurde ein Fehlgeschlagener oder unbefriedigender Versuch unternommen, sich an das ADS anzumelden sollten m.E. diese Files immer wieder gelöscht werden bevor ein neuer Versuch unternommen wird. 3) Laufen smb, nmb, winbind? Auch später nach änderungen mal restarten rcsmb restart rcnmb restart rcwinbind restart Hier mal ne WARNUNG zu winbind: nur weil es gestartet wurde, läuft es noch nicht gleich, es dauert manchmal sehr sehr lange bis es wirklich "durchgestartet" hat. Das ist wichtig wenn mehrfach versuche gemacht werden, beim ersten test ist das noch recht bedeutungslos, weil Punkt vier ja erst noch kommt ;-) 4) In ADS Aufnehmen: net ads join -l -U Administrator (Achtung: War der Rechner schon mal aufgenommen, ggf. erst im ADS löschen und mind. 30.min. warten vor neuaufnahme - das ist ein Windows Problem. Ein neustart des Win-Servers kann helfen, muß aber nicht.) Wieder ein Befehl der lange dauert - das ist so richtig! Nicht abbrechen!!! 5) jetzt erste Tests, z.B. ob wbinfo -u wbinfo -g Die User/Gruppen der Domain ausgibt. Und (wichtig) ob getent passwd getent group Die User / Gruppen im /etc/passwd "Look" ausgibt. Weitere Testbefehle z.B.: net ads info net ads status -U Administrator Tja man glaubt es kaum - und schon lief es alles :) Gruß Torben
participants (2)
-
Stefan Klemz -
Torben Schultz