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

Garming Sam garming at catalyst.net.nz
Wed Apr 4 23:29:41 UTC 2018

On 05/04/18 03:25, Stefan Metzmacher wrote:
> +	if (!NT_STATUS_IS_OK(status)) {
> +		DBG_NOTICE("DC location via winbind failed - %s\n",
> +			   nt_errstr(status));
> +		state->r.out.result = WERR_NO_SUCH_DOMAIN;
> +		goto finished;
> +	}
> info and info[0] is non-NULL should also be checked in a separate if
> statement, with a DBG_ERR or DBG_WARNING message indicating something
> like an internal error.
> 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.

> So, in general, when you specify the domain name as a NETBIOS name,
> Windows seems to return the DC UNC in NETBIOS form (and this follows the
> same pattern with DNS names). All this patch means is that we end up
> returning DNS names (for DCs outside our site), but if you specify the
> flag to return a particular format, everything is as expected.
> To me the patch looks like it's forcing the dns name even if the client
> asked for a netbios name (DS_IS_FLAT_NAME) explicitly.

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.

In regards to why it doesn't work with NETBIOS, I noticed this log
(searching for a Windows DC):

/home/ubuntu/samba/bin/smbd: (ipv4: 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
/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
/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 ( )
/home/ubuntu/samba/bin/winbindd: Got a positive name query response from ( )
/home/ubuntu/samba/bin/winbindd: Got a positive name query response from ( )
/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.



-------------- 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/20180405/696793f5/signature.sig>

More information about the samba-technical mailing list