On Wed, 2012-10-24 at 10:57 +0200, Sumit Bose wrote:
> From 13ff428b862b90fcbe2eb697565854442d489042 Mon Sep 17 00:00:00 2001
> From: Sumit Bose <sb...@redhat.com>
> Date: Tue, 9 Oct 2012 21:16:41 +0200
> Subject: [PATCH 02/18] s2n: save user principal name of sub-domain
> user
>
> If a sub-domain user of a IPA is looked up via the LDAP extdom
> extended
> operation we also add a generated user principal name to the cached
> entry. This can be used e.g. for password authentication later on.
> ---
> src/providers/ipa/ipa_s2n_exop.c | 33
> ++++++++++++++++++++++++++++++++-
> 1 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/src/providers/ipa/ipa_s2n_exop.c
> b/src/providers/ipa/ipa_s2n_exop.c
> index 004cdab..a5e23fb 100644
> --- a/src/providers/ipa/ipa_s2n_exop.c
> +++ b/src/providers/ipa/ipa_s2n_exop.c
> @@ -585,6 +585,9 @@ static void ipa_s2n_get_user_done(struct
> tevent_req *subreq)
> time_t now;
> uint64_t timeout = 10*60*60; /* FIXME: find a better timeout ! */
> const char *homedir = NULL;
> + char *uc_realm;
> + char *upn;
> + struct sysdb_attrs *user_attrs;
>
> ret = ipa_s2n_exop_recv(subreq, state, &result, &retoid,
> &retdata);
> talloc_zfree(subreq);
> @@ -627,11 +630,39 @@ static void ipa_s2n_get_user_done(struct
> tevent_req *subreq)
> }
> }
>
> + uc_realm = get_uppercase_realm(state, state->dom->name);
> + if (uc_realm == NULL) {
> + DEBUG(SSSDBG_OP_FAILURE, ("get_uppercase_realm
> failed.\n"));
> + ret = ENOMEM;
> + goto done;
> + }
> +
> + upn = talloc_asprintf(state, "%s@%s",
> attrs->a.user.pw_name,
> + uc_realm);
> + if (upn == NULL) {
> + DEBUG(SSSDBG_OP_FAILURE, ("talloc_asprintf
> failed.\n"));
> + ret = ENOMEM;
> + goto done;
> + }
If this operation is done after inspecting a MS-PAC shouldn't we use the
principal that comes with it ?
For AD domains especially that is important because AD domains can use a
UPN that differs from the actual username + uppercase(domain).
I am ok acking this as is for now as a short term solution but only if
you open a ticket to track this and fix it in the next cycle.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
