Я пытаюсь присоединиться к серверу RHEL6 с помощью samba4 в домене. Присоединение к интернет-рекламе работает правильно, а присоединение к члену - нет. Фактически wbinfo --getdcname не работает там, где работает wbinfo --dsgetdcname.
Если бы можно было пролить свет на разницу между этими командами, это было бы очень полезно.
Присоединение прошло успешно на Samba3 и работает, как ожидалось, за исключением Вложенные группы
[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
}
Из файла журнала winbind с отладкой на 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)
Однако позже, кажется, довольно ясно известно, где находится DC:
[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]
Как бы то ни было, у меня была такая же проблема, решение заключалось в том, что DNS-сервер, используемый сервером RHEL6, содержал устаревшую информацию. Информация в _msdcs.DOMAIN зона не соответствовала текущей настройке, что привело к сбою соединения. После очистки всех DNS-серверов и локального DNS-кеша соединение работало нормально. Вероятно, он также разрешился бы через 24 часа, что было временем кеширования.