[TriLUG] My SAMBA hell continues
Ryan Leathers
Ryan.Leathers at globalknowledge.com
Wed Sep 25 11:45:57 EDT 2002
Thanks to Jon for his response.
Troubles remain...
My distribution is Redhat 7.3 with smbd version 2.2.3a
I now have security=server set in the smb.conf on 2 of my Linux servers.
These point at my third Linux server which is set with security=user.
Other settings are listed at the bottom of this message. No Win2K or NT
servers are members of this workgroup. User PC's are running Win2K Pro
and are members of another domain.
I am able to browse, map drives and manipulate files using shares of all
3 Linux servers. My user ID and password stored on the 'security=user'
server happen to be the same as the user ID and password I use to
access the company domain.
Problem: When I try to map drives to Linux SMB shares using the
credentials of another user (other than what I used when I logged into
my Win2K PC in the company domain) the mapping fails. Here is an
example.
=============================================================
D:\>net use * \\IP_address_of_target\testuser /u:testuser
The password or user name is invalid for
\\IP_address_of_target\testuser.
Type the password for \\IP_address_of_target\testuser:
System error 1326 has occurred.
Logon failure: unknown user name or bad password.
I have verified that the user id and password are correct and I have
updated the smbpasswd file using the same shell script used for my
working account.
It seems to me that the credentials used for my company domain should
have nothing to do with authentication on my Linux servers - the fact
that the same strings are used is coincidence.
Still, this is the only account that can browse and map drives both in
the company domain and the Linux server workgroup.
Am I wrong ? Is there something else going on ?
Ryan
# Global parameters
[global]
workgroup = PILOT
netbios name = PILOT1
server string = Dell 8450 Redhat 7.3
interfaces = eth2
encrypt passwords = Yes
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
unix password sync = Yes
log file = /var/log/samba/%m.log
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
preferred master = True
dns proxy = No
hosts allow = (x.x.x. my RFC 1918 subnet here)
printing = lprng
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
[additional shares have been sanitized]
There are few reason not to add the servers to your present network.
You have an existing PDC on your subnet (even though its a windows
server...) - point your samba server to that for authentication. You can
use either server authentication or domain authentication. If you use
server authentication then point to either a PDC or a BDC.
Please note that if you use server, it will authenticate each and every
file access, while if you choose domain, it will cache the
authentication for a period or time.
If you choose to Authenticate to a local samba server then you have
quite a bit of work ahead for yourself - but I'm sure you already know
that.
In any case you will have to setup local users/groups on each server
(though Samba lets you create these automagically on authenticated
access).
Browseability of the servers should be easy enough. You can use either
WINS or DNS (Win2k pro has the ability to use DNS for its browseable
base).
At my former company I authenticated using all of the above methods with
no difficulties. Good Luck in your quest. BTW: what distribution are
you using? and what version of Samba?
Jon Carnes
On Tue, 2002-09-24 at 17:45, Ryan Leathers wrote:
> I'm migrating services from Win2k to Linux. The majority of my end
> users are sticking with windows on their desktop PC's.
> I am in need of some sound advice in handling authentication of users
> who "browse" SMB shares on Linux servers.
>
> In my pilot, I have 3 Linux servers running SMB. They are part of the
> same workgroup/domain. I am compelled to leave the existing domain
> alone and build this new workgroup during the pilot. I suppose it's
> most correct to call it a workgroup since there are no NT or Win2k
hosts
> (no domain controllers).
> Authentication is being handled per user. End users have Win2k Pro on
> their PC's and are generally logged in as members of another domain.
My
> problems are: synchronization of credentials, visibility of Linux SMB
> shares in browse lists on the Win2k hosts.
>
> My current plan: configure the Linux servers to point to one place for
> credentials. I will still have a credential conflict since users are
> members of a domain and a workgroup. They want to use a single set of
> uid/passwd for both. By setting the security=server option and
picking
> one of the Linux servers to be that server I hope to simplify my life.
> At least this way the credentials will be consistent for all shares on
> the Linux servers. To aid in my quest for "browsability" I plan on
> making the authentication server handle WINS chores and point the
others
> at it.
>
> Any thoughts ?
>
> Ryan
> -----Original Message-----
> From: Jon Carnes [mailto:jonc at nc.rr.com]
> Sent: Tuesday, September 24, 2002 7:53 AM
> To: trilug at trilug.org
> Subject: Re: [TriLUG] Suse releases exchange server clone ($999) no
> client licenses
>
> It's also worthy to note that this is now the cheapest drop-in
> replacement for an Exchange server. It's 40% cheaper than the previous
> Linux solution. This may not be a mile-stone for Open Source, but it
is
> certainly one for the evolution of Linux in the workplace.
>
> Migrating folks off of proprietary MS solutions is made difficult by
> their dependence on Exchange. If you remove the Exchange dependency
then
> you break the strongest lock that MS has on small and medium sized
> businesses.
>
> Also, this adds more competition into that market - which drops prices
> and encourages better more responsive programming and services. It's
a
> big deal for Linux to have these solutions available and actively
being
> developed. It's also a big deal to contractors (like me) who setup
Linux
> based services for folks - or even help them migrate off of MS
products
> over to cheaper Linux based solutions.
>
> The next nice thing will be when LDAP (or some Directory Services) is
> fully functional and supported with easy installations and
> administration.
>
> Jon Carnes
>
> On Tue, 2002-09-24 at 08:43, Ben Pitzer wrote:
> > Can this group ever get past the flame-bait distro bashing? C'mon,
> > folks, whatever your personal preference, other distros have
redeeming
> > qualities, too. And while the Skyrix portion of this product may be
> > closed source, it may be exactly what somebody needs to start to
move
> > towards Linux and an open source, non-Exchange clone groupware
> platform.
> >
> > Regards,
> > Ben Pitzer
> >
> > PS - Sorry to pick on you, Tom. Nothing personal. I've seen it,
and
> > thought about it before, and your post just reminded me that I
wanted
> to
> > say something.
> >
> > > I looked at this product before they released, and the important
> pieces
> > > (Skyrix) are closed source, in typical SuSE fashion.
> >
> > _______________________________________________
> > TriLUG mailing list
> > http://www.trilug.org/mailman/listinfo/trilug
> > TriLUG Organizational FAQ:
> > http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
>
>
> _______________________________________________
> TriLUG mailing list
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ:
> http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
_______________________________________________
TriLUG mailing list
http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ:
http://www.trilug.org/~lovelace/faq/TriLUG-faq.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3061 bytes
Desc: not available
URL: <http://www.trilug.org/pipermail/trilug/attachments/20020925/8318f461/attachment.bin>
More information about the TriLUG
mailing list