Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On 14.01.2016 10:01, Alexander Bokovoy wrote: On Thu, 14 Jan 2016, Martin Basti wrote: On 14.01.2016 08:24, Alexander Bokovoy wrote: On Thu, 03 Dec 2015, Simo Sorce wrote: The first patch is preparatory and is needed in general now that we want top allow alias and use krbCanonicalName as the canonical name when multiple values are avilable in krbPrincipalName. The second patch changes slightly how the interdomain trust account is created so that the getkeytab control can generate the proper key (with the right salt) for interop reasons with AD. The change should be upgrade safe because keys are generate at account creation so older accounts lacking the alias won't be a problem. Fixes ##5495 This patchset seems to fall through cracks -- it was ACKed but not committed. IIRC all simo's ACKed patches which haven't been pushed depend on simo's patch 560, which has no ACK If not then, patches need rebase, they have missing blobs no, 560 is unrelated. Pushed to: master: f9ed0b6ff8bf7e59de5450200d9fc5ad6e05299c ipa-4-3: 7e09456d8b80eabb87bb2cf595904b5cc740af8e -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On Thu, 14 Jan 2016, Martin Basti wrote: On 14.01.2016 08:24, Alexander Bokovoy wrote: On Thu, 03 Dec 2015, Simo Sorce wrote: The first patch is preparatory and is needed in general now that we want top allow alias and use krbCanonicalName as the canonical name when multiple values are avilable in krbPrincipalName. The second patch changes slightly how the interdomain trust account is created so that the getkeytab control can generate the proper key (with the right salt) for interop reasons with AD. The change should be upgrade safe because keys are generate at account creation so older accounts lacking the alias won't be a problem. Fixes ##5495 This patchset seems to fall through cracks -- it was ACKed but not committed. IIRC all simo's ACKed patches which haven't been pushed depend on simo's patch 560, which has no ACK If not then, patches need rebase, they have missing blobs no, 560 is unrelated. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On 14.01.2016 08:24, Alexander Bokovoy wrote: On Thu, 03 Dec 2015, Simo Sorce wrote: The first patch is preparatory and is needed in general now that we want top allow alias and use krbCanonicalName as the canonical name when multiple values are avilable in krbPrincipalName. The second patch changes slightly how the interdomain trust account is created so that the getkeytab control can generate the proper key (with the right salt) for interop reasons with AD. The change should be upgrade safe because keys are generate at account creation so older accounts lacking the alias won't be a problem. Fixes ##5495 This patchset seems to fall through cracks -- it was ACKed but not committed. IIRC all simo's ACKed patches which haven't been pushed depend on simo's patch 560, which has no ACK If not then, patches need rebase, they have missing blobs -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On Thu, 03 Dec 2015, Simo Sorce wrote: The first patch is preparatory and is needed in general now that we want top allow alias and use krbCanonicalName as the canonical name when multiple values are avilable in krbPrincipalName. The second patch changes slightly how the interdomain trust account is created so that the getkeytab control can generate the proper key (with the right salt) for interop reasons with AD. The change should be upgrade safe because keys are generate at account creation so older accounts lacking the alias won't be a problem. Fixes ##5495 This patchset seems to fall through cracks -- it was ACKed but not committed. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On Thu, 03 Dec 2015, Simo Sorce wrote: On Thu, 2015-12-03 at 19:33 +0200, Alexander Bokovoy wrote: On Thu, 03 Dec 2015, Simo Sorce wrote: >The first patch is preparatory and is needed in general now that we want >top allow alias and use krbCanonicalName as the canonical name when >multiple values are avilable in krbPrincipalName. > >The second patch changes slightly how the interdomain trust account is >created so that the getkeytab control can generate the proper key (with >the right salt) for interop reasons with AD. The change should be >upgrade safe because keys are generate at account creation so older >accounts lacking the alias won't be a problem. > >Fixes ##5495 Thanks. ACK to both. They work for me against Windows Server 2012R2. Now we need to fix Samba AD salt generation so that it is compatible with both Windows and FreeIPA for AES/DES keys and not only RC4... ;) And so we did: https://git.samba.org/?p=idra/samba.git;a=commitdiff;h=8e87601a998b43f58589ff88341946ca4d9ab5ee;hp=412cefc7c8222ccc77e15099a162f9fb7bb01c57 and: https://twitter.com/abbrasuo/status/672480716928716800 :-) Yep, thanks Simo! I've posted few screenshots of the current status of Samba AD with MIT Kerberos running on Fedora 23 and establishing cross-forest trust to FreeIPA on my Google+ page: https://plus.google.com/+AlexanderBokovoy/posts/NgozL7Rgw64 The patches to Samba are in Andreas' git tree, plus few changes Simo did for proper generation of the salt for interdomain trust object keys. Currently Samba generates the salt principal wrongly for TDO keys and it works in Heimdal only because Heimdal users RC4 keys for cross-realm trust which does not use the salt. Once Simo fixed the salt in password_hash ldb module, we were able to complete trust to FreeIPA in such way that MIT KDC was able to respond on AS request for the interdomain TDO principal and SSSD on FreeIPA side was able to use the resulting Kerberos session to authenticate with SASL GSSAPI to Samba AD's LDAP to look up users and groups. The POSIX attributes are managed by FreeIPA (UID/GIDs are autogenerated in this deployment) but they can also be picked up from Samba AD. We plan to work on remaining fixes to eventually get the full Samba AD support in Fedora 24, but this represents a huge milestone in our four year quest to make it a reality. Thanks to everyone! -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On Thu, 2015-12-03 at 19:33 +0200, Alexander Bokovoy wrote: > On Thu, 03 Dec 2015, Simo Sorce wrote: > >The first patch is preparatory and is needed in general now that we want > >top allow alias and use krbCanonicalName as the canonical name when > >multiple values are avilable in krbPrincipalName. > > > >The second patch changes slightly how the interdomain trust account is > >created so that the getkeytab control can generate the proper key (with > >the right salt) for interop reasons with AD. The change should be > >upgrade safe because keys are generate at account creation so older > >accounts lacking the alias won't be a problem. > > > >Fixes ##5495 > Thanks. ACK to both. They work for me against Windows Server 2012R2. > > Now we need to fix Samba AD salt generation so that it is compatible > with both Windows and FreeIPA for AES/DES keys and not only RC4... ;) And so we did: https://git.samba.org/?p=idra/samba.git;a=commitdiff;h=8e87601a998b43f58589ff88341946ca4d9ab5ee;hp=412cefc7c8222ccc77e15099a162f9fb7bb01c57 and: https://twitter.com/abbrasuo/status/672480716928716800 :-) Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
On Thu, 03 Dec 2015, Simo Sorce wrote: The first patch is preparatory and is needed in general now that we want top allow alias and use krbCanonicalName as the canonical name when multiple values are avilable in krbPrincipalName. The second patch changes slightly how the interdomain trust account is created so that the getkeytab control can generate the proper key (with the right salt) for interop reasons with AD. The change should be upgrade safe because keys are generate at account creation so older accounts lacking the alias won't be a problem. Fixes ##5495 Thanks. ACK to both. They work for me against Windows Server 2012R2. Now we need to fix Samba AD salt generation so that it is compatible with both Windows and FreeIPA for AES/DES keys and not only RC4... ;) -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control
The first patch is preparatory and is needed in general now that we want
top allow alias and use krbCanonicalName as the canonical name when
multiple values are avilable in krbPrincipalName.
The second patch changes slightly how the interdomain trust account is
created so that the getkeytab control can generate the proper key (with
the right salt) for interop reasons with AD. The change should be
upgrade safe because keys are generate at account creation so older
accounts lacking the alias won't be a problem.
Fixes ##5495
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From e13bb47a9e3673bb7af627bfb2bc59476552947e Mon Sep 17 00:00:00 2001
From: Simo Sorce
Date: Wed, 2 Dec 2015 15:20:42 -0500
Subject: [PATCH 1/2] Improve keytab code to select the right principal.
Whe requesting a keytab the salt used is the NORMAL type (for backwards and AD
compatibility), however since we added alias support we need to search for the
krbCanonicalName in preference, hen nothing is specified, and for the requested
principal name when a getkeytab operation is performed. This is so that the
correct salt can be applied. (Windows AD uses some peculiar aliases for some
special accounts to generate the salt).
Signed-off-by: Simo Sorce
---
daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 23 +++---
.../ipa-pwd-extop/ipa_pwd_extop.c | 3 ++-
daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 1 +
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 2 +-
4 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
index 5ca155dcf49923b06bdd1ea56c5fba8fff5e410e..9c62f0560aa999b2179a7767040047dfa89288e0 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
@@ -104,6 +104,7 @@ void ipapwd_keyset_free(struct ipapwd_keyset **pkset)
Slapi_Value **ipapwd_encrypt_encode_key(struct ipapwd_krbcfg *krbcfg,
struct ipapwd_data *data,
+char *preferred_principal,
int num_encsalts,
krb5_key_salt_tuple *encsalts,
char **errMesg)
@@ -128,12 +129,20 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct ipapwd_krbcfg *krbcfg,
kvno = ipapwd_get_cur_kvno(data->target);
-krbPrincipalName = slapi_entry_attr_get_charptr(data->target,
-"krbPrincipalName");
-if (!krbPrincipalName) {
-*errMesg = "no krbPrincipalName present in this entry\n";
-LOG_FATAL("%s", *errMesg);
-goto enc_error;
+if (preferred_principal) {
+krbPrincipalName = slapi_ch_strdup(preferred_principal);
+} else {
+krbPrincipalName = slapi_entry_attr_get_charptr(data->target,
+"krbCanonicalName");
+if (!krbPrincipalName) {
+krbPrincipalName = slapi_entry_attr_get_charptr(data->target,
+"krbPrincipalName");
+}
+if (!krbPrincipalName) {
+*errMesg = "no krbPrincipalName present in this entry\n";
+LOG_FATAL("%s", *errMesg);
+goto enc_error;
+}
}
krberr = krb5_parse_name(krbctx, krbPrincipalName, &princ);
@@ -215,7 +224,7 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg,
if (is_krb) {
-*svals = ipapwd_encrypt_encode_key(krbcfg, data,
+*svals = ipapwd_encrypt_encode_key(krbcfg, data, NULL,
krbcfg->num_pref_encsalts,
krbcfg->pref_encsalts,
errMesg);
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 a910625cea711ca8c564f3c547a1d61788b071be..527238b1b710dfe63d90338ccf806c86c8d9cf6c 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
@@ -661,6 +661,7 @@ static Slapi_Entry *get_entry_by_principal(const char *principal)
Slapi_PBlock *pb = NULL;
char *attrlist[] = { "krbPrincipalKey", "krbLastPwdChange",
"userPassword", "krbPrincipalName",
+ "krbCanonicalName",
"enrolledBy", "objectClass", NULL };
Slapi_Entry **es = NULL;
int res, ret, i;
@@ -1664,7 +1665,7 @@ static int ipapwd_getkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
data.target = target_entry;
data.password = password;
-svals = ipapwd_encrypt_encode_key(krbcfg, &data,
+svals = ipapwd_encrypt_encode_key(krbcfg, &data, service_name,
