idmap: get_kdc_ip_string: get_kdc_list fail NT_STATUS_NO_LOGON_SERVERS (with debugging)
Michael Tokarev via samba <[email protected]> Sat, 21 Mar 2026 13:35:41 +0300
| Newsgroups | gmane.network.samba.general |
|---|---|
| Message-ID | <[email protected]> |
Hi!
We're frequently getting messages in the logs, like this:
[2026/03/21 12:49:01.422282, 0, pid=485248, effective(0, 0), real(0,
0), traceid=275] source3/libads/kerberos.c:1128(get_kdc_ip_string)
get_kdc_ip_string: get_kdc_list fail NT_STATUS_NO_LOGON_SERVERS
I tried to investigate, and here's what I've found.
First, we run samba AD on two sites, with single DC on each.
And there's a samba file server running on each site.
The file server and the DC on this site are run on a single machine,
in a separate container each, so all communications are though local
network within singe physical machine, so there's no networking probs
between the two.
The domain is 100% samba-based (with a few windows machines joined
as members).
When winbindd starts, it automatically chooses the nearby DC local to
the site, and winbind-idmap process connects to the LDAP port of the
DC.
However, after some time, LDAP server process on the DC closes the
connection. I don't know how this works here, and why winbindd wants
to have persistent connection to the DC's LDAP service - to me it
looks too expensive, no windows machine is keeping such persistent
connection, only samba does it. But ok. The point is that the LDAP
service closes its end of the connection, apparently - probably some
dead time or some other timeout perhaps?
Next idmap receives a request (arbitrary):
child daemon request 54
winbindd_dual_ndrcmd: Running command wbint_UnixIDs2Sids (domain
'(null)')
...
idmap_find_domain called for domain 'tls'
idmap_ad_unixids_to_sids: Filter:
[(|(&(|(sAMAccountType=268435456)(sAMAccountType=536870912))(|(gidNumber=1060))))]
...
Next we've the following logging in idmap (just the log messages):
idmap_ad_tldap: tldap_msg_send: sending msg 10
idmap_ad_tldap: tldap_context_disconnect: TLDAP_SERVER_DOWN at
source3/lib/tldap.c:810
idmap_backend_unixids_to_sids: unixid_to_sids for domain tls returned
NT_STATUS_HOST_UNREACHABLE
wbint_UnixIDs2Sids: struct wbint_UnixIDs2Sids
out: struct wbint_UnixIDs2Sids
xids: ARRAY(1)
xids: struct unixid
id : 0x00000424 (1060)
type : ID_TYPE_GID (2)
sids: ARRAY(1)
sids : S-0-0
result : NT_STATUS_HOST_UNREACHABLE
Finished processing child request 54
Writing 4028 bytes to parent
Here, I already wonder wtf is going on here: why it doesn't perform any
retries here and returns an error to the caller? It feels like a bug
already, but maybe it's ok.
Next, another request, and things becomes interesting:
child daemon request 54
(the same request arrives again)
idmap_find_domain called for domain 'tls'
state.dcinfo: struct netr_DsRGetDCNameInfo
dc_unc : *
dc_unc : '\\svdcp.tls.msk.ru'
dc_address : *
dc_address : '\\192.168.19.6'
dc_address_type : DS_ADDRESS_TYPE_INET (1)
domain_guid : e71164c4-1b4d-4ff2-8fba-1755025a6bc0
domain_name : *
domain_name : 'tls.msk.ru'
forest_name : *
forest_name : 'tls.msk.ru'
dc_flags : 0xe00013fc (3758101500)
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
1: NBT_SERVER_GOOD_TIMESERV
0: NBT_SERVER_NDNC
0: NBT_SERVER_SELECT_SECRET_DOMAIN_6
1: NBT_SERVER_FULL_SECRET_DOMAIN_6
0: NBT_SERVER_ADS_WEB_SERVICE
0: NBT_SERVER_DS_8
0: NBT_SERVER_DS_9
0: NBT_SERVER_DS_10
1: NBT_SERVER_HAS_DNS_NAME
1: NBT_SERVER_IS_DEFAULT_NC
1: NBT_SERVER_FOREST_ROOT
dc_site_name : *
dc_site_name : 'Pereslavl-Office'
client_site_name : *
client_site_name : 'Pereslavl-Office'
sitename_fetch: Returning sitename for realm 'TLS.MSK.RU':
"Pereslavl-Office"
internal_resolve_name: looking up svdcp.tls.msk.ru#20 (sitename
Pereslavl-Office)
gencache_set_data_blob: Adding cache entry with
key=[NBT/SVDCP.TLS.MSK.RU#20] and timeout=[Thu Jan 1 03:00:00 1970 MSK]
(-1774086541 seconds in the past)
namecache_fetch: no entry for svdcp.tls.msk.ru#20 found.
at this time, it looks like idmap does not consider svdcp (the onsite
DC) as working. Next,
resolve_hosts: Attempting host lookup for name svdcp.tls.msk.ru<0x20>
namecache_store: storing 1 address for svdcp.tls.msk.ru#20: 192.168.19.6
gencache_set_data_blob: Adding cache entry with
key=[NBT/SVDCP.TLS.MSK.RU#20] and timeout=[Sat Mar 21 13:00:01 2026 MSK]
(660 seconds ahead)
internal_resolve_name: returning 1 addresses: 192.168.19.6
sitename_fetch: Returning sitename for realm 'TLS.MSK.RU':
"Pereslavl-Office"
create_local_private_krb5_conf_for_domain: fname =
/run/samba/smb_krb5/krb5.conf.TLS, realm = TLS.MSK.RU, domain = TLS
saf_fetch: failed to find server for "TLS.MSK.RU" domain
get_dc_list: preferred server list: ", *"
internal_resolve_name: looking up TLS.MSK.RU#dcdc (sitename
Pereslavl-Office)
resolve_ads: Attempting to resolve KDCs for TLS.MSK.RU using DNS
dns_cli_request_send: Asking 127.0.0.1 for
_kerberos._tcp.Pereslavl-Office._sites.dc._msdcs.TLS.MSK.RU/1/33 via UDP
... a few DNS queries
dns_rr_srv_fill_done: async DNS A lookup for svdcp.tls.msk.ru [0] got
svdcp.tls.msk.ru -> 192.168.19.6
check_negative_conn_cache: returning result
NT_STATUS_HOST_UNREACHABLE for domain TLS.MSK.RU server svdcp.tls.msk.ru
resolve_ads: Skipping blacklisted server [svdcp.tls.msk.ru] for
domain [TLS.MSK.RU]remove_duplicate_addrs2: looking for duplicate
address/port pairs
internal_resolve_name: returning 0 addresses:
(here, it looks like a \n is missing in the logging somewhere).
And here it now finally thinks svdcp is unreachable.
get_dc_list: Adding 0 DC's from auto lookup
get_dc_list: no servers found
get_kdc_ip_string: Failed to get KDC ip address
idmap_ad_get_tldap_ctx: Could not create private krb5.conf
idmap_ad_context_create: idmap_ad_get_tldap_ctx failed:
NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
idmap_ad_get_context: idmap_ad_context_create failed:
NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
idmap_backend_unixids_to_sids: unixid_to_sids for domain tls returned
NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
Finished processing child request 54
So, another request, another failure.
This continues, and some time later it tries to lookup global list of
DCs for the domain, finds the DC in another office, and connects to
it instead of the local one. Or it can't connect to the other office
due to (remote) network glitch and fails.
An example logging is available at
http://www.corpit.ru/mjt/tmp/winbindd-idmap.log
This is samba 4.23.6 (debian trixie, samba from backports). Exactly
the same thing we observed with 4.21 and 4.22 - actually, I installed
4.23 here just because of this issue, but nothing changed.
The setup is very basic, like this:
# Global parameters
[global]
netbios name = PANDA
realm = TLS.MSK.RU
security = ADS
server role = member server
template homedir = /home/%U
template shell = /bin/bash
winbind use default domain = Yes
workgroup = TLS
idmap config * : range = 5000-5099
idmap config * : backend = tdb
idmap config tls : unix_primary_group = yes
idmap config tls : schema_mode = rfc2307
idmap config tls : range = 1000-4999
idmap config tls : backend = ad
idmap_ldb:use rfc2307 = yes
disable netbios = yes
What can be done with this?
Thanks,
/mjt
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba