Hallo Thomas, Thomas Harding schrieb:
Ich gehe davon aus das die Meldung vom Client-PC kommt und der die Anmeldung verweigert. nicht der Server.
Die Meldung wird sowohl vom smbclient auf einer remote Linux-Box, als auch vom smbclient auf dem Server selbst zurückgegeben. Der smbclient holt seine Optionen auch aus der smb.conf, und die config auf dem server stand auf client plaintext auth = yes, weswegen ich auch darauf hingewiesen habe, dass selbst der smblient auf dem server gestartet kein Share öffnen durfte.
Wenns ein XP-Client war, liegt das dadran das seit Windows 2k oder XP (is so lange her) die Passwörter verschlüsselt werden müssen (jedenfalls default) das verhalten kannst du mit "start -> ausführen -> gpedit.msc" und dann bei "Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security options" umstellen
und zwar mit der option "Microsoft network client: Send unencrypted password to connect to third-party SMB servers"
das ganze musst dann enabled werden
!! DAS IST ABER UNSICHER UND NICHT EMPFOHLEN !!
Richtig, es ist unsicher. Da in unseren Netzen überwiegend MacOSX und Linux vertreten sind, ist es zusätzlich auch einfach etwas dämlich, da man drei verschiedene Workarounds kommunizieren muss.
was ich an deiner stelle machen würde ist ein kleines LDAP aufsetzen und die auth dann gg das ldap verz. zu machen (AD ist auch so ne art LDAP sprich verz. dienst) IMHO
Der Server ist direkter Ersatz für einen Win2003SBS, da wir eigentlich keinerlei Verzeichnisdienste brauchen. Deswegen war der primäre Wunsch, es so einfach wie möglich zu gestalten:D, also wirklich nur Unix-User anlegen und gut is. Mir schwebte heute die Idee im Kopf umher, pam irgendwie auf kerberos laufen zu lassen, damit es die von samba durchgereichten tokens versteht. Wie das gehen soll, weiß ich allerdings noch nicht. Beziehungsweise ob es zu zufriedenstellenderen Ergebnissen führt;)
mfg
Thomas
Gruß Ron