[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

2017-08-16 Thread Steve Weeks via FreeIPA-users
We switch our domains to ad.example.com and ipa.example.com and at least
with preliminary testing this seems to resolve the problem.  It was very
misleading that Fedora 25 and 26 worked fine either way.  Oh well.

Thanks for the help.


On Tue, Aug 15, 2017 at 3:18 AM, Alexander Bokovoy 
wrote:

> On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:
>
>> So we just got lucky with the fedora 25 systems?
>>
>> If we move the Linux system to host.ipa.example.com and leave the Windows
>> stuff as ad.example.com we should be fine?
>>
> Yes, as long as AD is not a sub-domain of IPA in terms of AD domain +
> DNS domain, that would work. You'd need to re-establish trust,
> obviously.
>
>
>
>> On Mon, Aug 14, 2017 at 2:24 PM, Alexander Bokovoy 
>> wrote:
>>
>> On ma, 14 elo 2017, Steve Weeks wrote:
>>>
>>> It is example.com and ad.example.com, but all DNS is handled by an
 external
 server so I assumed neither was a subdomain.  I don't understand DNS
 much
 and it seems to work just fine with Fedora 25 ipa clients and ad users.

 Which DNS server handles DNS zones is irrelevant. It is not about DNS
>>> zones, it is an issue with how Active Directory treats own domains (AD
>>> domain != DNS domain). You can check
>>> https://lists.fedoraproject.org/archives/list/freeipa-users@
>>> lists.fedorahosted.org/message/76P2HI7JYH6QXAQGAEEF5G7KFHMVO3E7/
>>> for more details.
>>>
>>> However, your specific arrangement of example.com for IPA and
>>> ad.example.com for AD is known to not work, as I said earlier.
>>>
>>>
>>>
>>>
>>> On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
 wrote:

 On ma, 14 elo 2017, Steve Weeks wrote:

>
> No, the IPA and AD domains are separate, but do have a cross-trust.
>
>>
>> We are running IPA 4.4.  This all works fine on Fedora 25 systems.
>>
>> Can you be more specific? In your logs below you choose
>> ad.example.com
>>
> and example.com. This is known to not work. If this is not your
> configuration then why did you choose it to obfuscate? Details matter.
>
>
>
>
> On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy <
> aboko...@redhat.com
>
>> >
>> wrote:
>>
>> On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:
>>
>>
>>> I'm having trouble logging in via the gui console to an Ubuntu 16
>>> Desktop
>>>
>>> host that is affiliated with a FreeIPA server, which in turn is
 affiliated
 with an Active Directory server.

 When I try to log in with debugging turned up on the SSSD I see an
 underlying error in the krb5_child log file: Cannot find KDC for
 realm "
 EXAMPLE.COM" while getting credentials for host/
 myhost.example@example.com

 Following an example from the freeipa-users mailing list, I am just
 working
 with kinit and kvno to identify the underlying problem. I get the
 same
 error, which I suppose is good. But I don't know how to resolve it
 from
 here. The transcript is below. On the first try at kvno, I get the
 same
 error. On the second try, it works. Any idea why? I suspect the
 failure
 on
 the first try is the real problem with authentication from the
 console.

 Any hints what to try next?

 Do you really have AD as a subdomain of IPA?


>>> I suspect you hit https://bugzilla.redhat.com/sh
>>> ow_bug.cgi?id=1421869
>>> There is no currently resolution for this. If you'd use different
>>> domain trees (example.com v example.org) it would work. It would
>>> work
>>> also for AD owning example.com and IPA being in ipa.example.com.
>>>
>>>
>>> Thanks
>>>
>>>
 - /etc/krb5.conf -
 #File modified by ipa-client-install

 includedir */var/lib/sss/pubconf/krb5.include.d/*


 [libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


 [realms]
  EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


 [domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM



 - Transcript -


 $ kdestroy -A


 $ kinit adu...@ad.example.com
 Password for adu...@ad.example.com:


 $ klist
 Ticket cache: KEYRING:persistent:1000:1000
 Default principal: 

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

2017-08-15 Thread Alexander Bokovoy via FreeIPA-users

On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:

So we just got lucky with the fedora 25 systems?

If we move the Linux system to host.ipa.example.com and leave the Windows
stuff as ad.example.com we should be fine?

Yes, as long as AD is not a sub-domain of IPA in terms of AD domain +
DNS domain, that would work. You'd need to re-establish trust,
obviously.



On Mon, Aug 14, 2017 at 2:24 PM, Alexander Bokovoy 
wrote:


On ma, 14 elo 2017, Steve Weeks wrote:


It is example.com and ad.example.com, but all DNS is handled by an
external
server so I assumed neither was a subdomain.  I don't understand DNS much
and it seems to work just fine with Fedora 25 ipa clients and ad users.


Which DNS server handles DNS zones is irrelevant. It is not about DNS
zones, it is an issue with how Active Directory treats own domains (AD
domain != DNS domain). You can check
https://lists.fedoraproject.org/archives/list/freeipa-users@
lists.fedorahosted.org/message/76P2HI7JYH6QXAQGAEEF5G7KFHMVO3E7/
for more details.

However, your specific arrangement of example.com for IPA and
ad.example.com for AD is known to not work, as I said earlier.





On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
wrote:

On ma, 14 elo 2017, Steve Weeks wrote:


No, the IPA and AD domains are separate, but do have a cross-trust.


We are running IPA 4.4.  This all works fine on Fedora 25 systems.

Can you be more specific? In your logs below you choose ad.example.com

and example.com. This is known to not work. If this is not your
configuration then why did you choose it to obfuscate? Details matter.




On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
wrote:

On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:



I'm having trouble logging in via the gui console to an Ubuntu 16
Desktop


host that is affiliated with a FreeIPA server, which in turn is
affiliated
with an Active Directory server.

When I try to log in with debugging turned up on the SSSD I see an
underlying error in the krb5_child log file: Cannot find KDC for
realm "
EXAMPLE.COM" while getting credentials for host/
myhost.example@example.com

Following an example from the freeipa-users mailing list, I am just
working
with kinit and kvno to identify the underlying problem. I get the same
error, which I suppose is good. But I don't know how to resolve it
from
here. The transcript is below. On the first try at kvno, I get the
same
error. On the second try, it works. Any idea why? I suspect the
failure
on
the first try is the real problem with authentication from the
console.

Any hints what to try next?

Do you really have AD as a subdomain of IPA?



I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
There is no currently resolution for this. If you'd use different
domain trees (example.com v example.org) it would work. It would work
also for AD owning example.com and IPA being in ipa.example.com.


Thanks



- /etc/krb5.conf -
#File modified by ipa-client-install

includedir */var/lib/sss/pubconf/krb5.include.d/*


[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 EXAMPLE.COM = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM



- Transcript -


$ kdestroy -A


$ kinit adu...@ad.example.com
Password for adu...@ad.example.com:


$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: adu...@ad.example.com

Valid starting   Expires  Service principal
08/14/2017 09:59:22  08/14/2017 19:59:22
krbtgt/AD.EXAMPLE.COM@AD.EXAMP
LE.COM
renew until 08/15/2017 09:59:17


$ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
[1994] 1502719211.714019: Getting credentials adu...@ad.example.com
->
host/myhost.example@example.com using ccache
KEYRING:persistent:1000:1000
[1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
host/myhost.example@example.com from KEYRING:persistent:1000:1000
with result: -1765328243/Matching credential not found
[1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
krbtgt/ad.example@ad.example.com from
KEYRING:persistent:1000:1000
with result: 0/Success
[1994] 1502719211.714395: Starting with TGT for client realm:
adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
[1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714456: Requesting TGT
krbtgt/example@ad.example.com using TGT

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

2017-08-14 Thread Alexander Bokovoy via FreeIPA-users

On ma, 14 elo 2017, Steve Weeks wrote:

It is example.com and ad.example.com, but all DNS is handled by an external
server so I assumed neither was a subdomain.  I don't understand DNS much
and it seems to work just fine with Fedora 25 ipa clients and ad users.

Which DNS server handles DNS zones is irrelevant. It is not about DNS
zones, it is an issue with how Active Directory treats own domains (AD
domain != DNS domain). You can check
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/76P2HI7JYH6QXAQGAEEF5G7KFHMVO3E7/
for more details.

However, your specific arrangement of example.com for IPA and
ad.example.com for AD is known to not work, as I said earlier.




On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
wrote:


On ma, 14 elo 2017, Steve Weeks wrote:


No, the IPA and AD domains are separate, but do have a cross-trust.

We are running IPA 4.4.  This all works fine on Fedora 25 systems.


Can you be more specific? In your logs below you choose ad.example.com
and example.com. This is known to not work. If this is not your
configuration then why did you choose it to obfuscate? Details matter.





On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
wrote:

On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:


I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop

host that is affiliated with a FreeIPA server, which in turn is
affiliated
with an Active Directory server.

When I try to log in with debugging turned up on the SSSD I see an
underlying error in the krb5_child log file: Cannot find KDC for realm "
EXAMPLE.COM" while getting credentials for host/
myhost.example@example.com

Following an example from the freeipa-users mailing list, I am just
working
with kinit and kvno to identify the underlying problem. I get the same
error, which I suppose is good. But I don't know how to resolve it from
here. The transcript is below. On the first try at kvno, I get the same
error. On the second try, it works. Any idea why? I suspect the failure
on
the first try is the real problem with authentication from the console.

Any hints what to try next?

Do you really have AD as a subdomain of IPA?


I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
There is no currently resolution for this. If you'd use different
domain trees (example.com v example.org) it would work. It would work
also for AD owning example.com and IPA being in ipa.example.com.


Thanks


- /etc/krb5.conf -
#File modified by ipa-client-install

includedir */var/lib/sss/pubconf/krb5.include.d/*


[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 EXAMPLE.COM = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM



- Transcript -


$ kdestroy -A


$ kinit adu...@ad.example.com
Password for adu...@ad.example.com:


$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: adu...@ad.example.com

Valid starting   Expires  Service principal
08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
LE.COM
renew until 08/15/2017 09:59:17


$ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
[1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
host/myhost.example@example.com using ccache
KEYRING:persistent:1000:1000
[1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
host/myhost.example@example.com from KEYRING:persistent:1000:1000
with result: -1765328243/Matching credential not found
[1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
with result: 0/Success
[1994] 1502719211.714395: Starting with TGT for client realm:
adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
[1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714456: Requesting TGT
krbtgt/example@ad.example.com using TGT
krbtgt/ad.example@ad.example.com
[1994] 1502719211.714486: Generated subkey for TGS request:
aes256-cts/020C
[1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[1994] 1502719211.714605: Encoding request body and padata into FAST
request
[1994] 1502719211.714662: Sending request (1686 bytes) to
AD.EXAMPLE.COM
[1994] 1502719211.717532: Resolving hostname 

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

2017-08-14 Thread Steve Weeks via FreeIPA-users
It is example.com and ad.example.com, but all DNS is handled by an external
server so I assumed neither was a subdomain.  I don't understand DNS much
and it seems to work just fine with Fedora 25 ipa clients and ad users.

On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
wrote:

> On ma, 14 elo 2017, Steve Weeks wrote:
>
>> No, the IPA and AD domains are separate, but do have a cross-trust.
>>
>> We are running IPA 4.4.  This all works fine on Fedora 25 systems.
>>
> Can you be more specific? In your logs below you choose ad.example.com
> and example.com. This is known to not work. If this is not your
> configuration then why did you choose it to obfuscate? Details matter.
>
>
>
>
>> On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
>> wrote:
>>
>> On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:
>>>
>>> I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop
 host that is affiliated with a FreeIPA server, which in turn is
 affiliated
 with an Active Directory server.

 When I try to log in with debugging turned up on the SSSD I see an
 underlying error in the krb5_child log file: Cannot find KDC for realm "
 EXAMPLE.COM" while getting credentials for host/
 myhost.example@example.com

 Following an example from the freeipa-users mailing list, I am just
 working
 with kinit and kvno to identify the underlying problem. I get the same
 error, which I suppose is good. But I don't know how to resolve it from
 here. The transcript is below. On the first try at kvno, I get the same
 error. On the second try, it works. Any idea why? I suspect the failure
 on
 the first try is the real problem with authentication from the console.

 Any hints what to try next?

 Do you really have AD as a subdomain of IPA?
>>>
>>> I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
>>> There is no currently resolution for this. If you'd use different
>>> domain trees (example.com v example.org) it would work. It would work
>>> also for AD owning example.com and IPA being in ipa.example.com.
>>>
>>>
>>> Thanks

 - /etc/krb5.conf -
 #File modified by ipa-client-install

 includedir */var/lib/sss/pubconf/krb5.include.d/*


 [libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


 [realms]
  EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


 [domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM



 - Transcript -


 $ kdestroy -A


 $ kinit adu...@ad.example.com
 Password for adu...@ad.example.com:


 $ klist
 Ticket cache: KEYRING:persistent:1000:1000
 Default principal: adu...@ad.example.com

 Valid starting   Expires  Service principal
 08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
 LE.COM
 renew until 08/15/2017 09:59:17


 $ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
 [1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
 host/myhost.example@example.com using ccache
 KEYRING:persistent:1000:1000
 [1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
 host/myhost.example@example.com from KEYRING:persistent:1000:1000
 with result: -1765328243/Matching credential not found
 [1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
 krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
 result: -1765328243/Matching credential not found
 [1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
 krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
 with result: 0/Success
 [1994] 1502719211.714395: Starting with TGT for client realm:
 adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
 [1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
 krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
 result: -1765328243/Matching credential not found
 [1994] 1502719211.714456: Requesting TGT
 krbtgt/example@ad.example.com using TGT
 krbtgt/ad.example@ad.example.com
 [1994] 1502719211.714486: Generated subkey for TGS request:
 aes256-cts/020C
 [1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
 aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
 [1994] 1502719211.714605: Encoding request body and padata into FAST
 request
 [1994] 1502719211.714662: Sending request (1686 bytes) to
 AD.EXAMPLE.COM
 [1994] 

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

2017-08-14 Thread Alexander Bokovoy via FreeIPA-users

On ma, 14 elo 2017, Steve Weeks wrote:

No, the IPA and AD domains are separate, but do have a cross-trust.

We are running IPA 4.4.  This all works fine on Fedora 25 systems.

Can you be more specific? In your logs below you choose ad.example.com
and example.com. This is known to not work. If this is not your
configuration then why did you choose it to obfuscate? Details matter.




On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
wrote:


On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:


I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop
host that is affiliated with a FreeIPA server, which in turn is affiliated
with an Active Directory server.

When I try to log in with debugging turned up on the SSSD I see an
underlying error in the krb5_child log file: Cannot find KDC for realm "
EXAMPLE.COM" while getting credentials for host/
myhost.example@example.com

Following an example from the freeipa-users mailing list, I am just
working
with kinit and kvno to identify the underlying problem. I get the same
error, which I suppose is good. But I don't know how to resolve it from
here. The transcript is below. On the first try at kvno, I get the same
error. On the second try, it works. Any idea why? I suspect the failure on
the first try is the real problem with authentication from the console.

Any hints what to try next?


Do you really have AD as a subdomain of IPA?

I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
There is no currently resolution for this. If you'd use different
domain trees (example.com v example.org) it would work. It would work
also for AD owning example.com and IPA being in ipa.example.com.



Thanks

- /etc/krb5.conf -
#File modified by ipa-client-install

includedir */var/lib/sss/pubconf/krb5.include.d/*


[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 EXAMPLE.COM = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM



- Transcript -


$ kdestroy -A


$ kinit adu...@ad.example.com
Password for adu...@ad.example.com:


$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: adu...@ad.example.com

Valid starting   Expires  Service principal
08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
LE.COM
renew until 08/15/2017 09:59:17


$ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
[1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
host/myhost.example@example.com using ccache
KEYRING:persistent:1000:1000
[1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
host/myhost.example@example.com from KEYRING:persistent:1000:1000
with result: -1765328243/Matching credential not found
[1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
with result: 0/Success
[1994] 1502719211.714395: Starting with TGT for client realm:
adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
[1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714456: Requesting TGT
krbtgt/example@ad.example.com using TGT
krbtgt/ad.example@ad.example.com
[1994] 1502719211.714486: Generated subkey for TGS request:
aes256-cts/020C
[1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[1994] 1502719211.714605: Encoding request body and padata into FAST
request
[1994] 1502719211.714662: Sending request (1686 bytes) to AD.EXAMPLE.COM
[1994] 1502719211.717532: Resolving hostname ad-host.ad.example.com.
[1994] 1502719211.719053: Sending initial UDP request to dgram
192.168.1.2:88
[1994] 1502719211.742171: Received answer (309 bytes) from dgram
192.168.1.2:88
[1994] 1502719211.743066: Response was not from master KDC
[1994] 1502719211.743082: Decoding FAST response
[1994] 1502719211.743109: Request or response is too big for UDP;
retrying with TCP
[1994] 1502719211.743113: Sending request (1686 bytes) to
AD.EXAMPLE.COM (tcp only)
[1994] 1502719211.743971: Resolving hostname ad-host.ad.example.com.
[1994] 1502719211.744908: Initiating TCP connection to stream
192.168.1.2:88
[1994] 1502719211.764062: Sending TCP request to stream 192.168.1.2:88
[1994] 1502719211.805666: Received answer (1643 bytes) from stream
192.168.1.2:88
[1994] 1502719211.805678: Terminating TCP connection to