On Wed, 02 Oct 2013, Sumit Bose wrote:
Hi,
the attached two patches are a proof-of-concept how we can eliminate the
need to have [capaths] defined in krb5.conf for member domains in
trusted forests together with Alexander's patch 0123.
capaths are used in the core KDC code at two places. One is to validate
transited field in the TGT, this is handled by Alexander's patch.
The other is to find out where to redirect a client asking for a cross
realm TGT for a realm we do not shared credential with but know and
trust a realm which can handle this. This is typically the case for
member domains(realms) in a trusted forest. We share credentials with
the forest root but not with the members but we know that the forest
root can handle requests for its member domains.
The patches are just proof-of-concept because I'm currently not sure if
this is kerberos-wise the right way to handle it. Additionally we might
want to enhance the patches to handle to more broader use case of
transitive-trusts.
Please note that for the time being there is a workaround implemented in
SSSD to add a suitable [capaths] section to the krb5.conf include file
managed by SSSD.
bye,
Sumit
From 73893a102c300627f7977afaf482ee83afc2a161 Mon Sep 17 00:00:00 2001
From: Sumit Bose <[email protected]>
Date: Wed, 2 Oct 2013 11:44:32 +0200
Subject: [PATCH 1/2] ipa-kdb: add transit_realm member to trusted domains
To be able to handle requests for member domains in a trusted forest we
must know which forest the domain belongs to. Because we only share
credentials with the forest root all request for member domains must go
through (transit) the KDC of the forest root. This will also be true for
other forests which are trusted by the forest we trust. But the patch
does not handle this case because it is currently not clear how
transitively trusted forests will be stored in the directory tree.
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 86 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 27d50ac..ce9b06a 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -32,6 +32,7 @@ struct ipadb_adtrusts {
char *domain_name;
char *flat_name;
char *domain_sid;
+ char *transit_realm;
struct dom_sid domsid;
struct dom_sid *sid_blacklist_incoming;
int len_sid_blacklist_incoming;
@@ -2119,6 +2120,7 @@ void ipadb_mspac_struct_free(struct ipadb_mspac **mspac)
free((*mspac)->trusts[i].domain_name);
free((*mspac)->trusts[i].flat_name);
free((*mspac)->trusts[i].domain_sid);
+ free((*mspac)->trusts[i].transit_realm);
free((*mspac)->trusts[i].sid_blacklist_incoming);
free((*mspac)->trusts[i].sid_blacklist_outgoing);
}
@@ -2209,6 +2211,84 @@ done:
return ret;
}
+static int get_transit_realm(LDAP *lc, LDAPMessage *le, char **transit_realm)
+{
+ char *dn_str = NULL;
+ char *val = NULL;
+ LDAPDN dn;
+ int ret;
+ size_t num_vals;
+ char *p;
+
+ dn_str = ldap_get_dn(lc, le);
+ if (dn_str == NULL) {
+ ret = EINVAL;
+ goto done;
+ }
+
+ ret = ldap_str2dn(dn_str, &dn, LDAP_DN_FORMAT_LDAPV3);
+ if (ret != LDAP_SUCCESS) {
+ ret = EINVAL;
+ goto done;
+ }
+
+ for (num_vals = 0; dn != NULL && dn[num_vals] != NULL; num_vals++);
+ if (num_vals < 5) {
We know base dn and trust container, so we can just use the part of the
string before trust container and deal with that only -- if it matches.
This way we would have two DN components available.
The rest looks fine for PoC.
We still need to identify what semantics should be followed by the KDB
method to check transitions. It would be good to support blending of KDB
driver decision and [capaths] tree if it is available to allow easier
handling of MIT Kerberos trusts with IPA for migration/co-existance
purposes: in case of existing MIT Kerberos realm, copying its [capaths]
tree is easy -- add it to IPA KDC's krb5.conf, create cross-realm
principals and everything should start working. Otherwise we would need
to implement special trust type explicitly to re-write existing
[capaths] parser and handler for no real benefit.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
