Here's the code to make winbindd work on a Samba DC

Here's the code to make winbindd work on a Samba DC
to handle domain trusts.  Jeremy and I talked about this
and it's going in as working code.  It keeps winbind clean
and solves the trust problem with minimal changes.

To summarize, there are 2 basic cases where the deadlock would
occur.  (1) lookuping up secondary groups for a user, and
(2) get[gr|pw]nam() calls that fall through the NSS layer because
they don't exist anywhere.

o To handle case #1, we bypass winbindd in sys_getgrouplist() unless
  the username includes the 'winbind separator'.

o Case #2 is handled by adding checks in winbindd to return failure
  if we are a DC and the domain matches our own.

This code has been tested using basic share connections, domain
logons, and with pam_winbind (both with and without 'winbind
use default domain').  The 'trustdomain' auth module should work
as well if an admin wants to manually create UNIX users for
acounts in the trusted domains.

Other misc fixes:

  * we need to fix check_ntlm_password() to be able to determine
    if an auth module is authoritative over a user (NT_STATUS_WRONG_PASSWORD,
    etc...).  I worked around my specific situation, but this needs to be
    fixed.  the winbindd auth module was causing delays.
  * fix named server mutex deadlock between trust domain auth module
    and winbindd looking up a uid
  * make sure SAM_ACCOUNT gets stored in the server_info struct for the
    _net_sam_logon() reply.

Configuration details:

The recommended method for supporting trusts is to use winbind.
The gets us around some of the server mutex issues as well.

  * set 'files winbind' for passwd: and group: in /etc/nsswitch.conf
  * create domain trusts like normal
  * join winbind on the pdc to the Samba domain using 'net rpc join'
  * add normal parameters to smb.conf for winbind
  * set 'auth method = guest sam winbind'
  * start smbd, nmbd, & winbindd

Problems that remain:

  * join a Windows 2k/XP box to a Samba domain.
  * create a 2-way trust between the Samba domain
    and an NT domain
  * logon to the windows client as a user from theh trusted
    domain
  * try to browse server in the trusted domain (or other
    workstations).  an NT client seems to work ok, but 2k
    and XP either prompt for passwords or fail with errors.

apparanently this never got tested since no one has ever been
able to logon as a trusted user to a Samba domain from a Windows
client.