[Freeipa-devel] Correct firewall ports for multi-master replicas

2014-07-12 Thread James
Hi freeipa-devel,

I just added automatic firewalling for puppet-ipa. (Disclaimer it's
currently untested...)

What I'm missing is an exact and exhaustive list of exactly which ports
each replica needs open for each other replica. I'm hoping that this
list is symmetrical.

If this list changes based on which $args are used to install FreeIPA,
let me know too.

These will get inserted here (if you're curious):
https://github.com/purpleidea/puppet-ipa/commit/31ede1a185f3d4bd5dd9848613e24a19f460f595#diff-e26063ec0e856ceac05cf5b4132f3330R61

Thanks!

James



signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types

2014-07-12 Thread Lukas Slebodnik
On (01/04/14 10:52), Tomas Babej wrote:

On 04/01/2014 10:40 AM, Alexander Bokovoy wrote:
 On Tue, 01 Apr 2014, Tomas Babej wrote:
 From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001
 From: Tomas Babej tba...@redhat.com
 Date: Wed, 5 Mar 2014 12:28:18 +0100
 Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types

 The ipa-range-check plugin used to determine the range type depending
 on the value of the attributes such as RID or secondary RID base. This
 approached caused variety of issues since the portfolio of ID range
 types expanded.

 The patch makes sure the following rules are implemented:
* No ID range pair can overlap on base ranges, with exception
  of two ipa-ad-trust-posix ranges belonging to the same forest
* For any ID range pair of ranges belonging to the same domain:
* Both ID ranges must be of the same type
* For ranges of ipa-ad-trust type or ipa-local type:
* Primary RID ranges can not overlap
* For ranges of ipa-local type:
* Primary and secondary RID ranges can not overlap
* Secondary RID ranges cannot overlap

 For the implementation part, the plugin was extended with a domain ID
 to forest root domain ID mapping derivation capabilities.

 https://fedorahosted.org/freeipa/ticket/4137

 -static int slapi_entry_to_range_info(struct slapi_entry *entry,
 +struct domain_info {
 +char *domain_id;
 +char *forest_root_id;
 +struct domain_info *next;
 +};
 +
 +static void free_domain_info(struct domain_info *info) {
 +if (info != NULL) {
 +slapi_ch_free_string((info-domain_id));
 +slapi_ch_free_string((info-forest_root_id));
 +free_domain_info(info-next);
 +free(info);
 +}
 +}
 Please, don't use recursion in the freeing part, there is really no
 pressing need to do so. Just use while() like you do in
 get_forest_root_id():

 +/* Searches for the domain_info struct with the specified domain_id
 + * in the linked list. Returns the forest root domain's ID, or NULL for
 + * local ranges. */
 +
 +static char* get_forest_root_id(struct domain_info *head, char*
 domain_id) {
 +
 +/* For local ranges there is no forest root domain,
 + * so consider only ranges with domain_id set */
 +if (domain_id != NULL) {
 +while(head) {
 +if (strcasecmp(head-domain_id, domain_id) == 0) {
 +return head-forest_root_id;
 +}
 +head = head-next;
 +}
 + }
 +
 +return NULL;
 +}
 +



Fixed, updated patch attached.

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 


From f98082d6cfd902417af94d7cd22d3cc85980a782 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 5 Mar 2014 12:28:18 +0100
Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types

The ipa-range-check plugin used to determine the range type depending
on the value of the attributes such as RID or secondary RID base. This
approached caused variety of issues since the portfolio of ID range
types expanded.

The patch makes sure the following rules are implemented:
* No ID range pair can overlap on base ranges, with exception
  of two ipa-ad-trust-posix ranges belonging to the same forest
* For any ID range pair of ranges belonging to the same domain:
* Both ID ranges must be of the same type
* For ranges of ipa-ad-trust type or ipa-local type:
* Primary RID ranges can not overlap
* For ranges of ipa-local type:
* Primary and secondary RID ranges can not overlap
* Secondary RID ranges cannot overlap

For the implementation part, the plugin was extended with a domain ID
to forest root domain ID mapping derivation capabilities.

https://fedorahosted.org/freeipa/ticket/4137
---

//snip

 
-no_overlap = ranges_overlap(new_range, old_range);
+ranges_valid = check_ranges(new_range, old_range);
 free_range_info(old_range);
 old_range = NULL;
-if (no_overlap != 0) {
+if (ranges_valid != 0) {
 ret = LDAP_CONSTRAINT_VIOLATION;
 
-switch (no_overlap){
+switch (ranges_valid){
 case 1:
 errmsg = New base range overlaps with existing base range.;
 break;
@@ -417,6 +627,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int 
modtype)
 case 5:
 errmsg = New secondary rid range overlaps with existing 
 primary rid range.;
 break;
+case 6:
+errmsg = New ID range has invalid type. All ranges in the 
same domain must be of the same type.;
 default:
There is a missing break. Ithink it is a problem, because you do not
want to fall through to the defaul and override errmsg.

Smple patch is attached.

LS
From 2f9060c011e7dd719887d7935a809887e26ac1e5 

Re: [Freeipa-devel] Design Review Keytab Retrieval

2014-07-12 Thread Lukas Slebodnik
On (23/06/14 14:35), Simo Sorce wrote:
- Original Message -
 - Original Message -
   Can you check if ipaProtectedOperation is in the aci attribute in the
   base tree object ?
   It should be there as excluded, and that should cause admin to not be
   able to retrieve keytabs.
  
  It was not. While running ipa-ldap-updater I got the following:
  InvalidSyntax: ACL Syntax Error(-5):(targetattr=
  \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are
  allowed to rekey any entity\22; allow(write) groupdn =
  \22ldap:///cn=admins: Invalid syntax.
 
 Uhmm I do not see anything obviously wrong with ACI instruction, it looks
 just like the one I replace, Ideas ?
 Do you have ipaProtectedOperation in the schema ?
 
 (I rebased patch 3 but will wait to send a patchset until we understand (and
 fix) why this is failing to update.

Ok, apparently it was a quoting issue in the .update files, hopefully that's
the only issue (I am at a conference today and do not have my test env. handy).

The attached patches are rebased on the latest master.

Simo.

From af7364cda7f5ef5948ce782bd5eded0b57583029 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Tue, 17 Sep 2013 00:30:14 -0400
Subject: [PATCH 3/6] keytab: Add new extended operation to get a keytab.

This new extended operation allow to create new keys or retrieve
existing ones. The new set of keys is returned as a ASN.1 structure
similar to the one that is passed in by the 'set keytab' extended
operation.

Access to the operation is regulated through a new special ACI that
allows 'retrieval' only if the user has access to an attribute named
ipaProtectedOperation postfixed by the subtypes 'read_keys' and
'write_keys' to distinguish between creation and retrieval operation.

For example for allowing retrieval by a specific user the following ACI
is set on cn=accounts:

(targetattr=ipaProtectedOperation;read_keys) ...
 ... userattr=ipaAllowedToPerform;read_keys#USERDN)

This ACI matches only if the service object hosts a new attribute named
ipaAllowedToPerform that holds the DN of the user attempting the
operation.

Resolves:
https://fedorahosted.org/freeipa/ticket/3859
---
 .../ipa-pwd-extop/ipa_pwd_extop.c  | 571 +
 install/share/60basev3.ldif|   3 +
 install/share/default-aci.ldif |   7 +
 install/updates/20-aci.update  |  13 +-
 util/ipa_krb5.h|   1 +
 5 files changed, 594 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index 
c0bb9fda26172699e9ae7628f61b763c746188fe..65a5d41f9ea85689952e818fa4e8018c39786db8
 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -1268,6 +1268,571 @@ free_and_return:
   return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
 }
 
+/* Format of getkeytab request
+ *
+ * KeytabGetRequest ::= CHOICE {
+ * newkeys  [0] Newkeys,
+ * curkeys  [1] CurrentKeys,
+ * reply[2] Reply
+ * }
+ *
+ * NewKeys ::= SEQUENCE {
+ * serviceIdentity [0] OCTET STRING,
+ * enctypes[1] SEQUENCE OF Int16
+ * password[2] OCTET STRING OPTIONAL,
+ * }
+ *
+ * CurrentKeys ::= SEQUENCE {
+ * serviceIdentity [0] OCTET STRING,
+ * }
+ */
+
+#define GK_REQUEST_NEWKEYS (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 0)
+#define GK_REQUEST_CURKEYS (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1)
+#define GKREQ_SVCNAME_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1)
+#define GKREQ_ENCTYPES_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1)
+#define GKREQ_PASSWORD_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 2)
+
+static int decode_getkeytab_request(struct berval *extop, bool *wantold,
+char **_svcname, char **_password,
+krb5_key_salt_tuple **kenctypes,
+int *num_kenctypes, char **_err_msg)
+{
+int rc = LDAP_OPERATIONS_ERROR;
+char *err_msg = NULL;
+BerElement *ber = NULL;
+ber_len_t tlen;
+ber_tag_t rtag;
+ber_tag_t ttag;
+ber_tag_t ctag;
+char *svcname = NULL;
+char *password = NULL;
+ber_int_t enctype;
+krb5_key_salt_tuple *enctypes = NULL;
+int num = 0;
+
+ber = ber_init(extop);
+if (ber == NULL) {
+err_msg = KeytabGet Request decode failed.\n;
+rc = LDAP_PROTOCOL_ERROR;
+goto done;
+}
+
+/* check this is a request */
+rtag = ber_peek_tag(ber, tlen);
+if (rtag != GK_REQUEST_NEWKEYS  rtag != GK_REQUEST_CURKEYS) {
+LOG_FATAL(ber_peek_tag failed, wrong request type\n);
+err_msg = Invalid payload.\n;
+rc = LDAP_PROTOCOL_ERROR;
+goto done;
+}
+
+/* ber parse code */
+ttag = ber_scanf(ber, {t[a], ctag, svcname);
+if (ttag 

[Freeipa-devel] [PATCH] Fix warning: Using uninitialized value ld.

2014-07-12 Thread Lukas Slebodnik
ehlo,

If create_getkeytab_control fails variable uninitialized pointer 'ld'
will be used in done section.

Simple patch is attached.
From 6d882d2ede4d639dde2883bb147f3921fc46ae1c Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik lsleb...@redhat.com
Date: Sat, 12 Jul 2014 18:18:21 +0200
Subject: [PATCH 1/4] Fix warning: Using uninitialized value ld.

If create_getkeytab_control fails variable uninitialized pointer 'ld' will be
used.
---
 ipa-client/ipa-getkeytab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipa-client/ipa-getkeytab.c b/ipa-client/ipa-getkeytab.c
index 
d0e975f1a24f15d6b8d109864e5af3548bcba4da..c887cff9bb5e3688cc84b5c28f791eb922f4fe61
 100644
--- a/ipa-client/ipa-getkeytab.c
+++ b/ipa-client/ipa-getkeytab.c
@@ -569,7 +569,7 @@ static int ldap_get_keytab(krb5_context krbctx, bool 
generate, char *password,
 struct krb_key_salt *es = NULL;
 int num_es = 0;
 struct berval *control = NULL;
-LDAP *ld;
+LDAP *ld = NULL;
 LDAPControl **srvctrl = NULL;
 BerElement *ber = NULL;
 ber_tag_t rtag;
-- 
1.9.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel