Update:
Uninstalled and re-installed all realmd components. Performed a realm join to parent domain. Authentication to parent domain is restored but authentication to subdomain is still not working.
Even though sssd is trying to authenticate to the correct domain controller it fails. I suspect it is because sssd does not know about principal in child domain and keytab does not have entries for child domain host.
What do I need to do to point sssd to the master kdc in child domain and authenticate users? Do we need to create a computer object for the server in child domain?
When you kinit to child domain (a.abc.com) - it fails "Response was not form master KDC" - it does go to the secondary domain controller in the child domain. See output of KRB5_TRACE=/dev/stdout below. Other configs and logs below: Secure.log Krb5.log Output of realm list Output of klist -k Sssd.conf Krb5.conf Output of pam.d system-auth
[root@server01 log]# KRB5_TRACE=/dev/stdout kinit -V username@a.abc.com Using default cache: /tmp/krb5cc_0 Using principal: username@a.abc.com [21234] 1488228264.116970: Getting initial credentials for username@a.abc.com [21234] 1488228264.117539: Sending request (209 bytes) to a.abc.com [21234] 1488228264.246215: Resolving hostname sdc01.a.abc.com. [21234] 1488228264.313399: Sending initial UDP request to dgram x.x.166.251:88 [21234] 1488228264.383772: Received answer (219 bytes) from dgram x.x.166.251:88 [21234] 1488228264.448453: Response was not from master KDC [21234] 1488228264.448519: Received error from KDC: -1765328359/Additional pre-authentication required [21234] 1488228264.448584: Processing preauth types: 16, 15, 19, 2 [21234] 1488228264.448622: Selected etype info: etype aes256-cts, salt "a.abc.comusername", params "" Password for username@a.abc.com: [21234] 1488228274.851028: AS key obtained for encrypted timestamp: aes256-cts/D574 [21234] 1488228274.851105: Encrypted timestamp (for 1488228256.665529): plain 301AA011180F32303137303232373230343431365AA10502030A27B9, encrypted 6818747034DA70128C9E22CF1A56A1815E14509E91693BB286BB899BBAE65F321141405718086D119447EB82A34498D0E16EA8E2F5FF71CA [21234] 1488228274.851138: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [21234] 1488228274.851170: Produced preauth for next request: 2 [21234] 1488228274.851208: Sending request (289 bytes) to a.abc.com [21234] 1488228274.982261: Resolving hostname infsdcpci02.a.abc.com. [21234] 1488228275.48986: Sending initial UDP request to dgram x.x.166.252:88 [21234] 1488228275.118201: Received answer (186 bytes) from dgram x.x.166.252:88 [21234] 1488228275.182721: Response was not from master KDC [21234] 1488228275.182772: Received error from KDC: -1765328360/Preauthentication failed [21234] 1488228275.182830: Preauth tryagain input types: 16, 15, 19, 2 [21234] 1488228275.182862: Retrying AS request with master KDC [21234] 1488228275.182889: Getting initial credentials for username@a.abc.com [21234] 1488228275.182963: Sending request (209 bytes) to a.abc.com (master) kinit: Preauthentication failed while getting initial credentials
#########################################################################
secure.log - because we are using authlite for two-factor authentication, system-auth points to the auth.py script (note that it uses the same script for parent domain and successfully authenticates using two factor)
Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: a.abc.com \jufgkdildfnkjvceveehvtfnckjleingtneevlgugrdhngrccjuirirnhckltihb Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
#####################################################################################
Krb5.log (In ther krb5.log, sssd authenticates to the parent domain "Attempting kinit for realm [ABC.COM" and gets "KDC policy rejects" error.
(Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child started. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x1000): total buffer size: [145] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): cmd [241] uid [1915601461] gid [1915601461] validate [true] enterprise principal [true] offline [false] UPN [username@a.abc.com] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x2000): No old ccache (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1915601461_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [check_use_fast] (0x0100): Not using FAST. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [become_user] (0x0200): Trying to become user [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [k5c_setup] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): Will perform online auth (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ABC.COM] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [map_krb5_error] (0x0020): 1303: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [pack_response_packet] (0x2000): response packet size: [4] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child completed successfully
[root@server01 etc]# realm list -all (shouldn't this output show both realms?) abc.com type: kerberos realm-name: ABC.COM domain-name: abc.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U login-policy: allow-permitted-logins permitted-logins: permitted-groups: Remote Access Users@abc.com, Remote Access Users@a.abc.com
######################################################
[root@PHXRASPCI01 pam.d]# klist -k (keytab only has entries for parent domain) Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM [root@SERVER01 pam.d]#
#############################################################
[root@server01 etc]# more /etc/sssd/sssd.conf
[sssd] domains = abc.com config_file_version = 2 services = nss, pam
[domain/abc.com] ad_domain = abc.com krb5_realm = ABC.COM ad_server = dc01.abc.com,dc02.abc.com,_srv_ realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple debug_level = 8 simple_allow_groups = TDI Remote Access Users@abc.com, TDI Remote Access Users@a.abc.com
########################################################
[root@server01 etc]# more /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d # forwardable = true rdns = false default_realm = ABC.COM # default_ccache_name = KEYRING:persistent:%{uid} # kdc_timesync = 1
[realms] ABC.COM = { kdc = dc01.abc.com kdc = dc02.abc.com admin_server = dc01.abc.com }
[domain_realm] .abc.com = ABC.COM abc.com = ABC.COM
################################################## system-auth
[root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
[
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.commailto:Sonia.Gilbert@HawaiianAir.com
[HA Email Signature Logo]
On Tue, Feb 28, 2017 at 02:31:08AM +0000, Gilbert, Sonia wrote:
Update:
Uninstalled and re-installed all realmd components. Performed a realm join to parent domain. Authentication to parent domain is restored but authentication to subdomain is still not working.
Even though sssd is trying to authenticate to the correct domain controller it fails. I suspect it is because sssd does not know about principal in child domain and keytab does not have entries for child domain host.
What do I need to do to point sssd to the master kdc in child domain and authenticate users? Do we need to create a computer object for the server in child domain?
When you kinit to child domain (a.abc.com) - it fails "Response was not form master KDC" - it does go to the secondary domain controller in the child domain.
The 'Response was not form master KDC' is just an info message not an error message. Using a secondary domain controller is completely ok during authentication, additionally AD does not use the 'master KDC' concept at all.
Since there is a trust relationship between parent and subdomain it is sufficient to have a keytab entry for only one domain. And as you can see during the kinit call the keytab isn't used at all. SSSD will use it after the TGT is received to validate the ticket but even here keys from one domain are sufficient.
See output of KRB5_TRACE=/dev/stdout below. Other configs and logs below: Secure.log Krb5.log Output of realm list Output of klist -k Sssd.conf Krb5.conf Output of pam.d system-auth
[root@server01 log]# KRB5_TRACE=/dev/stdout kinit -V username@a.abc.com Using default cache: /tmp/krb5cc_0 Using principal: username@a.abc.com [21234] 1488228264.116970: Getting initial credentials for username@a.abc.com [21234] 1488228264.117539: Sending request (209 bytes) to a.abc.com [21234] 1488228264.246215: Resolving hostname sdc01.a.abc.com. [21234] 1488228264.313399: Sending initial UDP request to dgram x.x.166.251:88 [21234] 1488228264.383772: Received answer (219 bytes) from dgram x.x.166.251:88 [21234] 1488228264.448453: Response was not from master KDC [21234] 1488228264.448519: Received error from KDC: -1765328359/Additional pre-authentication required [21234] 1488228264.448584: Processing preauth types: 16, 15, 19, 2 [21234] 1488228264.448622: Selected etype info: etype aes256-cts, salt "a.abc.comusername", params "" Password for username@a.abc.com: [21234] 1488228274.851028: AS key obtained for encrypted timestamp: aes256-cts/D574 [21234] 1488228274.851105: Encrypted timestamp (for 1488228256.665529): plain 301AA011180F32303137303232373230343431365AA10502030A27B9, encrypted 6818747034DA70128C9E22CF1A56A1815E14509E91693BB286BB899BBAE65F321141405718086D119447EB82A34498D0E16EA8E2F5FF71CA [21234] 1488228274.851138: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [21234] 1488228274.851170: Produced preauth for next request: 2 [21234] 1488228274.851208: Sending request (289 bytes) to a.abc.com [21234] 1488228274.982261: Resolving hostname infsdcpci02.a.abc.com. [21234] 1488228275.48986: Sending initial UDP request to dgram x.x.166.252:88 [21234] 1488228275.118201: Received answer (186 bytes) from dgram x.x.166.252:88 [21234] 1488228275.182721: Response was not from master KDC [21234] 1488228275.182772: Received error from KDC: -1765328360/Preauthentication failed [21234] 1488228275.182830: Preauth tryagain input types: 16, 15, 19, 2 [21234] 1488228275.182862: Retrying AS request with master KDC [21234] 1488228275.182889: Getting initial credentials for username@a.abc.com [21234] 1488228275.182963: Sending request (209 bytes) to a.abc.com (master) kinit: Preauthentication failed while getting initial credentials
The most probable reason for a 'Preauthentication failed' error is a wrong password. Did you change the password for 'username@a.abc.com' recently? Maybe there are replication issues between the AD domain controllers and the password was not updated correctly on some controllers?
A different reason might be different times on the DCs and the client, but I would expect different error codes in this case.
bye, Sumit
#########################################################################
secure.log - because we are using authlite for two-factor authentication, system-auth points to the auth.py script (note that it uses the same script for parent domain and successfully authenticates using two factor)
Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: a.abc.com \jufgkdildfnkjvceveehvtfnckjleingtneevlgugrdhngrccjuirirnhckltihb Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
#####################################################################################
Krb5.log (In ther krb5.log, sssd authenticates to the parent domain "Attempting kinit for realm [ABC.COM" and gets "KDC policy rejects" error.
(Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child started. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x1000): total buffer size: [145] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): cmd [241] uid [1915601461] gid [1915601461] validate [true] enterprise principal [true] offline [false] UPN [username@a.abc.com] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x2000): No old ccache (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1915601461_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [check_use_fast] (0x0100): Not using FAST. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [become_user] (0x0200): Trying to become user [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [k5c_setup] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): Will perform online auth (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ABC.COM] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [map_krb5_error] (0x0020): 1303: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [pack_response_packet] (0x2000): response packet size: [4] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child completed successfully
[root@server01 etc]# realm list -all (shouldn't this output show both realms?) abc.com type: kerberos realm-name: ABC.COM domain-name: abc.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U login-policy: allow-permitted-logins permitted-logins: permitted-groups: Remote Access Users@abc.com, Remote Access Users@a.abc.com
######################################################
[root@PHXRASPCI01 pam.d]# klist -k (keytab only has entries for parent domain) Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM [root@SERVER01 pam.d]#
#############################################################
[root@server01 etc]# more /etc/sssd/sssd.conf
[sssd] domains = abc.com config_file_version = 2 services = nss, pam
[domain/abc.com] ad_domain = abc.com krb5_realm = ABC.COM ad_server = dc01.abc.com,dc02.abc.com,_srv_ realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple debug_level = 8 simple_allow_groups = TDI Remote Access Users@abc.com, TDI Remote Access Users@a.abc.com
########################################################
[root@server01 etc]# more /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d # forwardable = true rdns = false default_realm = ABC.COM # default_ccache_name = KEYRING:persistent:%{uid} # kdc_timesync = 1
[realms] ABC.COM = { kdc = dc01.abc.com kdc = dc02.abc.com admin_server = dc01.abc.com }
[domain_realm] .abc.com = ABC.COM abc.com = ABC.COM
################################################## system-auth
[root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
[
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.commailto:Sonia.Gilbert@HawaiianAir.com
[HA Email Signature Logo]
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Aloha Sumit, Jakub, and Lukas,
Thank you for helping out with this. Up against compliance race to get this working and its looking more and more bleak. I really appreciate you folks taking another look.
The 'Response was not form master KDC' is just an info message not an error message. Using a secondary domain controller is completely ok during authentication, additionally AD does not use the 'master KDC' concept at all.
Since there is a trust relationship between parent and subdomain it is sufficient to have a keytab entry for only one domain. And as you can see during the kinit call the keytab isn't used at all. SSSD will use it after the >TGT is received to validate the ticket but even here keys from one domain are sufficient.
Authentication is sent through PAM which runs a custom script auth.py that was provided by authlite (vendor for MFA using yubikey). Authlite believes that 'ad_server' preference is not working. He has recreated the scenario in his lab. From the log snippet from secure.log you can see unsuccessful to child domain but success to parent. Below the logs you can see the feedback from Authlite. TDI Consoleworks is the user front end application running on centos which is set for external authentication using PAM.
Sumit, I suspect you are right about the wrong password. I had them reset it just be sure but still same result. Could auth.py script be passing the password incorrectly to child domain?
<<<<<Child domain>>>> Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 156, in pam_sm_authenticate Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 146, in update_password Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: jufgkdildfnkjvceveehvtfnckjleingkbgujrbcfjcuiifbfngndnurhdnhluce Mar 6 15:21:26 SERVER01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Mar 6 15:21:26 SERVER01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
<<<<parent domain>>>>> Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: jufgkdildfnkjvceveehvtfnckjleinggliiedlfdknhtlhjjkdhhbjgvigvrhkf Mar 6 15:22:46 SERVER01 cw[30366]: pam_sss(conwrks:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=username
<<<PAM>>>>> ################################################## system-auth [root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
<<<<<<<From authlite>>>>>>>>> OK guys, I have been working on this all weekend in a lab with 2 domains and 2 DCs each like your scenario.
To review: we absolutely need SSSD to honor the "ad_server" order. The only way to do this is to chuck the whole forest/trust thing and just look at the joined domain.
A machine can only be joined to one domain. This means there would need to be two separate CentOS/Consoleworks machines, one for parent domain and one for child domain. Users would need to go to the server that matches their domain, instead of all funneling into one Consoleworks URL.
Other possibilities:
1) I could make an auth.py that was *way* more complex: It could try to parse what domain was being requested by the authentication, and then spray the OTP sequentially to both DC in that domain over LDAP. That way affinity wouldn't matter so much.
I would consider this to be an exceedingly fraught/fragile solution. It would need:
* hardcoded domain list * a hardcoded list of DCs for each domain * an LDAP service account for each domain, with the passwords hardcoded into the auth.py file.
2) If you totally abandon domain joining, then maybe it could be possible to use a raw krb5 configuration to join 2 separate realms, but I have no idea how to make that configuration work. It would take more hours of research and testing. I think it also requires certificate trust of some nature with the DCs (which is automagically done by the AD module).
3) It could also be possible to use a raw ldap configuration, but that requires things you don't have, such as LDAP-S enabled on your DCs, punched through the firewall, and CentOS would need to trust the TLS certificates of the DCs. This would, obviously, also be many more hours of research and configuration.
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.com
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Monday, February 27, 2017 11:53 PM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: account not authenticating in child domain
On Tue, Feb 28, 2017 at 02:31:08AM +0000, Gilbert, Sonia wrote:
Update:
Uninstalled and re-installed all realmd components. Performed a realm join to parent domain. Authentication to parent domain is restored but authentication to subdomain is still not working.
Even though sssd is trying to authenticate to the correct domain controller it fails. I suspect it is because sssd does not know about principal in child domain and keytab does not have entries for child domain host.
What do I need to do to point sssd to the master kdc in child domain and authenticate users? Do we need to create a computer object for the server in child domain?
When you kinit to child domain (a.abc.com) - it fails "Response was not form master KDC" - it does go to the secondary domain controller in the child domain.
The 'Response was not form master KDC' is just an info message not an error message. Using a secondary domain controller is completely ok during authentication, additionally AD does not use the 'master KDC' concept at all.
Since there is a trust relationship between parent and subdomain it is sufficient to have a keytab entry for only one domain. And as you can see during the kinit call the keytab isn't used at all. SSSD will use it after the TGT is received to validate the ticket but even here keys from one domain are sufficient.
See output of KRB5_TRACE=/dev/stdout below. Other configs and logs below: Secure.log Krb5.log Output of realm list Output of klist -k Sssd.conf Krb5.conf Output of pam.d system-auth
[root@server01 log]# KRB5_TRACE=/dev/stdout kinit -V username@a.abc.com Using default cache: /tmp/krb5cc_0 Using principal: username@a.abc.com [21234] 1488228264.116970: Getting initial credentials for username@a.abc.com [21234] 1488228264.117539: Sending request (209 bytes) to a.abc.com [21234] 1488228264.246215: Resolving hostname sdc01.a.abc.com. [21234] 1488228264.313399: Sending initial UDP request to dgram x.x.166.251:88 [21234] 1488228264.383772: Received answer (219 bytes) from dgram x.x.166.251:88 [21234] 1488228264.448453: Response was not from master KDC [21234] 1488228264.448519: Received error from KDC: -1765328359/Additional pre-authentication required [21234] 1488228264.448584: Processing preauth types: 16, 15, 19, 2 [21234] 1488228264.448622: Selected etype info: etype aes256-cts, salt "a.abc.comusername", params "" Password for username@a.abc.com: [21234] 1488228274.851028: AS key obtained for encrypted timestamp: aes256-cts/D574 [21234] 1488228274.851105: Encrypted timestamp (for 1488228256.665529): plain 301AA011180F32303137303232373230343431365AA10502030A27B9, encrypted 6818747034DA70128C9E22CF1A56A1815E14509E91693BB286BB899BBAE65F32114140 5718086D119447EB82A34498D0E16EA8E2F5FF71CA [21234] 1488228274.851138: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [21234] 1488228274.851170: Produced preauth for next request: 2 [21234] 1488228274.851208: Sending request (289 bytes) to a.abc.com [21234] 1488228274.982261: Resolving hostname infsdcpci02.a.abc.com. [21234] 1488228275.48986: Sending initial UDP request to dgram x.x.166.252:88 [21234] 1488228275.118201: Received answer (186 bytes) from dgram x.x.166.252:88 [21234] 1488228275.182721: Response was not from master KDC [21234] 1488228275.182772: Received error from KDC: -1765328360/Preauthentication failed [21234] 1488228275.182830: Preauth tryagain input types: 16, 15, 19, 2 [21234] 1488228275.182862: Retrying AS request with master KDC [21234] 1488228275.182889: Getting initial credentials for username@a.abc.com [21234] 1488228275.182963: Sending request (209 bytes) to a.abc.com (master) kinit: Preauthentication failed while getting initial credentials
The most probable reason for a 'Preauthentication failed' error is a wrong password. Did you change the password for 'username@a.abc.com' recently? Maybe there are replication issues between the AD domain controllers and the password was not updated correctly on some controllers?
A different reason might be different times on the DCs and the client, but I would expect different error codes in this case.
bye, Sumit
###################################################################### ###
secure.log - because we are using authlite for two-factor authentication, system-auth points to the auth.py script (note that it uses the same script for parent domain and successfully authenticates using two factor)
Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: a.abc.com \jufgkdildfnkjvceveehvtfnckjleingtneevlgugrdhngrccjuirirnhckltihb Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
###################################################################### ###############
Krb5.log (In ther krb5.log, sssd authenticates to the parent domain "Attempting kinit for realm [ABC.COM" and gets "KDC policy rejects" error.
(Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child started. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x1000): total buffer size: [145] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): cmd [241] uid [1915601461] gid [1915601461] validate [true] enterprise principal [true] offline [false] UPN [username@a.abc.com] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x2000): No old ccache (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1915601461_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [check_use_fast] (0x0100): Not using FAST. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [become_user] (0x0200): Trying to become user [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [k5c_setup] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): Will perform online auth (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ABC.COM] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [map_krb5_error] (0x0020): 1303: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [pack_response_packet] (0x2000): response packet size: [4] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child completed successfully
[root@server01 etc]# realm list -all (shouldn't this output show both realms?) abc.com type: kerberos realm-name: ABC.COM domain-name: abc.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U login-policy: allow-permitted-logins permitted-logins: permitted-groups: Remote Access Users@abc.com, Remote Access Users@a.abc.com
######################################################
[root@SERVER01 pam.d]# klist -k (keytab only has entries for parent domain) Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM [root@SERVER01 pam.d]#
#############################################################
[root@server01 etc]# more /etc/sssd/sssd.conf
[sssd] domains = abc.com config_file_version = 2 services = nss, pam
[domain/abc.com] ad_domain = abc.com krb5_realm = ABC.COM ad_server = dc01.abc.com,dc02.abc.com,_srv_ realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple debug_level = 8 simple_allow_groups = TDI Remote Access Users@abc.com, TDI Remote Access Users@a.abc.com
########################################################
[root@server01 etc]# more /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d # forwardable = true rdns = false default_realm = ABC.COM # default_ccache_name = KEYRING:persistent:%{uid} # kdc_timesync = 1
[realms] ABC.COM = { kdc = dc01.abc.com kdc = dc02.abc.com admin_server = dc01.abc.com }
[domain_realm] .abc.com = ABC.COM abc.com = ABC.COM
################################################## system-auth
[root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
[
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.commailto:Sonia.Gilbert@HawaiianAir.com
[HA Email Signature Logo]
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 Wed, Mar 08, 2017 at 01:40:54AM +0000, Gilbert, Sonia wrote:
Aloha Sumit, Jakub, and Lukas,
Thank you for helping out with this. Up against compliance race to get this working and its looking more and more bleak. I really appreciate you folks taking another look.
The 'Response was not form master KDC' is just an info message not an error message. Using a secondary domain controller is completely ok during authentication, additionally AD does not use the 'master KDC' concept at all.
Since there is a trust relationship between parent and subdomain it is sufficient to have a keytab entry for only one domain. And as you can see during the kinit call the keytab isn't used at all. SSSD will use it after the >TGT is received to validate the ticket but even here keys from one domain are sufficient.
This sounds quite interesting and I would to work with you on this. But unfortunately I'm currently quite busy trying to meet some deadlines. I wonder if it would be ok if you ping me again in two weeks. By this time I'll should have had a closer look at http://s3.authlite.com/downloads/pam/auth.py and might have some ideas how to make it work with SSSD in an AD forest or what can be done on the SSSD side to support this use case.
I hope this will work for you.
bye, Sumit
Authentication is sent through PAM which runs a custom script auth.py that was provided by authlite (vendor for MFA using yubikey). Authlite believes that 'ad_server' preference is not working. He has recreated the scenario in his lab. From the log snippet from secure.log you can see unsuccessful to child domain but success to parent. Below the logs you can see the feedback from Authlite. TDI Consoleworks is the user front end application running on centos which is set for external authentication using PAM.
Sumit, I suspect you are right about the wrong password. I had them reset it just be sure but still same result. Could auth.py script be passing the password incorrectly to child domain?
<<<<<Child domain>>>> Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 156, in pam_sm_authenticate Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 146, in update_password Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Mar 6 15:21:22 SERVER01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: jufgkdildfnkjvceveehvtfnckjleingkbgujrbcfjcuiifbfngndnurhdnhluce Mar 6 15:21:26 SERVER01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Mar 6 15:21:26 SERVER01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
<<<<parent domain>>>>> Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Mar 6 15:22:44 SERVER01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: jufgkdildfnkjvceveehvtfnckjleinggliiedlfdknhtlhjjkdhhbjgvigvrhkf Mar 6 15:22:46 SERVER01 cw[30366]: pam_sss(conwrks:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=username
<<<PAM>>>>> ################################################## system-auth [root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
<<<<<<<From authlite>>>>>>>>> OK guys, I have been working on this all weekend in a lab with 2 domains and 2 DCs each like your scenario.
To review: we absolutely need SSSD to honor the "ad_server" order. The only way to do this is to chuck the whole forest/trust thing and just look at the joined domain.
A machine can only be joined to one domain. This means there would need to be two separate CentOS/Consoleworks machines, one for parent domain and one for child domain. Users would need to go to the server that matches their domain, instead of all funneling into one Consoleworks URL.
Other possibilities:
I could make an auth.py that was *way* more complex: It could try to parse what domain was being requested by the authentication, and then spray the OTP sequentially to both DC in that domain over LDAP. That way affinity wouldn't matter so much.
I would consider this to be an exceedingly fraught/fragile solution. It would need:
- hardcoded domain list
- a hardcoded list of DCs for each domain
- an LDAP service account for each domain, with the passwords hardcoded into the auth.py file.
If you totally abandon domain joining, then maybe it could be possible to use a raw krb5 configuration to join 2 separate realms, but I have no idea how to make that configuration work. It would take more hours of research and testing. I think it also requires certificate trust of some nature with the DCs (which is automagically done by the AD module).
It could also be possible to use a raw ldap configuration, but that requires things you don't have, such as LDAP-S enabled on your DCs, punched through the firewall, and CentOS would need to trust the TLS certificates of the DCs. This would, obviously, also be many more hours of research and configuration.
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.com
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Monday, February 27, 2017 11:53 PM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: account not authenticating in child domain
On Tue, Feb 28, 2017 at 02:31:08AM +0000, Gilbert, Sonia wrote:
Update:
Uninstalled and re-installed all realmd components. Performed a realm join to parent domain. Authentication to parent domain is restored but authentication to subdomain is still not working.
Even though sssd is trying to authenticate to the correct domain controller it fails. I suspect it is because sssd does not know about principal in child domain and keytab does not have entries for child domain host.
What do I need to do to point sssd to the master kdc in child domain and authenticate users? Do we need to create a computer object for the server in child domain?
When you kinit to child domain (a.abc.com) - it fails "Response was not form master KDC" - it does go to the secondary domain controller in the child domain.
The 'Response was not form master KDC' is just an info message not an error message. Using a secondary domain controller is completely ok during authentication, additionally AD does not use the 'master KDC' concept at all.
Since there is a trust relationship between parent and subdomain it is sufficient to have a keytab entry for only one domain. And as you can see during the kinit call the keytab isn't used at all. SSSD will use it after the TGT is received to validate the ticket but even here keys from one domain are sufficient.
See output of KRB5_TRACE=/dev/stdout below. Other configs and logs below: Secure.log Krb5.log Output of realm list Output of klist -k Sssd.conf Krb5.conf Output of pam.d system-auth
[root@server01 log]# KRB5_TRACE=/dev/stdout kinit -V username@a.abc.com Using default cache: /tmp/krb5cc_0 Using principal: username@a.abc.com [21234] 1488228264.116970: Getting initial credentials for username@a.abc.com [21234] 1488228264.117539: Sending request (209 bytes) to a.abc.com [21234] 1488228264.246215: Resolving hostname sdc01.a.abc.com. [21234] 1488228264.313399: Sending initial UDP request to dgram x.x.166.251:88 [21234] 1488228264.383772: Received answer (219 bytes) from dgram x.x.166.251:88 [21234] 1488228264.448453: Response was not from master KDC [21234] 1488228264.448519: Received error from KDC: -1765328359/Additional pre-authentication required [21234] 1488228264.448584: Processing preauth types: 16, 15, 19, 2 [21234] 1488228264.448622: Selected etype info: etype aes256-cts, salt "a.abc.comusername", params "" Password for username@a.abc.com: [21234] 1488228274.851028: AS key obtained for encrypted timestamp: aes256-cts/D574 [21234] 1488228274.851105: Encrypted timestamp (for 1488228256.665529): plain 301AA011180F32303137303232373230343431365AA10502030A27B9, encrypted 6818747034DA70128C9E22CF1A56A1815E14509E91693BB286BB899BBAE65F32114140 5718086D119447EB82A34498D0E16EA8E2F5FF71CA [21234] 1488228274.851138: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [21234] 1488228274.851170: Produced preauth for next request: 2 [21234] 1488228274.851208: Sending request (289 bytes) to a.abc.com [21234] 1488228274.982261: Resolving hostname infsdcpci02.a.abc.com. [21234] 1488228275.48986: Sending initial UDP request to dgram x.x.166.252:88 [21234] 1488228275.118201: Received answer (186 bytes) from dgram x.x.166.252:88 [21234] 1488228275.182721: Response was not from master KDC [21234] 1488228275.182772: Received error from KDC: -1765328360/Preauthentication failed [21234] 1488228275.182830: Preauth tryagain input types: 16, 15, 19, 2 [21234] 1488228275.182862: Retrying AS request with master KDC [21234] 1488228275.182889: Getting initial credentials for username@a.abc.com [21234] 1488228275.182963: Sending request (209 bytes) to a.abc.com (master) kinit: Preauthentication failed while getting initial credentials
The most probable reason for a 'Preauthentication failed' error is a wrong password. Did you change the password for 'username@a.abc.com' recently? Maybe there are replication issues between the AD domain controllers and the password was not updated correctly on some controllers?
A different reason might be different times on the DCs and the client, but I would expect different error codes in this case.
bye, Sumit
###################################################################### ###
secure.log - because we are using authlite for two-factor authentication, system-auth points to the auth.py script (note that it uses the same script for parent domain and successfully authenticates using two factor)
Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: Traceback (most recent call last): Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 163, in pam_sm_authenticate Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: update_password(pamh) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: File "/usr/lib64/security/auth.py", line 152, in update_password Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: pwd.getpwnam(domain + sep + res['OTP']) Feb 27 17:45:30 server01 /usr/lib64/security/auth.py[30366]: KeyError: getpwnam(): name not found: a.abc.com \jufgkdildfnkjvceveehvtfnckjleingtneevlgugrdhngrccjuirirnhckltihb Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=username@a.abc.com Feb 27 17:45:34 server01 cw[30366]: pam_sss(conwrks:auth): received for user username@a.abc.com: 4 (System error)
###################################################################### ###############
Krb5.log (In ther krb5.log, sssd authenticates to the parent domain "Attempting kinit for realm [ABC.COM" and gets "KDC policy rejects" error.
(Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child started. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x1000): total buffer size: [145] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): cmd [241] uid [1915601461] gid [1915601461] validate [true] enterprise principal [true] offline [false] UPN [username@a.abc.com] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x2000): No old ccache (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1915601461_XXXXXX] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [check_use_fast] (0x0100): Not using FAST. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [become_user] (0x0200): Trying to become user [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [k5c_setup] (0x2000): Running as [1915601461][1915601461]. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): Will perform online auth (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Mon Feb 27 14:45:33 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [ABC.COM] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [map_krb5_error] (0x0020): 1303: [-1765328372][KDC policy rejects request] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [pack_response_packet] (0x2000): response packet size: [4] (Mon Feb 27 14:45:34 2017) [[sssd[krb5_child[29102]]]] [main] (0x0400): krb5_child completed successfully
[root@server01 etc]# realm list -all (shouldn't this output show both realms?) abc.com type: kerberos realm-name: ABC.COM domain-name: abc.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common login-formats: %U login-policy: allow-permitted-logins permitted-logins: permitted-groups: Remote Access Users@abc.com, Remote Access Users@a.abc.com
######################################################
[root@SERVER01 pam.d]# klist -k (keytab only has entries for parent domain) Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01.abc.com@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 host/server01@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM 2 SERVER01$@ABC.COM [root@SERVER01 pam.d]#
#############################################################
[root@server01 etc]# more /etc/sssd/sssd.conf
[sssd] domains = abc.com config_file_version = 2 services = nss, pam
[domain/abc.com] ad_domain = abc.com krb5_realm = ABC.COM ad_server = dc01.abc.com,dc02.abc.com,_srv_ realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple debug_level = 8 simple_allow_groups = TDI Remote Access Users@abc.com, TDI Remote Access Users@a.abc.com
########################################################
[root@server01 etc]# more /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d # forwardable = true rdns = false default_realm = ABC.COM # default_ccache_name = KEYRING:persistent:%{uid} # kdc_timesync = 1
[realms] ABC.COM = { kdc = dc01.abc.com kdc = dc02.abc.com admin_server = dc01.abc.com }
[domain_realm] .abc.com = ABC.COM abc.com = ABC.COM
################################################## system-auth
[root@server01 pam.d]# more system-auth-ac #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth optional pam_python.so /usr/lib64/security/auth.py auth sufficient pam_sss.so use_first_pass forward_pass #auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
[
Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 Sonia.Gilbert@HawaiianAir.commailto:Sonia.Gilbert@HawaiianAir.com
[HA Email Signature Logo]
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 mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Gilbert, Sonia -
Sumit Bose