Oracle Internet Directoryを使用したUNIX認証およびユーザー・プロビジョニングの一元化

Transcription

1 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 オラクル ホワイト ペーパー 2005 年 9 月

2 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 Burlington Coat Factory 社のケース スタディ... 3 Unix の認証に対する BCF 社の要件... 3 背景... 3 ユーザー管理の一元化に必要な要件と結果... 4 Oracle Identity Management の利用 Oracle Internet Directory... 4 Burlington 社のソリューション... 5 ソリューションにおける考慮事項と背景... 5 コンポーネントと設計のイネーブル... 5 段階的なソリューション... 5 ディレクトリ スキーマのカスタマイズおよび Directory Information Tree の保守... 5 Posix グループの作成... 6 DIT ブランチの作成... 7 効率化のための索引付け... 7 OID への YP 情報の挿入... 7 パスワード ポリシー レルムに対するパスワード ポリシーの確立 ルート レベルのパスワード スキームの変更 UNIX シャドーへのパスワード属性のマッピング コンプライアンスの大幅な強化 構成ファイルに対する変更 OID データの OpenLDAP との同期 ローカル ホストのネームサーバー情報の変更 ホストの権限 ユーザーに対して新しいスキーマ変更が反映される OIDDAS の設定 Oracle Internet Directory へのセキュアな PAM クライアント アクセス 今後の予定 結論と今後の方向性 参考資料 Directory Entries Administration Password Policies in Oracle Internet Directory Integration with the Microsoft Active Directory Environment How To Setup OID Synchronization with Microsoft Active Directory Quick Start Understanding DIP Mapping Files Using Oracle Wallet Manager Secure Sockets Layer (SSL) and the Directory IETF RFC 2307Specifications Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 2

3 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 Burlington Coat Factory 社のケース スタディ Burlington Coat Factory(BCF) 社は アメリカ北東部を拠点とした衣料品小売業者大手です BCF 社はオラクル製品のスイート すなわち HR Payroll Financials などを含む Oracle E-Business suite-release 11i を使用し 本店はもとよりチェーン店でも RedHat Linux を使用しています BCF 社では SuSE Solaris も使用しています BCF 社では 効率的にユーザー管理するために全社で ID 管理を開始しました その一環として 様々な取組みが行われました 取組みの 1 つとして Oracle Internet Directory(OID) 環境と他の ID 管理プラットフォームとの統合プラットフォームを作成しました このホワイト ペーパーでは OID を使用して Unix の認証を実現するための試みを説明します Unix の認証に対する BCF 社の要件 BCF 社はエンドユーザー コンピューティングに様々な Linux(Redhat Rel3 Rel4 SuSe) を使用しています このプラットフォームを管理 保守するための主要な取組みは エンドユーザーが デスクトップからわずかなメンテナンスでコンピューティング環境にアクセスできる Base Image を作成することでした つまり ローカルなファイル システムとは異なり ユーザー ID やグループ ID の管理などシステムに関係するすべての情報を一元化します 背景 BCF 社は Linux ワークステーションを使用して 従業員と顧客に関する基幹業務を処理しています また 文書処理のニーズに対しては Star Office を使用し Oracle ERP などのアプリケーションを Linux といくつかの Unix 上で稼動しています コンバージョン / 統合上の理由から Windows PC の数は限定されます 今回の標準化の一環として Unix/ ネットワーキング管理グループは Linux ワークステーション 特にユーザー ID を管理 保守する様々な手法を試みました これらの経験から Oracle Internet Directory(OID) で実装している LDAP v3 ディレクトリ サービスの使用を決定しました このホワイト ペーパーでは この目的を実現するために採用した方法を説明します Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 3

4 ユーザー管理の一元化に必要な要件と結果 今回の主な要件は 従来の/etc/passwd ファイルやイエロー ページ イニシアティ ブとは異なり Unix ユーザーの認証と許可に一元化したディレクトリを使用する ことでした また OID を使用すると次のメリットがありました パスワード ポリシーの施行: Sarbanes-Oxley 法に準拠することによって OID ベースのユーザー管理へ簡単に移行できました 使用しているサーバーとサービスによって ユーザーを複数の権限グ ループに分類し 様々な権限で管理できました ID を一元管理すること によって 部門 QA 製品などのレルムの管理がより簡単になりました 一元化フレームワークにより 従業員のセルフサービス アプリケーショ ンのサポートも容易になりました 将来的には Oracle 11i ERP アプリケー ションを一元化した ID 管理システムへ接続する予定です Oracle Identity Management の利用 Oracle Internet Directory 次の図は OID による UNIX の認証/許可のアーキテクチャです Linux クライアント用 の企業イントラネット ディレクトリの 同期化 将来的な 統合 Unix サーバー/Linux ステーション Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 4 Oracle Corporation 発行 Centralizing UNIX Authentication and User Provisioning with Oracle Internet Directory の翻訳版です

5 Burlington 社のソリューションソリューションにおける考慮事項と背景 ユーザー情報を保存する一元化メカニズムを特定するにあたり BCF 社は LDAP ベースの様々なソリューションを試みました 結局 BCF 社は LDAP v3 のパスワード管理と保守の互換性 柔軟性 データベース ストレージ容量の点から OID を採用しました コンポーネントと設計のイネーブル 1. ディレクトリ スキーマの変更と Directory Information Tree の作成 2. YP 情報を OID へ挿入することによる 複数ノードのユーザー管理 3. 様々なパスワード管理とポリシーの作成 4. 様々な Unix 構成ファイルの修正 5. 初期設定と定期保守のための OID と OpenLDAP の同期化 いくつかのアプリケーションでは OpenLDAP を継続して使用しているため BCF 社では すべてのユーザーとサーバーを OID へ移行するのではなく 同期化するアプローチを採用しました 6. NCSD の構成 7. ホスト認証のイネーブル 8. グループとユーザーの管理および保守のための OID Delegated Administration Services の構成以降では OID で UNIX を検証をするための様々なコンポーネントとその手順を説明します 段階的なソリューション 以降では OID による認証を実現するためのスクリプトとその手順を説明します ディレクトリ スキーマのカスタマイズおよび Directory Information Tree の保守 BCF 社では 同社のユーザー データの性質と将来的な拡張をサポートするため に 複数のコンテナとカスタム属性を作成するという要件がありました これらの要件には 新規追加によるデフォルトの属性およびオブジェクトクラスのカスタマイズが含まれていました このプロセスには 1) スキーマの修正 2) ブランチの作成 3) 索引付け の 3 つの基本的な手順があります Burlington Coat Factory 社では ユーザーが存在しているデフォルトのレルム (cn=users,[basedn]) を使用し UNIX グループのために独自のブランチを作成しました OID で既存のスキーマを修正するために まず元のスキーマを削除してから 修正したものを挿入しました Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 5

6 Posix グループの作成次に示すように schema_mods というファイルには 4 つのスキーマの修正が含まれています 最初の 2 つでは 必要な属性 "cn" を挿入することによって オブジェクトクラス "posixgroup" を修正し 上位のオブジェクト "posixgroup" を "groupofuniquenames" から "top" へ (IETF RFC2307 で定義されたとおり ) 修正しました 3 番目と 4 番目のエントリでは "/etc/ldap.conf" で使用する "unixid" という新しい属性を作成しています 4 番目のエントリでは 新しい属性が関連付けられたオブジェクトクラスを挿入しています 新しい属性はすべて オブジェクトクラスの前のスキーマへ挿入する必要があります BCF 社では Portal で使用している ( デフォルトの )"uid" を使用せずに UNIX の認証 / 許可に対してカスタム ログイン属性を使用することにしました これは 許可のコントロール層としても機能します (LDAP ユーティリティの使用にあたり BCF 社では これらのユーティリティの他のバージョンの誤用をさけるため設定が必要でした そのため 1)$PATH 変数を設定する 2) ファイルシステム上でこれらのバージョンが存在する Oracle のユーティリティをシンボリック リンクする 3) その他の方法を実行する という選択肢がありました 次に ボックス内の LDIF のコードを示します dn: cn=subschemasubentry changetype: modify delete: objectclasses objectclasses: ( NAME 'posixgroup' SUP groupofuniquenames STRUCTURAL DESC 'Abstraction of a group of accounts' MUST ( gidnumber ) MAY ( userpassword $ memberuid $ description ) ) dn: cn=subschemasubentry changetype: modify add: objectclasses objectclasses: ( NAME 'posixgroup' SUP top STRUCTURAL DESC 'Abstraction of a group of accounts' MUST ( gidnumber $ cn ) MAY ( userpassword $ memberuid $ description ) ) dn: cn=subschemasubentry changetype: modify add: attributetypes attributetypes: ( NAME 'unixid' SUP uid ) dn: cn=subschemasubentry changetype: modify add: objectclasses objectclasses: ( NAME 'BcfUserIdentifiers' SUP inetorgperson STRUCTURAL MAY ( unixid ) ) エントリは 次のコマンドを発行してスキーマへ挿入されました Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 6

7 $ORACLE_HOME/bin/ldapmodify -D (binddn) -w (password) -f schema_mods.ldif スキーマへの修正に先立ち BCF 社は Internet Assigned Numbers Authority ( のPrivate Organization arc [ ] から無料発行された特別なオブジェクトIDを持っていました DIT ブランチの作成次に BCF 社は DIT 内で posixgroup を定義するブランチを作成しました 具体的には "bcfgroups" の "organizational unit" を作成しました これは 組織内のすべてのグループ カテゴリに対してコンテナとしてリテラルに機能する包括的なエントリです make_branches.ldif というファイルでは 次の LDIF ファイルが作成されました dn: ou=bcfgroups,dc=bcf,dc=coat,dc=com objectclass: organizationalunit ou: bcfgroups dn: cn=unix,cn=bcfgroups,dc=bcf,dc=coat,dc=com objectclass: organizationalrole cn: unix これらの内容は 次のコマンドによって DIT へ挿入されました $ORACLE_HOME/bin/ldapadd -D (binddn) -w (pasword) -f make_branches.ldif 効率化のための索引付け最後に BCF 社は次の属性を (indexattrs というファイル内で ) 索引付けしました loginshell homedirectory gidnumber uidnumber memberuid unixid これらの索引はすべて 並列化索引作成用の OID の catalog.sh ツールを使用して 1 つのパスで次のように作成されました $ORACLE_HOME/ldap/bin/catalog.sh -connect (connect string) -add -attr -file indexattrs OID への YP 情報の挿入 BCF 社は グループとユーザーの YP 情報を取得して それを OID へ挿入する必要がありました ypgroup ファイルから Directory へ挿入する場合には 次の行 network:*:103:user1,user2,user3 が BCF 社で作成されたスクリプトによって解析され 次のように Directory へインクルードされます Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 7

8 dn: cn=network,cn=unix,ou=bcfgroups,dc=bcf,dc=coat,dc=com objectclass: top objectclass: posixgroup cn: network gidnumber: 103 memberuid: user1 memberuid: user2 memberuid: user3 yppassword から Directory へ挿入する場合は clundell:<password>:103:chris Lundell:/home/clundell:/bin/csh は 次のようになります dn: cn=clundell,cn=users,dc=bcf,dc=coat,dc=com shadowmax: 126 objectclass: top objectclass: person objectclass: orcluser objectclass: orcluserv2 objectclass: organizationalperson objectclass: shadowaccount objectclass: inetorgperson objectclass: bcfuseridentifiers objectclass: posixaccount objectclass: ctcaluser orclcalendarstore: ctcalxitemid: 00101:00343 orcldefaultprofilegroup: cn=corporate,cn=portal ,cn=groups,dc=bcf, dc=coat,dc=com shadowinactive: 0 cn: clundell uidnumber: 3366 shadowwarning: 15 gecos: Chris Lundell shadowlastchange: mail: Chris.Lundell@coat.com displayname: Chris Lundell uid: clundell homedirectory: /home/clundell shadowmin: 7 unixid: clundell sn: Lundell userpassword: {CRYPT}xxx givenname: Chris loginshell: /bin/csh gidnumber: 103 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 8

9 パスワード ポリシー ここでは 次の 3 つの重要な作業がありました 1. レルムに対するパスワード ポリシーの確立 OID のほとんどのパスワード ポリシーは 次の DN に含まれています cn=pwdpolicyentry,cn=common,cn=products,cn=oraclecontext,dc =bcf,dc=coat,dc=com パスワード ポリシーの変更は ldapmodify を使用して実行し デフォルト値を変更しました dn: cn=pwdpolicyentry,cn=common,cn=products,cn=oraclecontext, dc=bcf,dc=coat,dc=com changetype: modify replace: pwdmaxage pwdmaxage: この例では レルム dc=bcf,dc=coat,dc=com に対する password max age を 7,776,000 秒 つまり 90 日に設定しました ( デフォルトでは 5,184,000 秒 つまり 60 日 ) 2. ルート レベルのパスワード スキームの変更 DIT のルート (orclsizelimit [1 回の検索におけるエントリの最大数 ] や orclcryptoscheme など ) で修正するために BCF 社は ルート レベルでの修正を実行しました 次に例を示します dn: changetype: modify replace: orclcryptoscheme orclcryptoscheme: CRYPT この例では ルート DSE に対する暗号化方式を MD4( デフォルト ) から UNIX CRYPT へ変更しました この変更は BCF 社が現在 UNIX CRYPT を使用してパスワードをハッシュしているため実行されましたが 将来は MD4 または MD5 へ変更されます (cn=pwdpolicyentry cn=common cn=products cn=oraclecontext dc=bcf dc=coat dc=com entry では ) 他にも次のパスワード属性を考慮する必要があります Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 9

10 pwdmaxage pwdexpirewarning pwdgraceloginlimit orclpwdalphanumeric pwdlockout pwdminlength orclpwdtoggle pwdlockoutduration pwdchecksyntax orclpwdillegalvalues pwdmaxfailur pwdfailurecountinterval これらの値は 組織の特定のポリシーに設定することができます 組織 ( すべてのユーザーに対する単一のポリシーを実現できない組織 ) の特定のポリシーを表す保管可能な LDIF ファイルを作成することもできましたが BCF 社では すべてのユーザーが単一の Directory ポリシーに従うことでコンプライアンス問題を緩和しました 3. UNIX シャドーへのパスワード属性のマッピング BCF 社は Oracle Internet Directory のパスワード属性をユーザー エントリのために UNIX のシャドー等価へマップしました UNIX の環境では OID のパスワード ポリシーを認識しないため ユーザーは OID のポリシーをシャドー等価へマップすることが必要です pwdmaxage pwdchangedtime orclisenabled pwdaccountlocktime orclactivenddate pwdexpirewarning => shadowmax => shadowlastchange => shadowexpire => shadowexpire => shadowexpire => shadowwarning 必要に応じ OID のパスワード属性の値が UTC で提供されます これは シャドー フィールドが認識する値であるため BCF 社はこの値を日数へ変換する必要がありました これは UNIX のいくつかのバリアントで該当します コンプライアンスの大幅な強化 BCF 社は OID によって柔軟で高度に構成可能なパスワード ポリシーの管理スキームを実現できました OID の特徴の中で重要な役割を果たしたのが PL/SQL のプラグイン パッケージでした これにより レルムで行われたパスワードの変更に対して厳密なルールを作成するパスワード管理が実現しました また BCF 社は パスワード変更ページ を作成し ユーザーがプラグインをコールして簡単にパスワードを変更できるようにしました 監査ログを使用した定数の同期化では OpenLDAP サーバーが OID との同期を保ちます OID に構成されたパスワード ルールには 次が含まれています Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 10

11 At least seven characters At least one lower case letter At least one upper case letter No Dictionary words allowed No letter used two or more times in succession None of a user s three previous passwords may be reused 構成ファイルに対する変更 このセクションでは OID の認証を実現するために 様々な Linux/Unix の構成ファイルに対して BCF 社が加えた変更を説明します 1. /etc/ldap.conf を変更します ( すべての UNIX フレーバー ) オプションの変更は UNIX のコメント ( ポンド記号 #) で示します 次に例を示します ldap.conf,v /09/20 14:12:26 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # # # Your LDAP server. Must be resolvable without using LDAP. host bcfldap.coat.com # The distinguished name of the search base. base dc=bcf,dc=coat,dc=com # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap:// / #uri ldaps:// / #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # The LDAP version to use (defaults to 3 # if supported by client library) #ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=example,dc=com # The credentials to bind with. # Optional: default is no credential. #bindpw secret # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) #rootbinddn Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 11

12 # The port. # Optional: default is 389. # The search scope. #scope sub #scope one scope base # Search timelimit timelimit 30 # Bind timelimit #bind_timelimit 30 # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 # Filter to AND with uid=%s pam_filter (&(objectclass=posixaccount)(objectclass=shadowaccount)) # The user ID attribute (defaults to uid) pam_login_attribute unixid # Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes # Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes # Group to enforce membership of #pam_groupdn cn=networkusers,dc=coat,dc=com # Group member attribute #pam_member_attribute member # Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0 # Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userprincipalname #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 12

13 # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. #pam_password clear # Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt # Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password nds # Update Active Directory password, by # creating Unicode password and updating # unicodepwd attribute. #pam_password ad # Use the OpenLDAP password change # extended operation to update the password. #pam_password exop # RFC2307bis naming contexts # Syntax: # nss_base_xxx base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=people, # to append the default base DN but this # may incur a small performance impact. nss_base_passwd cn=users,dc=bcf,dc=coat,dc=com?one nss_base_shadow cn=users,dc=bcf,dc=coat,dc=com?one nss_base_group cn=unix,ou=bcfgroups,dc=bcf,dc=coat,dc=com?one #nss_base_hosts ou=hosts,dc=example,dc=com?one #nss_base_services ou=services,dc=example,dc=com?one #nss_base_networks ou=networks,dc=example,dc=com?one #nss_base_protocols ou=protocols,dc=example,dc=com?one #nss_base_rpc ou=rpc,dc=example,dc=com?one #nss_base_ethers ou=ethers,dc=example,dc=com?one #nss_base_netmasks ou=networks,dc=example,dc=com?ne #nss_base_bootparams ou=ethers,dc=example,dc=com?one #nss_base_aliases ou=aliases,dc=example,dc=com?one #nss_base_netgroup ou=netgroup,dc=example,dc=com?one # attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass # configure --enable-nds is no longer supported. Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 13

14 # For NDS now do: #nss_map_attribute uniquemember member # configure --enable-mssfu-schema is no longer supported. # For MSSFU now do: #nss_map_attribute homedirectory sthomedirectory #nss_map_attribute loginshell stloginshell #nss_map_objectclass posixaccount User #nss_map_attribute uid mssfuname #nss_map_attribute uniquemember posixmember #nss_map_attribute userpassword mssfupassword #nss_map_attribute homedirectory mssfuhomedirectory #nss_map_objectclass posixgroup Group #pam_login_attribute mssfuname #pam_filter objectclass=user #pam_password ad # configure --enable-authpassword is no longer supported # For authpassword support, now do: #nss_map_attribute userpassword authpassword #pam_password nds # For IBM SecureWay support, do: #nss_map_objectclass posixaccount aixaccount #nss_map_attribute uid username #nss_map_attribute gidnumber gid #nss_map_attribute uidnumber uid #nss_map_attribute userpassword passwordchar #nss_map_objectclass posixgroup aixaccessgroup #nss_map_attribute cn groupname #nss_map_attribute uniquemember member #pam_login_attribute username #pam_filter objectclass=aixaccount #pam_password clear # Netscape SDK SSL options #sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" #tls_checkpeer no # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" #tls_cacertfile /usr/share/ssl/certs/private #tls_cacertdir /usr/share/ssl/certs # SSL cipher suite # See man ciphers for syntax #tls_ciphers SSLv3 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 14

15 # Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key #ssl no #pam_password md5 #pam_password crypt #pam_password crypt #ssl no #pam_password md5 passwd: files ldap shadow: files ldap group: files ldap 2. BCF 社は nsswitch.conf( すべての UNIX フレーバー ) で 階層を次のように 設定しました 3. /etc/pam.d/system-auth(redhat) および /etc/pam.conf(solaris) では 次のよう にしました auth required /lib/security/$isa/pam_env.so auth sufficient /lib/security/$isa/pam_unix.so likeauth nullok auth sufficient /lib/security/$isa/pam_ldap.so use_first_pass auth required /lib/security/$isa/pam_deny.so account required /lib/security/$isa/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$isa/pam_ldap.so password required /lib/security/$isa/pam_cracklib.so retry=3 type= password sufficient /lib/security/$isa/pam_unix.so nullok use_authtok password sufficient /lib/security/$isa/pam_ldap.so use_authtok password required /lib/security/$isa/pam_deny.so session required /lib/security/$isa/pam_limits.so session required /lib/security/$isa/pam_unix.so session optional /lib/security/$isa/pam_ldap.so 4. /etc/security/pam_unix2.conf(suse) では 次のようにしました auth: account: password: session: use_ldap use_ldap use_ldap none Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 15

16 OID データの OpenLDAP との同期 BCF 社は OID を一般に認証用に使用するだけでなく OID と特定の OpenLDAP サーバーを同期化することも必要でした ここでいくつかの問題に直面しましたが 次のように解決しました 同期化 / マッピングのプロセスは BCF 社の Chris Lundell 氏が記述した Perl プログラムです このプログラムは DMZ から OID データを Secure Sockets Layer(SSL) 全体へプルします OID が常駐している実働システムは 非常に厳重にロックされます Lundell 氏は OID の同期化プロセスで使用される構成ファイルに非常によく似たファイルを作成しました この構成ファイルの次の行を見てください cn:cn:inetorgperson ここで 最初のフィールドは OID の属性 2 番目のフィールドは OpenLDAP の属性 3 番目のフィールドは 2 番目の属性が属するオブジェクトクラスです もちろん 必要なスキーマは OID にも OpenLDAP にも反映する必要があります 現在 BCF 社は SSL の F5 ネットワーク ルータの制御下で稼動する 4 つの OpenLDAP サーバー (1 つのマスターと 3 つのスレーブ ) を LDAP プールに持っており OID サーバーは これらのサーバーのマスター リポジトリとして機能しています OID は F5 プールに設置されました 同期化のプロセスは 1) 監査ログを介したスウィーピングおよび監査ログ レベルの 0x1000 の設定による同期化 2) cron ジョブでのディレクトリ全体のスウィーピングによる同期化 の 2 つのプロシージャから構成されています これらのプロシージャは 一緒にまたは個別に実装できます ローカル ホストのネームサーバー情報の変更 Name Service Caching Daemon は パスワードとグループ データをシステム上で確実にキャッシュし 不要な OID/LDAP 検索を回避します BCF 社では Kill/Start プロシージャ (Solaris の場合 ) または chkconfig プロシージャ (Linux の場合 ) により 次のデーモンを実行しました また システムの開始時にこのデーモンが実行されるようシステムを構成しました /etc/init.d/nscd [start stop ] /etc/nscd.conf は Name Service キャッシュへの調整が済んだファイルです Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 16

17 ホストの権限 BCF 社は 認証の他に 許可情報をホストから提供する必要があり そのために OID を利用しました Pluggable Authentication Module(PAM) には ホスト許可 の方法が次の 2 通りあります 1) ユーザーのグループによる許可 2) ホストのグループによる許可 最初の方法では DNS が LDAP へロードされ メンバーはホスト エントリに含 まれます 次のコードを見てください dn: cn=quasar,ou=hosts,dc=bcf,dc=coat,dc=com objectclass: iphost objectclass: device objectclass: extensibleobject iphostnumber: cn: quasar.coat.com cn: quasar member: user1 member: user2 member: user3 (BCF 社では OID の認証のためにノード ナビスタが構成されました ) このエントリと許可されたユーザーを認識するために ナビスタの /etc/ldap.conf を構成します pam_groupdn cn=navistar,ou=hosts,dc=bcf,dc=coat,dc=com pam_member_attribute member 2 番目の方法では host 属性によって許可されたホストの一覧がユーザーのエントリに含まれています 次のエントリを見てください dn: cn=clundell,cn=users,dc=bcf,dc=coat,dc=com shadowmax: 126 objectclass: top objectclass: person objectclass: orcluser objectclass: orcluserv2 objectclass: organizationalperson objectclass: shadowaccount objectclass: inetorgperson objectclass: bcfuseridentifiers objectclass: posixaccount objectclass: ctcaluser objectclass: account orclcalendarstore: ctcalxitemid: 00101:00343 orcldefaultprofilegroup: cn=corporate,cn=portal ,cn=groups,dc=bcf, dc=coat,dc=com shadowinactive: 0 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 17

18 cn: clundell uidnumber: 3366 shadowwarning: 15 gecos: Chris Lundell shadowlastchange: mail: displayname: Chris Lundell uid: clundell homedirectory: /home/clundell shadowmin: 7 unixid: clundell sn: Lundell userpassword: {CRYPT}stW9GO0AJxmQa givenname: Chris loginshell: /bin/csh gidnumber: 103 host: nebulus host: quasar BCF 社は すべてのホストの /etc/ldap.conf ファイルで 次のディレクティブを実 行できるようにしました pam_check_host_attr yes ユーザーに対して新しいスキーマ変更が反映される OIDDAS の設定 OIDDAS(Delegated Administration Services) を使用して ユーザーとユーザーが 属するグループを作成 管理することができます BCF 社では OIDDAS を再構 成したうえで 新しいスキーマの変更を反映させる必要がありました ここでは その手順を説明します superuser( または管理権限を持つ他の LDAP ユーザー エントリ ) として OIDDAS へログインします 新しい UNIX のログイン属性を実装するために BCF 社は DAS 内で次の手順を実行しました Configuration Tab User Entry Add Objectclass BCF 社は ドロップダウン メニューから新しいオブジェクトクラスを選択し done を選択しました たとえば posixaccount は必要なクラスの 1 つです 次の手順へ進み 前の手順で選択したオブジェクトクラスに関連付ける属性を追加しました オブジェクトクラス posixaccount に対しては 属性の uidnumber gidnumber homedirectory loginshell が関連付けられました 次に 属性を様々なセクションに割り当てて user entry で GUI の複数のセクションを作成しました 結果は 図 1 のようになります Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 18

19 図 1: Delegated Administration Console Oracle Internet Directory へのセキュアな PAM クライアント アクセス 次の 2 つのオプションを利用して 認証の際に OID に対するクライアント アク セスの安全性を保障できます オプション 1: Simple Bind クライアントは クライアントのパスワードを検証するために 自身のパスワードを平文形式でサーバーへ送信する必要があります 検証のプロセスで OID は バックエンド リポジトリに格納されたユーザーの識別子を取得します サーバーは この識別子から暗号体系を復元します CRYPT MD5 SMD5 SHA SSHA などのハッシングの暗号体系によっては OID サーバーは平文のパスワードを圧縮前にハッシュします このため クライアントが他のハッシュ形式でパスワードを送信した場合 OID はそのバインド要求を拒否します BCF 社の pam_ldap デプロイメントでは これにより YP サーバーの最新のユーザー情報 ( または CRYPT 形式の Unix パスワード ) を OID へ透過に送信することができます Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 19

20 ただし CRYPT の暗号体系は脆弱であるため OID サーバーの暗号体系は Salted SHA(SSHA) などの他の強力な暗号体系に変更することができます これにより 新しいユーザーによって将来パスワードが追加 / 変更された場合 より強力なパスワードの識別子が生成され SSHA 形式で保存されます 現在の CRYPT で生成された識別子を持つユーザーには影響を与えません OID の暗号体系は Oracle Directory Manager を使用して設定できます 図 2: Oracle Directory Manager 次のコマンドを使用して 現在使用している暗号体系を問合せします $ ldapsearch -p b "" -s base "objectclass=*" orclcryptoscheme セキュリティ上の理由から 平文のパスワードを使用したシンプル バインドは SSL( 一方向 ) のサーバー認証モードによって安全性が保証され pam_ldap と OID サーバー間の通信チャネル上で資格証明が保護されます 注意 : pam_ldap がリンクされた SSL SDK によっては pam_client を適切な SSL ウォレット ファイルで構成する必要があります たとえば Netscape SSL SDK を使用している場合 cert7.db が使用され OpenSSL では CA の資格証明を含む BASE64 フラット ファイルが必要です OID のウォレットで使用している CA の資格証明をインポートするために BCF 社は Oracle Wallet Manager を使用して CA の資格証明をエクスポートし Netscape から certutil を実行して CA の資格証明を cert7.db へインポートします OIDをSSLモードでイネーブルにする方法は OID 管理者ガイド に詳しく記載されています Oracle walletの作成は Oracle Database セキュリティ ガイド で説明しています これらのドキュメントの参考資料については 後で説明します Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 20

21 オプション 2: SASL Bind Simple Bind を使用する代わりに OID は auth-only( 認証のみのモードで チェックサムまたは暗号化は使用しない ) で SASL/Digest-MD5 メカニズムをサポートします Openldap/Cyrus の SASL 実装を使用した pam_ldap では pam_ldap が OID の SASL Digest-MD5 で 両方のモードで機能するように (OpenLDAP インストールの一部である )Cyrus SASL をインストールする必要がありました 今後の予定 UNIX 環境に対する認証を一元管理するにあたり ( 一部を除いて )BCF 社では検討が必要でした 一般的な企業のデプロイでは 複数のオペレーティング システムが存在します PAM をセットアップするために何が実行でき 既存のオペレーティング システムに対してどのように構成を利用できるのでしょうか? また こうした広範囲な使用を基にして 顧客は Microsoft Active Directory と UNIX PAM をどのように統合できるでしょうか? これらの取組みに対してオラクル社は 強力な Directory Integration Platform(DIP) を提供し OID などの接続されたディレクトリと Active Directory 間のデータを容易に同期化します Windows に対するユーザー プロビジョニング 5 - Windows に対するユーザー ログイン 1 - ユーザーの追加 3 - AD と同期化したユーザー 2 - Oracle 環境におけるユーザー プロビジョニング 4 - Active Directory で作成されたユーザー 2 - UNIX のユーザー プロビジョニング 図 3: Windows に対するユーザー プロビジョニング このシナリオでは 管理者は Delegated Administration Service を使用してユーザーを作成します (DAS については セクションを参照 ) ここでは ユーザーの UNIX アカウントで必要なプロファイルを作成するだけでなく Portal や E-Business Suite などの Oracle アプリケーションのコンポーネントを使用するために必要なフットプリントを作成します Oracle と UNIX 両方の環境で イネーブルが同時発生します Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 21

22 Oracle Directory Integration Server は OID で新しいユーザーが作成されたことを認識すると Active Directory を介して関連する Windows アカウントと同期します この段階で プロビジョニングされたユーザーは Windows にログインできます Windows のアカウント名は UNIX のアカウント名と同じにすることができます または 管理者が OID を DIP の Active Directory Connector へマップするルールの一部として 別のユーザー名を指定することもできます これらのマッピング ルールでは 同期化する必要があるデータ そのデータ形式 変換ルールなどを定義します DIP における Active Directory Connector への OID のデフォルトのインストール設定では 最も一般的な要件が考慮されます 詳しくは Oracle Identity Management 統合ガイド ( 後述の 参考資料 セクションを参照 ) を参照してください もう 1 つの重要なポイントは ログイン サービスの可用性です 認証とプロビジョニング サービスはノンストップで使用できない場合 その価値が制限されます Oracle Identity Management のインフラストラクチャには 優れた可用性の認証サービスを提供する様々なオプションがあります その 1 つは Oracle10g Application Server Clusters(Identity Management) の使用です これは (OID を含め ) すべての Oracle Identity Management コンポーネントを複数のホストに個別にインストールする非分散型のトポロジです これらのホストは 外部のロード バランサの背後にデプロイされ 要求をダイレクトします ホストで障害が発生すると ロード バランサは要求を残りのホストへダイレクトします もう 1 つは Oracle10g Application Server Cold Failover Cluster を使用する方法です これは 2 ノードで 両方のノードが共有ストレージに接続されたハードウェア クラスタ上の active-passive 構成です Oracle10g Application Server Metadata Repository と Oracle Identity Management は 共有ストレージの同じ Oracle Home 内にインストールされます 新しいデータベースは OracleAS Metadata Repository としてインストールされます Oracle10gApplication Server Metadata Repository と Oracle Identity Management は 1 つのノードでアクティブに もう 1 つのノードで非アクティブになります これは デフォルトでインストールし構成する最も簡単なトポロジです High Availability のオプションに関する詳細は Oracle10g Application Server 高可用性ガイド を参照してください Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 22

23 結論と今後の方向性 この課題は BCF 社がユーザー管理を一元化し ユーザー管理の統合 アプリケーションのプロビジョニング アプリケーションへのユーザー アクセスの拡張という目標へ近付くうえで役立ちました 今後の取組みは 次の目標達成に向けられます 1. Oracle ERP と OID との完全統合 オラクルにはすでに Early Adopter Program が備わっています BCF 社は OID を ( デプロイメントの重要なステップとして ) 事前に導入したために いくつかの適切なポイントで参加することができました 2. カスタム ポータルと他の Web アプリケーションの OID との完全統合 OID および新たに統合された COREid 製品の機能は デプロイされたユーザー管理機能のほとんどをデフォルトでサポートしているため 処理をさらに簡素化する様々な取組みが現在 進行中です 3. クライアント / サーバーなどのカスタム アプリケーションと カスタマイズされた他の認証 / 許可モジュールを統合します BCF 社はほとんどの Linux/UNIX プラットフォームを標準化したため このホワイト ペーパーで説明した取組みによって同社のユーザー管理問題はほぼ解決されました BCF 社では 一元化した OID フレームワークの周囲にユーザー管理をデプロイしたため 他の LDAP 対応のアプリケーションに対する認証および許可の追加統合がきわめて容易です Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 23

24 参考資料 ディレクトリ エントリの管理 (Oracle Internet Directory 管理者ガイド ) Oracle Internet Directory のパスワード ポリシー (Oracle Internet Directory 管理者ガイド ) Microsoft Active Directory 環境との統合 (Oracle Identity Management 統合ガイド ) Oracle Wallet Manager の使用方法 (Oracle Database Advanced Security 管理者ガイド ) Secure Sockets Layer (SSL) とディレクトリ (Oracle Internet Directory 管理者ガイド ) IETF RFC 2307Specifications ( Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 24

25 Oracle Internet Directory を使用した UNIX 認証およびユーザー プロビジョニングの一元化 2005 年 9 月著者 : Chris Lundell (Burlington Coat Factory), Roger Raj (roger.raj@oracle.com), Olaf Stullich (olaf.stullich@oracle.com) 寄稿者 : Quan Dinh (Oracle Corporation) Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : Copyright 2005, Oracle. 無断転載を禁ず この文書はあくまで参考資料であり 掲載されている情報は予告なしに変更されることがあります オラクル社は 本ドキュメントの無謬性を保証しません また 本ドキュメントは 法律で明示的または暗黙的に記載されているかどうかに関係なく 商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません オラクル社は 本書の内容に関していかなる保証もいたしません また 本書により 契約上の直接的および間接的義務も発生しません 本書は 事前の書面による承諾を得ることなく 電子的または物理的に いかなる形式や方法によっても再生または伝送することはできません Oracle JD Edwards PeopleSoft および Retek は Oracle Corporation および関連会社の登録商標です 他の製品名は それぞれの所有者の商標です