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: [ID 232655 daemon.notice] ldap_modify: DSA is unwilling to perform
Mar 9 12:45:21 indi smbd: [ID 702911 daemon.notice] Failed to modify the workstation trust account.
Mar 9 12:45:21 indi smbd: [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...
More specifically the smb_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...
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.
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.
A network trace and a level 4 (as a start) log on the Samba side may help.
Can you post a debug level 10 from the Samba side, so we can see how far it gets before it gives up ?
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.
Created attachment 7371 [details]
Samba -d4 log
Log of the bug reproduced with `samba -d4'.
corresponds directly with the packet sniff also attached.
Created attachment 7372 [details]
Samba -d10 log
Log of a reproduction of the bug, with 'samba -d10'
Done separate of the packet sniff provided.
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?
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: [ID 232655 daemon.notice] ldap_modify: Insufficient access
Oct 29 22:18:24 pixel-mn smbd: [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.