Samba4 net join member fails

Question

I'm trying to join a RHEL6 server using samba4 to a domain. Net ads join works correctly, join member does not however. Effectively wbinfo --getdcname does not work where as wbinfo --dsgetdcname does.

If some light could be shed on the difference between these commands that would be very helpful.

The join is successful on Samba3 and works as expected except for Nested Groups

[root@sent-test-smg2 - (11:51:01) samba]#  net join member -U smg
Enter smg's password:
Failed to join domain: failed to find DC for domain member
ADS join did not work, falling back to RPC...
Unable to find a suitable server for domain SENT
Unable to find a suitable server for domain SENT

[root@sent-test-smg2 - (11:52:29) samba]#  net ads info
LDAP server: 10.74.160.8
LDAP server name: SENTVMDC2.Sent.local
Realm: SENT.LOCAL
Bind Path: dc=SENT,dc=LOCAL
LDAP port: 389
Server time: Fri, 04 Jul 2014 11:57:49 IST
KDC server: 10.74.160.8
Server time offset: 0

[root@sent-test-smg2 - (11:57:49) samba]#  wbinfo --online-status
BUILTIN : online
SENT-TEST-SMG2 : online
SENT : offline

[root@sent-test-smg2 - (11:59:28) samba]#  wbinfo --getdcname=SENT.LOCAL
Could not get dc name for SENT.LOCAL

[root@sent-test-smg2 - (11:59:42) samba]#  wbinfo -P
checking the NETLOGON dc connection to "" failed
error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233)

[root@sent-test-smg2 - (12:02:02) samba]#  wbinfo --dsgetdcname=sent.local
SENTVMDC2.Sent.local
\\10.74.160.8
1
f170eb24-d9f3-44cb-b622-02765ed83ed7
Sent.local
Sent.local
0xe00031fc
Ballycoolin
Ballycoolin

[root@sent-test-smg2 - (12:02:22) samba]#  wbinfo --getdcname=sent.local
Could not get dc name for sent.local

smb.conf:

[global]
   workgroup = SENT
   password server = *
   realm = SENT.LOCAL
   security = ads
   idmap config * : range = 10000-50000000
   winbind separator = +
   template homedir = /home/domain/%U
   template shell = /bin/bash
   winbind use default domain = true
   winbind offline logon = false
   preferred master = no
   allow trusted domains = no
   winbind enum users = Yes
   winbind enum groups = Yes
   winbind nested groups = Yes
   winbind expand groups = 10000
   server string = Linux Server
   interfaces = eth0
   bind interfaces only = yes
   strict locking = no
   wins server = 192.168.0.6
   idmap cache time = 1
   idmap negative cache time = 1
   winbind cache time = 1   
   idmap config * : range = 10000-50000000
   idmap config * : backend = rid
   idmap config SENT : range = 10000-50000000
   idmap config SENT : default = yes 
   idmap config SENT : backend = rid

krb.conf

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = SENT.LOCAL
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 SENT.LOCAL = {
  kdc = 192.168.0.6:88
  admin_server = 192.168.0.6:749
  kdc = *
 }

[domain_realm]
 SENT.LOCAL = SENT.LOCAL
 .SENT.LOCAL = SENT.LOCAL

 sent.local = SENT.LOCAL
 .sent.local = SENT.LOCAL

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

From the winbind log file with debugging at 10:

[2014/07/04 12:23:38.900108,  1, pid=12682, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:282(ndr_print_function_debug)
       wbint_PingDc: struct wbint_PingDc
          out: struct wbint_PingDc
              dcname                   : *
                  dcname                   : NULL
              result                   : NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
[2014/07/04 12:23:38.900835, 10, pid=12682, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:712(wb_request_done)
  wb_request_done[12705:PING_DC]: NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
[2014/07/04 12:23:38.901001, 10, pid=12682, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:773(winbind_client_response_written)
  winbind_client_response_written[12705:PING_DC]: delivered response to client
checking the NETLOGON dc connection to "" failed
error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233)

Yet later is seems to quite clearly know where the DC is:

[2014/07/04 12:23:39.044514,  9, pid=12707, effective(0, 0), real(0, 0)] ../source3/libsmb/conncache.c:150(check_negative_conn_cache)
  check_negative_conn_cache returning result 0 for domain SENT.LOCAL server 10.74.160.8
[2014/07/04 12:23:39.044732,  5, pid=12707, effective(0, 0), real(0, 0)] ../source3/libads/ldap.c:270(ads_try_connect)
  ads_try_connect: sending CLDAP request to 10.74.160.8 (realm: SENT.LOCAL)
[2014/07/04 12:23:39.046454,  1, pid=12707, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:245(ndr_print_debug)
       &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX
          command                  : LOGON_SAM_LOGON_RESPONSE_EX (23)
          sbz                      : 0x0000 (0)
          server_type              : 0x000031fc (12796)
                 0: NBT_SERVER_PDC           
                 1: NBT_SERVER_GC            
                 1: NBT_SERVER_LDAP          
                 1: NBT_SERVER_DS            
                 1: NBT_SERVER_KDC           
                 1: NBT_SERVER_TIMESERV      
                 1: NBT_SERVER_CLOSEST       
                 1: NBT_SERVER_WRITABLE      
                 0: NBT_SERVER_GOOD_TIMESERV 
                 0: NBT_SERVER_NDNC          
                 0: NBT_SERVER_SELECT_SECRET_DOMAIN_6
                 1: NBT_SERVER_FULL_SECRET_DOMAIN_6
                 1: NBT_SERVER_ADS_WEB_SERVICE
                 0: NBT_SERVER_HAS_DNS_NAME  
                 0: NBT_SERVER_IS_DEFAULT_NC 
                 0: NBT_SERVER_FOREST_ROOT   
          domain_uuid              : f170eb24-d9f3-44cb-b622-02765ed83ed7
          forest                   : 'Sent.local'
          dns_domain               : 'Sent.local'
          pdc_dns_name             : 'SENTVMDC2.Sent.local'
          domain_name              : 'SENT'
          pdc_name                 : 'SENTVMDC2'
          user_name                : ''
          server_site              : 'Ballycoolin'
          client_site              : 'Ballycoolin'
          sockaddr_size            : 0x00 (0)
          sockaddr: struct nbt_sockaddr
              sockaddr_family          : 0x00000000 (0)
              pdc_ip                   : (null)
              remaining                : DATA_BLOB length=0
          next_closest_site        : NULL
          nt_version               : 0x00000005 (5)
                 1: NETLOGON_NT_VERSION_1    
                 0: NETLOGON_NT_VERSION_5    
                 1: NETLOGON_NT_VERSION_5EX  
                 0: NETLOGON_NT_VERSION_5EX_WITH_IP
                 0: NETLOGON_NT_VERSION_WITH_CLOSEST_SITE
                 0: NETLOGON_NT_VERSION_AVOID_NT4EMUL
                 0: NETLOGON_NT_VERSION_PDC  
                 0: NETLOGON_NT_VERSION_IP   
                 0: NETLOGON_NT_VERSION_LOCAL
                 0: NETLOGON_NT_VERSION_GC   
          lmnt_token               : 0xffff (65535)
          lm20_token               : 0xffff (65535)
[2014/07/04 12:23:39.049085, 10, pid=12707, effective(0, 0), real(0, 0)] ../source3/libads/sitename_cache.c:70(sitename_store)
  sitename_store: realm = [SENT], sitename = [Ballycoolin], expire = [2085923199]

Solution

For what it's worth, I just had the same problem, the solution was that the DNS server used by the RHEL6 server contained outdated information. The information in the _msdcs.DOMAIN zone did not match the current setup, causing the join to fail. After flushing all DNS servers, and the local DNS cache, the join worked fine. It probably also would've solved itself after 24 hours, which was the caching time.

Comments

[Janne Pikkarainen]

Have you read the error logs in /var/log/samba or so?

[Antitribu]

Yes, unfortunately it doesn't add a lot of information beyond whats in the command line output. I've updated the question to include what little is there.

[Antitribu]

While i've rolled back to samba3 on many systems, my test system now appears to join without any other changes made it's probable this was the cause.

[jornane]

I found this post while Googling the problem, I decided to answer it when I found the problem myself. Too bad it was anti-climactic, but maybe it'll help the next internetteer ending up here :-)