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@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@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@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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to