LDAP multi-domain group sync issues

LDAP multi-domain group sync issues

Customer notes

Customer have a GitLab group, RETRACTEDGROUP, linked to an LDAP group in the RETRACTEDDOMAIN domain called RETRACTEDGROUP.

The LDAP group has members from two domains, OTHERRETRACTEDDOMAIN andRETRACTEDDOMAIN, but only the members from the RETRACTEDDOMAIN domain show up as members.

The OTHERRETRACTEDDOMAIN user, retracteduser, which has a GitLab account, doesn't show up as part of any groups. I started this yesterday, so cached LDAP results should be current.
Do you know why the retracteduser user is not showing up as a member of the RETRACTEDGROUP GitLab group?

Suspected Bug

Customer have found that this problem is due to issues with the Rails part of GitLab. For example, in access.rb, there is this function:

  def gitlab_groups_with_ldap_link

    ::Group.includes(:ldap_group_links).references(:ldap_group_links). 
      where.not(ldap_group_links: { id: nil }). 
      where(ldap_group_links: { provider: provider }) 
  end

which generates a SQL query to the underlying Postgres database like so:

SELECT "namespaces"."id" AS t0_r0, "namespaces"."name" AS t0_r1, "namespaces"."path" AS t0_r2, "namespaces"."owner_id" AS t0_r3, "namespaces"."created_at" AS t0_r4, "namespaces"."updated_at" AS t0_r5, "namespaces"."type" AS t0_r6, "namespaces"."description" AS t0_r7, "namespaces"."avatar" AS t0_r8, "namespaces"."membership_lock" AS t0_r9, "ldap_group_links"."id" AS t1_r0, "ldap_group_links"."cn" AS t1_r1, "ldap_group_links"."group_access" AS t1_r2, "ldap_group_links"."group_id" AS t1_r3, "ldap_group_links"."created_at" AS t1_r4, "ldap_group_links"."updated_at" AS t1_r5, "ldap_group_links"."provider" AS t1_r6 FROM "namespaces" LEFT OUTER JOIN "ldap_group_links" ON "ldap_group_links"."group_id" = "namespaces"."id" WHERE "namespaces"."type" IN ('Group') AND ("ldap_group_links"."id" IS NOT NULL) AND "ldap_group_links"."provider" = 'ldapmain'  ORDER BY "namespaces"."created_at" DESC, "namespaces"."id" DESC

In particular, the "ldap_group_links"."provider" = 'ldapmain' limits the ldap groups that are returned to just the ones in the user's domain. Fixing this part of the code doesn't resolve the issue, so perhaps you can look into this further for me, now that you have a place to start?

Additional information can be found on the ZD ticket linked below

cc// @dblessing @stanhu

This may also be referred to as AD 'trusted domains'. @MrChrisW linked the following articles in gitlab-org/gitlab-ee#1326 :

• https://technet.microsoft.com/en-us/library/cc961481.aspx
• https://technet.microsoft.com/en-us/library/cc783351(v=ws.10).aspx
• https://en.wikipedia.org/wiki/Active_Directory#Trusting
• http://stackoverflow.com/questions/5051381
• http://stackoverflow.com/questions/3161566

---

ZD: https://gitlab.zendesk.com/agent/tickets/26491

@jacobvosmaer-gitlab Looping you in here since Drew is out. I noticed that gitlab_groups_with_ldap_link is present in 8.5 but gone in subsequent versions. Did !229 (merged) address this particular issue?

This is not something we've supported in the past (as far as I can tell) and definitely not in the new group sync. We're assuming that two configured LDAP servers have no overlap, while in this customer's case, they do. My initial thought is that supporting this will be non-trivial - or will at least take lots of testing to ensure we don't break something else.

Give me some time to think over it some more. I look forward to @jacobvosmaer-gitlab thoughts, too.

If I remember correctly, 'two domains' means two 'providers' as far as GitLab is concerned. The LDAP group sync algorithm we use assumes we can break down the work per provider. This has been the case ever since we introduced 'multiple provider' support and it stayed the case during the recent big LDAP group sync refactor.

Probably this user gets unlucky because we first process the provider according to whom they belong in the group, and then the provider according to whom they do not, leaving them outside the group as an end result.

This could be changed, with the current group sync more so than with what we had before. But it would be tricky and the end result would be more complicated than what we have now.

@jacobvosmaer-gitlab You're right.

If we could:

1. Properly support LDAP failover.
2. Allow multiple base DNs

it would go a long way. The first point is relatively easy and we have an issue for it. The second is not so trivial, I am guessing.

mentioned in issue #666

Mentioned in issue #1326