Trust

Jonas Oberg jonas at coyote.org
Wed Oct 6 14:58:43 GMT 1999


Jonas Oberg <jonas at coyote.org> writes:

Since noone else does, I'm answering my own message :-) Please excuse
me for crossposting this to samba-technical, but I think this problem
is more general than the NT Domain code.  What might appear at first
to be a strange problem, actually boils down to a Connection refused
to the broadcast address at the end of this message. Scroll down there
if you're not interested in NT Domains.

This is from the latest CVS HEAD branch running on a system with the
GNU libc 2.1 and a Linux kernel 2.0.36.

Here's what I get when I add a trust on the NT server to the Samba
controler:

> [1999/10/05 15:58:03, 0] smbd/reply.c:session_trust_account(455)
>   session_trust_account: Domain trust account NTSERVER$ denied by server

This message seems to be OK.

> [1999/10/05 15:58:15, 0] smbd/reply.c:reply_sesssetup_and_X(738)
>   NT Password did not match ! Defaulting to Lanman

I think this is because it tries to change the password to some
random string (M$ KnowledgeBase claims that this is what should
happen), but Samba doesn't support this and it fails. This is
probably not a problem.

So, after I've added the Trust on the M$ NT client, I try
to share a directory and select my Samba-domain in the
"List Names From" box.  After some work, it shows the error
message "There are currently no logon servers available
to service the logon request."

Uping the debug level and looking through the nmb logs I
see that the NT server correctly contacts my Samba controller
using the name SAMBA<1c>. The Samba controller tries to match
this against it's own list;

> [1999/10/06 16:39:36, 10] nmbd/nmbd_subnetdb.c:namelist_entry_compare(92)
>  nmbd_subnetdb:namelist_entry_compare()
>  1 == memcmp( "SAMBA<1c>", "^A^B__MSBROWSE__^B<01>", 88 )
> [1999/10/06 16:39:36, 10] nmbd/nmbd_subnetdb.c:namelist_entry_compare(92)
>  nmbd_subnetdb:namelist_entry_compare()
>  1 == memcmp( "SAMBA<1c>", "SAMBA<00>", 88 )
> [1999/10/06 16:39:36, 10] nmbd/nmbd_subnetdb.c:namelist_entry_compare(92)
>  nmbd_subnetdb:namelist_entry_compare()
>  -1 == memcmp( "SAMBA<1c>", "SAMBA<1e>", 88 )
> [1999/10/06 16:39:36, 9] nmbd/nmbd_namelistdb.c:find_name_on_subnet(137)
>   find_name_on_subnet: on subnet 10.0.0.1 - name SAMBA<1c> NOT FOUND

So then, why doesn't <1c> appear in the namelist?  I dig further to see
why this name wasn't registred.

> [1999/10/06 16:38:34, 2] nmbd/nmbd_logonnames.c:become_logon_server(130)
>  become_logon_server: Atempting to become logon server for workgroup SAMBA on subnet 10.0.0.1
> [1999/10/06 16:38:34, 3] nmbd/nmbd_logonnames.c:become_logon_server(133)
>  become_logon_server: go to first stage: register SAMBA<1c> name
> [1999/10/06 16:38:34, 4] nmbd/nmbd_packets.c:initiate_name_register_packet(292)
>   initiate_name_register_packet: sending registration for name SAMBA<1c> (bcast=Yes) to IP 10.0.0.255
> [1999/10/06 16:38:34, 4] libsmb/nmblib.c:debug_nmb_packet(109)
>   nmb packet from 10.0.0.255(137) header: id=20231 opcode=Registration(5) response=No
>       header: flags: bcast=Yes rec_avail=No rec_des=Yes trunc=No auth=No
>       header: rcode=0 qdcount=1 ancount=0 nscount=0 arcount=1
>       question: q_name=SAMBA<1c> q_type=32 q_class=1
>       additional: nmb_name=SAMBA<1c> rr_type=32 rr_class=1 ttl=259200
>       additional   0 char ....Ce   hex 800082F34365

So far so good, we create the package and is about to send it away..

> [1999/10/06 16:38:34, 5] libsmb/nmblib.c:send_udp(715)
>   Sending a packet of len 68 to (10.0.0.255) on port 137
> [1999/10/06 16:38:34, 0] libsmb/nmblib.c:send_udp(722)
>   Packet send failed to 10.0.0.255(137) ERRNO=Connection refused

Oups!  This didn't work right!

> [1999/10/06 16:38:34, 0] nmbd/nmbd_packets.c:send_netbios_packet(133)
>   send_netbios_packet: send_packet() to IP 10.0.0.255 port 137 failed
> [1999/10/06 16:38:34, 0] nmbd/nmbd_nameregister.c:register_name(355)
>   register_name: Failed to send packet trying to register name SAMBA<1c>

And of course, we never note that we are SAMBA<1c>, thus in reality we
never become the logon server.  I should also note that I get the same
error message while trying to register SAMBA<1d>.  Would someone care
to explain to me why this isn't working and what I can do to make it
working?


Jonas


More information about the samba-technical mailing list