On Thu, May 02, 2013 at 05:23:38PM +0200, Ondrej Kos wrote:
> Hi,
> 
> Attached patch applies on top of Sumit's patchset and addresses bug
> https://fedorahosted.org/sssd/ticket/1568
> 
> When SID is always stored, we are able to use tokengroups in AD even
> with ID mapping option disabled.
> 
> Please, could some native speaker check the manpage change for
> correct wording?
> 
> Ondra
> 
> -- 
> Ondrej Kos
> Associate Software Engineer
> Identity Management
> Red Hat Czech

> From f95950ceae2f1ac9d6758a34ef048c9e7b24c378 Mon Sep 17 00:00:00 2001
> From: Ondrej Kos <o...@redhat.com>
> Date: Thu, 2 May 2013 16:29:20 +0200
> Subject: [PATCH] AD: Always use TokenGroups
> 
> https://fedorahosted.org/sssd/ticket/1568
> 
> Enable TokenGroups for AD provider even when the ID-mapping is disabled.
> ---
>  src/man/include/ldap_id_mapping.xml        | 4 ++++
>  src/providers/ad/ad_init.c                 | 3 ++-
>  src/providers/ldap/sdap_async_initgroups.c | 5 +----
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/src/man/include/ldap_id_mapping.xml 
> b/src/man/include/ldap_id_mapping.xml
> index 
> 71ff248f1f24242b911f615fd6afeb0382dfa5a1..090eefc270e7249b8c5692ae11896bb31d1394fd
>  100644
> --- a/src/man/include/ldap_id_mapping.xml
> +++ b/src/man/include/ldap_id_mapping.xml
> @@ -12,6 +12,10 @@
>          need to use manually-assigned values, ALL values must be
>          manually-assigned.
>      </para>
> +    <para>
> +        NOTE: Full cache wipe is needed when statically-assigned POSIX IDs
> +        change on the AD server side with ID mapping option enabled.
> +    </para>

I think the man page says the exact opposite? If ID mapping is enabled,
then the POSIX IDs are not used at all, so SSSD doesn't care.

>  
>      <refsect2 id='idmap_algorithm'>
>          <title>Mapping Algorithm</title>
> diff --git a/src/providers/ad/ad_init.c b/src/providers/ad/ad_init.c
> index 
> 087ec3c4507adc13be63242f15d5a1a9cd23e26c..48ae9692573cc5cac5c23ba47f6a0b33ce7c51bf
>  100644
> --- a/src/providers/ad/ad_init.c
> +++ b/src/providers/ad/ad_init.c
> @@ -157,7 +157,8 @@ sssm_ad_id_init(struct be_ctx *bectx,
>          goto done;
>      }
>  
> -    if (dp_opt_get_bool(sdap_ctx->opts->basic, SDAP_ID_MAPPING)) {
> +    if (dp_opt_get_bool(sdap_ctx->opts->basic, SDAP_ID_MAPPING) ||
> +        sdap_ctx->opts->schema_type == SDAP_SCHEMA_AD) {
>          /* Set up the ID mapping object */
>          ret = sdap_idmap_init(sdap_ctx, sdap_ctx, 
> &sdap_ctx->opts->idmap_ctx);
>          if (ret != EOK) goto done;
> diff --git a/src/providers/ldap/sdap_async_initgroups.c 
> b/src/providers/ldap/sdap_async_initgroups.c
> index 
> 5a6ba02851be1534cebe7e604573f61a80a62b38..40d8c3e8ae13af5c50abb249afaa2566d8708317
>  100644
> --- a/src/providers/ldap/sdap_async_initgroups.c
> +++ b/src/providers/ldap/sdap_async_initgroups.c
> @@ -2645,8 +2645,6 @@ static void sdap_get_initgr_user(struct tevent_req 
> *subreq)
>      const char *orig_dn;
>      const char *cname;
>      bool in_transaction = false;
> -    bool use_id_mapping =
> -            dp_opt_get_bool(state->opts->basic, SDAP_ID_MAPPING);
>  
>      DEBUG(9, ("Receiving info for the user\n"));
>  
> @@ -2749,8 +2747,7 @@ static void sdap_get_initgr_user(struct tevent_req 
> *subreq)
>              return;
>          }
>  
> -        if (use_id_mapping
> -                && state->opts->dc_functional_level >= DS_BEHAVIOR_WIN2008) {
> +        if (state->opts->dc_functional_level >= DS_BEHAVIOR_WIN2008) {
>              /* Take advantage of AD's tokenGroups mechanism to look up all
>               * parent groups in a single request.
>               */

Nack, that's not what the patch should be doing..

This code path would *still* be using ID mapping. The point of the
change is to read the list of SIDs during initgroups, even if we are not
mapping them to IDs. Then, because we always save the SID to all
group objects now, we would be able to look up the groups from cache
based on the SID coming from tokenGroups without having to look them up
in LDAP (with (&(objeclass=group)(member=USER_DN))).
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to