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

Oracle Internet Directory を使用した

UNIX 認証およびユーザー・プロビジョ

ニングの一元化

オラクル・ホワイト・ペーパー

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

パスワード・ポリシー ... 9

1. レルムに対するパスワード・ポリシーの確立... 9

2. ルート・レベルのパスワード・スキームの変更... 9

3. UNIXシャドーへのパスワード属性のマッピング... 10

コンプライアンスの大幅な強化 ... 10

構成ファイルに対する変更... 11

OIDデータのOpenLDAPとの同期 ... 16

ローカル・ホストのネームサーバー情報の変更... 16

ホストの権限 ... 17

ユーザーに対して新しいスキーマ変更が反映されるOIDDASの設定 ... 18

Oracle Internet DirectoryへのセキュアなPAMクライアント・アクセス .... 19

今後の予定 ... 21

結論と今後の方向性 ... 23

参考資料 ... 24

Directory Entries Administration ... 24

Password Policies in Oracle Internet Directory... 24

Integration with the Microsoft Active Directory Environment ... 24

How To Setup OID Synchronization with Microsoft Active Directory Quick

Start ... 24

Understanding DIP Mapping Files... 24

Using Oracle Wallet Manager ... 24

Secure Sockets Layer (SSL) and the Directory... 24

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 ディレクト リ・サービスの使用を決定しました。このホワイト・ペーパーでは、この目的を 実現するために採用した方法を説明します。

ユーザー管理の一元化に必要な要件と結果

今回の主な要件は、従来の/etc/passwd ファイルやイエロー・ページ・イニシアティ ブとは異なり、Unix ユーザーの認証と許可に一元化したディレクトリを使用する ことでした。また、OID を使用すると次のメリットがありました。 • パスワード・ポリシーの施行: Sarbanes-Oxley 法に準拠することによって、 OID ベースのユーザー管理へ簡単に移行できました。 • 使用しているサーバーとサービスによって、ユーザーを複数の権限グ ループに分類し、様々な権限で管理できました。ID を一元管理すること によって、部門、QA、製品などのレルムの管理がより簡単になりました。 • 一元化フレームワークにより、従業員のセルフサービス・アプリケーショ

ンのサポートも容易になりました。将来的には、Oracle 11i ERP アプリケー ションを一元化した ID 管理システムへ接続する予定です。

Oracle Identity Management の利用

− Oracle Internet Directory

次の図は、OID による UNIX の認証/許可のアーキテクチャです。 Linux クライアント用 の企業イントラネット ディレクトリの 同期化 将来的な 統合

Unix サーバー/Linux ステーション

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 で既存のスキーマを修正するために、まず元のスキーマを削除してか ら、修正したものを挿入しました。

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: ( 1.3.6.1.1.1.2.2 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: ( 1.3.6.1.1.1.2.2 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: ( 1.3.6.1.4.1.22078.2.1.1 NAME 'unixid' SUP uid )

dn: cn=subschemasubentry changetype: modify add: objectclasses

objectclasses: ( 1.3.6.1.4.1.22078.2.2.1 NAME

'BcfUserIdentifiers' SUP inetOrgPerson STRUCTURAL MAY ( unixid ) )

$ORACLE_HOME/bin/ldapmodify -D (binddn) -w (password) -f schema_mods.ldif スキーマへの修正に先立ち、BCF社は、Internet Assigned Numbers Authority （http://www.iana.org）のPrivate Organization arc [1.3.6.1.4.1]から無料発行された特別

なオブジェクト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 へインクルードされます。

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: 00101 ctcalxitemid: 00101:00343 orcldefaultprofilegroup: cn=corporate,cn=portal.041230.1430,cn=groups,dc=bcf, dc=coat,dc=com shadowinactive: 0 cn: clundell uidnumber: 3366 shadowwarning: 15 gecos: Chris Lundell shadowlastchange: 12922 mail: [email protected] displayname: Chris Lundell uid: clundell homedirectory: /home/clundell shadowmin: 7 unixid: clundell sn: Lundell userpassword: {CRYPT}xxx givenname: Chris loginshell: /bin/csh gidnumber: 103

パスワード・ポリシー

ここでは、次の 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: 7776000

この例では、レルム 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 では）他にも次のパスワード属性を考慮する必要があります。

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 => shadowmax pwdchangedtime => shadowlastchange orclisenabled => shadowexpire pwdaccountlocktime => shadowexpire orclactivenddate => shadowexpire pwdexpirewarning => shadowwarning 必要に応じ、OID のパスワード属性の値が UTC で提供されます。これは、シャ ドー・フィールドが認識する値であるため、BCF 社はこの値を日数へ変換する必 要がありました。これは、UNIX のいくつかのバリアントで該当します。

コンプライアンスの大幅な強化

BCF 社は、OID によって柔軟で高度に構成可能なパスワード・ポリシーの管理ス キームを実現できました。OID の特徴の中で重要な役割を果たしたのが PL/SQL のプラグイン・パッケージでした。これにより、レルムで行われたパスワードの 変更に対して厳密なルールを作成するパスワード管理が実現しました。また、BCF 社は「パスワード変更ページ」を作成し、ユーザーがプラグインをコールして簡 単にパスワードを変更できるようにしました。監査ログを使用した定数の同期化 では、OpenLDAP サーバーが OID との同期を保ちます。OID に構成されたパスワー ド・ルールには、次が含まれています。

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 のコメント（ポンド記号#）で示します。次に例を示します。

# @(#)$Id: ldap.conf,v 1.24 2001/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 # http://www.padl.com #

# 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://127.0.0.1/

#uri ldaps://127.0.0.1/

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

# 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

# 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

# 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

# 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 2. BCF 社は、nsswitch.conf（すべての UNIX フレーバー）で、階層を次のように 設定しました。

passwd: files ldap shadow: files ldap group: files ldap

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: use_ldap account: use_ldap password: use_ldap session: none

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 ]

ホストの権限

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: 172.16.182.168 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: 00101 ctcalxitemid: 00101:00343 orcldefaultprofilegroup: cn=corporate,cn=portal.041230.1430,cn=groups,dc=bcf, dc=coat,dc=com shadowinactive: 0

cn: clundell uidnumber: 3366 shadowwarning: 15 gecos: Chris Lundell shadowlastchange: 12922 mail: [email protected] 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 のようになります。

図 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 へ透過に送信すること ができます。

ただし、CRYPT の暗号体系は脆弱であるため、OID サーバーの暗号体系は、Salted SHA（SSHA）などの他の強力な暗号体系に変更することができます。これにより、 新しいユーザーによって将来パスワードが追加/変更された場合、より強力なパス ワードの識別子が生成され SSHA 形式で保存されます。現在の CRYPT で生成さ れた識別子を持つユーザーには影響を与えません。

OID の暗号体系は、Oracle Directory Manager を使用して設定できます。

図 2: Oracle Directory Manager

次のコマンドを使用して、現在使用している暗号体系を問合せします。

$ ldapsearch -p 3060 -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 セキュリティ・ガイド』 で説明しています。これらのドキュメントの参考資料については、後で説明しま す。

オプション 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 に対する ユーザー・ログイン 2 - Oracle 環境に おけるユー ザー・プロビ ジョニング 1 - ユーザーの追加 3 - AD と同期化 したユーザー 4 - Active Directory で 作成されたユーザー 2 - UNIX のユー ザー・プロビ ジョニング 図 3: Windows に対するユーザー・プロビジョニング

このシナリオでは、管理者は、Delegated Administration Service を使用してユーザー を作成します（DAS については、セクションを参照）。ここでは、ユーザーの UNIX アカウントで必要なプロファイルを作成するだけでなく、Portal や

E-Business Suite などの Oracle アプリケーションのコンポーネントを使用するため に必要なフットプリントを作成します。Oracle と UNIX 両方の環境で、イネーブ ルが同時発生します。

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 高 可用性ガイド』を参照してください。

結論と今後の方向性

この課題は、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 管理者ガイド）

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 認証およびユーザー・プロビジョニングの一元化 2005 年 9 月

著者: Chris Lundell (Burlington Coat Factory), Roger Raj ([email protected]), Olaf Stullich ([email protected]) 寄稿者: Quan Dinh (Oracle Corporation)

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2005, Oracle. 無断転載を禁ず。 この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載 されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証 または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、 契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理 的に、いかなる形式や方法によっても再生または伝送することはできません。

Oracle、JD Edwards、PeopleSoft および Retek は、Oracle Corporation および関連会社の登録商標です。他の製品名 は、それぞれの所有者の商標です。