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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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.
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 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 ""
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.
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On (24/04/17 18:41), 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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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.
Should :-) https://pagure.io/SSSD/sssd/issue/3329
It works with single principal "short-hostname$@DOMAIN.COM" in keytab because sssd can fall back to any UPN with AD "*$".
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).
+1 for workaround with ldap_sasl_authid
LS
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM etc.
Could some change have occurred to the AD Service Account to cause these?
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
Not sure if this helps.
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
Not sure if this helps.
*Correction*
Working one picked up this:
got princ_str: verylong-hostname
Wondering if there are any more suggestions on this topic?
Cheers, Tom
Sent from my iPhone
On Apr 25, 2017, at 3:17 AM, TomK tk@mdevsys.com wrote:
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/longhostname-host01.xyz.abc.com@COMPANY.COM: 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/longhostname-host01.xyz.abc.com@COMPANY.COM . . Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] . .
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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On (25/04/17 15:26), Tom wrote:
Wondering if there are any more suggestions on this topic?
Which version of sssd do you use?
Do I understand it correctly that workaround with ldap_sasl_authid does not work?
Could you provide log files? It would be good to sanitize just a domain part of hostname (+ REALM)
LS
SSSD searches for a principal to use in the keytab based on the following priority:
* Priority of lookup: 1) our.hostname@REALM or host/our.hostname@REALM depending on the input 2) SHORT.HOSTNAME$@REALM (AD domain) 3) host/our.hostname@REALM 4) foobar$@REALM (AD domain) 5) host/foobar@REALM 6) host/foo@BAR 7) pick the first principal in the keytab
I expect on the system where SSSD is choosing host/hostname there are no keytab principals which match the first 2 choices listed above and therefore SSSD uses the host/hostname principal. You can run 'klist -k' to check, or you can add -v to the adcli join command to see which principals are added. If there is a difference between systems, I would check the system hostname and also check if the '-N' argument is used which can modify the principal names added to the /etc/krb5.keytab during the join.
Also, you can add the --user-principal argument to the adcli join command which will allow you to get a TGT with the host/our.hostname@REALM principal
Kind regards, Justin Stephenson
On 04/25/2017 03:26 PM, Tom wrote:
Wondering if there are any more suggestions on this topic?
Cheers, Tom
Sent from my iPhone
On Apr 25, 2017, at 3:17 AM, TomK tk@mdevsys.com wrote:
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/longhostname-host01.xyz.abc.com@COMPANY.COM: > 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/longhostname-host01.xyz.abc.com@COMPANY.COM > . > . > Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] > . > . > > 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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
We managed to create the key tab entry that worked. We did this earlier and now are at the subject errors instead of the original one.
We simply added the working entry into the keytab as a suggested and that moved us to the subject errors.
The error code now is:
1765328360 which is preceeded by code 1765328359 .
Produced preauth for next request: 2
I checked this and the time on ad dc is same as on this virtual client.
Cheers. Tom
Sent from my iPhone
On Apr 25, 2017, at 4:22 PM, Justin Stephenson jstephen@redhat.com wrote:
SSSD searches for a principal to use in the keytab based on the following priority:
* Priority of lookup: 1) our.hostname@REALM or host/our.hostname@REALM depending on the input 2) SHORT.HOSTNAME$@REALM (AD domain) 3) host/our.hostname@REALM 4) foobar$@REALM (AD domain) 5) host/foobar@REALM 6) host/foo@BAR 7) pick the first principal in the keytabI expect on the system where SSSD is choosing host/hostname there are no keytab principals which match the first 2 choices listed above and therefore SSSD uses the host/hostname principal. You can run 'klist -k' to check, or you can add -v to the adcli join command to see which principals are added. If there is a difference between systems, I would check the system hostname and also check if the '-N' argument is used which can modify the principal names added to the /etc/krb5.keytab during the join.
Also, you can add the --user-principal argument to the adcli join command which will allow you to get a TGT with the host/our.hostname@REALM principal
Kind regards, Justin Stephenson
On 04/25/2017 03:26 PM, Tom wrote: Wondering if there are any more suggestions on this topic? Cheers, Tom Sent from my iPhone
On Apr 25, 2017, at 3:17 AM, TomK tk@mdevsys.com wrote:
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/longhostname-host01.xyz.abc.com@COMPANY.COM: >> 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/longhostname-host01.xyz.abc.com@COMPANY.COM >> . >> . >> Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] >> . >> . >> >> 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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On (25/04/17 16:35), Tom wrote:
We managed to create the key tab entry that worked. We did this earlier and now are at the subject errors instead of the original one.
We simply added the working entry into the keytab as a suggested and that moved us to the subject errors.
The error code now is:
1765328360 which is preceeded by code 1765328359 .
Produced preauth for next request: 2
I checked this and the time on ad dc is same as on this virtual client.
Please provide sanitized log files. *_child.log might be useful as well. And not only domain log file.
Please also provide version of sssd.
LS
On 4/25/2017 4:42 PM, Lukas Slebodnik wrote:
On (25/04/17 16:35), Tom wrote:
We managed to create the key tab entry that worked. We did this earlier and now are at the subject errors instead of the original one.
We simply added the working entry into the keytab as a suggested and that moved us to the subject errors.
The error code now is:
1765328360 which is preceeded by code 1765328359 .
Produced preauth for next request: 2
I checked this and the time on ad dc is same as on this virtual client.
Please provide sanitized log files. *_child.log might be useful as well. And not only domain log file.
Please also provide version of sssd.
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Thanks Lukas. Sent you, Sumit the sanitized file + sssd versions etc.
sssd-krb5-common-1.13.3-56.el6.x86_64
sssd-ldap-1.13.3-56.el6.x86_64
sssd-client-1.13.3-56.el6.x86_64
sssd-common-1.13.3-56.el6.x86_64
sssd-common-pac-1.13.3-56.el6.x86_64
sssd-ad-1.13.3-56.el6.x86_64
sssd-krb5-1.13.3-56.el6.x86_64
sssd-1.13.3-56.el6.x86_64
python-sssdconfig-1.13.3-56.el6.noarch
sssd-ipa-1.13.3-56.el6.x86_64
sssd-proxy-1.13.3-56.el6.x86_64
sssd-krb5-common-1.13.3-56.el6.x86_64
krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
pam_krb5-2.3.11-9.el6.x86_64
sssd-krb5-1.13.3-56.el6.x86_64
krb5-devel-1.10.3-65.el6.x86_64
On 4/25/2017 11:04 PM, TomK wrote:
On 4/25/2017 4:42 PM, Lukas Slebodnik wrote:
On (25/04/17 16:35), Tom wrote:
We managed to create the key tab entry that worked. We did this earlier and now are at the subject errors instead of the original one.
We simply added the working entry into the keytab as a suggested and that moved us to the subject errors.
The error code now is:
1765328360 which is preceeded by code 1765328359 .
Produced preauth for next request: 2
I checked this and the time on ad dc is same as on this virtual client.
Please provide sanitized log files. *_child.log might be useful as well. And not only domain log file.
Please also provide version of sssd.
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Thanks Lukas. Sent you, Sumit the sanitized file + sssd versions etc.
sssd-krb5-common-1.13.3-56.el6.x86_64
sssd-ldap-1.13.3-56.el6.x86_64
sssd-client-1.13.3-56.el6.x86_64
sssd-common-1.13.3-56.el6.x86_64
sssd-common-pac-1.13.3-56.el6.x86_64
sssd-ad-1.13.3-56.el6.x86_64
sssd-krb5-1.13.3-56.el6.x86_64
sssd-1.13.3-56.el6.x86_64
python-sssdconfig-1.13.3-56.el6.noarch
sssd-ipa-1.13.3-56.el6.x86_64
sssd-proxy-1.13.3-56.el6.x86_64
sssd-krb5-common-1.13.3-56.el6.x86_64
krb5-workstation-1.10.3-65.el6.x86_64
krb5-libs-1.10.3-65.el6.x86_64
pam_krb5-2.3.11-9.el6.x86_64
sssd-krb5-1.13.3-56.el6.x86_64
krb5-devel-1.10.3-65.el6.x86_64
Hey All,
Bit late and this was resolved in early May but wanted to share the solution here that worked for us with the help of folks on this list.
All of the following 3 solutions worked.
1) Remove the option --computer-name=$LHOST from the adcli command.
2) Leave the --computer-name as is but ensure to specify the host value in uppercase. ( ie --computer-name=CLIENTSRV-01 instead of --computer-name=clientsrv-01 )
3) Creating the keytab in lowercase manually, also worked.
Best solution for us was #1 above.
For details around these solutions, see below. Thanks Sumit, Lukas, Justin.
Is it possible to email the configuration and logs to RH only?
Cheers, Tom
Sent from my iPhone
On Apr 25, 2017, at 4:22 PM, Justin Stephenson jstephen@redhat.com wrote:
SSSD searches for a principal to use in the keytab based on the following priority:
* Priority of lookup: 1) our.hostname@REALM or host/our.hostname@REALM depending on the input 2) SHORT.HOSTNAME$@REALM (AD domain) 3) host/our.hostname@REALM 4) foobar$@REALM (AD domain) 5) host/foobar@REALM 6) host/foo@BAR 7) pick the first principal in the keytabI expect on the system where SSSD is choosing host/hostname there are no keytab principals which match the first 2 choices listed above and therefore SSSD uses the host/hostname principal. You can run 'klist -k' to check, or you can add -v to the adcli join command to see which principals are added. If there is a difference between systems, I would check the system hostname and also check if the '-N' argument is used which can modify the principal names added to the /etc/krb5.keytab during the join.
Also, you can add the --user-principal argument to the adcli join command which will allow you to get a TGT with the host/our.hostname@REALM principal
Kind regards, Justin Stephenson
On 04/25/2017 03:26 PM, Tom wrote: Wondering if there are any more suggestions on this topic? Cheers, Tom Sent from my iPhone
On Apr 25, 2017, at 3:17 AM, TomK tk@mdevsys.com wrote:
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/longhostname-host01.xyz.abc.com@COMPANY.COM: >> 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/longhostname-host01.xyz.abc.com@COMPANY.COM >> . >> . >> Principal name is: [host/longhostname-host01.xyz.abc.com@COMPANY.COM] >> . >> . >> >> 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, short-hostname@DOMAIN.COM, (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 -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
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: verylong-hostname@DOMAIN.COM but not: /host/verylong-hostname@DOMAIN.COM or /host/verylong-hostname.sub.domain.com@DOMAIN.COM 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/verylong-hostname.subdomain.domain.com@DOMAIN.COM
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Justin Stephenson -
Lukas Slebodnik -
Sumit Bose -
Tom -
TomK