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.