Re: [Freeipa-devel] [PATCHES] 137-144 LDAP code refactoring (Part 3)
On 28.1.2013 09:34, Jan Cholasta wrote: On 25.1.2013 14:54, Petr Viktorin wrote: On 01/24/2013 03:06 PM, Petr Viktorin wrote: On 01/24/2013 10:43 AM, Petr Viktorin wrote: On 01/22/2013 04:04 PM, Petr Viktorin wrote: On 01/21/2013 06:38 PM, Petr Viktorin wrote: On 01/17/2013 06:27 PM, Petr Viktorin wrote: Hello, This is the first batch of changes aimed to consolidate our LDAP code. Each should be a self-contained change that doesn't break anything. These patches do some general cleanup (some of the changes might seem trivial but help a lot when grepping through the code); merge the common parts LDAPEntry, Entry and Entity classes; and move stuff that depends on an installed server out of IPASimpleLDAPObject and SchemaCache. I'm posting them early so you can see where I'm going, and so you can find out if your work will conflict with mine. Here is a third set of patches. These apply on top of jcholast's patches 94-96. I found mistakes in two of the patches, attaching fixed versions. Since this patchset is becoming unwieldy, I've put it in a public repo that I'll keep updated. The following command will fetch it into your pviktori-ldap-refactor branch: git fetch git://github.com/encukou/freeipa ldap-refactor:pviktori-ldap-refactor I don't think patch 139 is necessary, I fixed this problem in patch 95 by not including 'dn' as attribute in _entry_to_entity. A patch from this patchset (part 3) causes some of the dns plugin tests to fail (idnsallowdynupdate is missing in dnszone_add output). Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 356 Add trusconfig-show and trustconfig-mod commands
Global trust configuration is generated ipa-adtrust-install script
is run. Add convenience commands to show auto-generated options
like SID or GUID or options chosen by user (NetBIOS). Most of these
options are not modifiable via trustconfig-mod command as it would
break current trusts.
Unit test file covering these new commands was added.
https://fedorahosted.org/freeipa/ticket/
From 091e7436201b012a12578dea20175750f3a80956 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Fri, 25 Jan 2013 10:10:17 +0100
Subject: [PATCH] Add trusconfig-show and trustconfig-mod commands
Global trust configuration is generated ipa-adtrust-install script
is run. Add convenience commands to show auto-generated options
like SID or GUID or options chosen by user (NetBIOS). Most of these
options are not modifiable via trustconfig-mod command as it would
break current trusts.
Unit test file covering these new commands was added.
https://fedorahosted.org/freeipa/ticket/
---
ipalib/plugins/trust.py| 172 +
tests/test_xmlrpc/test_trust_plugin.py | 159 ++
tests/test_xmlrpc/xmlrpc_test.py | 10 ++
3 files changed, 341 insertions(+)
create mode 100644 tests/test_xmlrpc/test_trust_plugin.py
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 2019d910b18ea507b9d05f5b6165e7b6d9a43e4e..8bcb0548e294e97283c9407c2b85356a3d118625 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -1,5 +1,6 @@
# Authors:
# Alexander Bokovoy aboko...@redhat.com
+# Martin Kosek mko...@redhat.com
#
# Copyright (C) 2011 Red Hat
# see file 'COPYING' for use and warranty information
@@ -95,6 +96,22 @@ Example:
4. List members of external members of ad_admins_external group to see their SIDs:
ipa group-show ad_admins_external
+
+
+GLOBAL TRUST CONFIGURATION
+
+When IPA AD trust subpackage is installed and ipa-adtrust-install is run,
+a local domain configuration (SID, GUID, NetBIOS name) is generated. These
+identifiers are then used when communicating with a trusted domain of the
+particular type.
+
+1. Show global trust configuration for Active Directory type of trust
+
+ ipa trustconfig-show --type ad
+
+2. Modify global trust configuration and set different primary fallback group
+
+ ipa trustconfig-mod --type ad --fallback-primary-group alternative AD group
)
trust_output_params = (
@@ -482,3 +499,158 @@ api.register(trust_mod)
api.register(trust_del)
api.register(trust_find)
api.register(trust_show)
+
+
+_trust_type_option = (
+StrEnum('trust_type',
+cli_name='type',
+label=_('Trust type (ad for Active Directory, default)'),
+values=(u'ad',),
+default=u'ad',
+autofill=True,
+),
+)
+
+class trustconfig(LDAPObject):
+
+Trusts global configuration object
+
+object_name = _('trust configuration')
+default_attributes = [
+'cn', 'ipantsecurityidentifier', 'ipantflatname', 'ipantdomainguid',
+'ipantfallbackprimarygroup',
+]
+
+label = _('Global Trust Configuration')
+label_singular = _('Global Trust Configuration')
+
+takes_params = (
+Str('cn',
+label=_('Domain'),
+flags=['no_update'],
+),
+Str('ipantsecurityidentifier',
+label=_('Security Identifier'),
+flags=['no_update'],
+),
+Str('ipantflatname',
+label=_('NetBIOS name'),
+flags=['no_update'],
+),
+Str('ipantdomainguid',
+label=_('Domain GUID'),
+flags=['no_update'],
+),
+Str('ipantfallbackprimarygroup',
+cli_name='fallback_primary_group',
+label=_('Fallback primary group'),
+),
+)
+
+def get_dn(self, *keys, **kwargs):
+trust_type = kwargs.get('trust_type')
+if trust_type is None:
+raise errors.RequirementError(name='trust_type')
+if kwargs['trust_type'] == u'ad':
+return DN(('cn', self.api.env.domain),
+self.api.env.container_cifsdomains, self.api.env.basedn)
+raise errors.ValidationError(name='trust_type',
+error=_(unsupported trust type))
+
+def _normalize_groupdn(self, entry_attrs):
+
+Checks that group with given name/DN exists and updates the entry_attrs
+
+if 'ipantfallbackprimarygroup' not in entry_attrs:
+return
+
+group = entry_attrs['ipantfallbackprimarygroup']
+if isinstance(group, (list, tuple)):
+group = group[0]
+
+if group is None:
+return
+
+try:
+dn = DN(group)
+# group is in a form of a DN
+try:
+self.backend.get_entry(dn)
+except errors.NotFound:
+self.api.Object['group'].handle_not_found(group)
+# DN is valid, we can just return
[Freeipa-devel] [RFE] Read and use per-service PAC type
Hi, please find the design page for ticket https://fedorahosted.org/freeipa/ticket/2960 at http://freeipa.org/page/V3/Read_and_use_per_service_pac_type or below. There are some questions in the text. bye, Sumit = Overview = In ticket #2184 a new option --pac_type was introduced to ipa service-mod to individually set the PAC type for each service ticket. The allowed values are: * MS-PAC, the PAC used by Microsoft and specified in * http://msdn.microsoft.com/en-us/library/cc237917.aspx * PAD, Posix Authorization Data, currently work in progress, draft can * be found at http://tools.ietf.org/html/draft-ietf-krb-wg-pad-01 * NONE, do not add any authorization data to the ticket If the attribute is not set the default values specified in the ipakrbauthzdata attribute of the ipaConfig object is used. ''Question: What about modifying ipaKrbAuthzData for host objects? Currently I think it is only possible with --setattr.'' ''Question: Since ipakrbauthzdata is optional in the ipaGuiConfig objectclass, someone might delete it manually, which hardcoded default do we want to use in this case?'' ''Question: Since ipakrbauthzdata is a multi-value attribute how should the case handled where on value is 'NONE'? I assume 'NONE' wins in this case.' = Use Cases = * For services which do not use the authorization data from the PAC the * PAC type can be set to 'NONE'. This will keep the tickets smaller and * avoids unneeded load on the FreeIPA server during the PAC processing. * For services which can only handle Kerberos tickets up to a maximal * size, e.g. NFS, see #3263, the PAC type should be set to 'NONE'. The * authorization data in the PAC can become quite large and can make the * Kerberos ticket grow larger than the service can handle * For services which cannot handle the default PAC type but need a * different one. (This is for future versions since currently only the * MS-PAC is supported) = Design= Since the UI/CLI changes were already handled by #2184 no additional user interaction is needed here. For the needed changes to the IPA KDC backend the changes done to fix #3263 can be used as a starting point. = Implementation = To avoid issues during upgrade I think all changes done to fix #3263 should be preserved, i.e. the NFS service will have a hardcoded default 'NONE'. Otherwise the LDAP objects of the NFS services must be modified during upgrade. In ipadb_sign_authdata() a call like pre ret = get_service_pac_type(server-princ, pac_type); /pre can be added, where get_service_pac_type() runs a LDAP search with a filter like '((objectclass=ipaService)(krbPrincipalName=SERVER_PRINCIPAL))' which looks for the ipakrbauthzdata attribute. = Feature Managment = === UI === UI related changes were added by ticket #2184. ''Question: it looks like the PAC type cannot be explicitly set to 'NONE' in the UI, I guess this needs fixing?'' === CLI === CLI related changes were added by ticket #2184. = Major configuration options and enablement = This feature does not need any options and is enabled by default. The behaviour is controlled by the value of the ipaKrbAuthzData of the service object and the ipaConfig object. = Replication = Changes only affect the KDC IPA backend. If not all server and replicas are updated with this feature KDCs which are not updated might still return Kerberos tickets with the default PAC type although there is a different one mentioned in the service object. = Updates and Upgrades = Any impact on the updates and upgrades? = Dependencies = This feature does not add any new dependencies. = External Impact = The changes will only touch the KDC IPA backend, no external impact is expected. = RFE Author = [[User:Sbose|Sumit Bose]] ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 97 Pylint cleanup
On 01/28/2013 03:25 PM, Jan Cholasta wrote: Hi, this patch fixes https://fedorahosted.org/freeipa/ticket/3379. Honza ACK. Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0145 Add the CA cert to LDAP after the CA install
On 01/25/2013 09:19 AM, Martin Kosek wrote: On 01/24/2013 06:47 PM, Petr Viktorin wrote: This makes a benign CRITICAL message in ipa-server-install go away. https://fedorahosted.org/freeipa/ticket/3375 ACK, works fine. We may wait with a push of this one until a proper triage. Martin Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Read and use per-service PAC type
On Tue, 2013-01-29 at 14:10 +0100, Sumit Bose wrote: = Implementation = To avoid issues during upgrade I think all changes done to fix #3263 should be preserved, i.e. the NFS service will have a hardcoded default 'NONE'. Otherwise the LDAP objects of the NFS services must be modified during upgrade. In ipadb_sign_authdata() a call like pre ret = get_service_pac_type(server-princ, pac_type); /pre can be added, where get_service_pac_type() runs a LDAP search with a filter like '((objectclass=ipaService)(krbPrincipalName=SERVER_PRINCIPAL))' which looks for the ipakrbauthzdata attribute. In ipa-kdb we can keep around data when the principal is retrieved from LDAP. So we should keep around data about the pac_type and then retrieve it through krb5_entry. If we are missing the krb5_entry we should ask MIT to change the interface to pass it in. We should *not* perform additional searches, they are costly. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 146-164 LDAP code refactoring (Part 4)
On 01/28/2013 04:09 PM, Petr Viktorin wrote:
On 01/28/2013 09:34 AM, Jan Cholasta wrote:
On 25.1.2013 14:54, Petr Viktorin wrote:
On 01/24/2013 03:06 PM, Petr Viktorin wrote:
On 01/24/2013 10:43 AM, Petr Viktorin wrote:
On 01/22/2013 04:04 PM, Petr Viktorin wrote:
On 01/21/2013 06:38 PM, Petr Viktorin wrote:
On 01/17/2013 06:27 PM, Petr Viktorin wrote:
Hello,
This is the first batch of changes aimed to consolidate our LDAP
code.
Each should be a self-contained change that doesn't break anything.
These patches do some general cleanup (some of the changes might
seem
trivial but help a lot when grepping through the code); merge the
common
parts LDAPEntry, Entry and Entity classes; and move stuff that
depends
on an installed server out of IPASimpleLDAPObject and SchemaCache.
I'm posting them early so you can see where I'm going, and so you
can
find out if your work will conflict with mine.
Here is a third set of patches. These apply on top of jcholast's
patches
94-96.
I found mistakes in two of the patches, attaching fixed versions.
Since this patchset is becoming unwieldy, I've put it in a public repo
that I'll keep updated. The following command will fetch it into your
pviktori-ldap-refactor branch:
git fetch git://github.com/encukou/freeipa
ldap-refactor:pviktori-ldap-refactor
I don't think patch 139 is necessary, I fixed this problem in patch 95
by not including 'dn' as attribute in _entry_to_entity.
You're right. I'm retiring patch 139.
We'll need to use entry.dn everywhere, and add an assert so that
entry['dn'] is never set.
Here is a fourth set of patches.
Honza noticed test failures caused by patch 143. Patch 123 grew a
conflict with master. Fixes attached.
--
Petr³
From 90b4c802d3bdeeb55f173568244365b401e03610 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 23 Jan 2013 06:38:32 -0500
Subject: [PATCH] Change {add,update,delete}_entry to take LDAPEntries
These methods currently take (dn, entry_attrs, normalize=True)
(or (dn, normalize=True) for delete).
Change them to also accept just an LDAPEntry, and document the
legacy calling style as such.
Part of the work for: https://fedorahosted.org/freeipa/ticket/2660
---
ipaserver/ipaldap.py | 81 +
1 files changed, 54 insertions(+), 27 deletions(-)
diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py
index 27016e92f9435461aedee98ecb82482913d0e435..3353a5dc8e9a27368c6193ca077ec69884cdc613 100644
--- a/ipaserver/ipaldap.py
+++ b/ipaserver/ipaldap.py
@@ -1354,21 +1354,40 @@ class LDAPConnection(object):
self.log.debug(get_members: result=%s, entries)
return entries
-def add_entry(self, dn, entry_attrs, normalize=True):
-Create a new entry.
-
-assert isinstance(dn, DN)
-
-if normalize:
-dn = self.normalize_dn(dn)
-# remove all None or [] values, python-ldap hates'em
-entry_attrs = dict(
-# FIXME, shouldn't these values be an error?
-(k, v) for (k, v) in entry_attrs.iteritems()
-if v is not None and v != []
-)
+def _get_dn_and_attrs(self, entry_or_dn, entry_attrs, normalize):
+Helper for legacy calling style for {add,update}_entry
+
+if entry_attrs is None:
+assert normalize is None
+return entry_or_dn.dn, entry_or_dn
+else:
+assert isinstance(entry_or_dn, DN)
+if normalize is None or normalize:
+entry_or_dn = self.normalize_dn(entry_or_dn)
+entry_attrs = dict(entry_attrs)
+for key, value in entry_attrs.items():
+if value is None:
+entry_attrs[key] = []
+return entry_or_dn, entry_attrs
+
+def add_entry(self, entry, entry_attrs=None, normalize=None):
+Create a new entry.
+
+This should be called as add_entry(entry).
+
+The legacy two/three-argument variant is:
+add_entry(dn, entry_attrs, normalize=True)
+
+dn, attrs = self._get_dn_and_attrs(entry, entry_attrs, normalize)
+
+# remove all [] values (python-ldap hates 'em)
+attrs = dict((k, v) for k, v in attrs.iteritems()
+# FIXME: Once entry values are always lists, this condition can
+# be just if v:
+if v is not None and v != [])
+
try:
-self.conn.add_s(dn, list(entry_attrs.iteritems()))
+self.conn.add_s(dn, list(attrs.iteritems()))
except _ldap.LDAPError, e:
self.handle_errors(e)
@@ -1455,16 +1474,15 @@ class LDAPConnection(object):
return modlist
-def update_entry(self, dn, entry_attrs, normalize=True):
-
-Update entry's attributes.
+def update_entry(self, entry, entry_attrs=None, normalize=None):
+Update entry's attributes.
-An attribute value set to None deletes all current
Re: [Freeipa-devel] [RFE] Read and use per-service PAC type
On Tue, Jan 29, 2013 at 10:13:12AM -0500, Simo Sorce wrote: On Tue, 2013-01-29 at 14:10 +0100, Sumit Bose wrote: = Implementation = To avoid issues during upgrade I think all changes done to fix #3263 should be preserved, i.e. the NFS service will have a hardcoded default 'NONE'. Otherwise the LDAP objects of the NFS services must be modified during upgrade. In ipadb_sign_authdata() a call like pre ret = get_service_pac_type(server-princ, pac_type); /pre can be added, where get_service_pac_type() runs a LDAP search with a filter like '((objectclass=ipaService)(krbPrincipalName=SERVER_PRINCIPAL))' which looks for the ipakrbauthzdata attribute. In ipa-kdb we can keep around data when the principal is retrieved from LDAP. So we should keep around data about the pac_type and then retrieve it through krb5_entry. If we are missing the krb5_entry we should ask MIT to change the interface to pass it in. ipadb_e_data is already used for extra data. I will update the page accordingly. bye, Sumit We should *not* perform additional searches, they are costly. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0104-0106 Provide means of displaying warning and informational messages on clients
On 01/04/2013 07:20 PM, Petr Viktorin wrote:
On 12/14/2012 09:04 AM, Jan Cholasta wrote:
On 13.12.2012 18:09, Petr Viktorin wrote:
On 12/13/2012 04:43 PM, Martin Kosek wrote:
On 12/13/2012 10:59 AM, Petr Viktorin wrote:
It's time to give this to another set of eyes :)
Design document: http://freeipa.org/page/V3/Messages
Ticket: https://fedorahosted.org/freeipa/ticket/2732
More info is in commit messages.
Because of https://fedorahosted.org/freeipa/ticket/3294, I needed to
change the
design document: when the client doesn't send the API version, it is
assumed
it's at a version before capabilities were introduced (i.e. 2.47).
The client still gets a warning if the version is missing. Except for
those
commands where IPA didn't send a version -- ping, cert-show, etc. --
the
warning wouldn't pass validation on old clients. (I'm assuming that
our client
is so far the only one that validates so strictly.)
I did a basic test of this patch and also quickly read through the
patches and
besides nitpicks (like unused inspect module in
tests/test_ipalib/test_messages.py in patch 0105) I did not find any
obvious
errors in the Python code.
Noted, will fix in future versions of the patch.
However, this patch breaks WebUI badly, I did not even get to a log in
screen.
Cooperation with Petr Vobornik will be needed. In my case, I got blank
screen
and Javascript error:
TypeError: IPA.messages.dialogs is undefined
https://vm-037.idm.lab.bos.redhat.com/ipa/ui/ipa.js
Line 1460
I assume this is related to the Internal Error that was returned in
the JSON call
{
error: null,
id: null,
principal: ad...@idm.lab.bos.redhat.com,
result: {
count: 5,
results: [
{
error: an internal error has occurred,
error_code: 903,
error_name: InternalError
},
{
...
This can be reproduced with:
# curl -v -H Content-Type:application/json -H
referer:https://`hostname`/ipa; -H Accept:applicaton/json
--negotiate -u :
--cacert /etc/ipa/ca.crt -d
'{method:i18n_messages,params:[[],{}],id:0}' -X POST
https://`hostname`/ipa/json
Good catch! The i18n_messages plugin already defines a messages
output. When I renamed this from warnings to messages I forgot to
check for clashes.
Since i18n_messages is an internal command only used by the Web UI, we
can rename its output to texts without breaking compatibility.
I'm attaching a preliminary fix (for both backend and UI), but hopefully
it won't be necessary, see below.
I am also not sure I like the requirement of a specific version option
to be
always passed. I would prefer that missing version option would mean
I use the
most recent version of API instead - it would make the custom
JSONRPC/XMLRPC
calls easier to use.
But since the version option was not being sent for some commands, we
may not
have a choice anyway if we do not want to break old clients in case we
add some
capabilities to these commands.
I see three other options, all worse:
- Do not use capabilities for the affected commands, meaning no new
functionality can be added to them (and by extension, no new
functionality common to all commands can be added).
- Treat a missing version as the current version
- Break backwards compatibility
And one possibly better (thanks to Petr¹ and Martin for opening my eyes
off-list!):
- Deprecate XML-RPC. All XML-RPC requests would be pinned to current
version (2.47). Capabilities/messages would only apply to JSON-RPC.
This would also allow us to solve the above name-clashing problem
elegantly. Here is a reminder of what a JSON response looks like:
{
error: null,
id: 0,
principal: ad...@idm.lab.bos.redhat.com,
result: {
summary: IPA server version 3.1.0GIT2e4bd02. API version
2.47
},
version: 3.1.0GIT2e4bd02
}
A XML-RPC response only contains the result part of that.
So with JSON, we can put the messages in the top level, which is much
better design.
Custom info in the top level seems to be a violation of the JSON-RPC
spec. I'd rather not do more of those, so I'm withdrawing this idea.
XML-RPC sucks in other ways too. We already have a workaround for its
inability to attach extra info to errors (commit
88262a75ffe7a25640333dcc4da2100830cae821, Add instructions support to
PublicError).
I've opened a RFC here: https://fedorahosted.org/freeipa/ticket/3299.
+1, XML-RPC sucks. This should have been done a long time ago.
Honza
Here are new patches.
XML-RPC requests with missing version are assumed to be old (the version
before capabilities are introduced, 2.47). This takes care of backcompat
with clients with bug 3294.
JSON-RPC requests with missing version are assumed to be testing calls
(e.g. curl), they get behavior of the latest version but also a warning.
I've also added this info to the design doc.
It turns out that these patches don't depend on whether our client uses
XML-RPC or JSON-RPC. If/when it supports
Re: [Freeipa-devel] [PATCH] 1079 address CA subsystem renewal issues
Petr Viktorin wrote: On 01/15/2013 05:15 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/15/2013 03:41 PM, Petr Viktorin wrote: On 01/14/2013 10:56 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/12/2013 12:49 AM, Rob Crittenden wrote: Rob Crittenden wrote: Petr Viktorin wrote: On 01/07/2013 05:42 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/07/2013 03:09 PM, Rob Crittenden wrote: Petr Viktorin wrote: [...] Works for me, but I have some questions (this is an area I know little about). Can we be 100% sure these certs are always renewed together? Is certmonger the only possible mechanism to update them? You raise a good point. If though some mechanism someone replaces one of these certs it will cause the script to fail. Some notification of this failure will be logged though, and of course, the certs won't be renewed. One could conceivably manually renew one of these certificates. It is probably a very remote possibility but it is non-zero. Can we be sure certmonger always does the updates in parallel? If it managed to update the audit cert before starting on the others, we'd get no CA restart for the others. These all get issued at the same time so should expire at the same time as well (see problem above). The script will hang around for 10 minutes waiting for the renewal to complete, then give up. The certs might take different amounts of time to update, right? Eventually, the expirations could go out of sync enough for it to matter. AFAICS, without proper locking we still get a race condition when the other certs start being renewed some time (much less than 10 min) after the audit one: (time axis goes down) audit cert other cert -- -- certmonger does renew. post-renew script starts . check state of other certs: OK . . certmonger starts renew certutil modifies NSS DB + certmonger modifies NSS DB == boom! This can't happen because we count the # of expected certs and wait until all are in MONITORING before continuing. The problem is that they're also in MONITORING before the whole renewal starts. If the script happens to check just before the state changes from MONITORING to GENERATING_CSR or whatever, we can get corruption. The worse that would happen is the trust wouldn't be set on the audit cert and dogtag wouldn't be restarted. The state the system would be in is this: - audit cert trust not updated, so next restart of CA will fail - CA is not restarted so will not use updated certificates And anyway, why does certmonger do renewals in parallel? It seems that if it did one at a time, always waiting until the post-renew script is done, this patch wouldn't be necessary. From what Nalin told me certmonger has some coarse locking such that renewals in a the same NSS database are serialized. As you point out, it would be nice to extend this locking to the post renewal scripts. We can ask Nalin about it. That would fix the potential corruption issue. It is still much nicer to not have to restart dogtag 4 times. Well, three extra restarts every few years seems like a small price to pay for robustness. It is a bit of a problem though because the certs all renew within seconds so end up fighting over who is restarting dogtag. This can cause some renewals go into a failure state to be retried later. This is fine functionally but makes QE a bit of a pain. You then have to make sure that renewal is basically done, then restart certmonger and check everything again, over and over until all the certs are renewed. This is difficult to automate. So we need to extend the certmonger lock, and wait until Dogtag is back up before exiting the script. That way it'd still take longer than 1 restart, but all the renews should succeed. Right, but older dogtag versions don't have the handy servlet to tell that the service is actually up and responding. So it is difficult to tell from tomcat alone whether the CA is actually up and handling requests. Revised patch that takes advantage of new version of certmonger. certmonger-0.65 adds locking from the time renewal begins to the end of the post_save_command. This lets us be sure that no other certmonger renewals will have the NSS database open in read-write mode. We need to be sure that tomcat is shut down before we let certmonger save the certificate to the NSS database because dogtag opens its database read/write and two writers can cause corruption. rob stop_pkicad and start_pkicad need the Dogtag version check to select pki_cad/pki_tomcatd. Fixed. A more serious issue is that stop_pkicad needs to be installed on upgrades. Currently the whole enable_certificate_renewal step in ipa-upgradeconfig is skipped if it was done before. I added a separate upgrade test for this. It currently won't work in SELinux enforcing mode because certmonger
[Freeipa-devel] krb5.conf on IPA server and SSSD setup
Hi! I've been chasing few bugs in FreeIPA's trusted domains support and found out some grave bugs in both SSSD and FreeIPA. On FreeIPA server side we configure krb5.conf using following settings: - includedir /var/lib/sss/pubconf/krb5.include.d [libdefaults] ... default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true ... [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.com -- Then SSSD generates files which contain domain_realm mapping for trusted domains in /var/lib/sss/pubconf/krb5.include.d and libkrb5 will read them as part of the krb5.conf sourcing. Few problems here: 1. KDC needs to know this mapping information in order to issue referrals to the clients. There is heuristic in libkrb5 that uses domain_realm mapping first and default_realm value if mapping didn't catch the principal which was not found in the database. 2. krb5.conf is parsed by applications usually only on startup. KDC is not an exception, so any changes to krb5.conf would require to restart KDC if we want them to be noticed. 3. Adding new trust implies therefore KDC restart. It also implies that SSSD should have updated the mapping which is not neccessary true time-wise. As result, operations like mapping trusted domain users via external groups in IPA might fail as IPA code running on IPA server needs to contact LDAP service at trusted domain's Global Catalog using SASL GSSAPI authentication. When ticket is obtained, we don't specify explicitly the realm of the service principal, it is constructed by underlying libldap/libsasl code. If explicit domain_realm mapping is in place on client side (and here client is the server as request is issued from IPA httpd code), trusted domain's Global Catalog host will be automatically mapped to trusted domain realm. Otherwise KDC will hint the client with referral to proper KDC for trusted domain realm. This is the step that might fail if trusted domain is sub-domain of IPA domain, for example, ad.example.com. In this case our explicit mapping for example.com will prevail and requests will always be sent for principal in EXAMPLE.COM realm. More to that, since client and KDC are the same host, KDC will use domain_realm mapping as well and hint client with referral to itself (since .example.com = EXAMPLE.COM). Obtaining ticket will fail again. So, I was trying to solve this issue and I've got to following setup with Nalin's help: 1. Define following settings in [libdefaults] of krb5.conf default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true realm_try_domains = 0 realm_try_domains = 0 forces libkrb5 to fallback discovery of realm to domain of the host via DNS if there is no other explicit mapping. 2. Remove any explicit domain_realm mapping for our default realm since it will be implicitly generated from default_realm value by the fallback code anyway. With these changes both KDC and libkrb5 will be able to properly serve out both own domain and trusted domain requests. At some point SSSD will kick in with its explicit mapping for trusted domain realm. Still, KDC will not be able to see this mapping until restart but in Krb5 1.12 we are getting new pluggable interface that will allow to refresh KDC configuration. And here I'm coming to grave error in the SSSD code: the name of explicit mapping file contains non-filtered domain name, which contains dot. krb5.conf manual page states that includedir allows to source all files which names are constructed from alpha-numeric chars, dashes and underscores. Files with other characters are ignored. So dots as in domain_realm_example.com are ignored and our mapping is never sourced. For IDN domains we also will need to transform the name into its Punycode (RFC3492) to avoid breaking out of alpha-numeric space. I'd suggest replacing dots with underscores. File name is irrelevant to libkrb5 after it was read as part of includedir processing, and files are only written by the SSSD. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] krb5.conf on IPA server and SSSD setup
On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote: And here I'm coming to grave error in the SSSD code: the name of explicit mapping file contains non-filtered domain name, which contains dot. krb5.conf manual page states that includedir allows to source all files which names are constructed from alpha-numeric chars, dashes and underscores. Files with other characters are ignored. So dots as in domain_realm_example.com are ignored and our mapping is never sourced. For IDN domains we also will need to transform the name into its Punycode (RFC3492) to avoid breaking out of alpha-numeric space. I'd suggest replacing dots with underscores. Please file a ticket ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] krb5.conf on IPA server and SSSD setup
On Tue, Jan 29, 2013 at 10:03:38PM +0100, Jakub Hrozek wrote: On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote: And here I'm coming to grave error in the SSSD code: the name of explicit mapping file contains non-filtered domain name, which contains dot. krb5.conf manual page states that includedir allows to source all files which names are constructed from alpha-numeric chars, dashes and underscores. Files with other characters are ignored. So dots as in domain_realm_example.com are ignored and our mapping is never sourced. For IDN domains we also will need to transform the name into its Punycode (RFC3492) to avoid breaking out of alpha-numeric space. I'd suggest replacing dots with underscores. Please file a ticket OK, I cloned the F18 bug into: https://fedorahosted.org/sssd/ticket/1795 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] OTP Design
Hello, We started to shape a page for the OTP prototyping work we are doing. It is work in progress but it has enough information to share and discuss. http://freeipa.org/page/V3/OTP Comments welcome! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
