On Tue, Feb 28, 2017 at 02:31:08AM +0000, Gilbert, Sonia wrote: 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. The most probable reason for a 'Preauthentication failed' error is a wrong password. Did you change the password for 'username(a)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

On Wed, Mar 08, 2017 at 01:40:54AM +0000, Gilbert, Sonia wrote: 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)a.abc.com > Mar 6 15:21:26 SERVER01 cw[30366]: pam_sss(conwrks:auth): received for user username(a)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(a)HawaiianAir.com > > > > > -----Original Message----- > From: Sumit Bose [mailto:sbose@redhat.com] > Sent: Monday, February 27, 2017 11:53 PM > To: sssd-users(a)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)a.abc.com Using default cache: /tmp/krb5cc_0 Using principal: > > username(a)a.abc.com [21234] 1488228264.116970: Getting initial > > credentials for username(a)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)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)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 &#39;username(a)a.abc.com&#39; > 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)a.abc.com Feb 27 17:45:34 server01 cw[30366]: > > pam_sss(conwrks:auth): received for user username(a)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)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(a)abc.com, Remote Access > > Users(a)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(a)ABC.COM > > 2 host/server01.abc.com(a)ABC.COM > > 2 host/server01.abc.com(a)ABC.COM > > 2 host/server01.abc.com(a)ABC.COM > > 2 host/server01.abc.com(a)ABC.COM > > 2 host/server01(a)ABC.COM > > 2 host/server01(a)ABC.COM > > 2 host/server01(a)ABC.COM > > 2 host/server01(a)ABC.COM > > 2 host/server01(a)ABC.COM > > 2 SERVER01$(a)ABC.COM > > 2 SERVER01$(a)ABC.COM > > 2 SERVER01$(a)ABC.COM > > 2 SERVER01$(a)ABC.COM > > 2 SERVER01$(a)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(a)abc.com, TDI Remote > > Access Users(a)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.com<mailto:Sonia.Gilbert@HawaiianAir.com> > > > > [HA Email Signature Logo] > > > > > > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org