[PATCH] Allow GetDCNameEx to be called for arbitrary sites and trusted domains

[Garming Sam]

Hi,

Using Volker's patches, the "No nmbd found" disappears, but the site
aware location is wrong (meaning the RPC call must fail in these cases).
It seems that the underlying dsgetdcname call does not respect the site
name parameter in winbind when using NETBIOS names. I've also noticed
that although I test the winbind forwarding and having different
domains, it doesn't actually test being in a different site (partly
because we don't have any DCs like that in selftest currently). With my
full patchset, making the query using a trust NETBIOS domain name AND a
specified site may fail if there is more than one site (or it
arbitrarily picks a DC whose site differs). Compared with the original
behaviour at least, that's significantly better, and all the DNS domains
should work as well as the single domain case with NETBIOS (where it's
currently remedied at the RPC layer).

To fix the trusted domain case, either dsgetdcname needs to use the
response from discover_dc_netbios to retry the query with the DNS realm
(this is on top of Volker's patches). Or it needs to do some other
mapping using information winbind might know. I've got a number of other
projects that I need to be working on, so I can't really look into this
further. I would really like to push this current patchset for now
(assuming you don't have any further objections), so as to fix most of
the cases just by implementing the forwarding behaviour, and hopefully
there's enough info that I've gathered to go on to fix the edge cases
around trusted domains (and presumably undo the RPC layer NETBIOS fix I
made).

Cheers,

Garming

On 05/04/18 14:16, Garming Sam wrote:
> On 05/04/18 11:29, Garming Sam via samba-technical wrote:
>> On 05/04/18 03:25, Stefan Metzmacher wrote:
>>> I also noticed that wb_irpc_GetDCName_done() should return the result of
>>> wb_dsgetdcname_recv() as application result using:
>>>
>>> state->r->out.result = status; and
>>> irpc_send_reply(state->msg, NT_STATUS_OK);
>>>
>>> and the memory context passed to wb_dsgetdcname_recv() should be
>>> state->dcinfo (if it's a valid talloc pointer) or state->msg
>> Right, I see, you want me to embed the error within the response, so as
>> to not confuse top level errors. It seems that in other cases in the
>> file wb_*_recv isn't supposed to fail, and I was just following the
>> pattern of the others.
> Addressed this now hopefully.
>
>> The flags from the original request are passed down to winbind, who will
>> correctly interpret them. The only thing I modify is the inbound flags
>> (which are separate from the outbound ones e.g. DS_RETURN_FLAT_NAME),
>> which would only affect the default format of the response.
> You should also note that there are some tests for DS_RETURN_FLAT_NAME
> in my patchset, which are asserting that the short trust name is returned.
>
> Cheers,
>
> Garming
>
>>
>> In regards to why it doesn't work with NETBIOS, I noticed this log
>> (searching for a Windows DC):
>>
>> /home/ubuntu/samba/bin/smbd: 10.9.0.11 (ipv4:10.9.0.11:55217) connect to
>> service IPC$ initially as user SAMDOM\Administrator (uid=0, gid=100)
>> (pid 15027)
>> /home/ubuntu/samba/bin/winbindd: dns_send_req: Failed to resolve
>> _ldap._tcp.default-first-site-nae._sites.dc._msdcs.samdom (Success)
>> /home/ubuntu/samba/bin/winbindd: ads_dns_lookup_srv: Failed to send DNS
>> query (NT_STATUS_UNSUCCESSFUL)
>> /home/ubuntu/samba/bin/winbindd: dns_send_req: Failed to resolve
>> _ldap._tcp.dc._msdcs.samdom (Success)
>> /home/ubuntu/samba/bin/winbindd: ads_dns_lookup_srv: Failed to send DNS
>> query (NT_STATUS_UNSUCCESSFUL)
>> /home/ubuntu/samba/bin/winbindd: resolve_lmhosts: Attempting lmhosts
>> lookup for name samdom<0x1c>
>> /home/ubuntu/samba/bin/winbindd: resolve_wins: WINS server resolution
>> selected and no WINS servers listed.
>> /home/ubuntu/samba/bin/winbindd: name_resolve_bcast: Attempting
>> broadcast lookup for name samdom<0x1c>
>> /home/ubuntu/samba/bin/winbindd: Got a positive name query response from
>> 10.9.0.12 ( 10.9.0.12 )
>> /home/ubuntu/samba/bin/winbindd: Got a positive name query response from
>> 10.9.0.12 ( )
>> /home/ubuntu/samba/bin/winbindd: Got a positive name query response from
>> 10.9.0.10 ( 10.9.0.10 )
>> /home/ubuntu/samba/bin/winbindd: No nmbd found
>>
>> source3/libsmb/clidgram.c: nbt_getdc_send
>>
>>         state->nmbd_pid = pidfile_pid(lp_pid_directory(), "nmbd");
>>         if (state->nmbd_pid == 0) {
>>                 DEBUG(3, ("No nmbd found\n"));
>>                 tevent_req_nterror(req, NT_STATUS_NOT_SUPPORTED);
>>                 return tevent_req_post(req, ev);
>>         }
>>
>> So it seems that it relies on nmbd running in order to make any further
>> identification. This seems to be the expected code path, so selftest
>> must have some additional records or some other method that circumvents
>> this. I'm also not confident about the site-awareness of the above calls
>> that are being triggered. It is possible that someone actually has to do
>> the NETBIOS name to DNS name conversion at some layer to get this right.
>> The goal for me was to mostly just plumb the call and ensure the single
>> domain case works as expected.
>>
>>
>> Cheers,
>>
>> Garming
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20180406/69620694/signature.sig>