[Freeipa-users] ipa-getkeytab missing permissions after migration

Thu Nov 12 19:35:40 UTC 2015

On 11/12/2015 03:58 PM, Simo Sorce wrote:
> On 11/11/15 15:22, Martin Kosek wrote:
>> On 11/10/2015 02:59 PM, Dominik Korittki wrote:
>>>
>>> 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 hosts.
>>> I am able to add hosts with this user, but ipa-getkeytab command
>>> returns the
>>> following message:
>>>
>>> root at 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
>>> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal"
>>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - conn=590 op=3 (main): Deny
>>> write on
>>> entry(fqdn=testhost.internal,cn=computers,cn=accounts,dc=internal).attr(ipaProtectedOperation;write_keys)
>>>
>>>
>>> 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",
>>> acidn="cn=accounts,dc=internal"
>>> [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
>>> ipaProtectedOperation;write_keys!
>>> [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 at INTERNAL]!
>>> [10/Nov/2015:10:40:36 +0100] NSACLPlugin - #### conn=591 op=3
>>> binddn="uid=mw-integrator,cn=users,cn=accounts,dc=internal"
>>> [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",
>>> acidn="cn=computers,cn=accounts,dc=internal"
>>>
>>>
>>> So it seems he can't find a proper write permission for
>>> ipaProtectedOperation;write_keys.
>>> 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 at ipa01:~ > ipa permission-show --all --raw 'System: Manage Host
>>> Keytab
>>> Permissions'
>>>    dn: cn=System: Manage Host Keytab
>>> Permissions,cn=permissions,cn=pbac,dc=internal
>>>    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 Permissions,cn=permissions,cn=pbac,dc=internal";)
>>>    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?
>>
>>
>> JFTR, the design for this new attribute is here:
>> http://www.freeipa.org/page/V4/Keytab_Retrieval
>>
>> Looking at the ACIs for ipaProtectedOperation, I see following:
>>
>> dn: cn=accounts,$SUFFIX
>> add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl
>> "Users allowed to retrieve keytab keys"; allow(read)
>> userattr="ipaAllowedToPerform;read_keys#USERDN";)
>> add:aci: (targetattr="ipaProtectedOperation;read_keys")(version 3.0; acl
>> "Groups allowed to retrieve keytab keys"; allow(read)
>> userattr="ipaAllowedToPerform;read_keys#GROUPDN";)
>> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Users allowed to create keytab keys"; allow(write)
>> userattr="ipaAllowedToPerform;write_keys#USERDN";)
>> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Groups allowed to create keytab keys"; allow(write)
>> userattr="ipaAllowedToPerform;write_keys#GROUPDN";)
>> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Entities are allowed to rekey themselves"; allow(write)
>> userdn="ldap:///self";)
>> add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Admins are allowed to rekey any entity"; allow(write) groupdn =
>> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
>> add:aci:
>> (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version
>>
>> 3.0; acl "Entities are allowed to rekey managed entries"; allow(write)
>> userattr="managedby#USERDN";)
>>
>> That means that hosts and services can write their own keys, or
>> principals in ipaAllowedToPerform;operation can do the operation, or
>> hosts/services in managedBy attribute can do write.
>>
>> For general keytab write access, we have the old style permission/ACI
>> "System: Manage Host Keytab". I tested it and it works:
>>
>> # ipa permission-show "System: Manage Host Keytab"
>>    Permission name: System: Manage Host Keytab
>>    Granted rights: write
>>    Effective attributes: krblastpwdchange, krbprincipalkey
>>    Default attributes: krbprincipalkey, krblastpwdchange
>>    Bind rule type: permission
>>    Subtree: cn=computers,cn=accounts,dc=rhel72
>>    Type: host
>>    Granted to Privilege: Host Enrollment, Host Administrators, fbar
>>    Indirect Member of roles: fbar, IT Specialist
>>
>> # ipa user-show fbar --all --raw
>>    dn: uid=fbar,cn=users,cn=accounts,dc=rhel72
>> ...
>>    memberof: cn=fbar,cn=roles,cn=accounts,dc=rhel72
>>    memberof: cn=ipausers,cn=groups,cn=accounts,dc=rhel72
>>    memberofindirect: cn=fbar,cn=privileges,cn=pbac,dc=rhel72
>>    memberofindirect: cn=System: Manage Host
>> Keytab,cn=permissions,cn=pbac,dc=rhel72
>> ...
>> # kinit fbar
>> # ipa-getkeytab -s `hostname` -k /tmp/fbar.keytab -p host/fbar.example.com
>> Failed to parse result: Insufficient access rights
>>
>> Retrying with pre-4.0 keytab retrieval method...
>> Keytab successfully retrieved and stored in: /tmp/fbar.keytab
>>
>> The keytab was created, but I wonder if this is expected and the
>> I wonder if this is expected and "System: Manage Host Keytab: should not
>> rather operate with ipaProtectedOperation. CCing Simo.
>
> It is not really expected, the fallback was made to allow a client to work
> against an older server not to work "around" permission issues.
>
> The idea is to actually change the default permissions soon(*) so that the
> *old* interface stops working by default and the admin has to enable it
> intentionally in cn=etc config option if they still have older clients around
> that need it.
>
> Simo.
>
> (*) I think we had a ticket, I would like it scheduled for 4.4 (I can implement
> it)

The closest ticket I found is:
https://fedorahosted.org/freeipa/ticket/232

I updated it with the results of this discussion. The patch would be very welcome!

Thank you,
Martin