Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1246132

Summary: trust-fetch-domains: Do not chown keytab to the sssd user
Product: Red Hat Enterprise Linux 7 Reporter: Jan Cholasta <jcholast>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: mkosek, rcritten, sumenon
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.2.0-3.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 12:04:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Cholasta 2015-07-23 13:59:52 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/5136

Currently, in the com.redhat.idm.trust-fetch-domains, we chown the retrieved keytab to the sssd user:


{{{
    # Make sure SSSD is able to read the keytab
    sssd = pwd.getpwnam('sssd')
    os.chown(oneway_keytab_name, sssd[2], sssd[3])
}}}

However, if sssd user does not exist, sssd is not running under the sssd user (and therefore cannot access the keytab). We should use root:root in such case.

Comment 3 Sudhir Menon 2015-09-15 12:33:13 UTC
Verified On: RHEL7.2

ipa-server-dns-4.2.0-8.el7.x86_64
ipa-server-4.2.0-8.el7.x86_64
ipa-server-trust-ad-4.2.0-8.el7.x86_64
sssd-1.13.0-25.el7.x86_64


Observations:
1. When 'sssd' service is running as root, ownership of keytab file is root:root and permissions is 600

[root@ipa01 keytabs]# ps -ef | grep sssd
root      9118     1  0 Sep14 ?        00:00:08 /usr/sbin/sssd -D -f
root      9119  9118  0 Sep14 ?        00:00:05 /usr/libexec/sssd/sssd_be --domain labs01.test --uid 0 --gid 0 --debug-to-files
root      9121  9118  0 Sep14 ?        00:00:01 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
root      9122  9118  0 Sep14 ?        00:00:01 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files
root      9123  9118  0 Sep14 ?        00:00:01 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
root      9124  9118  0 Sep14 ?        00:00:01 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files
root      9125  9118  0 Sep14 ?        00:00:01 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files

/var/lib/sss/keytabs
[root@ipa01 keytabs]# ls -l
total 8
-rw-------. 1 root root 177 Sep 14 20:41 test.in.keytab

2. When 'sssd' service is running as 'sssd' user, ownership of keytab file is sssd:sssd and permissions is 600

[root@ipa01 keytabs]# grep sssd /etc/passwd
sssd:x:988:983:User for sssd:/:/sbin/nologin

[root@ipa01 keytabs]# ps -ef | grep sssd
root     24746     1  0 17:10 ?        00:00:00 /usr/sbin/sssd -D -f
sssd     24747 24746  3 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_be --domain labs01.test --uid 988 --gid 983 --debug-to-files
sssd     24749 24746  1 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_nss --uid 988 --gid 983 --debug-to-files
sssd     24750 24746  0 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_sudo --uid 988 --gid 983 --debug-to-files
sssd     24751 24746  0 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_pam --uid 988 --gid 983 --debug-to-files
sssd     24752 24746  0 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_ssh --uid 988 --gid 983 --debug-to-files
sssd     24753 24746  0 17:10 ?        00:00:00 /usr/libexec/sssd/sssd_pac --uid 988 --gid 983 --debug-to-files

total 8
-rw-------. 1 sssd sssd 177 Sep 15 17:10 test.in.keytab

3. trust-fetch-domains work without any issues when sssd service is running as user 'sssd'

[root@ipa01 keytabs]# ipa -vvv trust-fetch-domains 
--------------------------------------------------------------------------------
List of trust domains successfully refreshed. Use trustdomain-find command to list them.
--------------------------------------------------------------------------------
----------------------------
Number of entries returned 0
----------------------------

4. [root@ipa01 keytabs]# ipa trust-show
Realm name: TEST.IN
  Realm name: test.in
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-742749997-2996825573-4184801258
  Trust direction: Trusting forest
  Trust type: Active Directory domain

5. [root@ipa01 keytabs]# ipa trustdomain-find
Realm name: TEST.IN
  Domain name: pune.test.in
  Domain NetBIOS name: PNE02
  Domain Security Identifier: S-1-5-21-971422787-3432055741-3831399297
  Domain enabled: True
  Domain name: test.in
  Domain NetBIOS name: TEST
  Domain Security Identifier: S-1-5-21-742749997-2996825573-4184801258
  Domain enabled: True
----------------------------
Number of entries returned 2
----------------------------

6. AD trust user information is displayed 
[root@ipa01 keytabs]# id user1
uid=1375001118(user1) gid=1375001118(user1) groups=1375001118(user1),1375000513(domain users)

[root@ipa01 keytabs]# wbinfo -n TEST\\user1
S-1-5-21-742749997-2996825573-4184801258-1118 SID_USER (1)

7. Ownership of sssd log files are correct.
[root@ipa01 sssd]# ls -l | grep sssd_nss
-rw-------. 1 sssd sssd  9814824 Sep 15 17:21 sssd_nss.log
[root@ipa01 sssd]# ls -l | grep sssd_pam
-rw-------. 1 sssd sssd  4137528 Sep 15 17:21 sssd_pam.log
[root@ipa01 sssd]# ls -l | grep sssd_ssh
-rw-------. 1 sssd sssd  4204027 Sep 15 17:21 sssd_ssh.log
[root@ipa01 sssd]# ls -l | grep sssd_pac
-rw-------. 1 sssd sssd  4090200 Sep 15 17:21 sssd_pac.log
[root@ipa01 sssd]# ls -l | grep sssd_sudo
-rw-------. 1 sssd sssd  4615010 Sep 15 17:21 sssd_sudo.log

8. AD trust user login works.

Comment 5 errata-xmlrpc 2015-11-19 12:04:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html