Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-30 Thread Simo Sorce 
On Fri, 2012-07-27 at 18:54 -0400, Simo Sorce wrote:
 On Fri, 2012-07-27 at 07:15 +0300, Alexander Bokovoy wrote:
  On Thu, 12 Jul 2012, Alexander Bokovoy wrote:
  On Thu, 12 Jul 2012, Simo Sorce wrote:
  On Thu, 2012-07-12 at 10:48 +0300, Alexander Bokovoy wrote:
  On Wed, 11 Jul 2012, Simo Sorce wrote:
  From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
  From: Simo Sorce sso...@redhat.com
  Date: Fri, 6 Jul 2012 16:18:29 -0400
  Subject: [PATCH] Add special modify op to regen ipaNTHash
  
  The NT Hash is the same thing as the RC4-HMAC key, so we add a function 
  to
  extract it from krb5 keys if they are available to avoid forcing a 
  password
  change when configuring trust relationships.
  ---
   .../ipa-pwd-extop/ipapwd_prepost.c |  147 
   +++-
   1 file changed, 144 insertions(+), 3 deletions(-)
  
  diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
  b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
  index 
  deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d
   100644
  --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
  +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
  @@ -41,7 +41,12 @@
   #  include config.h
   #endif
  
  -#define _XOPEN_SOURCE /* strptime needs this */
  +/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
  + * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
  +#ifndef _GNU_SOURCE
  +#define _GNU_SOURCE 1
  +#endif
  +
   #include stdio.h
   #include string.h
   #include strings.h
  @@ -53,6 +58,7 @@
   #include dirsrv/slapi-plugin.h
   #include lber.h
   #include time.h
  +#include endian.h
  
   #include ipapwd.h
   #include util.h
  @@ -379,6 +385,12 @@ done:
   return 0;
   }
  
  +#define NTHASH_REGEN_VAL MagicRegen
  +#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
  +static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
  +   char *dn, struct slapi_entry *entry,
  +   struct ipapwd_krbcfg *krbcfg);
  +
   /* PRE MOD Operation:
* Gets the clean text password (fail the operation if the password 
   came
* pre-hashed, unless this is a replicated operation).
  @@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
   int has_krb_keys = 0;
   int has_history = 0;
   int gen_krb_keys = 0;
  +int is_magic_regen = 0;
   int ret, rc;
  
   LOG_TRACE( =\n);
  @@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
   default:
   break;
   }
  +} else if (slapi_attr_types_equivalent(lmod-mod_type, 
  ipaNTHash)) {
  +/* check op filtering out LDAP_MOD_BVALUES */
  +switch (lmod-mod_op  0x0f) {
  +case LDAP_MOD_REPLACE:
  This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.
  
  This is because I resent the old patch :(
  
  Hopefully the correct patch is now attached.
  Yes, now it is updated, thanks.
  
  I'm going to experiment a bit with these patches, adding ipasam
  responder to test them.
  Here is ipasam part.
 
 ACK the ipasam part.

Pushed all 4 patches to master.

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][RFC] Implement special operation to revoer NT hash for a user

2012-07-27 Thread Simo Sorce 
On Fri, 2012-07-27 at 07:15 +0300, Alexander Bokovoy wrote:
 On Thu, 12 Jul 2012, Alexander Bokovoy wrote:
 On Thu, 12 Jul 2012, Simo Sorce wrote:
 On Thu, 2012-07-12 at 10:48 +0300, Alexander Bokovoy wrote:
 On Wed, 11 Jul 2012, Simo Sorce wrote:
 From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
 From: Simo Sorce sso...@redhat.com
 Date: Fri, 6 Jul 2012 16:18:29 -0400
 Subject: [PATCH] Add special modify op to regen ipaNTHash
 
 The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
 extract it from krb5 keys if they are available to avoid forcing a 
 password
 change when configuring trust relationships.
 ---
  .../ipa-pwd-extop/ipapwd_prepost.c |  147 
  +++-
  1 file changed, 144 insertions(+), 3 deletions(-)
 
 diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
 b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 index 
 deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d
  100644
 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 @@ -41,7 +41,12 @@
  #  include config.h
  #endif
 
 -#define _XOPEN_SOURCE /* strptime needs this */
 +/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
 + * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
 +#ifndef _GNU_SOURCE
 +#define _GNU_SOURCE 1
 +#endif
 +
  #include stdio.h
  #include string.h
  #include strings.h
 @@ -53,6 +58,7 @@
  #include dirsrv/slapi-plugin.h
  #include lber.h
  #include time.h
 +#include endian.h
 
  #include ipapwd.h
  #include util.h
 @@ -379,6 +385,12 @@ done:
  return 0;
  }
 
 +#define NTHASH_REGEN_VAL MagicRegen
 +#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
 +static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
 +   char *dn, struct slapi_entry *entry,
 +   struct ipapwd_krbcfg *krbcfg);
 +
  /* PRE MOD Operation:
   * Gets the clean text password (fail the operation if the password came
   * pre-hashed, unless this is a replicated operation).
 @@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
  int has_krb_keys = 0;
  int has_history = 0;
  int gen_krb_keys = 0;
 +int is_magic_regen = 0;
  int ret, rc;
 
  LOG_TRACE( =\n);
 @@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
  default:
  break;
  }
 +} else if (slapi_attr_types_equivalent(lmod-mod_type, 
 ipaNTHash)) {
 +/* check op filtering out LDAP_MOD_BVALUES */
 +switch (lmod-mod_op  0x0f) {
 +case LDAP_MOD_REPLACE:
 This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.
 
 This is because I resent the old patch :(
 
 Hopefully the correct patch is now attached.
 Yes, now it is updated, thanks.
 
 I'm going to experiment a bit with these patches, adding ipasam
 responder to test them.
 Here is ipasam part.

ACK the ipasam part.

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][RFC] Implement special operation to revoer NT hash for a user

2012-07-26 Thread Alexander Bokovoy 

On Thu, 12 Jul 2012, Alexander Bokovoy wrote:

On Thu, 12 Jul 2012, Simo Sorce wrote:

On Thu, 2012-07-12 at 10:48 +0300, Alexander Bokovoy wrote:

On Wed, 11 Jul 2012, Simo Sorce wrote:

From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 16:18:29 -0400
Subject: [PATCH] Add special modify op to regen ipaNTHash

The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
extract it from krb5 keys if they are available to avoid forcing a password
change when configuring trust relationships.
---
.../ipa-pwd-extop/ipapwd_prepost.c |  147 +++-
1 file changed, 144 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index 
deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d
 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -41,7 +41,12 @@
#  include config.h
#endif

-#define _XOPEN_SOURCE /* strptime needs this */
+/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
+ * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
#include stdio.h
#include string.h
#include strings.h
@@ -53,6 +58,7 @@
#include dirsrv/slapi-plugin.h
#include lber.h
#include time.h
+#include endian.h

#include ipapwd.h
#include util.h
@@ -379,6 +385,12 @@ done:
return 0;
}

+#define NTHASH_REGEN_VAL MagicRegen
+#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char *dn, struct slapi_entry *entry,
+   struct ipapwd_krbcfg *krbcfg);
+
/* PRE MOD Operation:
 * Gets the clean text password (fail the operation if the password came
 * pre-hashed, unless this is a replicated operation).
@@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
int has_krb_keys = 0;
int has_history = 0;
int gen_krb_keys = 0;
+int is_magic_regen = 0;
int ret, rc;

LOG_TRACE( =\n);
@@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
default:
break;
}
+} else if (slapi_attr_types_equivalent(lmod-mod_type, ipaNTHash)) {
+/* check op filtering out LDAP_MOD_BVALUES */
+switch (lmod-mod_op  0x0f) {
+case LDAP_MOD_REPLACE:

This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.


This is because I resent the old patch :(

Hopefully the correct patch is now attached.

Yes, now it is updated, thanks.

I'm going to experiment a bit with these patches, adding ipasam
responder to test them.

Here is ipasam part.



--
/ Alexander Bokovoy
From 0cd261dd74154efc9ef6b09ef283cc1fe3448d5e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Thu, 26 Jul 2012 22:05:25 +0300
Subject: [PATCH 6/6] When ipaNTHash is missing, ask IPA to generate it from
 kerberos keys

---
 daemons/ipa-sam/ipa_sam.c |   96 +++--
 1 file changed, 93 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 
ab4b116c5f2b3b8dae6e8309403afba5fdf86708..aa54429b5bec4b26906b2a34e59ff95299a67f80
 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -2400,6 +2400,74 @@ static bool init_sam_from_td(struct samu *user, struct 
pdb_trusted_domain *td,
return true;
 }
 
+static bool ipasam_nthash_retrieve(struct ldapsam_privates *ldap_state,
+  TALLOC_CTX *mem_ctx,
+  char *entry_dn,
+  DATA_BLOB *nthash)
+{
+   int ret;
+   bool retval;
+   LDAPMessage *result;
+   LDAPMessage *entry = NULL;
+   int count;
+   struct smbldap_state *smbldap_state = ldap_state-smbldap_state;
+   const char *attr_list[] = {
+   LDAP_ATTRIBUTE_NTHASH,
+   NULL
+ };
+
+   ret = smbldap_search(smbldap_state, entry_dn,
+LDAP_SCOPE_BASE, , attr_list, 0,
+result);
+   if (ret != LDAP_SUCCESS) {
+   DEBUG(1, (Failed to get NT hash: %s\n,
+ ldap_err2string (ret)));
+   return false;
+   }
+
+   count = ldap_count_entries(smbldap_state-ldap_struct, result);
+
+   if (count != 1) {
+   DEBUG(1, (Unexpected number of results [%d] for NT hash 
+ of the single entry search.\n, count));
+   ldap_msgfree(result);
+   return false;
+   }
+
+   entry = ldap_first_entry(smbldap_state-ldap_struct, result);
+   if (entry ==

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-12 Thread Alexander Bokovoy 

On Wed, 11 Jul 2012, Simo Sorce wrote:

On Wed, 2012-07-11 at 16:40 +0300, Alexander Bokovoy wrote:

On Wed, 11 Jul 2012, Simo Sorce wrote:
On Wed, 2012-07-11 at 15:41 +0300, Alexander Bokovoy wrote:
 If users don't have RC4-HMAC key and don't have ipaNTHash set, they
 can't log in into smbd anyway until they change their password.

Yes the point is that you may have users you do not want to give a
password to. No need to keep retrying to generate a hash.

 My idea was that when the ipa trust-add operation is run we execute a
 magicregen op for the user that run it. Then we can run a process that
 adds ipaNThash via magicregen for all users we want it to.
 So we get to the same issue of a task run against potentially unbound
 number of users, including replication interaction.

 Instead, a scheme with ipasam-based generator would mean we:
 1. Fetch the user attributes from LDAP
 2. Notice ipaNTHash is missing and not disabled
 3. Issue ipaNTHash update request if (2) is true.

 Maybe we can turn off ipaNTHash from your pre-mod code if there is no
 RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
 overriden, of course. Then we can rely on it in (2) above.

Not sure what you mean by 'turn off ipaNTHash from your pre-mod code'.
Set ipaNTHash value to '0', for example. I.e. not 16 bytes and not
missing.


 If we decide to use it in ipasam, extended operation will be simpliest
 thing -- contrary to other approaches which would require two LDAP
 requests. It also allows to return the key in the same go.

True, but it is still required only once per user, in normal course of
action you should always get the ipaNTHash back. Even in the race
condition case the worst that can happen is that you fail auth once.
Given it is not that critical as it can happen only once per user I am
not sure it is worth optimizing for this case and create a whole new
extended operation for it.
As per discussion with Simo on IRC, NACK for current approach with
LDAP_MOD_REPLACE, NACK for extended operation as well.

Please replace LDAP_MOD_REPLACE with LDAP_MOD_ADD detection. smbldap
code in smbd uses LDAP_MOD_DELETE/LDAP_MOD_ADD combination as
replacement of LDAP_MOD_REPLACE to avoid some nasty bugs with Novell
Directory so we have to live with this approach.


Attached patch that changes REPLACE - ADD


It still doesn't give you much, there are 2 cases:

1) For users that are supposed to have the ipaNTHash, you will go
through this operation *once* in the lifetime of a pre-existing user
(new users get ipaNTHash immediately).

2) For users that will never get the ipaNTHash will simply never have
it, you only keep repeating this operation and then fail authentication
as you won't get back a valid hash, I do not think optimizing this
failure case is worth a full extop.
My point was to get pre-mod code to set ipaNTHash to invalid (non-16
byte) value to signify that they are 'disabled' for NTLM operations.
This way I can get ipaNTHash on user fetch but can locally detect that
the user is without password and therefore avoid the whole process.


Do you still want to do this ?
We could store the value 'DISABLED' instead of the hash, but then I'd
have to change the password plugin to respect it. If you want that I
think we need to open a new bug and treat it as a separate feature.

Yes, I think it could be good optimization. I've made following ticket:
https://fedorahosted.org/freeipa/ticket/2921


--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-12 Thread Alexander Bokovoy 

On Wed, 11 Jul 2012, Simo Sorce wrote:

From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 16:18:29 -0400
Subject: [PATCH] Add special modify op to regen ipaNTHash

The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
extract it from krb5 keys if they are available to avoid forcing a password
change when configuring trust relationships.
---
.../ipa-pwd-extop/ipapwd_prepost.c |  147 +++-
1 file changed, 144 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index 
deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d
 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -41,7 +41,12 @@
#  include config.h
#endif

-#define _XOPEN_SOURCE /* strptime needs this */
+/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
+ * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
#include stdio.h
#include string.h
#include strings.h
@@ -53,6 +58,7 @@
#include dirsrv/slapi-plugin.h
#include lber.h
#include time.h
+#include endian.h

#include ipapwd.h
#include util.h
@@ -379,6 +385,12 @@ done:
return 0;
}

+#define NTHASH_REGEN_VAL MagicRegen
+#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char *dn, struct slapi_entry *entry,
+   struct ipapwd_krbcfg *krbcfg);
+
/* PRE MOD Operation:
 * Gets the clean text password (fail the operation if the password came
 * pre-hashed, unless this is a replicated operation).
@@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
int has_krb_keys = 0;
int has_history = 0;
int gen_krb_keys = 0;
+int is_magic_regen = 0;
int ret, rc;

LOG_TRACE( =\n);
@@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
default:
break;
}
+} else if (slapi_attr_types_equivalent(lmod-mod_type, ipaNTHash)) {
+/* check op filtering out LDAP_MOD_BVALUES */
+switch (lmod-mod_op  0x0f) {
+case LDAP_MOD_REPLACE:

This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.



+if (!lmod-mod_bvalues ||
+!lmod-mod_bvalues[0]) {
+rc = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+bv = lmod-mod_bvalues[0];
+if ((bv-bv_len = NTHASH_REGEN_LEN -1) 
+(bv-bv_len = NTHASH_REGEN_LEN) 
+(strncmp(NTHASH_REGEN_VAL,
+ bv-bv_val, bv-bv_len) == 0)) {
+is_magic_regen = 1;
+/* make sure the database will later ignore this mod */
+slapi_mods_remove(smods);
+}
+default:
+break;
+}
} else if (slapi_attr_types_equivalent(lmod-mod_type,
unhashed#user#password)) {
/* we check for unahsehd password here so that we are sure to
@@ -472,8 +506,9 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
lmod = slapi_mods_get_next_mod(smods);
}

-/* If userPassword is not modified we are done here */
-if (! is_pwd_op) {
+/* If userPassword is not modified check if this is a request to generate
+ * NT hashes otherwise we are done here */
+if (!is_pwd_op  !is_magic_regen) {
rc = LDAP_SUCCESS;
goto done;
}
@@ -522,6 +557,22 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
goto done;
}

+if (!is_pwd_op) {
+/* This may be a magic op to ask us to generate the NT hashes */
+if (is_magic_regen) {
+/* Make sense to call only if this entry has krb keys to source
+ * the nthash from */
+if (is_krb) {
+rc = ipapwd_regen_nthash(pb, smods, dn, e, krbcfg);
+} else {
+rc = LDAP_UNWILLING_TO_PERFORM;
+}
+} else {
+rc = LDAP_OPERATIONS_ERROR;
+}
+goto done;
+}
+
/* run through the mods again and adjust flags if operations affect them */
lmod = slapi_mods_get_first_mod(smods);
while (lmod) {
@@ -831,6 +882,96 @@ done:
return 0;
}

+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char *dn, struct slapi_entry *entry,
+   struct ipapwd_krbcfg *krbcfg)
+{
+Slapi_Attr *attr;
+Slapi_Value *value;
+const struct berval *val;
+struct berval *ntvals[2] = { NULL, NULL };
+struct berval bval;
+krb5_key_data *keys;
+int

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-12 Thread Simo Sorce 
On Thu, 2012-07-12 at 10:48 +0300, Alexander Bokovoy wrote:
 On Wed, 11 Jul 2012, Simo Sorce wrote:
 From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
 From: Simo Sorce sso...@redhat.com
 Date: Fri, 6 Jul 2012 16:18:29 -0400
 Subject: [PATCH] Add special modify op to regen ipaNTHash
 
 The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
 extract it from krb5 keys if they are available to avoid forcing a password
 change when configuring trust relationships.
 ---
  .../ipa-pwd-extop/ipapwd_prepost.c |  147 
  +++-
  1 file changed, 144 insertions(+), 3 deletions(-)
 
 diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
 b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 index 
 deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d
  100644
 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
 @@ -41,7 +41,12 @@
  #  include config.h
  #endif
  
 -#define _XOPEN_SOURCE /* strptime needs this */
 +/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
 + * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
 +#ifndef _GNU_SOURCE
 +#define _GNU_SOURCE 1
 +#endif
 +
  #include stdio.h
  #include string.h
  #include strings.h
 @@ -53,6 +58,7 @@
  #include dirsrv/slapi-plugin.h
  #include lber.h
  #include time.h
 +#include endian.h
  
  #include ipapwd.h
  #include util.h
 @@ -379,6 +385,12 @@ done:
  return 0;
  }
  
 +#define NTHASH_REGEN_VAL MagicRegen
 +#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
 +static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
 +   char *dn, struct slapi_entry *entry,
 +   struct ipapwd_krbcfg *krbcfg);
 +
  /* PRE MOD Operation:
   * Gets the clean text password (fail the operation if the password came
   * pre-hashed, unless this is a replicated operation).
 @@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
  int has_krb_keys = 0;
  int has_history = 0;
  int gen_krb_keys = 0;
 +int is_magic_regen = 0;
  int ret, rc;
  
  LOG_TRACE( =\n);
 @@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
  default:
  break;
  }
 +} else if (slapi_attr_types_equivalent(lmod-mod_type, 
 ipaNTHash)) {
 +/* check op filtering out LDAP_MOD_BVALUES */
 +switch (lmod-mod_op  0x0f) {
 +case LDAP_MOD_REPLACE:
 This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.

This is because I resent the old patch :(

Hopefully the correct patch is now attached.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York
From 00e2aa83eabf5e4f60fd662d7ecd4e91f4209103 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 16:18:29 -0400
Subject: [PATCH] Add special modify op to regen ipaNTHash

The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
extract it from krb5 keys if they are available to avoid forcing a password
change when configuring trust relationships.
---
 .../ipa-pwd-extop/ipapwd_prepost.c |  146 +++-
 1 file changed, 143 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index deae642f82edcc4674a1c9580661c3dae94b..e4909c94585b6fac6b7f8347b806a8841107f3d0 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -41,7 +41,12 @@
 #  include config.h
 #endif
 
-#define _XOPEN_SOURCE /* strptime needs this */
+/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
+ * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
 #include stdio.h
 #include string.h
 #include strings.h
@@ -53,6 +58,7 @@
 #include dirsrv/slapi-plugin.h
 #include lber.h
 #include time.h
+#include endian.h
 
 #include ipapwd.h
 #include util.h
@@ -379,6 +385,12 @@ done:
 return 0;
 }
 
+#define NTHASH_REGEN_VAL MagicRegen
+#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char *dn, struct slapi_entry *entry,
+   struct ipapwd_krbcfg *krbcfg);
+
 /* PRE MOD Operation:
  * Gets the clean text password (fail the operation if the password came
  * pre-hashed, unless this is a replicated operation).
@@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
 int has_krb_keys = 0;
 int has_history = 0;
 int gen_krb_keys = 0;
+int is_magic_regen = 0;
 int ret, rc;
 
 LOG_TRACE( =\n);
@@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
 default:
 break;
 }
+} else if

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-12 Thread Alexander Bokovoy 

On Thu, 12 Jul 2012, Simo Sorce wrote:

On Thu, 2012-07-12 at 10:48 +0300, Alexander Bokovoy wrote:

On Wed, 11 Jul 2012, Simo Sorce wrote:
From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 16:18:29 -0400
Subject: [PATCH] Add special modify op to regen ipaNTHash

The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
extract it from krb5 keys if they are available to avoid forcing a password
change when configuring trust relationships.
---
 .../ipa-pwd-extop/ipapwd_prepost.c |  147 +++-
 1 file changed, 144 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index 
deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d 
100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -41,7 +41,12 @@
 #  include config.h
 #endif

-#define _XOPEN_SOURCE /* strptime needs this */
+/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
+ * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
 #include stdio.h
 #include string.h
 #include strings.h
@@ -53,6 +58,7 @@
 #include dirsrv/slapi-plugin.h
 #include lber.h
 #include time.h
+#include endian.h

 #include ipapwd.h
 #include util.h
@@ -379,6 +385,12 @@ done:
 return 0;
 }

+#define NTHASH_REGEN_VAL MagicRegen
+#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char *dn, struct slapi_entry *entry,
+   struct ipapwd_krbcfg *krbcfg);
+
 /* PRE MOD Operation:
  * Gets the clean text password (fail the operation if the password came
  * pre-hashed, unless this is a replicated operation).
@@ -407,6 +419,7 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
 int has_krb_keys = 0;
 int has_history = 0;
 int gen_krb_keys = 0;
+int is_magic_regen = 0;
 int ret, rc;

 LOG_TRACE( =\n);
@@ -447,6 +460,27 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb)
 default:
 break;
 }
+} else if (slapi_attr_types_equivalent(lmod-mod_type, ipaNTHash)) {
+/* check op filtering out LDAP_MOD_BVALUES */
+switch (lmod-mod_op  0x0f) {
+case LDAP_MOD_REPLACE:
This is still LDAP_MOD_REPLACE, not LDAP_MOD_ADD.


This is because I resent the old patch :(

Hopefully the correct patch is now attached.

Yes, now it is updated, thanks.

I'm going to experiment a bit with these patches, adding ipasam
responder to test them.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Alexander Bokovoy 

On Sat, 07 Jul 2012, Simo Sorce wrote:

When installing the adtrust code we need to be able to get the ipaNTHash
populated as in some cases we may need it to authenticate connections
over SMB w/o using kerberos during the trust setup phase.

The NT hash is really just the same thing as the rc4-hmac key we already
have by default in the Kerberos Keys.

This patch-set implements a check in the password plugin for the pre-mod
operation to catch the attempt to replace the attribute with the value
'MagicRegen' in the ipaNThash attribute.

If no previous ipaNTHash value is present, and the kerberos keys are
available, then we attempt to find the rc4-hmac key and if we find it we
store it in the ipaNTHash.

This will allow us to give the admin user (and potentially any other
user) the NT hash samba requires without forcing them to reset their
password, assuming the rc4-hmac key is present (currently it is by
default).

I marked this patch-set as RFC as I want opinions on the method (LDAP
modify with replace operation) I utilized to perform the extraction.

If it bode well with everybody we can consider the patch-set for
inclusion.

I tested it and extracting the hash works fine and it works later on
using smbclient to access a share.

This patchset implements task  #2867:
https://fedorahosted.org/freeipa/ticket/2867

I've read through the code and I think it is a sensible approach. However,
let's get through its possible use first. If I understood correctly,
ipasam is supposed to do following:

1. Upon user lookup ldapsam_getsampwnam() in ipa_sam.c will be called
2. It will call init_sam_from_ldap()
3. init_sam_from_ldap() will attempt to read ipaNTHash
4. If (3) failed, we don't call pdb_set_nt_passwd() to set NT hash in
internal pdb structure that is later used by smbd to authenticate the
user.

Now, with this RFC in action, we'll have:
3a. read ipaNTHash
3b. if failed, perform mod/replace ipaNTHash value with MagicRegen
3c. read ipaNTHash

Besides two reads, we may have possible race condition where attribute value
is not yet written back when (3c) occurs.

Can we replace this sequence with a single extended operation?

3. Perform extended operation, say, IPA_OBTAIN_NTHASH, get ipaNTHash
value back for a specified DN

The operation internally would handle both cases when ipaNTHash is
available and when it is not. 

We also can simply use ipaNTHash attribute length as differentiating 
factor for cases when ipaNTHash generation should be prevented. I.e.

absent or empty ipaNTHash would cause generating the hash from kerberos
keys if possible, ipaNTHash set to size less than 16 would prevent
generating the hash.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Simo Sorce 
On Wed, 2012-07-11 at 14:55 +0300, Alexander Bokovoy wrote:
 On Sat, 07 Jul 2012, Simo Sorce wrote:
 When installing the adtrust code we need to be able to get the ipaNTHash
 populated as in some cases we may need it to authenticate connections
 over SMB w/o using kerberos during the trust setup phase.
 
 The NT hash is really just the same thing as the rc4-hmac key we already
 have by default in the Kerberos Keys.
 
 This patch-set implements a check in the password plugin for the pre-mod
 operation to catch the attempt to replace the attribute with the value
 'MagicRegen' in the ipaNThash attribute.
 
 If no previous ipaNTHash value is present, and the kerberos keys are
 available, then we attempt to find the rc4-hmac key and if we find it we
 store it in the ipaNTHash.
 
 This will allow us to give the admin user (and potentially any other
 user) the NT hash samba requires without forcing them to reset their
 password, assuming the rc4-hmac key is present (currently it is by
 default).
 
 I marked this patch-set as RFC as I want opinions on the method (LDAP
 modify with replace operation) I utilized to perform the extraction.
 
 If it bode well with everybody we can consider the patch-set for
 inclusion.
 
 I tested it and extracting the hash works fine and it works later on
 using smbclient to access a share.
 
 This patchset implements task  #2867:
 https://fedorahosted.org/freeipa/ticket/2867
 I've read through the code and I think it is a sensible approach. However,
 let's get through its possible use first. If I understood correctly,
 ipasam is supposed to do following:
 
 1. Upon user lookup ldapsam_getsampwnam() in ipa_sam.c will be called
 2. It will call init_sam_from_ldap()
 3. init_sam_from_ldap() will attempt to read ipaNTHash
 4. If (3) failed, we don't call pdb_set_nt_passwd() to set NT hash in
 internal pdb structure that is later used by smbd to authenticate the
 user.
 
 Now, with this RFC in action, we'll have:
 3a. read ipaNTHash
 3b. if failed, perform mod/replace ipaNTHash value with MagicRegen
 3c. read ipaNTHash
 
 Besides two reads, we may have possible race condition where attribute value
 is not yet written back when (3c) occurs.

My idea ws that you run the MagicRegen operation out of band, and not in
ipasam. The reason is that for users without an RC4-HMAC key you'd keep
doing it over and over again.

My idea was that when the ipa trust-add operation is run we execute a
magicregen op for the user that run it. Then we can run a process that
adds ipaNThash via magicregen for all users we want it to.

This is something you really need to do only once as after you have
added the appropriate objectclass any password change will keep things
in sync.

 Can we replace this sequence with a single extended operation?

I prefer avoiding whole extended operations for trivial stuff that needs
to be run once only.

 3. Perform extended operation, say, IPA_OBTAIN_NTHASH, get ipaNTHash
 value back for a specified DN
 
 The operation internally would handle both cases when ipaNTHash is
 available and when it is not. 
 
 We also can simply use ipaNTHash attribute length as differentiating 
 factor for cases when ipaNTHash generation should be prevented. I.e.
 absent or empty ipaNTHash would cause generating the hash from kerberos
 keys if possible, ipaNTHash set to size less than 16 would prevent
 generating the hash.

We could do that but I think it would be a lot of work for very little
gain.

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][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Alexander Bokovoy 

On Wed, 11 Jul 2012, Simo Sorce wrote:

On Wed, 2012-07-11 at 14:55 +0300, Alexander Bokovoy wrote:

On Sat, 07 Jul 2012, Simo Sorce wrote:
When installing the adtrust code we need to be able to get the ipaNTHash
populated as in some cases we may need it to authenticate connections
over SMB w/o using kerberos during the trust setup phase.

The NT hash is really just the same thing as the rc4-hmac key we already
have by default in the Kerberos Keys.

This patch-set implements a check in the password plugin for the pre-mod
operation to catch the attempt to replace the attribute with the value
'MagicRegen' in the ipaNThash attribute.

If no previous ipaNTHash value is present, and the kerberos keys are
available, then we attempt to find the rc4-hmac key and if we find it we
store it in the ipaNTHash.

This will allow us to give the admin user (and potentially any other
user) the NT hash samba requires without forcing them to reset their
password, assuming the rc4-hmac key is present (currently it is by
default).

I marked this patch-set as RFC as I want opinions on the method (LDAP
modify with replace operation) I utilized to perform the extraction.

If it bode well with everybody we can consider the patch-set for
inclusion.

I tested it and extracting the hash works fine and it works later on
using smbclient to access a share.

This patchset implements task  #2867:
https://fedorahosted.org/freeipa/ticket/2867
I've read through the code and I think it is a sensible approach. However,
let's get through its possible use first. If I understood correctly,
ipasam is supposed to do following:

1. Upon user lookup ldapsam_getsampwnam() in ipa_sam.c will be called
2. It will call init_sam_from_ldap()
3. init_sam_from_ldap() will attempt to read ipaNTHash
4. If (3) failed, we don't call pdb_set_nt_passwd() to set NT hash in
internal pdb structure that is later used by smbd to authenticate the
user.

Now, with this RFC in action, we'll have:
3a. read ipaNTHash
3b. if failed, perform mod/replace ipaNTHash value with MagicRegen
3c. read ipaNTHash

Besides two reads, we may have possible race condition where attribute value
is not yet written back when (3c) occurs.


My idea ws that you run the MagicRegen operation out of band, and not in
ipasam. The reason is that for users without an RC4-HMAC key you'd keep
doing it over and over again.

If users don't have RC4-HMAC key and don't have ipaNTHash set, they
can't log in into smbd anyway until they change their password.


My idea was that when the ipa trust-add operation is run we execute a
magicregen op for the user that run it. Then we can run a process that
adds ipaNThash via magicregen for all users we want it to.

So we get to the same issue of a task run against potentially unbound
number of users, including replication interaction.

Instead, a scheme with ipasam-based generator would mean we:
1. Fetch the user attributes from LDAP
2. Notice ipaNTHash is missing and not disabled
3. Issue ipaNTHash update request if (2) is true.

Maybe we can turn off ipaNTHash from your pre-mod code if there is no
RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
overriden, of course. Then we can rely on it in (2) above.


This is something you really need to do only once as after you have
added the appropriate objectclass any password change will keep things
in sync.


Can we replace this sequence with a single extended operation?


I prefer avoiding whole extended operations for trivial stuff that needs
to be run once only.

If we decide to use it in ipasam, extended operation will be simpliest
thing -- contrary to other approaches which would require two LDAP
requests. It also allows to return the key in the same go.


3. Perform extended operation, say, IPA_OBTAIN_NTHASH, get ipaNTHash
value back for a specified DN

The operation internally would handle both cases when ipaNTHash is
available and when it is not.

We also can simply use ipaNTHash attribute length as differentiating
factor for cases when ipaNTHash generation should be prevented. I.e.
absent or empty ipaNTHash would cause generating the hash from kerberos
keys if possible, ipaNTHash set to size less than 16 would prevent
generating the hash.


We could do that but I think it would be a lot of work for very little
gain.
See above. Being able to differentiate cases 
- RC4-HMAC is missing, no automatic ipaNTHash generation

- RC4-HMAC is available, generate ipaNTHash
- ipaNTHash is generated via password change

is worth it because it allows to avoid additional roundtrips from
ipasam and still be able to avoid generator tasks.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Simo Sorce 
On Wed, 2012-07-11 at 15:41 +0300, Alexander Bokovoy wrote:
 If users don't have RC4-HMAC key and don't have ipaNTHash set, they
 can't log in into smbd anyway until they change their password.

Yes the point is that you may have users you do not want to give a
password to. No need to keep retrying to generate a hash.

 My idea was that when the ipa trust-add operation is run we execute a
 magicregen op for the user that run it. Then we can run a process that
 adds ipaNThash via magicregen for all users we want it to.
 So we get to the same issue of a task run against potentially unbound
 number of users, including replication interaction.
 
 Instead, a scheme with ipasam-based generator would mean we:
 1. Fetch the user attributes from LDAP
 2. Notice ipaNTHash is missing and not disabled
 3. Issue ipaNTHash update request if (2) is true.
 
 Maybe we can turn off ipaNTHash from your pre-mod code if there is no
 RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
 overriden, of course. Then we can rely on it in (2) above.

Not sure what you mean by 'turn off ipaNTHash from your pre-mod code'.

 If we decide to use it in ipasam, extended operation will be simpliest
 thing -- contrary to other approaches which would require two LDAP
 requests. It also allows to return the key in the same go.

True, but it is still required only once per user, in normal course of
action you should always get the ipaNTHash back. Even in the race
condition case the worst that can happen is that you fail auth once.
Given it is not that critical as it can happen only once per user I am
not sure it is worth optimizing for this case and create a whole new
extended operation for it.

 See above. Being able to differentiate cases 
 - RC4-HMAC is missing, no automatic ipaNTHash generation
 - RC4-HMAC is available, generate ipaNTHash
 - ipaNTHash is generated via password change
 
 is worth it because it allows to avoid additional roundtrips from
 ipasam and still be able to avoid generator tasks.

It still doesn't give you much, there are 2 cases:

1) For users that are supposed to have the ipaNTHash, you will go
through this operation *once* in the lifetime of a pre-existing user
(new users get ipaNTHash immediately).

2) For users that will never get the ipaNTHash will simply never have
it, you only keep repeating this operation and then fail authentication
as you won't get back a valid hash, I do not think optimizing this
failure case is worth a full extop.

The generator task is not strictly necessary, it's an option, you can
make the 2 roundtrips in ipasam (I think I will have to relax
permissions to allow you to do that as a cifs/fqdn principal) once per
user, doesn't look like a big deal.

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][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Alexander Bokovoy 

On Wed, 11 Jul 2012, Simo Sorce wrote:

On Wed, 2012-07-11 at 15:41 +0300, Alexander Bokovoy wrote:

If users don't have RC4-HMAC key and don't have ipaNTHash set, they
can't log in into smbd anyway until they change their password.


Yes the point is that you may have users you do not want to give a
password to. No need to keep retrying to generate a hash.


My idea was that when the ipa trust-add operation is run we execute a
magicregen op for the user that run it. Then we can run a process that
adds ipaNThash via magicregen for all users we want it to.
So we get to the same issue of a task run against potentially unbound
number of users, including replication interaction.

Instead, a scheme with ipasam-based generator would mean we:
1. Fetch the user attributes from LDAP
2. Notice ipaNTHash is missing and not disabled
3. Issue ipaNTHash update request if (2) is true.

Maybe we can turn off ipaNTHash from your pre-mod code if there is no
RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
overriden, of course. Then we can rely on it in (2) above.


Not sure what you mean by 'turn off ipaNTHash from your pre-mod code'.

Set ipaNTHash value to '0', for example. I.e. not 16 bytes and not
missing.



If we decide to use it in ipasam, extended operation will be simpliest
thing -- contrary to other approaches which would require two LDAP
requests. It also allows to return the key in the same go.


True, but it is still required only once per user, in normal course of
action you should always get the ipaNTHash back. Even in the race
condition case the worst that can happen is that you fail auth once.
Given it is not that critical as it can happen only once per user I am
not sure it is worth optimizing for this case and create a whole new
extended operation for it.

As per discussion with Simo on IRC, NACK for current approach with
LDAP_MOD_REPLACE, NACK for extended operation as well.

Please replace LDAP_MOD_REPLACE with LDAP_MOD_ADD detection. smbldap
code in smbd uses LDAP_MOD_DELETE/LDAP_MOD_ADD combination as
replacement of LDAP_MOD_REPLACE to avoid some nasty bugs with Novell
Directory so we have to live with this approach.


See above. Being able to differentiate cases
- RC4-HMAC is missing, no automatic ipaNTHash generation
- RC4-HMAC is available, generate ipaNTHash
- ipaNTHash is generated via password change

is worth it because it allows to avoid additional roundtrips from
ipasam and still be able to avoid generator tasks.


It still doesn't give you much, there are 2 cases:

1) For users that are supposed to have the ipaNTHash, you will go
through this operation *once* in the lifetime of a pre-existing user
(new users get ipaNTHash immediately).

2) For users that will never get the ipaNTHash will simply never have
it, you only keep repeating this operation and then fail authentication
as you won't get back a valid hash, I do not think optimizing this
failure case is worth a full extop.

My point was to get pre-mod code to set ipaNTHash to invalid (non-16
byte) value to signify that they are 'disabled' for NTLM operations.
This way I can get ipaNTHash on user fetch but can locally detect that
the user is without password and therefore avoid the whole process.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-11 Thread Simo Sorce 
On Wed, 2012-07-11 at 16:40 +0300, Alexander Bokovoy wrote:
 On Wed, 11 Jul 2012, Simo Sorce wrote:
 On Wed, 2012-07-11 at 15:41 +0300, Alexander Bokovoy wrote:
  If users don't have RC4-HMAC key and don't have ipaNTHash set, they
  can't log in into smbd anyway until they change their password.
 
 Yes the point is that you may have users you do not want to give a
 password to. No need to keep retrying to generate a hash.
 
  My idea was that when the ipa trust-add operation is run we execute a
  magicregen op for the user that run it. Then we can run a process that
  adds ipaNThash via magicregen for all users we want it to.
  So we get to the same issue of a task run against potentially unbound
  number of users, including replication interaction.
 
  Instead, a scheme with ipasam-based generator would mean we:
  1. Fetch the user attributes from LDAP
  2. Notice ipaNTHash is missing and not disabled
  3. Issue ipaNTHash update request if (2) is true.
 
  Maybe we can turn off ipaNTHash from your pre-mod code if there is no
  RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
  overriden, of course. Then we can rely on it in (2) above.
 
 Not sure what you mean by 'turn off ipaNTHash from your pre-mod code'.
 Set ipaNTHash value to '0', for example. I.e. not 16 bytes and not
 missing.
 
 
  If we decide to use it in ipasam, extended operation will be simpliest
  thing -- contrary to other approaches which would require two LDAP
  requests. It also allows to return the key in the same go.
 
 True, but it is still required only once per user, in normal course of
 action you should always get the ipaNTHash back. Even in the race
 condition case the worst that can happen is that you fail auth once.
 Given it is not that critical as it can happen only once per user I am
 not sure it is worth optimizing for this case and create a whole new
 extended operation for it.
 As per discussion with Simo on IRC, NACK for current approach with
 LDAP_MOD_REPLACE, NACK for extended operation as well.
 
 Please replace LDAP_MOD_REPLACE with LDAP_MOD_ADD detection. smbldap
 code in smbd uses LDAP_MOD_DELETE/LDAP_MOD_ADD combination as
 replacement of LDAP_MOD_REPLACE to avoid some nasty bugs with Novell
 Directory so we have to live with this approach.

Attached patch that changes REPLACE - ADD

 It still doesn't give you much, there are 2 cases:
 
 1) For users that are supposed to have the ipaNTHash, you will go
 through this operation *once* in the lifetime of a pre-existing user
 (new users get ipaNTHash immediately).
 
 2) For users that will never get the ipaNTHash will simply never have
 it, you only keep repeating this operation and then fail authentication
 as you won't get back a valid hash, I do not think optimizing this
 failure case is worth a full extop.
 My point was to get pre-mod code to set ipaNTHash to invalid (non-16
 byte) value to signify that they are 'disabled' for NTLM operations.
 This way I can get ipaNTHash on user fetch but can locally detect that
 the user is without password and therefore avoid the whole process.

Do you still want to do this ?
We could store the value 'DISABLED' instead of the hash, but then I'd
have to change the password plugin to respect it. If you want that I
think we need to open a new bug and treat it as a separate feature.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 84ef09a1193ff42fc301fb71354055c5039f51a5 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 16:18:29 -0400
Subject: [PATCH] Add special modify op to regen ipaNTHash

The NT Hash is the same thing as the RC4-HMAC key, so we add a function to
extract it from krb5 keys if they are available to avoid forcing a password
change when configuring trust relationships.
---
 .../ipa-pwd-extop/ipapwd_prepost.c |  147 +++-
 1 file changed, 144 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
index deae642f82edcc4674a1c9580661c3dae94b..24fa52eb9ac92004576ccdba4f576162c358770d 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c
@@ -41,7 +41,12 @@
 #  include config.h
 #endif
 
-#define _XOPEN_SOURCE /* strptime needs this */
+/* strptime needs _XOPEN_SOURCE and endian.h needs __USE_BSD
+ * _GNU_SOURCE imply both, and we use it elsewhere, so use this */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
+
 #include stdio.h
 #include string.h
 #include strings.h
@@ -53,6 +58,7 @@
 #include dirsrv/slapi-plugin.h
 #include lber.h
 #include time.h
+#include endian.h
 
 #include ipapwd.h
 #include util.h
@@ -379,6 +385,12 @@ done:
 return 0;
 }
 
+#define NTHASH_REGEN_VAL MagicRegen
+#define NTHASH_REGEN_LEN sizeof(NTHASH_REGEN_VAL)
+static int ipapwd_regen_nthash(Slapi_PBlock *pb, Slapi_Mods *smods,
+   char

[Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

2012-07-07 Thread Simo Sorce 
When installing the adtrust code we need to be able to get the ipaNTHash
populated as in some cases we may need it to authenticate connections
over SMB w/o using kerberos during the trust setup phase.

The NT hash is really just the same thing as the rc4-hmac key we already
have by default in the Kerberos Keys.

This patch-set implements a check in the password plugin for the pre-mod
operation to catch the attempt to replace the attribute with the value
'MagicRegen' in the ipaNThash attribute.

If no previous ipaNTHash value is present, and the kerberos keys are
available, then we attempt to find the rc4-hmac key and if we find it we
store it in the ipaNTHash.

This will allow us to give the admin user (and potentially any other
user) the NT hash samba requires without forcing them to reset their
password, assuming the rc4-hmac key is present (currently it is by
default).

I marked this patch-set as RFC as I want opinions on the method (LDAP
modify with replace operation) I utilized to perform the extraction.

If it bode well with everybody we can consider the patch-set for
inclusion.

I tested it and extracting the hash works fine and it works later on
using smbclient to access a share.

This patchset implements task  #2867:
https://fedorahosted.org/freeipa/ticket/2867

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From c3d1c24413698e6d371b1de17b6efde9e1b7acb0 Mon Sep 17 00:00:00 2001
From: Simo Sorce sso...@redhat.com
Date: Fri, 6 Jul 2012 11:15:15 -0400
Subject: [PATCH 1/7] Move code into common krb5 utils

This moves the decoding function that reads the keys from the ber format
into a structure in the common krb5 util code right below the function
that encodes the same data structure into a ber format.
This way the 2 functions are in the same place and can be both used by
all ia components.
---
 daemons/ipa-kdb/ipa_kdb_principals.c |  148 ++---
 util/ipa_krb5.c  |  150 ++
 util/ipa_krb5.h  |2 +
 3 files changed, 159 insertions(+), 141 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index d87d6fe9f82b479db6ab8e6b59a8b5ee580b9a27..6f8b296fa4cb19cbfe5c37536316d6f0e7f83b9c 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -205,152 +205,18 @@ static int ipadb_ldap_attr_to_key_data(LDAP *lcontext, LDAPMessage *le,
krb5_kvno *res_mkvno)
 {
 struct berval **vals;
-krb5_key_data *keys = NULL;
-BerElement *be = NULL;
-void *tmp;
-int i = 0;
-int ret = ENOENT;
+int mkvno;
+int ret;
 
 vals = ldap_get_values_len(lcontext, le, attrname);
-if (vals) {
-ber_tag_t tag;
-ber_int_t major_vno;
-ber_int_t minor_vno;
-ber_int_t kvno;
-ber_int_t mkvno;
-ber_int_t type;
-ber_tag_t seqtag;
-ber_len_t seqlen;
-ber_len_t setlen;
-ber_tag_t retag;
-ber_tag_t opttag;
-struct berval tval;
-
-be = ber_alloc_t(LBER_USE_DER);
-if (!be) {
-return ENOMEM;
-}
-
-/* reinit the ber element with the new val */
-ber_init2(be, vals[0], LBER_USE_DER);
-
-/* fill key_data struct with the data */
-retag = ber_scanf(be, {t[i]t[i]t[i]t[i]t[{,
-  tag, major_vno,
-  tag, minor_vno,
-  tag, kvno,
-  tag, mkvno,
-  seqtag);
-if (retag == LBER_ERROR ||
-major_vno != 1 ||
-minor_vno != 1 ||
-seqtag != (LBER_CONSTRUCTED | LBER_CLASS_CONTEXT | 4)) {
-ret = EINVAL;
-goto done;
-}
-
-retag = ber_skip_tag(be, seqlen);
-
-/* sequence of keys */
-for (i = 0; retag == LBER_SEQUENCE; i++) {
-
-tmp = realloc(keys, (i + 1) * sizeof(krb5_key_data));
-if (!tmp) {
-ret = ENOMEM;
-goto done;
-}
-keys = tmp;
-
-memset(keys[i], 0, sizeof(krb5_key_data));
-
-keys[i].key_data_kvno = kvno;
-
-/* do we have a salt type ? (optional) */
-retag = ber_scanf(be, t, opttag);
-if (retag == LBER_ERROR) {
-ret = EINVAL;
-goto done;
-}
-if (opttag == (LBER_CONSTRUCTED | LBER_CLASS_CONTEXT | 0)) {
-keys[i].key_data_ver = 2;
-
-retag = ber_scanf(be, [l{tl[i],
-  seqlen, tag, setlen, type);
-if (tag != (LBER_CONSTRUCTED | LBER_CLASS_CONTEXT | 0)) {
-ret = EINVAL;
-goto done;
-}
-keys[i].key_data_type[1] = type;
-
-/* do we have salt data ? (optional) */
-