I'm trying to get winbindd working (2.2.6pre2) but it won't start because it claims to not find the domain controller (Samba as PDC) that the rest of the network is happily using.
-d10 output from winbindd: Could not open a connection to U_MTPPI for \PIPE\lsarpc (NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND) Digging into the code, winbindd gets a list of domain controllers via broadcast and then confirms each directly with a unicast query to the controller itself (in cm_get_dc_name in winbindd_cm.c) specifically querying the 0x1c role. That query is coming into nmbd as a unicast query. from log.nmbd: process_node_status_request: status request for name U_MTPPI<1c> from IP 192.168.92.56 on subnet UNICAST_SUBNET. Well, it seems that my nmbd isn't registering itself with a 0x1c on the UNICAST_SUBNET, because the GET_NEXT_SUBNET_INCLUDING_UNICAST macro (really the get_next_subnet_maybe_unicast function) only returns the unicast subnet as part of that linked list if the samba server is a WINS client. So the domain controller is not responding to the request from winbindd. Winbindd fails to get secrets, and does not work. If there's a way to make that query not come in as a unicast, then that's probably the best fix, but I don't know how, or even if it's possible. So, I can either fix winbindd to not directly confirm 0x1c, but maybe just use another role (0x1e?) or fix nmbd to register 0x1c on the UNICAST_SUBNET by replacing the GET_NEXT_SUBNET_INCLUDING_UNICAST with an alternative implementation of that get_next_subnet_maybe_unicast that returns the UNICAST_SUBNET even when not a WINS client. What's best? Does NT/2000/XP put itself on the UNICAST_SUBNET with the 0x1c role when it's acting as the PDC? Thanks, Kevin Stefanik
