Hello folks,

I created a replica IPA host with version 4.1.0-18.el7.centos.4,
while the initial master is a FreeIPA 3.3.3.

Everything seems to work fine with the new host except for one thing:
We have a special IPA user, which has the rights for managing and enrolling 
I am able to add hosts with this user, but ipa-getkeytab command returns the 
following message:

root@ipa01:~ > ipa-getkeytab -q -s ipa01.internal -p "host/testhost.internal" 
-k testhost.internal.keytab
Failed to parse result: Insufficient access rights

The keytab was successfully created, though. dirsrv error logs showed me this 
after raising log level:

[10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=590 op=3 
[10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny write on 
 to uid=mw-integrator,cn=users,cn=accounts,dc=internal: no aci matched the subject by aci(53): 
aciname= "Entities are allowed to rekey managed entries", 
[10/Nov/2015:10:40:36 +0100] is_allowed_to_access_attr - [file ipa_pwd_extop.c, 
line 756]: slapi_access_allowed does not allow WRITE to 
[10/Nov/2015:10:40:36 +0100] ipapwd_getkeytab - [file ipa_pwd_extop.c, line 
1630]: Not allowed to set keytab on [host/testhost.internal@INTERNAL]!
[10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3 
[10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=591 op=3 (main): Allow write on 
entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(krbPrincipalKey) to 
uid=mw-integrator,cn=users,cn=accounts,dc=internal: allowed by aci(277): aciname= 
"permission:System: Manage Host Keytab", 

So it seems he can't find a proper write permission for 
When creating a permission with write access to this attribute everything works 
fine, but should'nt there
already be a proper permission? I discovered the following permission:

root@ipa01:~ > ipa permission-show --all --raw 'System: Manage Host Keytab 
  dn: cn=System: Manage Host Keytab 
  cn: System: Manage Host Keytab Permissions
  ipapermright: write
  ipapermright: read
  ipapermright: compare
  ipapermright: search
  ipapermincludedattr: createtimestamp
  ipapermincludedattr: modifytimestamp
  ipapermincludedattr: entryusn
  ipapermdefaultattr: objectclass
  ipapermdefaultattr: ipaallowedtoperform;write_keys
  ipapermdefaultattr: ipaallowedtoperform;read_keys
  ipapermbindruletype: permission
  ipapermlocation: cn=computers,cn=accounts,dc=internal
  ipapermtargetfilter: (objectclass=ipahost)
  member: cn=Host Administrators,cn=privileges,cn=pbac,dc=internal
  aci: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform;read_keys || 
ipaallowedtoperform;write_keys || modifytimestamp || objectclass")(targetfilter = 
"(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow 
(compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab 
  ipapermissiontype: V2
  ipapermissiontype: MANAGED
  ipapermissiontype: SYSTEM
  memberindirect: uid=mw-integrator,cn=users,cn=accounts,dc=internal
  memberindirect: cn=IT Specialist,cn=roles,cn=accounts,dc=internal
  memberindirect: cn=MW Host Enroller,cn=roles,cn=accounts,dc=internal
  objectclass: ipapermission
  objectclass: top
  objectclass: groupofnames
  objectclass: ipapermissionv2

So there is a aci with write access on ipaallowedtoperform;write_keys,
but not on ipaProtectedOperation;write_keys.

So the question is: Has something gone wrong while migrating the aci's to 
freeipa v4 style?
If yes, how can I fix it?

Dominik Korittki

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to