Dear All,
I have two AD domains, one running on Windows 2000 and one running on Windows 2003. Each with XP clients, and no trust.
Ihave a linux file server running samba 3 on Centos 4.2, the smb.conf file specifies that security=server, and points the password server to the operations master on the Windows 2000 domain.
All clients and 2000 servers on the Windows 2000 domain, (xp or otherwise) can access the smb shares on the linux box no problem.
The windows 2003 server and XP clients on that domain cannot, first time round they receive the error "The request is not supported", after adding this:
client signing = auto
to my smb.conf file I get the error "the filename, directory name or volume label syntax is incorrect."
I tried disabling packet signing on the win2k3 box group policy - it made no difference.
I disconnect the linux server from using the windows 2000 server as a password server and setup up separate smb accounts and it works fine from the win2k3 box.
I believe this is something to do with packet signing but just cant seem to find out the problem. I fixed this on a previous linux server the other way round (mounting 2k3 on Linux, but can't remember how I did it), I note that that server has a /proc/fs/cifs directory where I can kill packet signing, but the new server with the current problem does not. However I don't recall installing cifs nor does it seem to be on the older server.
Any ideas?
Pete
Peter Farrow peter@farrows.org wrote:
I have two AD domains, one running on Windows 2000 and one running on Windows 2003. Each with XP clients, and no
trust.
... I disconnect the linux server from using the windows 2000 server as a password server and setup up separate smb
accounts
and it works fine from the win2k3 box.
I'm really scratching my head here because I think you just identified the reality of your situation -- the limitation of your Windows clients, not any configuration issue with Samba server.
Samba will gladly handle authentication fine, even across domains that don't have trusts between them. The problem is that your Samba server has a computername and related SID in only one domain. Windows clients
Even if you configure the Samba server to be a member server in both domains, you still have differing SIDs on the objects stored and presented. So various Windows clients in each domain may balk at the SIDs of objects presented in RPC calls.
I could be mistaken, but this issue has far more to do with SIDs and what the Windows clients do and don't know about, than the Samba server configuration. SIDs are everything in the NT security model, and are very, very different than UID/GID of the legacy UNIX model.
Nope,
The samba server is not a member of either domain and has no sid in that respect, its simply doing passthru authentication to the 2000 server box, using the password server directive in smb.conf.
In a test environment removing the 2003 domain controller and replacing it with another 2000 controller it works fine. Its to do with 2003 server. XP clients when connect to a 2003 server automatically start packet signing because the domain controller policy says "do it if its possible", I changed this to "don't do it" but it still didn't work.
This isn't a SID issue,
Pete
Bryan J. Smith wrote:
Peter Farrow peter@farrows.org wrote:
I have two AD domains, one running on Windows 2000 and one running on Windows 2003. Each with XP clients, and no
trust.
... I disconnect the linux server from using the windows 2000 server as a password server and setup up separate smb
accounts
and it works fine from the win2k3 box.
I'm really scratching my head here because I think you just identified the reality of your situation -- the limitation of your Windows clients, not any configuration issue with Samba server.
Samba will gladly handle authentication fine, even across domains that don't have trusts between them. The problem is that your Samba server has a computername and related SID in only one domain. Windows clients
Even if you configure the Samba server to be a member server in both domains, you still have differing SIDs on the objects stored and presented. So various Windows clients in each domain may balk at the SIDs of objects presented in RPC calls.
I could be mistaken, but this issue has far more to do with SIDs and what the Windows clients do and don't know about, than the Samba server configuration. SIDs are everything in the NT security model, and are very, very different than UID/GID of the legacy UNIX model.
-
Bryan J. Smith -
Peter Farrow