開発環境の認証を改善して
Redmineを社内標準にした話
2016/11/26 redmine.tokyo 第11回勉強会
Ryou Soda
• 自己紹介
• 弊社のRedmine環境
• 以前の開発環境
• LDAP+AD認証環境構築
• 動作確認
• 現在の開発環境
• おわりに
目次
 蘇田 亮(ソダ リョウ) @ryouma_nagare
 札幌に本社があるシステム開発ベンダーの東京事業所に勤務。
 Linux歴はFM-TOWNSから始まり20年を越えました。好きなディストリビューションはVineLinux。
 サーバ/DB系が得意。オープン系のWebアプリの基盤/設計がメインでしたが、1年ほど前にインフラ系の部
署に強引に異動。運用/監視業務は嫌いですが、基盤を作るのは好きです。
 Redmine歴は4年ぐらい。
 趣味はポケコン、Palmなどの古いガジェット収集。
自己紹介
弊社のRedmine環境
4コア/8GBの仮想サーバで運用中
その他にテスト用として3.2、3.3の
計3インスタンスを運用中。
個人的な好みで、unicorn+nginxで動
かしています。
CentOS7.2+Redmine2.6がメイン
→標準のガントチャートにはもう戻れません
LycheeREDMINEを導入しています
使い方の例 - 工数管理
→WorkTimeプラグインにお世話になりっぱなし
案件の掛け持ちや間接稼働が多い部署のため、
• 工数管理専用のプロジェクトを作成
• 案件=チケットとして工数入力
しています。
使い方の例 - パートナー社員の契約管理
社外常駐者もいるため、全員の契約状況把握のために
• バージョン=会社名、親チケット=人名、子チケット=1契約
• 開始日~期日=契約期間
• カテゴリ=契約のステータス
として管理しています。
最近、ラズパイ3にも入れました
Redmine3.3をPassenger+
Apacheで動かしています。
Zabbixのアラートの他、リポジト
リのコミット時にLEDを点滅させて
遊んでいます。
実用性は求めていませんw
以前の開発環境
社員数の都合上、プロジェクトはパートナー社員を含めた体制で進める
ことが多いが、受入時に会社がするのは、
統括会社へ申請して社員ID発行
メールアドレス発行
NW検疫のアカウント発行
で全て。
会社がすること
→統括会社のADには登録されるらしいが、開発環境から
は見えない
VPN
ファイルサーバ
社員アカウントだけ
各種開発サーバ等
 リポジトリ、BTSなどすべてローカル認証。
 IDは社員番号、メアドなどバラバラ…
当然、こんな状況に
社員アカウント
自前でLDAPを構築してパート
ナー社員アカウントを登録
とりあえず自分のプロジェクトだけでも
→Apache、subversion等が対応できない。
だが、参照先が2つなのは不便
→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=local
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: XXX
dn: cn=proxy,ou=XXX,dc=YYY,dc=ZZZ,dc=local
objectClass: referral
objectClass: extensibleObject
dc: AAATree
cn: proxy
ref: ldap://[ADのIP]/ou=OU_Users,dc=YYY,dc=local
解決策:referralオブジェクトを作成
OpenLDAP ActiveDirectory
見えた
chain-uri "ldap://[ADのIP]/"
chain-rebind-as-user true
chain-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 Proxy
database ldap
chase-referrals no
suffix "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=local
sAMAccountName: [パートナー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
ご静聴ありがとうございました

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