[SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04

steve steve at steve-ss.com
Wed May 21 09:54:03 UTC 2014


Hi
We've exhausted all the possibilities over on the samba list and think 
we have a bug with the Lubuntu version of 1.11.5 against a Samba4 DC. We 
have 1.11.5 ddns working perfectly against the same DC and nsupdate 
works fine from the failing lubuntu laptop. I hope you don't mind in me 
quoting from the samba lists below. Any help would be most gratefully 
received:

sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = hh3.site
[nss]
[pam]
[domain/hh3.site]
ad_server = hh16.hh3.site
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = False

log:
tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor 
code may provide more information, Minor = Server not found in Kerberos 
database.
(Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [child_sig_handler] 
(0x0020): child [6460] failed with status [1].
(Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [nsupdate_child_handler] 
(0x0040): Dynamic DNS child failed with status [256]
(Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] [be_nsupdate_done] 
(0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS 
update failed
(Wed May 21 11:33:50 2014) [sssd[be[hh3.site]]] 
[sdap_dyndns_update_done] (0x0080): nsupdate failed, retrying with 
server name
tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor 
code may provide more information, Minor = Server not found in Kerberos 
database.
(Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [child_sig_handler] 
(0x0020): child [6464] failed with status [1].
(Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [nsupdate_child_handler] 
(0x0040): Dynamic DNS child failed with status [256]
(Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] [be_nsupdate_done] 
(0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS 
update failed
(Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] 
[ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed 
[1432158228]: Dynamic DNS update failed
(Wed May 21 11:33:51 2014) [sssd[be[hh3.site]]] 
[ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed 
[1432158228]: Dynamic DNS update failed


On 21/05/14 10:07, steve wrote:
 > On 20/05/14 15:35, Rowland Penny wrote:
 >> On 20/05/14 14:12, steve wrote:
 >>> Hi
 >>> I'm trying to get an Ubuntu 14.04 client to update its rr to a working
 >>> bind dns DC with Samba 4.1.7. The setup is the same as with our
 >>> openSUSE clients with sssd 1.11.15
 >>> /etc/hosts
 >>> 127.0.0.1    lubuntu-laptop.hh3.site lubuntu-laptop
 >>> 127.0.1.1 localhost

DC log:
 >>> Kerberos: ENC-TS Pre-authentication succeeded --
 >>> LUBUNTU-LAPTOP$@HH3.SITE using arcfour-hmac-md5
 >>> Kerberos: AS-REQ authtime: 2014-05-20T14:01:35 starttime: unset
 >>> endtime: 2014-05-21T00:01:35 renew till: 2014-05-21T14:01:35
 >>> Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96,
 >>> aes128-cts-hmac-sha1-96, arcfour-hmac-md5, des3-cbc-sha1, 25, 26,
 >>> using arcfour-hmac-md5/arcfour-hmac-md5
 >>> Kerberos: Requested flags: renewable-ok
 >>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from
 >>> ipv4:192.168.1.22:40240 for ldap/hh16.hh3.site at HH3.SITE [canonicalize,
 >>> renewable]
 >>> Kerberos: TGS-REQ authtime: 2014-05-20T14:01:35 starttime:
 >>> 2014-05-20T14:01:35 endtime: 2014-05-21T00:01:35 renew till:
 >>> 2014-05-21T14:01:35
 >>> Terminating connection - 'kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
 >>> single_terminate: reason[kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
 >>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from
 >>> ipv4:192.168.1.22:40241 for DNS/a.root-servers.net at HH3.SITE
 >>> [canonicalize, renewable]
 >>> Kerberos: Searching referral for a.root-servers.net
 >>> Kerberos: Returning a referral to realm ROOT-SERVERS.NET for server
 >>> DNS/a.root-servers.net at HH3.SITE that was not found
 >>> Failed find a single entry for
 >>> 
(&(objectClass=trustedDomain)(|(flatname=ROOT-SERVERS.NET)(trustPartner=ROOT-SERVERS.NET))):
 >>> got 0
 >>> Kerberos: samba_kdc_fetch: could not find principal in DB
 >>> Kerberos: Server not found in database:
 >>> krbtgt/ROOT-SERVERS.NET at HH3.SITE: no such entry found in hdb
 >>> Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40241
 >>> Terminating connection - 'kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
 >>> single_terminate: reason[kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
 >>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from
 >>> ipv4:192.168.1.22:40242 for DNS/a.root-servers.net at HH3.SITE [renewable]
 >>> Kerberos: Server not found in database:
 >>> DNS/a.root-servers.net at HH3.SITE: no such entry found in hdb
 >>> Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40242
 >>> Terminating connection - 'kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
 >>> single_terminate: reason[kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
 >>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from
 >>> ipv4:192.168.1.22:40243 for DNS/a.root-servers.net at HH3.SITE
 >>> [canonicalize, renewable]
 >>> Kerberos: Searching referral for a.root-servers.net
 >>> Kerberos: Returning a referral to realm ROOT-SERVERS.NET for server
 >>> DNS/a.root-servers.net at HH3.SITE that was not found
 >>> Failed find a single entry for
 >>> 
(&(objectClass=trustedDomain)(|(flatname=ROOT-SERVERS.NET)(trustPartner=ROOT-SERVERS.NET))):
 >>> got 0
 >>> Kerberos: samba_kdc_fetch: could not find principal in DB
 >>> Kerberos: Server not found in database:
 >>> krbtgt/ROOT-SERVERS.NET at HH3.SITE: no such entry found in hdb
 >>> Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40243
 >>> Terminating connection - 'kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
 >>> single_terminate: reason[kdc_tcp_call_loop:
 >>> tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
 >>> Kerberos: TGS-REQ LUBUNTU-LAPTOP$@HH3.SITE from
 >>> ipv4:192.168.1.22:40244 for DNS/a.root-servers.net at HH3.SITE [renewable]
 >>> Kerberos: Server not found in database:
 >>> DNS/a.root-servers.net at HH3.SITE: no such entry found in hdb
 >>> Kerberos: Failed building TGS-REP to ipv4:192.168.1.22:40244
 >>>
 >>> The worrying thing is that we can still get tickets even though it has
 >>> the wrong A record in DNS.
 >>> What is this, 'a.root-servers.net' business? Why not our domain?
 >>> What have we overlooked?
 >>> Thanks,
 >>> Steve
 >>>
 >>
 > OK
 > It works fine with nsupdate on the Administrator's tgt:
 >
 > Kerberos: AS-REQ Administrator at HH3.SITE from ipv4:192.168.1.22:35207 
for krbtgt/HH3.SITE at HH3.SITE
 > Kerberos: Client sent patypes: 149
 > Kerberos: Looking for PKINIT pa-data -- Administrator at HH3.SITE
 > Kerberos: Looking for ENC-TS pa-data -- Administrator at HH3.SITE
 > Kerberos: No preauth found, returning PREAUTH-REQUIRED -- 
Administrator at HH3.SITE
 > Kerberos: AS-REQ Administrator at HH3.SITE from ipv4:192.168.1.22:60295 
for krbtgt/HH3.SITE at HH3.SITE
 > Kerberos: Client sent patypes: encrypted-timestamp, 149
 > Kerberos: Looking for PKINIT pa-data -- Administrator at HH3.SITE
 > Kerberos: Looking for ENC-TS pa-data -- Administrator at HH3.SITE
 > Kerberos: ENC-TS Pre-authentication succeeded -- 
Administrator at HH3.SITE using arcfour-hmac-md5
 > Kerberos: AS-REQ authtime: 2014-05-21T10:51:46 starttime: unset 
endtime: 2014-05-21T20:51:46 renew till: 2014-05-22T10:51:42
 > Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, 
aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, 25, 26, using 
arcfour-hmac-md5/arcfour-hmac-md5
 > Kerberos: Requested flags: renewable-ok
 > Kerberos: TGS-REQ Administrator at HH3.SITE from ipv4:192.168.1.22:57157 
for DNS/hh16.hh3.site at HH3.SITE [canonicalize, renewable]
 > Kerberos: TGS-REQ authtime: 2014-05-21T10:51:46 starttime: 
2014-05-21T10:52:50 endtime: 2014-05-21T20:51:46 renew till: 
2014-05-22T10:51:42
 >
 > and named responds:
 > R
 > 2014-05-21T10:52:50.315641+02:00 hh16 named[1965]: samba_dlz: 
starting transaction on zone hh3.site
 > 2014-05-21T10:52:50.319042+02:00 hh16 named[1965]: samba_dlz: 
allowing update of signer=Administrator\@HH3.SITE 
name=lubuntu-laptop.hh3.site tcpaddr=192.168.1.22 type=A 
key=3111087606.sig-hh16.hh3.site/160/0
 > 2014-05-21T10:52:50.321707+02:00 hh16 named[1965]: samba_dlz: 
allowing update of signer=Administrator\@HH3.SITE 
name=lubuntu-laptop.hh3.site tcpaddr=192.168.1.22 type=A 
key=3111087606.sig-hh16.hh3.site/160/0
 > 2014-05-21T10:52:50.322267+02:00 hh16 named[1965]: client 
192.168.1.22#48170/key Administrator\@HH3.SITE: updating zone 
'hh3.site/NONE': deleting rrset at 'lubuntu-laptop.hh3.site' A
 > 2014-05-21T10:52:50.325538+02:00 hh16 named[1965]: samba_dlz: 
subtracted rdataset lubuntu-laptop.hh3.site 
'lubuntu-laptop.hh3.site.#0113600#011IN#011A#011192.168.1.22'
 > 2014-05-21T10:52:50.326263+02:00 hh16 named[1965]: client 
192.168.1.22#48170/key Administrator\@HH3.SITE: updating zone 
'hh3.site/NONE': adding an RR at 'lubuntu-laptop.hh3.site' A
 > 2014-05-21T10:52:50.329767+02:00 hh16 named[1965]: samba_dlz: added 
rdataset lubuntu-laptop.hh3.site 
'lubuntu-laptop.hh3.site.#0113600#011IN#011A#011192.168.1.22'
 > 2014-05-21T10:52:50.644113+02:00 hh16 named[1965]: samba_dlz: 
committed transaction on zone hh3.site
 >
 > Note, that via sssd, nothing is logged by bind, I suppose because the 
KDC throws it out before it gets there.
 >
 > So, can we now point the blame at whatever Ubuntu have done with sssd 
1.11.5? The sssd guys tell me that all they do is call out to nsupdate 
for the ddns. As a 1.11.5 build from source on openSUSE works OK, do I 
have enough information to narrow it down to the Ubuntu package? Do I 
now have to build sssd on the laptop to prove my point?
 >
 > @Rowland. Do you have a 'debianified' build method for 1.11.5?

Sorry, but no, Ubuntu 14.04 comes with 1.11.3 and I am using this. It 
must be possible though, Timo Aaltonen builds it for the Ubuntu 12.04 
PPA here: https://launchpad.net/~sssd/+archive/updates

Perhaps you need to move this post to the sssd mailing list, you seem to 
have tried everything possible, so could it be a problem with the Ubuntu 
sssd package itself ?

Rowland

 >
 > Thanks everyone for their patience.
 > Steve


More information about the sssd-users mailing list