web-dev-qa-db-ja.com

FreeIPAをLDAPサーバーとして使用するようにGitlabを構成する

実行中の問題が少し発生しましたが、修正できないようです。

以下のシナリオに従ってください。

私は2つのサーバーを持っています：

ONE（10.0.3.10）：Ubuntuベースで、Gitlab（debパッケージとして）が次の構成でインストールされています

/ 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

TWO（10.0.3.100）：Oracle 6.5ベース、FreeIPAがインストールされている

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

問題は次のように聞こえます：

Gitlab Documentation によると、これにより、GitlabでLDAPサーバーのグループをGitlabのグループに関連付けることができるようになります。しかし、これは私の目標ではありません。

FreeIPA内に「developer」という名前のグループを作成しました。これはGitlabログインへのアクセスを許可するグループです。代わりに、どのユーザーでもログインでき、さらにパスワードなしでログインできます。

だから、私の質問は非常に単純です：一体何が間違っているのですか？

9月21日編集

だから...私はgitlabが機能するように部分的に構成することができました。私が自分自身を発見したことのいくつかは、いくつかの@abbraで、役に立ちました。

FreeIPA VMをRHEL6.5からRHEL7に更新し、FreeIPA4.1を使用できるようになりました。

また、私のIPAセットアップは次の形式を取りました。

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

Gitlab configに関しては、次のようになりました（debパッケージを使用して、次のフォームを使用することにしました。これは、上記のフォームとほぼ同じであるはずです）。

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)'

しかし、ログインを機能させることができた場合、フィルタリングはまったく機能せず、まったく手がかりがありません。

誰かが私が間違っていることを知っていますか？

ldapgitlabfreeipa
2
Dragos Cirjan

構成に2つの問題があります。

  1. あまりにも一般的で誤った設定を使用しています：

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

    代わりに、

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

  2. ユーザーのチェックは、間違ったサブツリーに対して行われます。

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

    代わりに、メインサブツリーを使用する必要があります。

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

説明

FreIPAは、ユーザーとグループをcn=accounts,dc=exampleの下のコンテナに保存します。ユーザーの場合はcn=users,cn=accounts,dc=example、グループの場合はcn=groups,cn=accounts,dc=example。この構造で使用されるLDAPスキーマはRFC2307bisに基づいており、メンバーオブジェクトの適切な識別名（DN）を指すmemberOf属性を使用できます。 LDAPで。

FreeIPAはまた、cn=compat,dc=exampleの下に別のツリー（compatサブツリー）を動的にエクスポートして、RFC2307で定義されたLDAPスキーマを期待するクライアントに同じコンテンツを提示します。 RFC2307bisとは異なり、この古いスキーマでは、LDAPのメンバーオブジェクトを識別名で指定することはできません。代わりに、メンバーシップは、メンバーオブジェクトの属性uidの値を使用して指定されます。

ベースdc=exampleを使用してツリー全体を検索すると、両方のサブツリーから応答が返されます。 memberOfフィルタを使用して検索を行うと、cn=accounts,dc=exampleの元のサブツリーには互換性サブツリーへの参照がなく、互換性サブツリーのエントリには参照がないため、結果は空になります。別のLDAPスキーマを使用しているため、memberOf属性。

Compatサブツリーも元のエントリよりも前にエントリを返すため、GitLabは最初に返されたエントリを選択し、必要なすべての属性（電子メールなど）が含まれていないため、ユーザーを検索しようとしたときの結果に混乱します。

最後に、リクエストが認証されていることを確認してください。すでに単純なバインドを使用しているため、これは上記の構成では問題になりませんが、FreeIPA 4.xでは、認証されていない検索リクエストに表示される属性に追加の制限が設けられているため、他の人の時間を節約するために、ここでも言及します。

3
abbra

現在のデータだけに基づいてアドバイスすることは困難です。ラボで括弧が欠落している可能性があります。また、一方のケースではdeveloperグループを参照し、もう一方のケースではdevelopersを参照します。

私がお勧めするのは、テール/var/log/dirsrv/slapd-YOUR-REALM/accessファイル、FreeIPA LDAPサーバーに送信されている実際のLDAPクエリとは何か、LDAPの回答とは何かを確認し、これらの結果に基づいてgitlab構成を更新します。

1
Martin Kosek