On Thu, Feb 02, 2017 at 09:11:39PM +0000, Gilbert, Sonia wrote:
> Thanks for helping out Lukas.
> 
> Kinit resolves to dc02 then fails pre-authentication because it was not the 
> master KDC, after providing password, then resolves to dc01 and then gets the 
> policy rejects again.  Tried a few times and it seems that it does not matter 
> which server it resolves, get the same messages about not being master and 
> policy reject.  I also tried to set the " dns_lookup_kdc = false" but just 
> caused it not find a server.  Klist, only see the server object in the 
> a.abc.com domain.
> 
> Below are the results of KRB5_TRACE=/dev/stderr kinit [email protected]:
> 
> [root@server01 etc]# KRB5_TRACE=/dev/stderr kinit [email protected]

In general, I think you should either use -E/-C or use upper-case realm.

> [17578] 1486068170.688787: Getting initial credentials for [email protected]
> [17578] 1486068170.689166: Sending request (193 bytes) to abc.com
> [17578] 1486068170.818519: Resolving hostname infdcpci02.abc.com.
> [17578] 1486068170.883645: Sending initial UDP request to dgram 
> x.x.161.252:88 (dc02)
> [17578] 1486068170.946802: Received answer (195 bytes) from dgram 
> x.x.161.252:88
> [17578] 1486068171.9293: Response was not from master KDC
> [17578] 1486068171.9356: Received error from KDC: -1765328359/Additional 
> pre-authentication required
> [17578] 1486068171.9425: Processing preauth types: 16, 15, 19, 2
> [17578] 1486068171.9456: Selected etype info: etype aes256-cts, salt 
> "abc.com018443", params ""
> 
> [17578] 1486068435.915755: AS key obtained for encrypted timestamp: 
> aes256-cts/B3B5
> [17578] 1486068435.915855: Encrypted timestamp (for 1486068405.778558): plain 
> 301AA011180F32303137303230323230343634355AA10502030BE13E, encrypted 
> B9066FF3F56DC8C931B4AA95937AE59185BCE87FDC1D2BF482A575B8166CEDA85E95D7EF5F36253F77D6674F208413BF079CEB6B45CBB101
> [17578] 1486068435.915914: Preauth module encrypted_timestamp (2) (real) 
> returned: 0/Success
> [17578] 1486068435.915931: Produced preauth for next request: 2
> [17578] 1486068435.915978: Sending request (273 bytes) to abc.com
> [17578] 1486068436.45327: Resolving hostname infdcpci01.abc.com.
> [17578] 1486068436.110256: Sending initial UDP request to dgram 
> x.x.161.251:88  (different server  dc01)
> [17578] 1486068436.191100: Received answer (102 bytes) from dgram 
> x.x.161.251:88

Is this a DC from the same realm?

> [17578] 1486068436.256271: Response was not from master KDC
> [17578] 1486068436.256323: Received error from KDC: -1765328372/KDC policy 
> rejects request
> [17578] 1486068436.256366: Retrying AS request with master KDC
> [17578] 1486068436.256381: Getting initial credentials for [email protected]
> [17578] 1486068436.256480: Sending request (193 bytes) to abc.com (master)
> kinit: KDC policy rejects request while getting initial credentials
> 
> 
> With krb5.conf:
> dns_lookup_kdc = false
> 
> [root@server01 etc]# KRB5_TRACE=/dev/stderr kinit [email protected]
> [17798] 1486068606.982122: Getting initial credentials for [email protected]
> [17798] 1486068606.982485: Sending request (193 bytes) to abc.com
> [17798] 1486068606.982757: Retrying AS request with master KDC
> [17798] 1486068606.982798: Getting initial credentials for [email protected]
> [17798] 1486068606.982864: Sending request (193 bytes) to abc.com (master)
> kinit: Cannot find KDC for realm "abc.com" while getting initial credentials

Does it work if you define a 'known good' DC in krb5.conf ?

> 
> 
> [root@server01 etc]# klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- 
> --------------------------------------------------------------------------
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 host/[email protected]
>    2 [email protected]
>    2 [email protected]
>    2 [email protected]
>    2 [email protected]
>    2 [email protected]
> 
> Sonia Gilbert, -Engineer II, Information Protection & Compliance Team
> 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503
> [email protected]
> 
> 
> 
> 
> -----Original Message-----
> From: Lukas Slebodnik [mailto:[email protected]] 
> Sent: Thursday, February 02, 2017 10:41 AM
> To: End-user discussions about the System Security Services Daemon 
> <[email protected]>
> Subject: [SSSD-users] Re: account not authenticating in child domain
> 
> On (02/02/17 19:55), Gilbert, Sonia wrote:
> >No.  Also they said that they opened up the firewall for all the ports.
> >
> >[root@server01 /]# kinit [email protected] Password for [email protected]:
> >kinit: KDC policy rejects request while getting initial credentials
> >
> >Could it be trying to use krb5.keytab?  Is it unique to each instance.  
> >Since it was removed from the realm, will it need to have a new keytab 
> >generated.  Is that a local verification or do we also have to do something 
> >on the AD server?
> >
> Use KRB5_TRACE for extra tracing information.
> e.g.
>    KRB5_TRACE=/dev/stderr kinit [email protected]
> 
> LS
> _______________________________________________
> sssd-users mailing list -- [email protected] To unsubscribe 
> send an email to [email protected]
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to