I'm not sure if this topic falls under a Windows forum or Linux.

Here's what I'm trying to achieve:

- Expose a file path in Linux through Samba service.
- Mount the same path as a Windows Drive, say X:, on a Windows 2003 Server, as the NT System account, so that services running on windows can see it.
- Allow users who have accounts on the Windows 2k3 server also see the X: drive for read/write access

I have been able to achieve exactly the above when
a) the remote file system was another windows machine and SMB/NetBIOS was used to share/mount/access the drive
b) the remote file system was an NFS mount from a AIX/Unix share

When Linux is used as the file system host, the mount process itself works, and the resulting X: drive can be accessed by the user who mounted it. Of course, in this case the NT System is mounting it and can be accessed as well. However, when another user logs in, he/she can see the X: drive, but a password not correct error pops up when the drive is double-clicked.

The drive is mounted using the standard format:

net use X: \\server-name\path <password> /user:<application-system-user> /persistent:YES

The smb.conf entry for security looks like this:

security = share
passdb backend = tdbsam
valid users = <application-system-user>
path = /shared-path/
writeable = yes
:
:

While I know "security = share" is deprecated, when "security = user" is used instead, the error message complains of a user name and password.

Long term, I may use a domain controller and configure accordingly with the "security = domain" option. But for now I am willing to make it work with the share or user option.

I was able to work around by adding the failed user's username/password in smbpasswd, adding the user to the "valid users" entry in smb.conf, and adding the relevant entry in smbusers.

It looks like Windows 2003 is negotiating the logged on user's credentials instead of what is already mapped within the pre-authenticated mount ! How do I force the share to auto-negotiate using the <application-system-user> credential instead ? Especially since this works fine for the Windows/SMB and Unix/NFS share from the exact same Windows 2003 server (smb client).

The <application-system-user> is a valid Linux account as well as a samba account, with all the right read/write privileges. I've even changed group security policy to use LM, NTLM or even NTLMv2 when possible, within the Windows 2k3 server to see if it's a negotiation error. Made no difference. What am I missing here ?

Any assistance is appreciated.

Regards,
Dev

You really need to use something other than security = share, as not only is is deprecated in Samba, it doesn't work properly in any post-ME version of Windows.

Do you want Samba to authenticate against Active Directory? In that case, what you're looking for is security = ADS, and you will have to create a computer account in AD by "joining" the domain with net ads join.

I will want to use AD authentication later, but not just yet. The purpose right now is to limit access to the Linux share to only users who have access to the Win2k3 server (SMB client). So, as long as they log in to the Windows server through their domain account or a local host account, they can transparently access the share (say, through drive X: ) without having to run scripts, perform mounts, request additional permissions etc.,

I'm willing to drop security = share in a heartbeat, if I can get the prerequisites for security = user to work. What setting can I enter in the smb.conf file and/or change in Windows, to ensure the credential used to mount the share should be the one used to negotiate the logged in user's access instead of their own ?

Moving this thread to Linux-Server, where it belongs. Here's the link if anyone would like to help answering the question:

http://www.linuxquestions.org/questi...08#post4985308