On (09/01/14 14:10), Sumit Bose wrote:
On Tue, Dec 17, 2013 at 05:18:38PM +0100, Lukas Slebodnik wrote:
> ehlo,
>
> attached patches address ticket #2172
I think you meant #2175?
I meant #2172.
>
> LS
> From e9bc3fa6bd52afc5108e79182f32bb26d2843609 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn(a)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
^^^^^
I changed ticket number.
> ---
> 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.
Fixed
> + break;
> + default:
> return false;
> }
>
> --
> 1.8.4.2
>
> From 3c0de1fd3274f70c7ab27d95a55c72b703808c80 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn(a)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
^^^^^
I changed ticket number.
ACK
> From a374f755b4c1d2fe5860285b973a915b3bacdd23 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik <lslebodn(a)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
Sorry for
mixing ticket numbers.
slice to the given domain. Why can the slice not be calculated
algorithmically?
Problem occurs with id_provider ldap (Active Directory)
Behaviour was changed (regression) in the commit d3e1d88ce7de3216a862b
(in the file src/providers/ldap/ldap_id.c)
id_mapping cannot be detected in ldap provider if ldap_idmap_default_domain_sid
is not configured *and thus* wrong LDAP filter was used.
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.
I confused you with wrong ticket number. Does my solution make sense with
ticket #2172? or should I change behaviour in the file
src/providers/ldap/ldap_id.c (introduced in the commit d3e1d88ce7de3216a862b)
Thank you for review.
Updated patches are attached.
LS