Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
On 04/14/2014 07:18 PM, Simo Sorce wrote:
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 359, in
check_output
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',)
Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we
miss permissions for users).
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 301,
in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 319,
in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 359,
in
check_output
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',)
Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we
miss permissions for users).
Martin
/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).
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0523 Fix expected output in permission tests
On 04/14/2014 09:41 PM, Petr Viktorin wrote: It turns out the test failure caused by the realmdomains ACI was not a single occurrence. Another one was caused by Read Group Password Policy. /me sighs. This fixes the tests, ACK. Pushed to master: 3deb76cf17a79a0736aa555f550415e6d9f2ed08 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config
On 04/14/2014 10:00 PM, Petr Viktorin wrote: Read access is given to all authenticated users. This only works when I added cn and objectclass attributes to the ACI. Is this expected? It would work when we add nsContainer ACI for cn=etc though as it has the nsContainer objectlass. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression
OTP Token add failed because of invalid function call. qr_widget doesn't
contain `on_value_changed` method since it inherits from `IPA.widget`
and not from `IPA.input_widget`.
Emitting the event was preserved for future possible usage.
https://fedorahosted.org/freeipa/ticket/4306
--
Petr Vobornik
From d047720e6f00a2579546b7f60716b5846df034c6 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 15 Apr 2014 09:47:21 +0200
Subject: [PATCH] webui: fix OTP Token add regression
OTP Token add failed because of invalid function call. qr_widget doesn't
contain `on_value_changed` method since it inherits from `IPA.widget` and
not from `IPA.input_widget`.
Emitting the event was preserved for future possible usage.
https://fedorahosted.org/freeipa/ticket/4306
---
install/ui/src/freeipa/otptoken.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/otptoken.js b/install/ui/src/freeipa/otptoken.js
index 99dedd94bfd2727d29aae76b9ef9166ef6d3503a..cf14869ce431d1a89e84687d1c88ffb500ddaf97 100644
--- a/install/ui/src/freeipa/otptoken.js
+++ b/install/ui/src/freeipa/otptoken.js
@@ -398,7 +398,7 @@ otptoken.qr_widget = function(spec) {
that.qrcode.makeCode(that.text);
that.uri_control.text(that.text);
that.div_link_control.prop('href', that.text);
-that.on_value_changed();
+that.emit('value-change', { source: that, value: val });
};
/**
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config
On 04/15/2014 09:53 AM, Martin Kosek wrote:
On 04/14/2014 10:00 PM, Petr Viktorin wrote:
Read access is given to all authenticated users.
This only works when I added cn and objectclass attributes to the ACI. Is this
expected?
It would work when we add nsContainer ACI for cn=etc though as it has the
nsContainer objectlass.
You're right, cn and objectclass should be granted explicitly. My mistake.
Fixed patch attached.
--
Petr³
From 94e2401bde270c1671a10e18389e1c5b5a99ff7b Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 14:56:30 +0100
Subject: [PATCH] Add managed read permission to config
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
ipalib/plugins/config.py | 22 ++
1 file changed, 22 insertions(+)
diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py
index 05369be4e93052f18c6cefa03621d651f470749b..4ac411c74c75ab7408c5c876f1efaec8788a5618 100644
--- a/ipalib/plugins/config.py
+++ b/ipalib/plugins/config.py
@@ -94,6 +94,28 @@ class config(LDAPObject):
'ipaselinuxusermapdefault', 'ipaconfigstring', 'ipakrbauthzdata',
'ipauserauthtype'
]
+container_dn = DN(('cn', 'ipaconfig'), ('cn', 'etc'))
+permission_filter_objectclasses = ['ipaguiconfig']
+managed_permissions = {
+'System: Read Global Configuration': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass',
+'ipacertificatesubjectbase', 'ipaconfigstring',
+'ipadefaultemaildomain', 'ipadefaultloginshell',
+'ipadefaultprimarygroup', 'ipagroupobjectclasses',
+'ipagroupsearchfields', 'ipahomesrootdir',
+'ipakrbauthzdata', 'ipamaxusernamelength',
+'ipamigrationenabled', 'ipapwdexpadvnotify',
+'ipaselinuxusermapdefault', 'ipaselinuxusermaporder',
+'ipasearchrecordslimit', 'ipasearchtimelimit',
+'ipauserauthtype', 'ipauserobjectclasses',
+'ipausersearchfields', 'ipacustomfields',
+},
+},
+}
label = _('Configuration')
label_singular = _('Configuration')
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config
On 04/15/2014 10:37 AM, Petr Viktorin wrote: On 04/15/2014 09:53 AM, Martin Kosek wrote: On 04/14/2014 10:00 PM, Petr Viktorin wrote: Read access is given to all authenticated users. This only works when I added cn and objectclass attributes to the ACI. Is this expected? It would work when we add nsContainer ACI for cn=etc though as it has the nsContainer objectlass. You're right, cn and objectclass should be granted explicitly. My mistake. Fixed patch attached. That's better - works fine. ACK. Pushed to master: 75eaf0bddfe0ce3eaea86b42a767c16846379b4b Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [RFC] Migrating existing environments to Trust
Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . I came across several questions which need answers so that more details can be added to the design. Besides that comments and suggestions are welcome as well. For your convenience I added the test below as well. bye, Sumit = Overview = This page illustrates how existing solutions which make AD users available to Linux hosts can be migrated to FreeIPA with Trusts. This includes migrations from the FreeIPA WinSync feature or environments where the AD users where correlated to NIS users. The common problem here is that some if not all attributes needed by a POSIX user or group must be overwritten or supplied by the IPA server. The link to the related AD object is preferably the SID but if it is not available on both sides the name of the object must be used. AD will keep the responsibility for authentication and provide the AD group-memberships of the object. = Use Cases = * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) = Design = In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. # Instead of just offering a single override option the introduction of views are suggested. A suitable client can ask for a specific view with override options different from the default override view.Questions: #* Will the default view always be applied? I think it makes sense to always apply it to get a consistent default behavior. If there is a reason for a client to get the unmodified data a special view called e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin to be able to send the raw data to the IPA client so that SSSD can use different views on the client which might be needed for docker/container use cases. #* Will views only be applied to users from other domains or to IPA users as well? #* Do we want stackable views? #* Do we want to override everything or shall there be immutable attributes like e.g. the SID or the user name? #* Shall we allow different UIDs/GIDs in different views? #* I think overriding UIDs/GIDs should only be allowed for ipa-ad-trust-posix idranges, mixing override with algorithmic mapping does not make sense imo. # The views will be stored in containers below cn=views,cn=accounts,$SUFFIX with containers for users and groups. The objectclasses will look similar to posixAccount and posixGroup objectclasses but with only optional (MAY) attributes. Questions: #* Do we want to consider to allow to add arbitrary attributes to a view to cover requests like We have this beautiful application which can get all user data via the SSSD D-BUS responder but our AD admin will not extend the AD LDAP schema to add the required attributes. Can IPA add them for users from trusted domains? #* It was suggested to use a UUID to reference the original objects. For AD users and groups the SID would be a good choice because it is unique and already contains a reference to the original domain. I wonder if we should add a type prefix like 'SID:' to be able to add other types like 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will be a reference to the other IPA domain. On the other hand a type can be added later and if the type is missing a SID is assumed. On the SSSD side the views can be stored below the corresponding user or group object in the cache and the SYSDB API has to be enhanced to return merged results. The merging only happens in the responders (NSS, D-BUS) before sending data to the clients. To manage the views a new set CLI tools/Web UI pages should be added. Depending if we would like to allow to override IPA users as well or only users from trusted domains the tools might get their own name space, ipa override-*, or can be added below the trust name space, ipa trust-override-*. It has to be noted that changes of a view will only be visible on the client after the related cached object is expired. = Implementation = =Feature Management = == UI == == CLI == = Major configuration options and enablement = Any configuration options? Any commands to enable/disable the feature or turn on/off its parts? = Replication = Any impact on replication? = Updates and Upgrades = Any impact on updates and upgrades? = Dependencies = Any new package and library dependencies. = External Impact =
Re: [Freeipa-devel] [PATCH] 569-583 New Login Screen
On Tue, 15 Apr 2014 09:39:54 +0200 Petr Vobornik pvobo...@redhat.com wrote: On 11.4.2014 14:31, Misnyovszki Adam wrote: On Fri, 28 Mar 2014 14:04:13 +0100 Petr Vobornik pvobo...@redhat.com wrote: Attached patches replace IPA.unauthorized dialog with new Login Screen. To make it happen, a support for standalone facets had to be developed because current framework was limited by facets dependent on entities and a container with menu. This new feature was already used for Load facet which is part of this patchset and also will be a basis for API browser and OTP sync page. Patches should fix these tickets: https://fedorahosted.org/freeipa/ticket/3903 https://fedorahosted.org/freeipa/ticket/4017 Depends on patches #565-#568. [PATCH] webui: facet container -- A widget which servers as container for facets. FacetContainer is a base class. App is specialization. Doing this abstraction will allow us to implement various facet containers. [PATCH] webui: FormMixin a mixin used for fields validation. Basically implements a logic which is already in details facet and dialog. Now this logic can be used in any component. The long term goal is to replace the logic in details facet and dialog with this mixin. [PATCH] webui: ContainerMixin - A mixin which implements widget storing logic. Similar logic is already implemented in details facet and dialog. Long term goal is to replace that with this one. Separating the logic into mixin makes it usable in other components. [PATCH] webui: standalone facet --- `facet.Facet` is a new base class for facets. It doesn't have any dependencies on entities so it's usable for general purpose facets, e.g., future API browser, load facet or login facet. [PATCH] webui: activity widget -- A widget for showing ongoing activity. Displays a text with changing dots. It listens to `network-activity-start` and `network-activity-end` topics. [PATCH] webui: publish network activity topics -- Network activity is now published through global topics. It allows other components like activity_widget to listen to them. [PATCH] webui: load page Load page is a simple facet which is displayed up to 'runtime' phase. On application start it tells the user that there is ongoing activity. [PATCH] webui: validation summary widget A widget which aggregates warnings and errors and shows them on one place. [PATCH] webui: login screen widget -- Reimplementation of unauthorized dialog into separate widget. It uses RCUE design. New features compared to unauthorized dialog: - reflects auth methods from `auth` module - validation summary - differentiates Kerberos auth failure with session expiration - Caps Lock warning - form based method doesn't allow password only submission https://fedorahosted.org/freeipa/ticket/4017 https://fedorahosted.org/freeipa/ticket/3903 [PATCH] webui: login page - A facet with login sreen widget. [PATCH] webui: authentication module General purpose authentication interface and state. See doc of 'freeipa/auth' module. [PATCH] webui: use asynchronous call for authentication Change `IPA.login_password` and `IPA.get_credentials` to use async AJAX and to return promise instead of blocking the code. IPA.get_credentials is still partially blocking because of negotiate process. We can't do anything about that. It allows activity indicators to do their job. [PATCH] webui: fix combobox styles to work with selenium testing [PATCH] webui-ci: adapt to new login screen [PATCH] webui: remove IPA.unauthorized_dialog Hi, - Attached patch fixes weird combobox behaviour - opens automatically on facet load Thank you. I squashed it into patch 581 since it's a fix for unpushed code. - When trying to log in with password only(username field is empty), there is an error message Authentication with Kerberos failed, which is not the desired behaviour. It should sign that the username field is invalid. New, attached version of patch #577 should fix that. It was a typo. - When trying to log in with kerberos credentials, and the realm of the krb ticket is not the same as the realm of freeipa(eg freeipa realm is IPA.TEST.COM, and the ticket's is TEST.COM), firefox goes into an endless cycle calling the kerberos auth url. Currently it seems to me as a browser issue. Anyways, with correct krb ticket, authentication works fine. As investigated with Adam - not a FreeIPA issue.
Re: [Freeipa-devel] [PATCH] 569-583 New Login Screen
On 15.4.2014 12:05, Misnyovszki Adam wrote: On Tue, 15 Apr 2014 09:39:54 +0200 Petr Vobornik pvobo...@redhat.com wrote: On 11.4.2014 14:31, Misnyovszki Adam wrote: On Fri, 28 Mar 2014 14:04:13 +0100 Petr Vobornik pvobo...@redhat.com wrote: Attached patches replace IPA.unauthorized dialog with new Login Screen. To make it happen, a support for standalone facets had to be developed because current framework was limited by facets dependent on entities and a container with menu. This new feature was already used for Load facet which is part of this patchset and also will be a basis for API browser and OTP sync page. Patches should fix these tickets: https://fedorahosted.org/freeipa/ticket/3903 https://fedorahosted.org/freeipa/ticket/4017 Depends on patches #565-#568. [PATCH] webui: facet container -- A widget which servers as container for facets. FacetContainer is a base class. App is specialization. Doing this abstraction will allow us to implement various facet containers. [PATCH] webui: FormMixin a mixin used for fields validation. Basically implements a logic which is already in details facet and dialog. Now this logic can be used in any component. The long term goal is to replace the logic in details facet and dialog with this mixin. [PATCH] webui: ContainerMixin - A mixin which implements widget storing logic. Similar logic is already implemented in details facet and dialog. Long term goal is to replace that with this one. Separating the logic into mixin makes it usable in other components. [PATCH] webui: standalone facet --- `facet.Facet` is a new base class for facets. It doesn't have any dependencies on entities so it's usable for general purpose facets, e.g., future API browser, load facet or login facet. [PATCH] webui: activity widget -- A widget for showing ongoing activity. Displays a text with changing dots. It listens to `network-activity-start` and `network-activity-end` topics. [PATCH] webui: publish network activity topics -- Network activity is now published through global topics. It allows other components like activity_widget to listen to them. [PATCH] webui: load page Load page is a simple facet which is displayed up to 'runtime' phase. On application start it tells the user that there is ongoing activity. [PATCH] webui: validation summary widget A widget which aggregates warnings and errors and shows them on one place. [PATCH] webui: login screen widget -- Reimplementation of unauthorized dialog into separate widget. It uses RCUE design. New features compared to unauthorized dialog: - reflects auth methods from `auth` module - validation summary - differentiates Kerberos auth failure with session expiration - Caps Lock warning - form based method doesn't allow password only submission https://fedorahosted.org/freeipa/ticket/4017 https://fedorahosted.org/freeipa/ticket/3903 [PATCH] webui: login page - A facet with login sreen widget. [PATCH] webui: authentication module General purpose authentication interface and state. See doc of 'freeipa/auth' module. [PATCH] webui: use asynchronous call for authentication Change `IPA.login_password` and `IPA.get_credentials` to use async AJAX and to return promise instead of blocking the code. IPA.get_credentials is still partially blocking because of negotiate process. We can't do anything about that. It allows activity indicators to do their job. [PATCH] webui: fix combobox styles to work with selenium testing [PATCH] webui-ci: adapt to new login screen [PATCH] webui: remove IPA.unauthorized_dialog Hi, - Attached patch fixes weird combobox behaviour - opens automatically on facet load Thank you. I squashed it into patch 581 since it's a fix for unpushed code. - When trying to log in with password only(username field is empty), there is an error message Authentication with Kerberos failed, which is not the desired behaviour. It should sign that the username field is invalid. New, attached version of patch #577 should fix that. It was a typo. - When trying to log in with kerberos credentials, and the realm of the krb ticket is not the same as the realm of freeipa(eg freeipa realm is IPA.TEST.COM, and the ticket's is TEST.COM), firefox goes into an endless cycle calling the kerberos auth url. Currently it seems to me as a browser issue. Anyways, with correct krb ticket, authentication works fine. As investigated with Adam - not a FreeIPA issue. Although, unit tests ran, integration tests ran as expected, and browsing through the code manually was ok for me, so if that validation issue is corrected, than it will be an ACK. Thanks: Adam
Re: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix
On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: Hi, this patch fixes FreeIPA Jenkins CI test freeipa-integration-forced_client_reenrollment-f19, by turning sshfp records into a set, and sorting them before assertion. https://fedorahosted.org/freeipa/ticket/4298 Greets Adam The list.sort() method sorts in-place and returns None, so now the test would not really test anything. Use the sorted() function. You might want to log the value before returning it. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line 359, in
check_output
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?
--
Petr³
From d7dff344118643a891e1e073978a4fd517feba72 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permissions to krbtpolicy
Unlike other objects, the ticket policy is stored in different
subtrees: global policy in cn=kerberos and per-user policy in
cn=users,cn=accounts.
Add two permissions, one for each location.
Also, modify tests so that adding new permissions in cn=users
doesn't cause failures.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
install/updates/40-delegation.update | 7 +
ipalib/plugins/krbtpolicy.py | 38 -
ipatests/test_xmlrpc/test_permission_plugin.py | 39 --
3 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index 27e605789ba152ac61796217ca12a603958931c1..6ab849bf86d129ef93472e970705b117147f0818 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -408,3 +408,10 @@ dn: cn=Password Policy Readers,cn=privileges,cn=pbac,$SUFFIX
default:objectClass: top
default:cn: Password Policy Readers
default:description: Read password policies
+
+dn: cn=Kerberos Ticket Policy Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: Kerberos Ticket Policy Readers
+default:description: Read global and per-user Kerberos ticket policy
diff --git a/ipalib/plugins/krbtpolicy.py b/ipalib/plugins/krbtpolicy.py
index a05583dfb4d3067a1a7f1e097859eac26c3be2ae..4ae676dc5b7ece54c57c9d99afea92ca397b36be 100644
--- a/ipalib/plugins/krbtpolicy.py
+++ b/ipalib/plugins/krbtpolicy.py
@@ -75,8 +75,44 @@ class krbtpolicy(LDAPObject):
object_name = _('kerberos ticket policy settings')
default_attributes = ['krbmaxticketlife', 'krbmaxrenewableage']
limit_object_classes =
[Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember
Read access to both rules and definitions is given to a new privilege,
'Automember Readers', as well as the existing 'Automember Task
Administrator'.
--
Petr³
From d5d9ca67a3ac3219807efddad4670c71d54f5501 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permissions to automember
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
install/updates/40-delegation.update | 7 +++
ipalib/plugins/automember.py | 29 +
2 files changed, 36 insertions(+)
diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index 27e605789ba152ac61796217ca12a603958931c1..d69ade6b347130a40779e1b2159a42761381da8e 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -408,3 +408,10 @@ dn: cn=Password Policy Readers,cn=privileges,cn=pbac,$SUFFIX
default:objectClass: top
default:cn: Password Policy Readers
default:description: Read password policies
+
+dn: cn=Automember Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: Automember Readers
+default:description: Read Automember definitions
diff --git a/ipalib/plugins/automember.py b/ipalib/plugins/automember.py
index 4b3f6f06f80ca8d20245a784ac2ba9a07c17a3e9..dad35d45850e56e90ea5f6a30769badec6941119 100644
--- a/ipalib/plugins/automember.py
+++ b/ipalib/plugins/automember.py
@@ -183,10 +183,39 @@ class automember(LDAPObject):
object_name = 'Automember rule'
object_name_plural = 'Automember rules'
object_class = ['top', 'automemberregexrule']
+permission_filter_objectclasses = ['automemberregexrule']
default_attributes = [
'automemberinclusiveregex', 'automemberexclusiveregex',
'cn', 'automembertargetgroup', 'description', 'automemberdefaultgroup'
]
+managed_permissions = {
+'System: Read Automember Definitions': {
+'non_object': True,
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'ipapermtargetfilter': {'(objectclass=automemberdefinition)'},
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'objectclass', 'cn', 'automemberscope', 'automemberfilter',
+'automembergroupingattr', 'automemberdefaultgroup',
+'automemberdisabled',
+},
+'default_privileges': {'Automember Readers',
+ 'Automember Task Administrator'},
+},
+'System: Read Automember Rules': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'cn', 'objectclass', 'automembertargetgroup', 'description',
+'automemberexclusiveregex', 'automemberinclusiveregex',
+},
+'default_privileges': {'Automember Readers',
+ 'Automember Task Administrator'},
+},
+}
label = _('Auto Membership Rule')
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
359, in
check_output
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.
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression
On Tue, 15 Apr 2014 09:54:22 +0200 Petr Vobornik pvobo...@redhat.com wrote: OTP Token add failed because of invalid function call. qr_widget doesn't contain `on_value_changed` method since it inherits from `IPA.widget` and not from `IPA.input_widget`. Emitting the event was preserved for future possible usage. https://fedorahosted.org/freeipa/ticket/4306 ACK Greets Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
359, in
check_output
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.
Simo.
Patches work fine. The only problem I see that we now expose group password
policies
# 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
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
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.
Both
(target != ldap:///some=dn;)(target !=
[Freeipa-devel] Draft: Read permissions for user
Hello, At Devconf, we decided what most of the default read permissions should look like, but we did not get to user. Here is a draft of 4 read permissions. Please comment. Basic info (anonymous): [top] objectclass [person] cn, sn, description [organizationalPerson] title [inetOrgPerson] uid displayName, givenName, initials manager [inetUser] memberOf [ipaObject] ipaUniqueID [ipaSshUser] ipaSshPubKey [ipaUserAuthTypeClass] ipaUserAuthType [posixAccount] gecos, gidNumber, homeDirectory, loginShell, uidNumber Details (all authenticated): [person] seeAlso, telephoneNumber [organizationalPerson] fax, l, ou, st, postalCode, street destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, postalAddress, postOfficeBox, preferredDeliveryMethod, registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address [inetOrgPerson] carLicense, departmentNumber, employeeNumber, employeeType, preferredLanguage, mail, mobile, pager audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, labeledURI, o, photo, roomNumber, secretary, userCertificate, userPKCS12, userSMIMECertificate, x500UniqueIdentifier [inetUser] inetUserHttpURL, inetUserStatus [ipaUser] userClass Kerberos/login-related (all authenticated): [krbPrincipalAux] krbPrincipalName, krbCanonicalName, krbPrincipalAliases, krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange [+] nsAccountLock Kerberos-related (user admins only): [krbPrincipalAux] krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange No read permission: [person] userPassword [krbPrincipalAux] krbPrincipalKey, krbExtraData, krbPwdHistory krbLastAdminUnlock, krbLoginFailedCount, krbPrincipalType, krbPwdPolicyReference, krbTicketPolicyReference, krbUPEnabled [krbTicketPolicyAux] krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags [mepOriginEntry] mepManagedEntry -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
359, in
check_output
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.
Simo.
Patches work fine. The only problem I see that we now expose group password
policies
# 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
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
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
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py, line
359, in
check_output
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.
Simo.
Patches work fine. The only problem I see that we now expose group password
policies
# 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
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
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
Re: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix
On Tue, 15 Apr 2014 12:51:47 +0200
Petr Viktorin pvikt...@redhat.com wrote:
On 04/15/2014 12:41 PM, Misnyovszki Adam wrote:
Hi,
this patch fixes FreeIPA Jenkins CI test
freeipa-integration-forced_client_reenrollment-f19, by turning sshfp
records into a set, and sorting them before assertion.
https://fedorahosted.org/freeipa/ticket/4298
Greets
Adam
The list.sort() method sorts in-place and returns None, so now the
test would not really test anything. Use the sorted() function.
You might want to log the value before returning it.
My mistake, see the attached, corrected patch.
Thanks
AdamFrom a738f565c9167759af2c47fa7471d20d8b7783a6 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Thu, 10 Apr 2014 18:44:51 +0200
Subject: [PATCH] CI - test_forced_client_reenrollment stability fix
fixes FreeIPA Jenkins CI test freeipa-integration-forced_client_reenrollment-f19
https://fedorahosted.org/freeipa/ticket/4298
---
ipatests/test_integration/test_forced_client_reenrollment.py | 4
1 file changed, 4 insertions(+)
diff --git a/ipatests/test_integration/test_forced_client_reenrollment.py b/ipatests/test_integration/test_forced_client_reenrollment.py
index 4ba4cda1d4fe509110fffa91e1c13d78b457f64d..e3bb2b44d42476735ba52c4737668741f0fd5102 100644
--- a/ipatests/test_integration/test_forced_client_reenrollment.py
+++ b/ipatests/test_integration/test_forced_client_reenrollment.py
@@ -256,6 +256,10 @@ class TestForcedClientReenrollment(IntegrationTest):
sshfp_record = line.replace('SSHFP record:', '').strip()
assert sshfp_record, 'SSHFP record not found'
+
+sshfp_record = sorted(sshfp_record.split(', '))
+self.log.debug(SSHFP record for host %s: %s, client_host, str(sshfp_record))
+
return sshfp_record
def backup_keytab(self):
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Ade Lee wrote: Attached a new patch to address some of the concerns below, specifically I created a new base class DogtagInstance, in which much of the common CA/KRA code is placed. I'm sure we could go further in reducing duplication, and I'm open to further suggestions and refinements. I did not tackle the packaging and spec file dependencies, because I'd like some clearer direction on how we want to proceed here. In any case, I think the splitting of the ipa packages into ca and possibly kra packages should be a separate patch. As before, with this patch you can: - install a ca and drm using ipa-server-install - install a ca and drm replica using ipa-replica-prepare hostname ipa-replica-install --setup-ca --setup-drm replia file You need to use a PKI build from the 10.2 (master) branch). One such build is given below: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo The terms KRA and DRM tend to be used interchangeably. Should we pick one? Need to bump the version number in install/conf/ipa-pki-proxy.conf so that upgrades get the new LocationMatch. ipa-replica-install still uses the if/then to set the value of enable_drm when it can be reduced like you did in ipa-server-install. In ipa-server-install you have an extra comment, probably left for yourself: # code to create drm here In dogtaginstance.py there are a few direct references to DRM in comments and output. cainstance.py doesn't need to override is_installed.py I also don't think you need the explicit definitions for enable, start_instance, etc. Those should be inherited from the DogtagInstance class, in both cainstance.py and drminstance.py. I think spawn_instance should take an option to add things to nolog in case there are server-independent things we don't want to log. I don't want to pile too much on, but it seems to me that if we are going to copy in default.conf then we can do away with realm_info completely and just use default.conf. Both would need to be supported for a while though. Martin, what do you think? I still have quite a bit of functional testing to go. I've only installed a fresh standalone master. Still need to do upgrade and replication testing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for
u'Testperm_RN' using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line
197, in runTest
self.test(*self.arg)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 301, in
lambda
func = lambda: self.check(nice, **test)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 319, in
check
self.check_output(nice, cmd, args, options, expected,
extra_check)
File
/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 359, in
check_output
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.
Simo.
Patches work fine. The only problem I see that we now expose group
password
policies
# 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
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
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
[Freeipa-devel] [PATCH 0236] Fix crash in create_zone()
Hello,
Fix crash in create_zone().
dns_zone_getmgr(zone) call in cleanup section was called even if zone
was NULL.
This patch should go to master, v4 and v3 branches where applicable.
You probably need to use debugger to reproduce this crash. I have encountered
it during work on new DNSSEC code ...
--
Petr^2 Spacek
From 5a929a3543df69eb6ee3029429c6c6e3653d54e7 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 15 Apr 2014 18:44:34 +0200
Subject: [PATCH] Fix crash in create_zone().
dns_zone_getmgr(zone) call in cleanup section was called even if zone
was NULL.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index cf8d45ecc6ef24653be731020703c24c9b4c7214..6c2ead85459eaf531311a15c5817acb4117e7618 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -901,10 +901,11 @@ create_zone(ldap_instance_t *ldap_inst, dns_name_t *name, dns_zone_t **zonep)
return ISC_R_SUCCESS;
cleanup:
- if (dns_zone_getmgr(zone) != NULL)
- dns_zonemgr_releasezone(ldap_inst-zmgr, zone);
- if (zone != NULL)
+ if (zone != NULL) {
+ if (dns_zone_getmgr(zone) != NULL)
+ dns_zonemgr_releasezone(ldap_inst-zmgr, zone);
dns_zone_detach(zone);
+ }
if (task != NULL)
isc_task_detach(task);
--
1.9.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Attached is a patch that adds the script ipa-drm-install.
This script will be used to install a drm in any ipa server that
contains a Dogtag CA. Right now, it works for a master. I will add
logic in a subsequent patch to allow the installation on a replica using
the same script.
This patch is to applied on top of the previous one.
So, patch 2 and then patch 3.
I will create a patch to address the issues mentioned below, as well as
some other formatting issues reported by pycharm.
Thanks,
Ade
On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote:
Ade Lee wrote:
Attached a new patch to address some of the concerns below, specifically
I created a new base class DogtagInstance, in which much of the common
CA/KRA code is placed. I'm sure we could go further in reducing
duplication, and I'm open to further suggestions and refinements.
I did not tackle the packaging and spec file dependencies, because I'd
like some clearer direction on how we want to proceed here. In any
case, I think the splitting of the ipa packages into ca and possibly kra
packages should be a separate patch.
As before, with this patch you can:
- install a ca and drm using ipa-server-install
- install a ca and drm replica using
ipa-replica-prepare hostname
ipa-replica-install --setup-ca --setup-drm replia file
You need to use a PKI build from the 10.2 (master) branch). One such
build is given below:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo
The terms KRA and DRM tend to be used interchangeably. Should we pick one?
Need to bump the version number in install/conf/ipa-pki-proxy.conf so
that upgrades get the new LocationMatch.
ipa-replica-install still uses the if/then to set the value of
enable_drm when it can be reduced like you did in ipa-server-install.
In ipa-server-install you have an extra comment, probably left for
yourself: # code to create drm here
In dogtaginstance.py there are a few direct references to DRM in
comments and output.
cainstance.py doesn't need to override is_installed.py
I also don't think you need the explicit definitions for enable,
start_instance, etc. Those should be inherited from the DogtagInstance
class, in both cainstance.py and drminstance.py.
I think spawn_instance should take an option to add things to nolog in
case there are server-independent things we don't want to log.
I don't want to pile too much on, but it seems to me that if we are
going to copy in default.conf then we can do away with realm_info
completely and just use default.conf. Both would need to be supported
for a while though. Martin, what do you think?
I still have quite a bit of functional testing to go. I've only
installed a fresh standalone master. Still need to do upgrade and
replication testing.
rob
From fa31152ca6ff6bf5d6401b7bcf726a65e3904835 Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Tue, 15 Apr 2014 14:09:32 -0400
Subject: [PATCH] Added ipa-drm-install
ipa-drm-install can be used (with no arguments) to
add a DRM to an existing ipa instance that already contains
a Dogtag CA.
In a subsequent patch, I will add logic to this script to
detect if a drm naming context exists, and if so, to look for
a replica file for installing on a replica.
---
freeipa.spec.in | 2 +
install/po/Makefile.in| 1 +
install/tools/Makefile.am | 1 +
install/tools/ipa-dns-install | 1 +
install/tools/ipa-drm-install | 196 ++
install/tools/ipa-upgradeconfig | 67 +
ipaserver/install/drminstance.py | 4 +
ipaserver/install/dsinstance.py | 77 +++
ipaserver/install/installutils.py | 25 +++--
9 files changed, 297 insertions(+), 77 deletions(-)
create mode 100644 install/tools/ipa-drm-install
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 8ae5e2e083e960c034c738b01d0655575253b6f7..bff9c1acc957dd2d963e15d4c4928f61e37f1d7c 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -143,6 +143,7 @@ Requires: selinux-policy = 3.12.1-135
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.47.7
Requires: pki-ca = 10.1.1
+Requires: pki-kra = 10.1.1
Requires: dogtag-pki-server-theme
%if 0%{?rhel}
Requires: subscription-manager
@@ -622,6 +623,7 @@ fi
%{_sbindir}/ipa-restore
%{_sbindir}/ipa-ca-install
%{_sbindir}/ipa-dns-install
+%{_sbindir}/ipa-drm-install
%{_sbindir}/ipa-server-install
%{_sbindir}/ipa-replica-conncheck
%{_sbindir}/ipa-replica-install
diff --git a/install/po/Makefile.in b/install/po/Makefile.in
index 6dca615c13acf8d40030da0318a1103f4ece1181..c8d7b6353e2b2b00f6e9e6f8cfe3bcc8f84ae73f 100644
--- a/install/po/Makefile.in
+++ b/install/po/Makefile.in
@@ -47,6 +47,7 @@ PY_EXPLICIT_FILES = \
install/tools/ipa-csreplica-manage \
install/tools/ipactl \
install/tools/ipa-dns-install \
+
[Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile
Hello,
The following patches update the Solaris documentation and add a proxy
agent/profile for Solaris.
- Solaris documentation update
https://fedorahosted.org/freeipa/ticket/3731
- Patch adds default Proxy Agent and default_secure profile through
20-nss_ldap.update when ipa-server-install is run.
https://fedorahosted.org/freeipa/ticket/2561
Thanks,
Gabe
From ead26af4688e4ae067448ac8ea4c9d5870e99fd7 Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Tue, 15 Apr 2014 18:41:27 -0600
Subject: [PATCH] [DOC] Update Solaris client documentation
- Re-organized Solaris client sections
- Added examples of DUAProfile(s) with ldapclient
- Updated Sudo section
- Updated NFS options
- Change defunct Blastwave repository to OpenCSW
https://fedorahosted.org/freeipa/ticket/3731
---
src/user_guide/en-US/InstallingClients.xml | 659 -
1 file changed, 359 insertions(+), 300 deletions(-)
diff --git a/src/user_guide/en-US/InstallingClients.xml b/src/user_guide/en-US/InstallingClients.xml
index 1665a6cc5071e652bcb5d8008a23e34eb26db9e8..29762f2fffd489a853504ea0217237d3d88e066b 100644
--- a/src/user_guide/en-US/InstallingClients.xml
+++ b/src/user_guide/en-US/InstallingClients.xml
@@ -906,48 +906,140 @@ ipa-client
section id=Configuring_an_IPA_Client_on_Solaris condition=fedora
titleConfiguring a Solaris System as IPAA; Client/title
- section id=Configuring_an_IPA_Client_on_Solaris_10
- titleConfiguring Solaris 10/title
- orderedlist
-listitem id=st.sol1
+ section id=Configuring_NTP_on_Solaris
+ titleConfiguring NTP/title
+ para
+Configure and enable NTP and synchronize the time between the client and the IPA; server.
+ /para
+ /section
+ section id=Configuring_Solaris_NSS
+ titleConfiguring the Name Service Switch File/title
+ para
+Solaris by default comes with multiple Name Service Switch (NSS) configuration file templates. When the commandldapclient/command is executed, it copies the filename/etc/nsswitch.ldap/filename to the filename/etc/nsswitch.conf/filename file.
+ /para
+ orderedlist
+listitem
para
- IPA; provides an example profile for configuring Solaris 10 as IPAA; client. This can be loaded using commandldapclient/command and the commandinit/command command:
+ On the Solaris client, remove the optionldap/option option from all entries in filename/etc/nsswitch.ldap/filename except for the optionpasswd/option, optiongroup/option, optionshadow/option, optionnetgroup/option, and optionsudoers/option entries.
/para
-programlisting language=Bash[root@solaris ~]# ldapclient init ipa.example.com/programlisting
+/listitem
+listitem
para
- The commandldapclient/command can also be run to enter the information for the IPA; domain manually:
+ Add the optiondns/option option to the optionhosts/option and optionipnodes/option in filename/etc/nsswitch.ldap/filename. For example:
+screenhosts: files dns
+ipnodes:files dns/screen
/para
-
-programlisting language=Bash[root@solaris ~]# ldapclient manual
- -a credentialLevel=proxy
- -a authenticationMethod=tls:simple
- -a defaultSearchBase=dc=example,dc=com
- -a domainName=example.com
- -a defaultServerList=192.168.0.1
- -a proxyDN=cn=proxyagent,ou=profile,dc=example,dc=com
- -a proxyPassword={NS1}fbc123a92116812
- -a attributeMap=group:memberuid=memberUid
- -a attributeMap=group:gidnumber=gidNumber
- -a attributeMap=passwd:gidnumber=gidNumber
- -a attributeMap=passwd:uidnumber=uidNumber
- -a attributeMap=passwd:homedirectory=homeDirectory
- -a attributeMap=passwd:loginshell=loginShell
- -a attributeMap=shadow:userpassword=userPassword
- -a objectClassMap=group:posixGroup=posixgroup
- -a objectClassMap=passwd:posixAccount=posixaccount
- -a objectClassMap=shadow:shadowAccount=posixaccount
- -a serviceSearchDescriptor=passwd:cn=users,cn=accounts,dc=example,dc=com
- -a serviceSearchDescriptor=group:cn=groups,cn=accounts,dc=example,dc=com
- -a serviceSearchDescriptor=netgroup:cn=sysaccounts,cn=etc,dc=example,dc=com
- -a serviceSearchDescriptor=shadow:cn=sysaccounts,cn=etc,dc=example,dc=com
- -a serviceSearchDescriptor=sudoers:cn=sysaccounts,cn=etc,dc=example,dc=com/programlisting
/listitem
+ /orderedlist
+ /section
+ section id=Configuring_Solaris_LDAP_Authentication
+ titleConfiguring LDAP Authentication/title
+ para
+Solaris uses the Directory User Agent Profile (DUAProfile) to configure Solaris as a LDAP client. Using a DUAProfile is easier both for installing and maintaining the Solaris clients as they will re-read the LDAP configuration from the DUA profile periodically.
+ /para
+ para
+IPA; provides a default profile for configuring Solaris as IPAA; client. One to connect to IPA; with an anonymous bind (xref linkend=Connecting_Solaris_to_IPA_with_Anonymous_Bind /), and the other to connect to IPA; securely (xref linkend=Connecting_Solaris_to_IPA_Securely
Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos realm container name
On 04/15/2014 06:10 PM, Ludwig Krispenz wrote:
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:
Hello,
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
Readers'.
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.
LGTM
Simo.
521 breaks a unit test:
==
FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN'
using
--subtree
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 301, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 319, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py,
line 359, in
check_output
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.
Simo.
Patches work fine. The only problem I see that we now expose group password
policies
# 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
cn: MKOSEK-FEDORA20.TEST
# global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test
dn:
cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc
=test
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
