8:31 p.m.
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)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
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)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)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@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(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]
3:53 a.m.
New subject: 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
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)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)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)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@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(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
7:40 p.m.
New subject: account not authenticating in child domain
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)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 '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
######################################################################
###
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
2:47 a.m.
New subject: account not authenticating in child domain
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)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 '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
> >
> > ######################################################################
> > ###
> >
> > 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
2605
days inactive
2613
days old
sssd-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Gilbert, Sonia -
Sumit Bose