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 1204504 - [RFE] Add access control so hosts can create their own services
Summary: [RFE] Add access control so hosts can create their own services
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks: 1181710
TreeView+ depends on / blocked
 
Reported: 2015-03-22 17:29 UTC by Martin Kosek
Modified: 2015-11-19 12:02 UTC (History)
5 users (show)

Fixed In Version: ipa-4.2.0-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:02:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2362 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2015-11-19 10:40:46 UTC

Description Martin Kosek 2015-03-22 17:29:48 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/4567

Today hosts can write to values in only its managed services but it cannot create those services. This is due to missing aci capabilities, mostly because a host and service are not in a hierarchical parent/child relationship.

This will need to limit the krbprincipalname of the service to match the fqdn of the host entry, ideally also confirming that managedby contains the host fqdn.

One use case for this is certmonger, requesting a certificate for a non-existent service on the host. Certmonger today always includes the --add option to attempt service creation if it does not already exists. It fails today with an error about not being in the serviceadmin role (because a host can't add services by default).

There is an RFE against 389-ds to add a new ACI type to achieve this: https://fedorahosted.org/389/ticket/47904
Comment 1 Tomas Babej 2015-06-29 11:45:56 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/ce50630d5ece036e35d8e11db8383e4e7e9159ae
Comment 4 Scott Poore 2015-09-18 14:23:04 UTC 
How can we verify this?

Should we be able to use "ipa service-add" while using the host principal for a client?

[root@client ~]# kdestroy -A

[root@client ~]# kinit -kt /etc/krb5.keytab 

[root@client ~]# ipa service-add TEST/$(hostname)@TESTRELM.TEST
ipa: ERROR: Host does not have corresponding DNS A/AAAA record

[root@client ~]# dig +short client.testrelm.test
192.168.122.73

[root@client ~]# dig +short master.testrelm.test
192.168.122.71

[root@master httpd]# tail -1 error_log 
[Fri Sep 18 09:12:00.177142 2015] [:error] [pid 2265] ipa: INFO: [jsonserver_session] host/client.testrelm.test: service_add(u'TEST/client.testrelm.test', force=False, all=False, raw=False, version=u'2.156', no_members=False): DNSNotARecordError

[root@client ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: host/client.testrelm.test

Valid starting       Expires              Service principal
09/18/2015 09:11:55  09/19/2015 09:11:55  krbtgt/TESTRELM.TEST
Comment 5 Petr Vobornik 2015-09-18 14:39:12 UTC 
Scott, does it work with --force option? It should force it even if there is not a record in DNS.

Probably issue here is that DNS tree is not readable by everyone so the DNS check fails.
Comment 6 Scott Poore 2015-09-18 14:51:29 UTC 
Yes, I forgot to mention that force works.

[root@client ~]# ipa service-add DNS/$(hostname)@TESTRELM.TEST --force
------------------------------------------------------
Added service "DNS/client.testrelm.test"
------------------------------------------------------
  Principal: DNS/client.testrelm.test
  Managed by: client.testrelm.test


Should the DNS tree have permissions changes to in order to complete this bug or should that be opened as a separate bug?  Doesn't seem like it should fail like that for what should be a read-only type operation?

Thanks,
Scott
Comment 7 Petr Vobornik 2015-09-18 15:04:22 UTC 
Hmm, now I noticed that the check is done by dns.resolver and not by checking DNS records directly in LDAP.
  answers = resolver.query(fqdn, rdatatype.A)

So my previous statement is not really correct.

Does it work for admin on the test machine?
Comment 8 Scott Poore 2015-09-18 15:11:45 UTC 
Wait, nevermind.  I found the problem.  My IPA master had reverted resolv.conf back to before IPA was installed when I booted the VM this morning.  This works:

[root@client ~]# ipa service-add TEST/client.testrelm.test
-------------------------------------------------------
Added service "TEST/client.testrelm.test"
-------------------------------------------------------
  Principal: TEST/client.testrelm.test
  Managed by: client.testrelm.test

[root@client ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: host/client.testrelm.test

Valid starting       Expires              Service principal
09/18/2015 10:08:48  09/19/2015 10:08:43  HTTP/master.testrelm.test
09/18/2015 10:08:43  09/19/2015 10:08:43  krbtgt/TESTRELM.TEST

So, is that enough to verify the bug, or do we need something else as well?
Comment 9 Petr Vobornik 2015-09-18 15:24:27 UTC 
It's enough.
Comment 10 Scott Poore 2015-09-18 15:33:56 UTC 
Verified.

Version ::

ipa-server-4.2.0-11.el7.x86_64

Results ::

[root@client ~]# kdestroy -A

[root@client ~]# kinit -kt /etc/krb5.keytab 

[root@client ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: host/client.testrelm.test

Valid starting       Expires              Service principal
09/18/2015 10:33:03  09/19/2015 10:33:03  krbtgt/TESTRELM.TEST

[root@client ~]# ipa service-add EXAMPLE/$(hostname)
----------------------------------------------------------
Added service "EXAMPLE/client.testrelm.test"
----------------------------------------------------------
  Principal: EXAMPLE/client.testrelm.test
  Managed by: client.testrelm.test
Comment 11 Scott Poore 2015-09-18 15:51:47 UTC 
Adding negative test to verify that cannot add for other host:

[root@client ~]# ipa service-add TEST/master.testrelm.test
ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 'krbprincipalname=TEST/master.testrelm.test,cn=services,cn=accounts,dc=testrelm,dc=test'.
Comment 12 errata-xmlrpc 2015-11-19 12:02:20 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
Note You need to log in before you can comment on or make changes to this bug.