Bug 8805 - CIFS cannot join Samba4 Domain
CIFS cannot join Samba4 Domain
Status: NEW
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
unspecified
x64 Solaris
: P5 major
: ---
Assigned To: Andrew Bartlett
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-09 20:01 UTC by Michael Farnbach
Modified: 2013-11-25 02:19 UTC (History)
2 users (show)

See Also:


Attachments
snoop -x packet sniff for samba server (25.84 KB, application/octet-stream)
2012-03-10 17:55 UTC, Michael Farnbach
no flags Details
Samba -d4 log (6.94 KB, text/plain)
2012-03-10 17:58 UTC, Michael Farnbach
no flags Details
Samba -d10 log (73.74 KB, text/plain)
2012-03-10 18:00 UTC, Michael Farnbach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Farnbach 2012-03-09 20:01:29 UTC
I'm trying to join CIFS to Samba4 domain with the following...

# smbadm join -u "GARDENHOME\administrator

And I get the following results...

Joining GARDENHOME ... this may take a minute ...
failed to join GARDENHOME: UNSUCCESSFUL
Please refer to the system log for more information.

In the system log I see,

Mar  9 12:45:21 indi smbd[16109]: [ID 232655 daemon.notice] ldap_modify: DSA is unwilling to perform
Mar  9 12:45:21 indi smbd[16109]: [ID 702911 daemon.notice] Failed to modify the workstation trust account.
Mar  9 12:45:21 indi smbd[16109]: [ID 871254 daemon.error] smbd: failed joining GARDENHOME (UNSUCCESSFUL)

Samba log shows no errors.

The good news is that you can see from the source code what its trying to do to be added...

http://src.opensolaris.org/source/

More specifically the smb_join...


http://src.opensolaris.org/source/search?q=&project=onnv&defs=&refs=smb_join&path=&hist=
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/smbsrv/libsmb/common/smb_doorclnt.c#115
http://src.opensolaris.org/source/s?refs=SMB_DR_JOIN&project=onnv
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/smbsrv/smbd/smbd_doorsvc.c#111
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/smbsrv/smbd/smbd_doorsvc.c#smbd_dop_join
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/smbsrv/smbd/smbd_join.c#smbd_join
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/smbsrv/smbd/smbd_join.c#smbd_join_domain
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/smbsrv/libmlsvc/common/mlsvc_util.c#mlsvc_join




For the record, I'm using the internal Samba DNS and to get it even this far I had to manually add the following SRV records to dnsmasq to augment the internal DNS...

srv-host=_ldap._tcp.dc._msdcs,actived.garden.home,3268,0,100
srv-host=_ldap._tcp.dc._msdcs.garden.home,actived.garden.home,3268,0,100
srv-host=2A4CBEB7-48BD-4615-856F-61339489BD47._msdcs.garden.home,actived.garden.home,3260,0,100
srv-host=_kerberos-master._udp.garden.home,actived.garden.home,3268,0,100

The _ldap._tcp.dc._msdcs record was found as an A record, and Solaris demands it be an SRV record.

The 22A4CBEB7-48BD-4615-856F-61339489BD47 record is actually the NTDS DNS Alias for the domain controller.
Comment 1 Andrew Bartlett 2012-03-09 21:29:34 UTC
First, please try this without dnsmasq in any way involved. 

This has worked before, so a bisection could possibly assist, or at least searching for the commits fixing it last time could help tell us if it is your environment or Samba. 

https://wiki.samba.org/index.php/Capture_Packets

A network trace and a level 4 (as a start) log on the Samba side may help.
Comment 2 Jeremy Allison 2012-03-10 01:11:37 UTC
Can you post a debug level 10 from the Samba side, so we can see how far it gets before it gives up ?

Thanks,

Jeremy.
Comment 3 Michael Farnbach 2012-03-10 17:55:07 UTC
Created attachment 7370 [details]
snoop -x packet sniff for samba server

Here is a packet trace on the server side created with 'snoop -x'.

Created during a reproduction of the bug relayed.
Comment 4 Michael Farnbach 2012-03-10 17:58:11 UTC
Created attachment 7371 [details]
Samba -d4 log

Log of the bug reproduced with `samba -d4'.

corresponds directly with the packet sniff also attached.
Comment 5 Michael Farnbach 2012-03-10 18:00:41 UTC
Created attachment 7372 [details]
Samba -d10 log

Log of a reproduction of the bug, with 'samba -d10'

Done separate of the packet sniff provided.
Comment 6 Michael Farnbach 2012-03-10 18:06:03 UTC
Thanks to all for your attention on this.

I tried to get the debug and packet sniffs for without dnsmasq, but now the entries are cached on the client. I'll do more research to find out how to flush them out adequately and get that to you later.

But for what it is worth, the log shows that the name associated with the entry is queried, but not returned. When I checked with host, and dig, I found that there were A entries for some of the names, but no SRV entries.

If you don't mind, unless we can determine how that impacts this bug directly let me get my ducks in a row on that and submit as a separate bug?
Comment 7 Ben Dischinger 2013-10-30 04:47:33 UTC
FYI, I also ran into this bug attempting to join Solaris CIFS to a properly configured Samba 4.1 DC domain.

The Solaris CIFS server was receiving the following error:

Oct 29 22:18:24 pixel-mn smbd[29460]: [ID 232655 daemon.notice] ldap_modify: Insufficient access
Oct 29 22:18:24 pixel-mn smbd[29460]: [ID 702911 daemon.notice] Workstation trust account update failed

The Samba server was denying access based on an ACL entry.

[2013/10/29 21:47:28.360513, 10, pid=28721, effective(0, 0), real(0, 0)] ../source4/dsdb/common/dsdb_access.c:47(dsdb_acl_debug)
  Access on CN=pixel-mn,CN=Computers,DC=qfstest,DC=wave-mn,DC=us,DC=oracle,DC=com deniedSecurity context:     : struct security_token


I haven't determined exactly what the issue was, but editing the ACL through the the security tab from a windows machine, and granting full 'SELF' access to the pixel-mn computer object allowed the Solaris CIFS to successfully join the domain.