It fails with:
ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry ...
This prevents certmonger certificate requests to function correctly.
Is this related to the new permissions system or something else?
Reproduction details would be helpful, if only for posterity.
It's an ACI error, so I would guess the new permission system is related.
Try this:
# kinit -kt /etc/krb5.keytab # ipa service-mod HTTP/$HOSTNAME --certificate=
Or, since host-mod is called internally in cert-request, this (you need to supply http.csr):
# kinit -kt /etc/krb5.keytab # ipa cert-request http.csr --principal HTTP/$HOSTNAME
Or, since certmonger calls cert-request for requests that use the IPA CA, this:
# certmonger resubmit -d /etc/httpd/alias -n Server-Cert
This worked fine in my tests. Honza, can you try restarting DS and running the commands again?
I suspect this may be similar to the issue I reported in other review: http://www.redhat.com/archives/freeipa-devel/2014-June/msg00113.html
CCing Ludwig.
Could you provide the deployed acis and aci logging - or access to a system showing the problems - or steps to reproduce, not only the failing update, but the steps to get into this situation. Martin, same question for the similar problem you reported.
If the problem goes away after restart it could be related to https://fedorahosted.org/389/ticket/47806
Replying to [comment:4 mkosek]:
It did not help.
Replying to [comment:5 lkrispen]:
Could you provide the deployed acis and aci logging - or access to a system showing the problems - or steps to reproduce, not only the failing update, but the steps to get into this situation.
Steps to reproduce are above, run any of them on a clean IPA install. I can provide you access to a system where this happens if you need it.
I did install freeipa 3.3.5-1.fc20 and 389 1.3.2.16-1.fc20
then did ipa-server-install and run the steps, but don't see any failure
[root@vm-111 ~]# kinit -kt /etc/krb5.keytab [root@vm-111 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_O6ZkLoX Default principal: host/vm-111.idm.lab.eng.brq.redhat.com@IDM.LAB.ENG.BRQ.REDHAT.COM
Valid starting Expires Service principal 06/10/2014 10:58:31 06/11/2014 10:58:31 krbtgt/IDM.LAB.ENG.BRQ.REDHAT.COM@IDM.LAB.ENG.BRQ.REDHAT.COM [root@vm-111 ~]# ipa service-mod HTTP/$HOSTNAME --certificate=
Principal: HTTP/vm-111.idm.lab.eng.brq.redhat.com@IDM.LAB.ENG.BRQ.REDHAT.COM Managed by: vm-111.idm.lab.eng.brq.redhat.com
I tried on vm-129, cannot reproduce: ipa service-mod HTTP/$HOSTNAME --certificate=
Principal: HTTP/vm-129.idm.lab.bos.redhat.com@IDM.LAB.BOS.REDHAT.COM Managed by: vm-129.idm.lab.bos.redhat.com
[09/Jun/2014:21:32:30 -0400] conn=30 op=5 MOD dn="krbprincipalname=HTTP/vm-129.idm.lab.bos.redhat.com@IDM.LAB.BOS.REDHAT.COM,cn=services,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" [09/Jun/2014:21:32:30 -0400] conn=30 op=5 RESULT err=0 tag=103 nentries=0 etime=0
[09/Jun/2014:21:32:30 -0400] NSACLPlugin - conn=30 op=5 (main): Allow write on entry(krbprincipalname=http/vm-129.idm.lab.bos.redhat.com@idm.lab.bos.redhat.com,cn=services,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com).attr(userCertificate) to fqdn=vm-129.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com: allowed by aci(105): aciname= "Hosts can manage service Certificates and kerberos keys", acidn="cn=services,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com"
If this reproduces again, please help Ludwig. It is also possible that the issue is fixed by an ACI fix Ludwig told me about once that did not get yet to F20 389-ds-base.
This scenario works fine with 389-ds-base-1.3.2.20-1. Please re-open if this issue strikes again.
Metadata Update from @jcholast: - Issue assigned to someone - Issue set to the milestone: FreeIPA 4.0.1
Login to comment on this ticket.