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

Volker Lendecke Volker.Lendecke at SerNet.DE
Fri Apr 6 06:25:56 UTC 2018


Hello!

Just FYI: I have a big (unfinished) patchset in preparation that
rewrites source3/libsmb/dsgetdcname to be fully async and a lot more
correct and flexible and that rely on the patches you are working upon
now.

With best regards,

Volker Lendecke

On Fri, Apr 06, 2018 at 04:23:00PM +1200, Garming Sam via samba-technical wrote:
> 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
> >>
> >>
> 
> 




-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de



More information about the samba-technical mailing list