[SSSD] [PATCHES] MAN: Describe change in idmapping with ldap provider

Sumit Bose sbose at redhat.com
Thu Jan 9 13:10:19 UTC 2014


On Tue, Dec 17, 2013 at 05:18:38PM +0100, Lukas Slebodnik wrote:
> ehlo,
> 
> attached patches address ticket #2172

I think you meant #2175?

> 
> LS

> From e9bc3fa6bd52afc5108e79182f32bb26d2843609 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn at redhat.com>
> Date: Fri, 13 Dec 2013 15:33:23 +0100
> Subject: [PATCH 1/3] sdap_idamp: Fall back to another method if sid is wrong
> 
> sss_idmap_domain_has_algorithmic_mapping can return also
> IDMAP_SID_UNKNOWN, but it does not mean that idmaping is
> unavailable. We should fall back to another method of detection
> (sss_idmap_domain_by_name_has_algorithmic_mapping)
> and do not return false immediately.
> 
> Resolves:
> https://fedorahosted.org/sssd/ticket/2175
> ---
>  src/providers/ldap/sdap_idmap.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/providers/ldap/sdap_idmap.c b/src/providers/ldap/sdap_idmap.c
> index 871b8e0bf2357b1dde3f179bb6dba3d5e7537413..c2c98ae3cc089c5431de072a07403c2b5c3eb273 100644
> --- a/src/providers/ldap/sdap_idmap.c
> +++ b/src/providers/ldap/sdap_idmap.c
> @@ -522,9 +522,15 @@ bool sdap_idmap_domain_has_algorithmic_mapping(struct sdap_idmap_ctx *ctx,
>  
>      err = sss_idmap_domain_has_algorithmic_mapping(ctx->map, dom_sid,
>                                                     &has_algorithmic_mapping);
> -    if (err == IDMAP_SUCCESS) {
> +    switch (err){
> +    case IDMAP_SUCCESS:
>          return has_algorithmic_mapping;
> -    } else if (err != IDMAP_SID_UNKNOWN && err != IDMAP_NO_DOMAIN) {
> +    case IDMAP_SID_INVALID: /* FALLTHROUGH */
> +    case IDMAP_SID_UNKNOWN: /* FALLTHROUGH */
> +    case IDMAP_NO_DOMAIN:   /* FALLTHROUGH */
> +        /* continue with idmap_domain_by_name */

I agree with the change but in the commit message you say
'IDMAP_SID_UNKNOWN' but you add 'IDMAP_SID_INVALID' here. So the commit
messages should be changed.

> +        break;
> +    default:
>          return false;
>      }
>  
> -- 
> 1.8.4.2
> 

> From 3c0de1fd3274f70c7ab27d95a55c72b703808c80 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn at redhat.com>
> Date: Fri, 13 Dec 2013 18:20:08 +0100
> Subject: [PATCH 2/3] LDAP: Don't fail if subdomain cannot be found by sid
> 
> Domain needn't contain sid if id_provider is ldap.
> With enabled id mapping, user couldn't be stored, because domain
> couldn't be found by sid.
> 
> Resolves:
> https://fedorahosted.org/sssd/ticket/2175

ACK

> From a374f755b4c1d2fe5860285b973a915b3bacdd23 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn at redhat.com>
> Date: Tue, 17 Dec 2013 17:03:50 +0100
> Subject: [PATCH 3/3] MAN: Describe change in id mapping with ldap provider
> 
> ID mapping could be configured with id_provider ldap only with
> enabling option ldap_id_mapping. This behaviour was changed
> in the commit d3e1d88ce7de3216a862b
> "LDAP: Require ID numbers when ID mapping is off"
> 
> ldap_idmap_default_domain_sid need to be also configured since that change.
> 
> Resolves:
> https://fedorahosted.org/sssd/ticket/2172
> ---
>  src/man/sssd-ldap.5.xml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/man/sssd-ldap.5.xml b/src/man/sssd-ldap.5.xml
> index 72586fb1d97037ebd43a737c2a0394bcd652bac9..7a2ab60e067999847795983e1d551cbf62faad9a 100644
> --- a/src/man/sssd-ldap.5.xml
> +++ b/src/man/sssd-ldap.5.xml
> @@ -1428,6 +1428,10 @@
>                              ActiveDirectory objectSID mapping.
>                          </para>
>                          <para>
> +                            The option ldap_idmap_default_domain_sid need to be
> +                            configured for id mapping with ldap provider.
> +                        </para>
> +                        <para>
>                              Default: false
>                          </para>
>                      </listitem>
> -- 
> 1.8.4.2
> 

I do not understand the reason for this. First I think the ticket number
is wrong. Second ldap_idmap_default_domain_sid is only used to assign a
slice to the given domain. Why can the slice not be calculated
algorithmically?

What is needed when using ldap_id_mapping=True with the plain LDAP
provider is ldap_user_primary_group. The reason is that
ldap_id_mapping=True assumes that the POSIX ID of the primary group must
be calculated from a SID as well. To get this SID the numerical value
from the attribute given by ldap_user_primary_group is used as the RID
of the primary group. Then the domain SID from the user SID is
prepended and the POSIX GID is calculated from the resulting SID. By
default ldap_user_primary_group is not set for the LDAP provider and
hence lookup fail.

bye,
Sumit

> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list