On 4/25/2017 2:00 AM, TomK wrote:
On 4/24/2017 9:40 PM, TomK wrote:
On 4/24/2017 12:41 PM, Sumit Bose wrote:
On Mon, Apr 24, 2017 at 12:22:02PM -0400, TomK wrote:
On 4/21/2017 9:48 PM, TomK wrote:
Hey All,
We are connecting a set of servers directly with AD. The AD computer
object is created for the host and is associated to a service account.
This service account works well with other hosts on the same domain.
Since this is a direct SSSD to AD setup, we are using adcli to
establish
a connection to AD.
adcli populates a /etc/krb5.keytab file with a number of entries
including:
* Added the entries to the keytab:
host/[email protected]:
FILE:/etc/krb5.keytab
and runs successfully, without errors, to completion. However when
starting up sssd, we see the following in the log files:
.
.
[[sssd[ldap_child[11774]]]] [main] (0x0400): ldap_child started.
[[sssd[ldap_child[11774]]]] [main] (0x2000): context initialized
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): total buffer
size: 71
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): realm_str
size: 12
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got realm_str:
COMPANY.COM
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): princ_str
size: 35
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got princ_str:
host/longhostname-host01.xyz.abc.co
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): keytab_name
size: 0
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): lifetime: 86400
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x0200): Will run as
[0][0].
[[sssd[ldap_child[11774]]]] [privileged_krb5_setup] (0x2000): Kerberos
context initialized
[[sssd[ldap_child[11774]]]] [main] (0x2000): Kerberos context
initialized
[[sssd[ldap_child[11774]]]] [become_user] (0x0200): Trying to become
user [0][0].
[[sssd[ldap_child[11774]]]] [become_user] (0x0200): Already user [0].
[[sssd[ldap_child[11774]]]] [main] (0x2000): Running as [0][0].
[[sssd[ldap_child[11774]]]] [main] (0x2000): getting TGT sync
got princ_str: host/[email protected]
.
.
Principal name is: [host/[email protected]]
.
.
followed by:
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.219837: Looked up etypes in keytab: des-cbc-crc, des,
des-cbc-crc, rc4-hmac, aes128-cts, aes256-cts
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.219898: Sending request (224 bytes) to COMPANY.COM
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.220151: Initiating TCP connection to stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.222555: Sending TCP request to stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.226128: Received answer from stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.226205: Response was from master KDC
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000):
[11774]
1492661662.226238: Received error from KDC: -1765328378/Client not
found
in Kerberos database
Verified that the krb5.keytab has the principal and it matches
exactly.
The OS is RHEL 6.7. Wondering if anyone ran into this and what
could be
some of the problems that could be causing this? Do we need something
extra to be done on the AD side besides creating the computer object?
We'd take it from there to dig further since I realize I can't provide
all the details without first editing things out as I did above.
Hey All,
Solved the above by specifying the exact and ONLY keytab entries the AD
server needed, [email protected], (autogenerated entries from
calling adcli were resulting in the above error message). Not sure
why but
an incorrect keytab entry was being picked up from the krb5.keytab
file even
though adcli was used to generate the krb5.keytab file. However now
Which id_provider did use? The AD provider should pick the right keytab
entry be default. As an alternative you can specify the right principal
with the ldap_sasl_authid option in the [domain/...] section of
sssd.conf (see man sssd-ldap for details).
receiving the following:
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313217: Received
error from KDC: -1765328359/Additional pre-authentication required
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313394:
Processing
preauth types: 11, 19, 2, 16, 15
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313457: Selected
etype info: etype rc4-hmac, salt "", params ""
hm, maybe adding the 'allow_weak_crypto' option to /etc/krb5.conf might
help, see man krb5.conf for details.
HTH
bye,
Sumit
The above eventually cascades into this:
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313894: Produced
preauth for next request: 2
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313965: Sending
request (276 bytes) to DOMAIN.COM
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.314134:
Initiating
TCP connection to stream 1.2.3.4:88
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.314426:
Sending TCP
request to stream 1.2.3.4:88
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.323829: Received
answer from stream 1.2.3.4:88
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.323997:
Response was
from master KDC
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.324066: Received
error from KDC: -1765328360/Preauthentication failed
Part of debugging, the option "Do not require Kerberos
preauthentication"
was unchecked. Any tips for getting this to work with
preauthentication are
greately appreciated.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the
sun.
_______________________________________________
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]
Hey Sumit,
Thanks.
id_provider = ad
It's direct from SSSD to AD in this environment. Tried the
allow_weak_crypto anyway but no effect.
We typically didn't have to use ldap_sasl_authid with these configs to
work. So hence my earlier question: if using keytabs for authentication
between Linux and AD, what is the correct procedure to setup the AD
objects? Would like to find out what is missing on that side since the
object doesn't appear to be created in the same manner as the ones done
earlier. For example, we can run kinit against something like this:
[email protected] but not:
/host/[email protected] or
/host/[email protected] etc.
Could some change have occurred to the AD Service Account to cause these?
I should add that prior to the difference between the working and non
working hosts were that the non working one picked up the following
principle:
got princ_str: verylong-hostname
whereas the non working one always picked the following one:
got princ_str: host/[email protected]
Not sure if this helps.
*Correction*
Working one picked up this:
got princ_str: verylong-hostname
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
