Configure o Gitlab para usar o FreeIPA como servidor LDAP

Question

Estou correndo para um pouco de dificuldade e não consigo consertar isso.

Por favor, siga o cenário abaixo:

Eu tenho dois servidores:

ONE (10.0.3.10): baseado no Ubuntu, tendo o Gitlab (como pacote deb) instalado com a seguinte configuração

/etc/gitlab/gitlab.rb

# The URL through which GitLab will be accessed.
external_url "https://gitlab.example.com/"

# Whether to redirect http to https.
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/ssl/my-ssl/ssl-unified.crt"
nginx['ssl_certificate_key'] = "/etc/ssl/my-ssl/ssl.key"

# The directory where Git repositories will be stored.
git_data_dir "/var/opt/gitlab/git-data"


gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
  ## label
  #
  # A human-friendly name for your LDAP server. It is OK to change the label later,
  # for instance if you find out it is too large to fit on the web page.
  #
  # Example: 'Paris' or 'Acme, Ltd.'
  label: 'LDAP'

  host: '10.0.3.100'
  port: 389
  #uid: 'sAMAccountName'
  uid: 'uid'
  method: 'plain' # "tls" or "ssl" or "plain"
  bind_dn: 'uid=gitlab_ldap,cn=users,cn=accounts,dc=example'
  password: 'test'

  # This setting specifies if LDAP server is Active Directory LDAP server.
  # For non AD servers it skips the AD specific queries.
  # If your LDAP server is not AD, set this to false.
  #active_directory: true

  # If allow_username_or_email_login is enabled, GitLab will ignore everything
  # after the first '@' in the LDAP username submitted by the user on login.
  #
  # Example:
  # - the user enters '[email protected]' and 'p@ssw0rd' as LDAP credentials;
  # - GitLab queries the LDAP server with 'jane.doe' and 'p@ssw0rd'.
  #
  # If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
  # disable this setting, because the userPrincipalName contains an '@'.
  allow_username_or_email_login: true

  # To maintain tight control over the number of active users on your GitLab installation,
  # enable this setting to keep new users blocked until they have been cleared by the admin
  # (default: false).
  block_auto_created_users: false

  # Base where we can search for users
  #
  #   Ex. ou=People,dc=gitlab,dc=example
  #
  base: 'dc=example'
  group_base: 'OU=groups,DC=example'

  # Filter LDAP users
  #
  #   Format: RFC 4515 http://tools.ietf.org/search/rfc4515
  #   Ex. (employeeType=developer)
  #
  #   Note: GitLab does not support omniauth-ldap's custom filter syntax.
  #
  #user_filter: ''
  user_filter: 'memberOf=cn=developers,cn=groups,cn=compat,dc=example'

# GitLab EE only: add more LDAP servers
# Choose an ID made of a-z and 0-9 . This ID will be stored in the database
# so that GitLab can remember which LDAP server a user belongs to.
# uswest2:
#   label:
#   host:
#   ....
EOS

DOIS (10.0.3.100): baseado em Oracle 6.5, tendo o FreeIPA instalado

ipa-server-install -U -r EXAMPLE -n example.com --hostname=ipa.example.com -p FreeIPAAll -a FreeIPAAll

O problema é assim:

De acordo com Documentação do Gitlab , isso deve permitir que o Gitlab permita que eu associe grupos do servidor LDAP a grupos de Gitlab. No entanto, esse não é meu objetivo.

Eu criei um grupo dentro do FreeIPA, chamado 'desenvolvedor', que deve ser o único que dá acesso ao login do Gitlab. Em vez disso, eu posso entrar com qualquer usuário, mais eu posso fazer o login sem senha.

Então, minha pergunta é bem simples: o que diabos eu estou fazendo de errado?

Editar 21 de setembro

Então ... consegui configurar parcialmente o gitlab para funcionar. Algumas das coisas que eu descobri, com alguns @abbra, foram mais que úteis.

Consegui atualizar minha VM FreeIPA do RHEL 6.5 para o RHEL 7, agora com o FreeIPA 4.1.

Além disso, minha configuração de IPA tomou o seguinte formato:

ipa-server-install -U -r EXAMPLE -n example.local --hostname=ipa.example.lo -p FreeIPAAll -a FreeIPAAll

Quanto ao gitlab config, ficou assim (usando o pacote deb, decidi usar o seguinte formulário, que deve ser o mesmo com o formulário acima).

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = '10.1.3.100'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'uid'
gitlab_rails['ldap_method'] = 'plain' # 'ssl' or 'plain'
gitlab_rails['ldap_bind_dn'] = 'cn=users,cn=accounts,dc=example,dc=local'
gitlab_rails['ldap_password'] = ''
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'cn=accounts,dc=example,dc=local'
gitlab_rails['ldap_group_base'] = 'cn=groups,cn=accounts,dc=example,dc=local'
#gitlab_rails['ldap_user_filter'] = '(memberOf=cn=gitlab,cn=groups,cn=accounts,dc=example,dc=local)'

No entanto , se consegui fazer o login funcionar, a filtragem não funciona de todo e estou totalmente sem pistas.

Alguém tem alguma ideia do que estou fazendo de errado?

    

Answer 1

Você tem dois problemas em sua configuração:

1. Você está usando configurações muito genéricas e incorretas:

   base: 'dc=example'
   group_base: 'OU=groups,DC=example'
   

   Em vez disso, eles devem ser

   base: 'cn=accounts,dc=example'
   group_base: 'cn=groups,cn=accounts,DC=example'
   

2. Sua verificação para usuários é feita contra subárvore incorreta:

   user_filter: 'memberOf=cn=developers,cn=groups,cn=compat,dc=example'
   

   Em vez disso, você deve usar a subárvore principal:

   user_filter: 'memberOf=cn=developers,cn=groups,cn=accounts,dc=example'
   

Explicação

O FreIPA armazena usuários e grupos nos contêineres em cn=accounts,dc=example , por exemplo, cn=users,cn=accounts,dc=example para usuários e cn=groups,cn=accounts,dc=example para grupos.O esquema LDAP usado por essa estrutura é baseado no RFC2307bis que permite usar o atributo memberOf apontando para o nome distinto (DN) apropriado de um objeto membro no LDAP.

FreeIPA também exporta dinamicamente uma árvore separada (subárvore compat) sob cn=compat,dc=example para apresentar o mesmo conteúdo para clientes que esperam um esquema LDAP definido em RFC2307. Ao contrário do RFC2307bis, esse esquema mais antigo não permite especificar um objeto membro no LDAP por seu nome distinto. Em vez disso, uma associação é especificada usando o valor de um atributo uid do objeto membro.

Quando você pesquisa na árvore inteira usando a base dc=example , obtém respostas das duas subárvores. Quando você pesquisa com memberOf filter, ele virá com um resultado vazio porque a subárvore original em cn=accounts,dc=example não possui nenhuma referência à subárvore compat e as entradas na subárvore compat não têm memberOf do atributo para usar um esquema LDAP diferente.

A subárvore compat também está retornando suas entradas antes das originais, portanto, o GitLab fica confuso com o resultado ao tentar pesquisar um usuário, pois ele seleciona uma primeira entrada retornada e não contém todos os atributos necessários (como e-mail).

Por fim, verifique se suas solicitações estão autenticadas. Este não é um problema com a sua configuração acima, porque você já está usando uma ligação simples, mas o FreeIPA 4.x colocou limitações adicionais em quais atributos são visíveis para solicitações de busca não autenticadas, então para salvar o tempo de outras pessoas eu também mencionaria aqui .

    

Answer 2

É difícil aconselhar com base apenas nos dados atuais. Pode estar faltando parênteses em seu laboratório, também em um caso você se refere a developer group e a developers no outro.

O que eu recomendo é seguir o arquivo /var/log/dirsrv/slapd-YOUR-REALM/access , ver qual é a consulta LDAP real enviada ao servidor LDAP FreeIPA, qual é a resposta LDAP e atualizar a configuração do gitlab com base nessas descobertas.