Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: On Wed, 11 Sep 2013, Simo Sorce wrote: On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). I'm already searching on cn=REALM.NAME,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) 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
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On 09/20/2013 09:23 AM, Tomas Babej wrote: On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: On Wed, 11 Sep 2013, Simo Sorce wrote: On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). I'm already searching on cn=REALM.NAME,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) ACK Pushed to: master: a9843d6918f73c2236d0083b1e8adf54ca34eb0d ipa-3-3: de5ec4fbd916c52e7474f1e4dae3b69c80eb497a -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). 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] 0114 ipa-sam: fix setting encryption type for trust object already created
On Wed, 11 Sep 2013, Simo Sorce wrote: On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). I'm already searching on cn=REALM.NAME,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On Sat, 07 Sep 2013, Simo Sorce wrote:
On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote:
On Sat, 07 Sep 2013, Simo Sorce wrote:
On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote:
On Sat, 07 Sep 2013, Simo Sorce wrote:
On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote:
+ enctypes = KERB_ENCTYPE_DES_CBC_CRC |
+ KERB_ENCTYPE_DES_CBC_MD5 |
+ KERB_ENCTYPE_RC4_HMAC_MD5 |
+ KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 |
+ KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96;
Why are we hardcoding support for *DES* enctype, we disable DES by
default and also Windows never uses it by default.
This is actually a copy of the same statement from
fill_pdb_trusted_domain().
Should I remove it?
Yes please remove DES types, is there any chance we can make this list
configurable ? (not a hard requirement, only if ti is something easy to
do, maybe as a further enhancement down the road).
If you can point me to some place in cn=config or $SUFFIX that could be
read by cifs/fqdn on ipa-sam module init, I can look in fetching that.
But I suspect it is much harder to deduce exact list of supported types.
Look in:
cn=REALM.NAME,cn=kerberos,$SUFFIX
there we have 2 lists:
krbDefaultEncSaltTypes - use this
krbSupportedEncSaltTypes
in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples()
that can covert strings to enctypes.
RC4 enctype will be the only one available for
Windows 2003 trusts then...
It's the only one 2003 enables by default anyway and the only one that
we can use as DES is disabled on FreeIPA.
Since admin could enable DES on FreeIPA manually, right now ipa-sam
would allow using DES to Windows 2003. If we remove DES enctypes
unconditionally, it would not be possible.
If you look at the attributes I pointed you at above, then you have a
way to support DES by simply changing the defaults and restarting
FreeIPA.
DES is dead anyway and not sufficiently secure for cross-realm keys
anymore, even if we do not support it at all I think we are just fine.
Ok, attached three patches 0114-0116 is a new revision that implements also
fetching encryption types from the Kerberos configuration container.
The patches depend on each other in that order.
--
/ Alexander Bokovoy
From 875c3f5dff578962352fe3673b3a6bcf82014976 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: do not modify objectclass when 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 object classes in trust object entry
which is not allowed by ACI.
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.
---
daemons/ipa-sam/ipa_sam.c| 112 +--
install/updates/60-trusts.update | 1 +
ipaserver/dcerpc.py | 9
3 files changed, 81 insertions(+), 41 deletions(-)
diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 4a2fca5..cf39bb9 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,
-
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. 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] 0114 ipa-sam: fix setting encryption type for trust object already created
On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? RC4 enctype will be the only one available for Windows 2003 trusts then... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. 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] 0114 ipa-sam: fix setting encryption type for trust object already created
On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
