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@xxxxxxxxxxx> 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.
>
>
>
>
>
