[Samba] Ubuntu client ddns failure

Wed May 21 03:36:54 MDT 2014

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
>>> sssd.conf
>>> id_provider = ad
>>> auth_provider = ad
>>> access_provider = ad
>>> ldap_id_mapping = False
>>>
>>> /etc/hosts
>>> 127.0.0.1    lubuntu-laptop.hh3.site lubuntu-laptop
>>> 127.0.1.1 localhost
>>>
>> Don't know if this is your problem, but you have got /etc/hosts wrong,
>> shouldn't it be:
>>
>> 127.0.0.1    localhost
>> 127.0.1.1    lubuntu-laptop.hh3.site    lubuntu-laptop
>>
>> Rowland
>>
>>> But it is sending a request for the wrong zone:
>>>
>>> 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
>