Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On Wed, 04 Sep 2013, Petr Viktorin wrote: On 08/19/2013 12:29 PM, Petr Viktorin wrote: Hello, The first patch fixes a minor problem that Pylint 1.0 finds in our code. The second patch makes make-lint compatible with Pylint 1.0. It contains a workaround for a Pylint bug; before pushing this we should wait for a while to see if a fixed Pylint is released. A fixed version of Pylint was released, bug workarounds are no longer necessary. Updated patches attached. https://fedorahosted.org/freeipa/ticket/3865 I tried the patches and still see an error on up to date Fedora 19 (including updates-testing): ./make-lint Traceback (most recent call last): File ./make-lint, line 272, in module sys.exit(main()) File ./make-lint, line 243, in main linter.check(files) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 599, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File /usr/lib/python2.7/site-packages/pylint/lint.py, line 685, in check_astroid_module walker.walk(astroid) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk self.walk(child) File /usr/lib/python2.7/site-packages/pylint/utils.py, line 659, in walk cb(astroid) File ./make-lint, line 126, in visit_getattr ignored = self._find_ignored_attrs(owner) File ./make-lint, line 110, in _find_ignored_attrs for klass in self._related_classes(owner): File ./make-lint, line 102, in _related_classes for base in klass.ancestors(): File /usr/lib/python2.7/site-packages/astroid/scoped_nodes.py, line 810, in ancestors for grandpa in baseobj.ancestors(True, context): File /usr/lib/python2.7/site-packages/astroid/scoped_nodes.py, line 801, in ancestors for baseobj in stmt.infer(context): TypeError: unbound method infer() must be called with Tuple instance as first argument (got InferenceContext instance instead) At this point I'm not sure whether it is astroid's issue or ours... Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in Fedora 19 where version updates after release are generally discouraged, especially in case of ABI change). -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa health check (was: certmonger/oddjob for DNSSEC key maintenance)
On 4.9.2013 19:17, Simo Sorce wrote: On Wed, 2013-09-04 at 09:08 -0400, Dmitri Pal wrote: On 09/03/2013 04:01 PM, Simo Sorce wrote: On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: On 09/02/2013 09:42 AM, Petr Spacek wrote: On 27.8.2013 23:08, Dmitri Pal wrote: On 08/27/2013 03:05 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 08/09/2013 08:30 AM, Petr Spacek wrote: Hello, I would like to get opinions about key maintenance for DNSSEC. Problem summary: - FreeIPA will support DNSSEC - DNSSEC deployment requires 2,n cryptographic keys for each DNS zone (i.e. objects in LDAP) - The same keys are shared by all FreeIPA servers - Keys have limited lifetime and have to be re-generated on monthly basics (in very first approximation, it will be configurable and the interval will differ for different key types) - The plan is to store keys in LDAP and let 'something' (i.e. certmonger or oddjob?) to generate and store the new keys back into LDAP - There are command line tools for key-generation (dnssec-keygen from the package bind-utils) - We plan to select one super-master which will handle regular key-regeneration (i.e. do the same as we do for special CA certificates) - Keys stored in LDAP will be encrypted somehow, most probably by some symmetric key shared among all IPA DNS servers Could certmonger or oddjob do key maintenance for us? I can imagine something like this: - watch some attributes in LDAP and wait until some key expires - run dnssec-keygen utility - read resulting keys and encrypt them with given 'master key' - store resulting blobs in LDAP - wait until another key reaches expiration timestamp It is simplified, because there will be multiple keys with different lifetimes, but the idea is the same. All the gory details are in the thread '[Freeipa-devel] DNSSEC support design considerations: key material handling': https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html Nalin and others, what do you think? Is certmonger or oddjob the right place to do something like this? Thank you for your time! Was there any discussion of this mail? I think at least some of this was covered in another thread, DNSSEC support design considerations: key material handling at https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html rob Yes, I have found that thread though I have not found it to come to some conclusion and a firm plan. I will leave to Petr to summarize outstanding issues and repost them. All questions stated in the first e-mail in this thread are still open: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html There was no reply to these questions during my vacation, so I don't have much to add at the moment. Nalin, please, could you provide your opinion? How modular/extendible the certmonger is? Does it make sense to add DNSSEC key-management to certmonger? What about CA rotation problem? Can we share some algorithms (e.g. for super-master election) between CA rotation and DNSSEC key rotation mechanisms? BTW I like the idea of masters being responsible for generating a subset of the keys as Loris suggested. E-mail from Loris in archives: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html The idea seems really nice and simple, but I'm afraid that there could be some serious race conditions. - How will it work when topology changes? - What if number of masters is number of days in month? (= Auto-tune interval from month to smaller time period = Again, what should we do after a topology change?) - What we should do if topology was changed when a master was disconnected from the rest of the network? (I.e. Link over WAN was down at the moment of change.) What will happen after re-connection to the topology? Example: Time 0: Masters A, B; topology: A---B Time 1: Master A have lost connection to master B Time 2: Master C was added; topology: A § B---C Time 3 (Day 3): A + C did rotation at the same time Time 4: Connection was restored; topology: A---B---C Now what? I have a feeling that we need something like quorum protocol for writes (only for sensitive operations like CA cert and DNSSEC key rotations). http://en.wikipedia.org/wiki/Quorum_(distributed_computing) The other question is how should we handle catastrophic situations where more than half of masters were lost? (Two of three data centres were blown by a tornado etc.) It becomes more and more obvious that there is no simple solution that we can use out of box. Let us start with a single nominated server. If the server is lost the key rotation responsibility can be moved to some other server manually. Not optimal but at least the first step. The next step would be to be able to define alternative (failover) servers. Here is an example. Let us say we have masters A, B, C. In topology A - B - C. Master A is responsible for the key rotation B is the fail-over. The key
Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: On Wed, 04 Sep 2013, Petr Viktorin wrote: On 08/19/2013 12:29 PM, Petr Viktorin wrote: Hello, The first patch fixes a minor problem that Pylint 1.0 finds in our code. The second patch makes make-lint compatible with Pylint 1.0. It contains a workaround for a Pylint bug; before pushing this we should wait for a while to see if a fixed Pylint is released. A fixed version of Pylint was released, bug workarounds are no longer necessary. Updated patches attached. https://fedorahosted.org/freeipa/ticket/3865 I tried the patches and still see an error on up to date Fedora 19 (including updates-testing): ./make-lint Traceback (most recent call last): [...] TypeError: unbound method infer() must be called with Tuple instance as first argument (got InferenceContext instance instead) At this point I'm not sure whether it is astroid's issue or ours... Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in Fedora 19 where version updates after release are generally discouraged, especially in case of ABI change). Hello, Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, you have the earlier buggy version. As for Fedora policy, it would probably be best to make that point with the maintainer. https://admin.fedoraproject.org/updates/FEDORA-2013-14942/pylint-1.0.0-2.fc19 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 3.9.2013 18:16, Dmitri Pal wrote: On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI
On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: This patch has a few problems that I'd like some help with. There are a few notes here as well. 1. The handling of the 'key' option is insecure. It should probably be treated like a password (hidden from logs, etc). However, in this case, it is binary, so I'm not quite sure how to do that. Passing it as a command line option may be nice for scripting, but is potentially a security problem if it ends up in bash.history. It would also be nice if the encoding were base32 instead of base64, since nearly all the OTP tools use this encoding. Not only in bash_history; anyone can see command line parameters of running programs. We'll need to modify the framework to support more another password parameter type. The base32 on input/output can be added to that new type. 2. The 'key' option also appears in otp-find. I'd like to suppress this. How? Use the 'no_search' flag (which is currently undocumented; see below). 3. I had to make the 'id' option optional to make the uuid autogeneration work in otp-add. However, this has the side-effect that 'id' is now optional in all the other commands. This is particularly bad in the case of otp-del, where calling this command with no ID transparently removes all tokens. How can I make this optional for otp-add but required for all other commands? You'll need to add a new option flag. 1. Add a 'optional_create' flag to the comment in ipalib.parameters.Param. 2. Handle the flag in ipalib.crud.Create.get_options (clone with attribute=attribute, required=False) See the handling of 'ask_create' for exapmles. Please also document 'no_search' while you're modifying this part of the code. 4. otp-import is not implemented. I spent a few hours looking and I didn't find any otp tool that actually uses this xml format for exporting. Should we implement this now or wait until someone can actually export data to us? 5. otp-del happily deletes the last token for a user. How can I find out the dn of the user executing the command? Also, what is the right exception to throw in pre_callback()? Don't you want to check the token's owner rather than the current user? You could use LastMemberError here, or make your own error. 6. user-show does not list the associated tokens for this user. Do we care? It is a single search: otp-find --owner npmccallum. 7. otp-add only prints the qr code if the --qrcode option is specified. This is for two reasons. First, and most importantly, the qr code doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping garbage on people's screens by default. Second, you may not always want the qr code output (like for a hard token or manual code entry). Would it make sense to add --qrcode to otp-show as well? If otp-add is the only opportunity to get the QR code, it's is easy to miss. 8. If a user is deleted, the user's assigned tokens are left unmodified. That is *not* to say they are orphaned. The owner attribute retains a dn to an invalid user. This also means that otp-find --owner=deletedUser will fail since we can't look up the deleted user. How does dirsrv handle this for other relationships? In the hosts plugin, services are deleted in host_del.pre_callback. You could follow that example. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount
On 09/03/2013 01:02 PM, Ana Krivokapic wrote: On 09/03/2013 12:27 PM, Petr Viktorin wrote: On 09/02/2013 01:31 PM, Ana Krivokapic wrote: On 09/02/2013 12:55 PM, Petr Viktorin wrote: On 08/30/2013 04:10 PM, Ana Krivokapic wrote: Hello, The attached patch addresses ticket https://fedorahosted.org/freeipa/ticket/3740. Hello, Please write a design doc for this RFE. I updated the Minor Enhancements page: http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in this case. Also you'll need to update the ipa-client-install man page. Done. I wonder if `location` is too generic a name for this option. Did you think about `--automount-location`, Good point, I changed `--location` to `--automount-location`. plus maybe `--automount` without argument to just use the default location? It's a bit longer but it would make it immediately clear what the option is about. I think this is a bit of an overkill, as --automount-location=default does precisely that. I would rather not complicate things further by adding more options. Thanks for the review, updated patch is attached. Looks good! One more comment for usability. The man page should explain that --automount-location configures automount by running ipa-client-automount(1). Fixed in updated patch. ACK, pushed to master: 95483d3b9f0973e825cf37340f8ca91b567ab134 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa health check (was: certmonger/oddjob for DNSSEC key maintenance)
On Thu, 2013-09-05 at 09:50 +0200, Petr Spacek wrote: Honestly, as a former sysadmin, I don't think that built-in SMTP client is a very good idea. 1) Each notification mechanism adds big complexity to the implementation: - message queue - fail-over if 'upstream' SMTP server is down - authentication to 'upstream server' - flood/repeated message detection/limitation - ... - and configuration for all this. Some of points above can be solved by existing MTA, but not all of them. 2) Besides implementation, it adds administrative burden during normal system operation: You have to reconfigure all SMTP clients if something was changed in SMTP server configuration. For example: - the organization started to require authentication/SSL for all SMTP connections - mail server's address was changed - backup mail server was added etc. Also, consider the situation where 'replica in trouble' is unable to send a message for some reason (WAN link to/from branch office is down, MTA/machine crashed etc.) This should be handled by some general monitoring system. Another aspect is that admin could want to use another communication channel than e-mail or combination of more channels at once (send e-mail/Jabber message instantly + send SMS if severity = CRITICAL). Yet another problem is that definition of 'severity' depends on organization. You have to have a component which translates message from machine to context organization-defined 'severity'. And then we have dependency problem: If authentication service is down, then you don't need explicit notification that all 20 IMAP servers doesn't work. etc. etc. IMHO, for those reasons we should implement 'a tool for replica health check' with reasonably detailed output and defer problems mentioned above to generic monitoring systems. The monitoring problem is way more complex than it seems after first look. If you takes monitoring seriously, you already have a monitoring system. If you don't, then line 'ipa health-check | mail ad...@example.com' in cron is perfectly enough. Does it make sense? Perfectly! 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] [PATCH 0017] Add OTP support to ipalib CLI
On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: This patch has a few problems that I'd like some help with. There are a few notes here as well. 1. The handling of the 'key' option is insecure. It should probably be treated like a password (hidden from logs, etc). However, in this case, it is binary, so I'm not quite sure how to do that. Passing it as a command line option may be nice for scripting, but is potentially a security problem if it ends up in bash.history. It would also be nice if the encoding were base32 instead of base64, since nearly all the OTP tools use this encoding. Not only in bash_history; anyone can see command line parameters of running programs. We'll need to modify the framework to support more another password parameter type. The base32 on input/output can be added to that new type. To clarify, by scripting I meant calling this from a python script. In this case, the argument wouldn't show up in the argv. Sorry my wording wasn't clear here. The primary case where this will apply is in otp-import (if we implement it). We will parse the XML and call self.api.Command.otp_add() for each token found, including the key. So it would be good to have this option available in python but not the shell. 5. otp-del happily deletes the last token for a user. How can I find out the dn of the user executing the command? Also, what is the right exception to throw in pre_callback()? Don't you want to check the token's owner rather than the current user? You could use LastMemberError here, or make your own error. If the executing user has permissions to remove another user's token, we assume they are an admin and know what they are doing. So this case only arises if the executing user is removing his/her own tokens. For instance: if executor == owner and tokenCount(owner) == 1: raise LastMemberError() 7. otp-add only prints the qr code if the --qrcode option is specified. This is for two reasons. First, and most importantly, the qr code doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping garbage on people's screens by default. Second, you may not always want the qr code output (like for a hard token or manual code entry). Would it make sense to add --qrcode to otp-show as well? If otp-add is the only opportunity to get the QR code, it's is easy to miss. Only admins have permission to read 'key' from LDAP after creation. Standard users can create the OTP token object with a 'key', but cannot read back the key. Hence, the URI is only available at creation (provisioning) time. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run
Hello,
Add timestamps to named debug logs in /var/named/data/named.run.
Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and
timestamps were invaluable.
--
Petr^2 Spacek
From 8d370b97d902d4106253dd9d6eb05f227ef92487 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 5 Sep 2013 15:42:16 +0200
Subject: [PATCH] Add timestamps to named debug logs in
/var/named/data/named.run
---
install/share/bind.named.conf.template | 1 +
1 file changed, 1 insertion(+)
diff --git a/install/share/bind.named.conf.template b/install/share/bind.named.conf.template
index a244957fafaf6ff9903abb8c00c1d361a49ec9f6..5727a1536accd135cb556d76dfccf965bc098e29 100644
--- a/install/share/bind.named.conf.template
+++ b/install/share/bind.named.conf.template
@@ -26,6 +26,7 @@ logging {
channel default_debug {
file data/named.run;
severity dynamic;
+ print-time yes;
};
};
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run
On Thu, 2013-09-05 at 16:25 +0200, Petr Spacek wrote: Hello, Add timestamps to named debug logs in /var/named/data/named.run. Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and timestamps were invaluable. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run
On 09/05/2013 04:25 PM, Petr Spacek wrote: Hello, Add timestamps to named debug logs in /var/named/data/named.run. Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and timestamps were invaluable. ACK -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
Hi!
Attached please find a patch to clean up a mess we have with SID
blacklist handling in ipa-sam. I noticed recently that Windows does not
show IPA trusts as having AES encryption enabled. When investigating why
is that happening, I've found out that there is a set of errors causing
that but most important ones are the following two:
- Wrong handle type was used to modify trust object information, and
- SID blacklist handling in ipa-sam prevented LDAP updates from being
correct which led to rejecting them by the LDAP server.
Attached patch should fix the problem, more details are in the commit
message.
https://fedorahosted.org/freeipa/ticket/3898
--
/ Alexander Bokovoy
From aa63ab5d61d6f19401fa04d673095f14a1b5d0d3 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Thu, 5 Sep 2013 08:13:53 +0300
Subject: [PATCH 1/3] ipa-sam: fix setting encryption type for trust object
already created
When trust is established, last step done by IPA framework is to set
encryption types associated with the trust. This operation fails due
to ipa-sam attempting to modify trust object improperly:
- object classes were changed unconditionally on each update
- ACI entry was missing permission to modify SID blacklists
- SID blacklists were reset on each update of the trust object
using incorrect method which caused LDAP parsing errors at the
server side due to multiple removals of the same value
- trust POSIX offset value was not initialized which caused errors
when fetching the trusted domain object in PDB. We don't use it yet
but should initialize it to some default value (0 for now).
Since the same code is used to create and update trusted domain object in LDAP,
care should be taken to not remove/override those attributes that are set
on the initialization of the trusted domain object but never touched by the
ipa-sam
anymore. SID blacklists are initialized by ipa-sam but used by Kerberos DAL
driver
and managed by IPA framework.
Additionally, wrong handle was used by dcerpc.py code when executing
SetInformationTrustedDomain() against IPA smbd which prevented even to
reach the point where ipa-sam would be asked to modify the trust object.
https://fedorahosted.org/freeipa/ticket/3898
---
daemons/ipa-sam/ipa_sam.c| 82 +++-
install/updates/60-trusts.update | 1 +
ipaserver/dcerpc.py | 9 +
3 files changed, 65 insertions(+), 27 deletions(-)
diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 4a2fca5..a1e00dc 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -2229,11 +2229,14 @@ static NTSTATUS ipasam_set_trusted_domain(struct
pdb_methods *methods,
LDAPMod **mods;
bool res;
char *trusted_dn = NULL;
- int ret, i;
+ int ret, i, count;
NTSTATUS status;
TALLOC_CTX *tmp_ctx;
char *trustpw;
char *sid;
+ char **in_blacklist = NULL;
+ char **out_blacklist = NULL;
+ uint32_t enctypes, trust_offset;
DEBUG(10, (ipasam_set_trusted_domain called for domain %s\n, domain));
@@ -2250,10 +2253,12 @@ static NTSTATUS ipasam_set_trusted_domain(struct
pdb_methods *methods,
}
mods = NULL;
- smbldap_make_mod(priv2ld(ldap_state), entry, mods, objectClass,
-LDAP_OBJ_TRUSTED_DOMAIN);
- smbldap_make_mod(priv2ld(ldap_state), entry, mods, objectClass,
-LDAP_OBJ_ID_OBJECT);
+ if (entry == NULL) {
+ smbldap_make_mod(priv2ld(ldap_state), entry, mods,
objectClass,
+LDAP_OBJ_TRUSTED_DOMAIN);
+ smbldap_make_mod(priv2ld(ldap_state), entry, mods,
objectClass,
+LDAP_OBJ_ID_OBJECT);
+ }
if (entry != NULL) {
sid = get_single_attribute(tmp_ctx, priv2ld(ldap_state), entry,
@@ -2314,26 +2319,37 @@ static NTSTATUS ipasam_set_trusted_domain(struct
pdb_methods *methods,
}
}
+ trust_offset = 0;
if (td-trust_posix_offset != NULL) {
- res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry,
- mods,
-
LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET,
- *td-trust_posix_offset);
- if (!res) {
- status = NT_STATUS_UNSUCCESSFUL;
- goto done;
- }
+ trust_offset = *td-trust_posix_offset;
}
+ res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry,
+ mods,
+ LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET,
+ trust_offset);
+ if (!res) {
+ status = NT_STATUS_UNSUCCESSFUL;
+ goto done;
+ }
+
+
Re: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI
On 09/05/2013 12:29 AM, Nathaniel McCallum wrote: I forgot to mention that this code ignores the design page in one area: radius-show does not list the users attached to this server. How important is this? user-find --radius=MyRADIUSServer should find all the users. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel This is probably OK but then the design needs to be updated. Also I would suggest documenting that to get all users associated with a radius server you need to run the command above. -- 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
[Freeipa-devel] Notes and questions for fine-grained read permissions
Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). An IPA terminology refresher for reference: - ACI: The DS-level permission. - Permission: IPA object that encapsulates one ACI. Example: add user. Permissions aren't as flexible as raw ACIs. - Privilege: IPA object that groups several permissions, e.g. with a manage users privilege you can add user, modify user, ... - Role: IPA object that groups privileges, e.g. an User Administrator can manage users and groups. Roles are assigned to users/groups/hosts. # Permission structure I think it would be best to have two permissions for each object, one for the entries and one for the container. This keeps the ACIs manageable with existing permission API: aci: (target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Groups;allow (read,search,compare) groupdn = ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX;) aci: (target = ldap:///cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Group Container;allow (read,search,compare) groupdn = ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX;) These would be combined in a Group Readers privilege. All the privileges would be granted to a role called Users, which would contain ipausers and admins. # External users system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). # Protected attributes How to handle passwords and other non-public attributes? I'm thinking about keeping a global list of such attributes, and applying it to each read permission ACI on normal operations and upgrades; either generating a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. Possibly that list would be configurable and stored in LDAP. For reference, we currently exclude these in the anonymous read rule: userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming # Compat tree Do we want to reuse the read privileges for the compat tree, or create extra ones? # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On (03/09/13 00:43), Timo Aaltonen wrote: This fixes https://fedorahosted.org/freeipa/ticket/1887 and https://fedorahosted.org/freeipa/ticket/2455 the first three patches fix some bugs in how python is used fourth patch checks if dbus is already running before trying to start it fifth fixes some compilation warnings sixth finally adds the Debian platform module there are also distro patches that aren't upstreamable as-is, that do stuff like - give--install-layout=deb to setup.py - disable make-testcert since it needs a server running - fix hardcoded NFS related paths and a variable in ipa-client-automount - fix ldap.conf path in ipa-client-install - fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like Fedora) - change nss includes in ipa_pwd.c (nss/.. not nss3/..) Solution is simple. Use pkg-config generated NSS_CFLAGS bash$ pkg-config --cflags nss -I/usr/include/nss -I/usr/include/nspr bash$ uname -a Linux positron 3.10-2-686-pae #1 SMP Debian 3.10.5-1 (2013-08-07) i686 GNU/Linux bash$pkg-config --cflags nss -I/usr/include/nss3 -I/usr/include/nspr4 bash$uname -a Linux unused-4-233.brq.redhat.com 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux It works in sssd. I can send a patch. LS dunno what to do about those, the packaging can keep on carrying those but if you have ideas how to make them configurable so that upstream git/tarball could be used for development/testing on Debian then that would be nice. t From b08da1b7712f9621283719b190134586e59fb333 Mon Sep 17 00:00:00 2001 From: Timo Aaltonen tjaal...@ubuntu.com Date: Tue, 3 Sep 2013 00:01:12 +0300 Subject: [PATCH 1/6] Use /usr/bin/python as fallback python path --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a21cf7e33275fd1a783e89baf237c8dcd8db6508..428f19b1a83da8c424893ea35c901f52dafaf546 100644 --- a/Makefile +++ b/Makefile @@ -50,7 +50,7 @@ ifneq ($(DEVELOPER_MODE),0) LINT_OPTIONS=--no-fail endif -PYTHON ?= $(shell rpm -E %__python) +PYTHON ?= $(shell rpm -E %__python || echo /usr/bin/python) all: bootstrap-autogen server tests @for subdir in $(SUBDIRS); do \ -- 1.8.3.2 From 7360486d7ed343202062716c0eb4f731923bb509 Mon Sep 17 00:00:00 2001 From: Timo Aaltonen tjaal...@ubuntu.com Date: Tue, 3 Sep 2013 00:03:12 +0300 Subject: [PATCH 2/6] Don't search platform path Don't use Python.h from the platform specific path --- ipapython/py_default_encoding/setup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipapython/py_default_encoding/setup.py b/ipapython/py_default_encoding/setup.py index de2478c1962aba7a78919efdb266bf0600965905..6a1af628272c6cd3eaa755c5728a7a5d020050ec 100644 --- a/ipapython/py_default_encoding/setup.py +++ b/ipapython/py_default_encoding/setup.py @@ -22,7 +22,7 @@ from distutils.sysconfig import get_python_inc import sys import os -python_header = os.path.join(get_python_inc(plat_specific=1), 'Python.h') +python_header = os.path.join(get_python_inc(plat_specific=0), 'Python.h') if not os.path.exists(python_header): sys.exit(Cannot find Python development packages that provide Python.h) -- 1.8.3.2 From be86f0a9bbc3196aa8808243aba6d7e68c6d083b Mon Sep 17 00:00:00 2001 From: Nick Hatch nicholas.ha...@gmail.com Date: Tue, 3 Sep 2013 00:08:13 +0300 Subject: [PATCH 3/6] Don't exclude symlinks when loading plugins --- ipalib/util.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/util.py b/ipalib/util.py index 3c52e4fd9a3e08d160dd4ae7076590be8b869d2c..e14077487e979f077ddc1f9e925678884a64b5b5 100644 --- a/ipalib/util.py +++ b/ipalib/util.py @@ -81,7 +81,7 @@ def find_modules_in_dir(src_dir): if not name.endswith(suffix): continue pyfile = os.path.join(src_dir, name) -if os.path.islink(pyfile) or not os.path.isfile(pyfile): +if not os.path.isfile(pyfile): continue module = name[:-len(suffix)] if module == '__init__': -- 1.8.3.2 From 34d002d5483b9853a8329215ab12c946b8df7525 Mon Sep 17 00:00:00 2001 From: Nick Hatch nicholas.ha...@gmail.com Date: Tue, 3 Sep 2013 00:10:30 +0300 Subject: [PATCH 4/6] Check dbus before starting it Check to see if the messagebus (dbus) is running before attempting to start it --- ipa-client/ipa-install/ipa-client-install | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 280edd793326150c416fe1b82f9866435e9c6509..7241a3421e348666c47f03a9b4fdac472b2ccabb 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -372,10 +372,11 @@ def uninstall(options, env): # Always start certmonger. We can't untrack something if it isn't # running messagebus = ipaservices.knownservices.messagebus -try: -messagebus.start() -
Re: [Freeipa-devel] FreeIPA server package group
Martin Kosek wrote: On 08/29/2013 12:22 PM, Tomas Babej wrote: On 08/29/2013 11:55 AM, Petr Viktorin wrote: On 08/28/2013 12:20 PM, Tomas Babej wrote: On 08/28/2013 12:03 PM, Petr Viktorin wrote: On 08/28/2013 11:46 AM, Tomas Babej wrote: On 08/26/2013 10:14 AM, Tomas Babej wrote: On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: On 08/26/2013 09:54 AM, Tomas Babej wrote: Hi, I cooked up a patch for comps that adds a FreeIPA package group. Please chime in if you're OK with package selection / description. For illustration, see the attached image. FreeIPA will be added as an add-on in an installer under the Infrastructure server environment, that means, in the included images it will be at the same level as DNS or FTP server. It will also appear in the Software Selection tool (PackageKit). It should also be available under as yum groupinstall FreeIPA server, and in PackageKit, as I understand comps is also source for that too. https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups https://fedorahosted.org/freeipa/ticket/3630 IMO the Audit part in the description is false advertisement. Same issue is in package descriptions. I know, it's taken directly from there. I'd rather have it consistent, if we're going to change it here, we should do there too, so that we do not end up with multiple (seemingly incomplete) descriptions at various places. Anybody else does have any other concerns? We need to move with this effort since string freeze for F20 is coming. I'm particulary dubious about including the freeipa-tests package. I don't think that should be included, developer tests are unnecessary for a server. It was marked as optional in the initial proposal, but I agree it's unnecessary for it to be there at all. We discussed the A (as Audit) part in the description with Rob. The fact is that this is taken from the freeipa-server package description and nobody complained in 7 years. Updated tests attached. Oh, one more thing I remembered just now -- is it too late? We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. I included it there. If anyone else wants to chime in, please do now, I'll create a ticket with rel-eng at the end of the day. Thanks for this effort. What is the status of the bug - did you create the request already? We will need to do one more change and remove freeipa-server-strict package as up on the decision on today's developer meeting we decided to drop this subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous Integration system instead. I missed that meeting so maybe I'm re-hashing things, but I don't see how CI solves the problem that the strict subpackage does. Sure, it won't be as much a surprise to us when other packages are updated, but this doesn't prevent a user from also updating to the package. The strict package prevents upgrade until we've confirmed that things are actually working. CI does not. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ipa health check
On 09/05/2013 08:56 AM, Simo Sorce wrote: On Thu, 2013-09-05 at 09:50 +0200, Petr Spacek wrote: Honestly, as a former sysadmin, I don't think that built-in SMTP client is a very good idea. 1) Each notification mechanism adds big complexity to the implementation: - message queue - fail-over if 'upstream' SMTP server is down - authentication to 'upstream server' - flood/repeated message detection/limitation - ... - and configuration for all this. Some of points above can be solved by existing MTA, but not all of them. 2) Besides implementation, it adds administrative burden during normal system operation: You have to reconfigure all SMTP clients if something was changed in SMTP server configuration. For example: - the organization started to require authentication/SSL for all SMTP connections - mail server's address was changed - backup mail server was added etc. Also, consider the situation where 'replica in trouble' is unable to send a message for some reason (WAN link to/from branch office is down, MTA/machine crashed etc.) This should be handled by some general monitoring system. Another aspect is that admin could want to use another communication channel than e-mail or combination of more channels at once (send e-mail/Jabber message instantly + send SMS if severity = CRITICAL). Yet another problem is that definition of 'severity' depends on organization. You have to have a component which translates message from machine to context organization-defined 'severity'. And then we have dependency problem: If authentication service is down, then you don't need explicit notification that all 20 IMAP servers doesn't work. etc. etc. IMHO, for those reasons we should implement 'a tool for replica health check' with reasonably detailed output and defer problems mentioned above to generic monitoring systems. The monitoring problem is way more complex than it seems after first look. If you takes monitoring seriously, you already have a monitoring system. If you don't, then line 'ipa health-check | mail ad...@example.com' in cron is perfectly enough. Does it make sense? Perfectly! Simo. I agree too. I was not suggesting to replace any kind of deep monitoring rather a spot check for which the command above should be totally fine. -- 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
