開発環境の認証を改善してRedmine を社内標準にした話

2016/11/26 redmine.tokyo 第 11 回勉強会Ryou Soda 　

• 自己紹介

• 弊社の Redmine 環境

• 以前の開発環境

• LDAP＋ AD認証環境構築• 動作確認

• 現在の開発環境

• おわりに

目次

蘇田　亮（ソダ　リョウ）　 @ryouma_nagare札幌に本社があるシステム開発ベンダーの東京事業所に勤務。

Linux 歴は FM-TOWNS から始まり 20 年を越えました。好きなディストリビューションはVineLinux 。

サーバ／ DB 系が得意。オープン系の Web アプリの基盤／設計がメインでしたが、１年ほど前にインフラ系の部署に強引に異動。運用／監視業務は嫌いですが、基盤を作るのは好きです。

Redmine 歴は 4 年ぐらい。

趣味はポケコン、 Palm などの古いガジェット収集。

自己紹介

弊社の Redmine 環境

4 コア／８ GB の仮想サーバで運用中

その他にテスト用として 3.2 、 3.3 の計３インスタンスを運用中。個人的な好みで、 unicorn ＋ nginxで動かしています。

CentOS7.2 ＋ Redmine2.6 がメイン

→ 標準のガントチャートにはもう戻れません

LycheeREDMINE を導入しています

使い方の例 － 工数管理

→WorkTime プラグインにお世話になりっぱなし

案件の掛け持ちや間接稼働が多い部署のため、

• 工数管理専用のプロジェクトを作成• 案件＝チケットとして工数入力しています。

使い方の例 － パートナー社員の契約管理

社外常駐者もいるため、全員の契約状況把握のために

• バージョン＝会社名、親チケット＝人名、子チケット＝１契約• 開始日～期日＝契約期間• カテゴリ＝契約のステータスとして管理しています。

最近、ラズパイ３にも入れましたRedmine3.3 をPassenger ＋ Apache で動かしています。Zabbix のアラートの他、リポジトリのコミット時に LEDを点滅させて遊んでいます。

実用性は求めていませんｗ

以前の開発環境

社員数の都合上、プロジェクトはパートナー社員を含めた体制で進めることが多いが、受入時に会社がするのは、

統括会社へ申請して社員 ID 発行メールアドレス発行NW 検疫のアカウント発行で全て。

会社がすること

→ 統括会社の AD には登録されるらしいが、開発環境からは見えない

VPN

ファイルサーバ

社員アカウントだけ

各種開発サーバ等

リポジトリ、 BTS などすべてローカル認証。

ID は社員番号、メアドなどバラバラ…

当然、こんな状況に

社員アカウント

自前で LDAP を構築してパートナー社員アカウント

を登録

とりあえず自分のプロジェクトだけでも

→Apache 、 subversion等が対応できない。

だが、参照先が２つなのは不便

→LDAP をエンドポイントとして両方引くしかない！

社員アカウントパートナー社員アカウント

解決するには

LDAP＋ AD認証環境構築

一つのツリーに見せかけるため、 LDAP を AD のサブドメインとして定義。

AD： dc=ZZZ,dc=localユーザ DN： cn=[漢字フルネーム ],OU=OU_Users,dc=ZZZ,dc=local 　という超セン

スのない定義。

LDAP： dc=YYY,dc=ZZZ,dc=local

ドメイン定義

自分のアカウントで AD を検索すると、パスワード変更のたびに LDAP の設定変更が必要になってしまうので、

パスワード期限なし検索権限のみの AD アカウントを要求。

検索用アカウントを作成

→ 裏から手を回した。 AD の管理者に直接交渉。

　　社内で協力してもらったのはこれだけ。

日本語での情報が見あたらず、たどり着いた Linuxtopia のページと、

最終的には OpenLDAP の関連ファイルを man する

ことで必要な情報を得た。

検索ワード： "Linuxtopia LDAP Administration Chaining"

情報の入手

→ 最初から標準ドキュメントを見るべきでした

→ ログイン名属性は AD に合わせるしかない

ActiveDirectory OpenLDAP

問題： AD と LDAP の属性差異

# OpenLDAP User schema

objectclass ( 1.1.2.2.1

NAME 'PartnerObject'

DESC 'Partner Object'

SUP 'inetOrgPerson'

STRUCTURAL

MUST ( sAMAccountName ) )

→sAMAccountName に uid と同じ値をセットする。　　※ AD のスキーマ定義も LDAP に登録する必要があります。

解決策： inetOrgPerson スキーマを拡張

DN のフォーマットは

sAMAccountName=[ アカウント名 ],ou=[ 会社名 ],ou=partner,dc=YYY,dc=ZZZ,dc=local

ActiveDirectory OpenLDAP

社員アカウント

パートナー社員アカウント

問題：ツリーを一つに見せる必要がある

dn: ou=XXX,dc=YYY,dc=ZZZ,dc=localchangetype: addobjectClass: topobjectClass: organizationalUnitou: XXX

dn: cn=proxy,ou=XXX,dc=YYY,dc=ZZZ,dc=localobjectClass: referralobjectClass: extensibleObjectdc: AAATreecn: proxyref: ldap://[AD の IP]/ou=OU_Users,dc=YYY,dc=local

解決策： referral オブジェクトを作成

OpenLDAP ActiveDirectory

見えた

chain-uri "ldap://[AD の IP]/"chain-rebind-as-user truechain-idassert-bind bindmethod="simple" binddn="[AD 検索ユーザーの DN]" credentials="[ パスワード ] " mode="legacy" flags="non-prescriptive"chain-acl-bind bindmethod="simple" binddn="[AD 検索ユーザーの DN]" credentials="[ パスワード ]"

AD 検索アカウントの DN

slapd.conf ー referral をたどる

# For Proxydatabase ldapchase-referrals nosuffix "dc=ZZZ,dc=local"uri ldap://[AD の IP]/acl-bind bindmethod="simple" binddn="[AD 検索ユーザーの DN]" credentials="[ パスワード ] "idassert-bind bindmethod="simple" binddn="[AD 検索ユーザーの DN]" credentials="[ パスワード ]" mode="legacy" flags="non-prescriptive"

AD のドメインがサーチベースの場合、AD のみを検索する

slapd.conf ー LDAP をプロキシとして AD 検索

動作確認

$ ldapsearch -x -h [LDAPの IP] -D "[LDAP検索ユーザーの DN]" -w'[パスワード ]' \ -b "dc=YYY,dc=ZZZ,dc=local" \ "(sAMAccountName=[社員 ID])" \ "sAMAccountName" "mail"

dn:: Y2496JiH55Sw5LquLG91PU9VX1VzZXJzLGRjPXRhZHMsZGM9bG9jYWw=sAMAccountName: [社員 ID]mail: [社員のメアド ]@ZZZ.co.jp

検索結果あり

LDAP のサブドメインで社員アカウント検索

$ ldapsearch -x -h [LDAPの IP] -D "[LDAP検索ユーザーの DN]" -w'[パスワード ]' \ -b "dc=YYY,dc=ZZZ,dc=local" \ "(sAMAccountName=[パートナー ID])" \ "sAMAccountName" "mail"

dn: sAMAccountName=[パートナー ID],ou=[会社名 ],ou=partner,dc=YYY,dc=ZZZ,dc=localsAMAccountName: [パートナー ID]mail: [パートナーのメアド ]@ZZZ.co.jp

LDAP のサブドメインでパートナーアカウント検索

検索結果あり

$ ldapsearch -x -h [LDAPの IP] -D "[LDAP検索ユーザーの DN]" -w'[パスワード ]' \ -b "dc=ZZZ,dc=local" \ "(sAMAccountName=[社員 ID])" \ "sAMAccountName" "mail"

dn:: Y2496JiH55Sw5LquLG91PU9VX1VzZXJzLGRjPXRhZHMsZGM9bG9jYWw=sAMAccountName: [社員 ID]mail: [社員のメアド ]@ZZZ.co.jp

AD のドメインで社員アカウント検索

検索結果あり

$ ldapsearch -x -h [LDAPの IP] -D "[LDAP検索ユーザーの DN]" -w'[パスワード ]' \ -b "dc=ZZZ,dc=local" \ "(sAMAccountName=[パートナー ID])" \ "sAMAccountName" "mail"

→ すべて希望通りの結果

AD のドメインでパートナーアカウント検索

検索結果なし

現在の開発環境

参照先が一つになったので

周辺のツールが相乗り可能に

subversion 　－　 SASL経由で LDAP 認証

GitBucket 　 －　デフォルトで LDAP対応Apache 　－　 mod_authz_ldap で BASIC 認証のデータソースを LDAP

に

Let‘s Chat －　 LDAP対応の OSS チャット

WordPress 　－　 LDAP でセルフサインアップを可能に

phpLDAPadmin －　受入部署やパートナー自身の管理用 GUI

周辺ツール

→LDAP に対応しないツールは基本的に使わない

　　ようになった

おわりに

自分が使っていた Redmine をベースとして社内標準にした。

アカウント統一によって Redmine のリポジトリ設定でマッピングが不要になった。

パートナー社員受入時のワークフローに LDAP アカウント作成が組み込まれた。 ただし、各 PJ の申告次第

phpLDAPadmin を提供したことでアカウントのメンテナンスから解放された。 パスワード忘れは事務方で対応

チャット、社内向けの技術系ブログを始めたことで、情報がやりとりしやすくなった。 ローカルアカウントを作成しなくてよくなったので、参加のハードルが下がった Redmine のメンテナンス周知や、技術的な問い合わせがスピードアップ

よかったこと

→ 自分にとってはメリットがいっぱいあったが、

Redmine をうまく活用できずに、炎上プロジェクトが発生。

野良 Redmine 、野良リポジトリは相変わらず LDAP を使ってくれない。 社内共通の subversion もローカル認証のまま…

LDAP で参加のハードルを下げてもログインのみにとどまる社員が多い。 チャットも ROM 専が多い

30代半ば～後半くらいのリーダークラスが従来のやり方を変えることに消極的。 若手の社員はあまり抵抗がない

現在の問題

→周囲にはそれほどでもなかったらしい。

LDAP を導入することで、ログインのハードルは下がったが、なかなかアクティブになってくれない。

もともとアクティブだった社員はよりアクティブになったので、温度差が広がってしまった。

今後は Redmine を中心にアクティブな社員を増やすべく、行動を解析していきたいが、そこまで努力する必要があるか？と考えてしまって、だいぶ心が折れています…

反省

監視中

→ アクティブでない社員の解析はできないので、単なる趣味…

手順／設定等は Qiita で

http://qiita.com/ryouma_nagare/items/bcda4c372347ed83fe7c

ご静聴ありがとうございました