On 04/15/2014 05:45 PM, Ludwig Krispenz wrote:

On 04/15/2014 05:10 PM, Martin Kosek wrote:
On 04/15/2014 05:08 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote:
On 04/15/2014 03:16 PM, Simo Sorce wrote:
On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote:
On 04/15/2014 09:43 AM, Martin Kosek wrote:
On 04/15/2014 09:38 AM, Martin Kosek wrote:
On 04/14/2014 07:18 PM, Simo Sorce wrote:
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:

The first patch adds default read permissions to krbtpolicy. Since the plugin manages entries in two trees, there are two permissions. Since two permissions are needed to cover krbtpolicy, it can't be used as a
permission's --type.
The permissions are added to a new privilege, 'Kerberos Ticket Policy

The second patch adds an ACI for reading the Kerberos realm name. Since client enrollment won't work without this, I don't see a reason for
having it managed by a permission.



521 breaks a unit test:

====================================================================== FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in
      func = lambda: self.check(nice, **test)
File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in
self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in
      assert_deepequal(expected, got, nice)
File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal
      assert_deepequal(e_sub, g_sub, doc, stack + (key,))
File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal
      VALUE % (doc, expected, got, stack)
AssertionError: assert_deepequal: expected != got.
test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree
    expected = 1
    got = 2
    path = ('count',)
Thanks for the catch, tests updated.

Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we
miss permissions for users).
Right; I don't think this permission by itself should allow access to
users. Correct me if that's wrong.

I created a users permission for testing:
     ipa permission-add 'allow reading user objectclass' --type user
--right={read,search,compare} --attrs objectclass --bind all

/me hit Send too soon.

Although 522 works functionally and client now discovers the IPA server, there
is no path from SUFFIX to cn=REALM for anonymous users.

I would personally change the ACI to

(targetattr = "cn || objectclass")(targetfilter =
"(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl "Anonymous read access to Kerberos container";allow (read,compare,search)
userdn = "ldap:///anyone";;)'

and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass).
Right, that's necessary for UIs to list the container.
Simo, are you okay with this?
It is no secret that an IPA server has a container named after the
domain. And the REALM name is available unauthenticated from DNS, so
knowledge of it's existence is given.
Therefore I see no problem if anonymous can see the container exists, as long as no contents (beyond what we already determined need to be) are
revealed I see no problem.


Patches work fine. The only problem I see that we now expose group password

# ldapsearch -h `hostname` -x -b
'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn
# MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test

# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
cn: global_policy

# ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
cn: ipausers

It seems suboptimal as we now moved access to group password policy to special permission and we probably do not want to leak a list of defined group policies.

Question is how to prevent it as the group password policies have nsContainer
OC. I see 2 options:

1) Update pwpolicy plugin to avoid using nsContainer for group password policy
(I do not think it is needed, krbPwdPolicy contains cn attribute

2) Update our container allowing ACI to not display it.

Option 1) would be nice, but I am afraid it would break search in older
versions which expects the nsContainer OC to be there.

As for option 2) I am not sure how best to do it. It would be best to exclude both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI syntax
to do it.

(target != "ldap:///some=dn";)(target != "ldap:///other=dn";)
(target != "ldap:///some=dn"; && target != "ldap:///other=dn";)
are not correct. CCing Ludwig to advise.

Alternative is to exclude the the password policies by targetfilter, but I
think excluding whole tree is better.

It's like an LDAP filter but no quite so maybe:
(&(target != "ldap:///some=dn";)(target != "ldap:///other=dn";))  ?


Try again...

[15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax
Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target !=
\22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target !=
\22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass || cn\22)(version 3.0; acl \22Anonymous read access to containers\22; allow(read,
search, compare) userdn = \22ldap:///anyone\22;)

(target!="ldap:///some=dn || ldap:///other=dn";) is accepted, but in a quick test also didn't work as expected. Need to investigate a bit more
looks like we do not handle multiple targets at all. Although in the bind rules logical operations of binddns and bindgroups are handled, so that would be an enhancement :-(

so I think you either have to move to denies for the two subtrees and a general allow for the parent tree, which is not nice or use targetfilter if possible.

Freeipa-devel mailing list

Freeipa-devel mailing list

Reply via email to