![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
この記事では、以下の概念について学びます。
- ローカル・パスワード・データベースのセットアップ
- smbpasswd ファイル・フォーマット
- Samba と他のシステムとの間でのパスワードの同期
- パスワードの代替バックエンド・ストレージ
- Samba とLDAP (Lightweight Directory Access Protocol) の統合
- アクセス制御リスト (ACL)
この記事は、LPI (Linux Professional Institute) のMixed Environment Specialty 試験 (302) の主題 313 の目標 313.2 の試験対策となります。この目標の重要度は 8 です。
この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 313 の目標 313.2 の試験対策となります。この目標の重要度は 8 です。
この連載記事を最大限に活用するには、Linux の高度な知識と、記事に記載されたコマンドを演習できる実際の Linux システムが必要です。さらに、認証および承認メカニズムのテストに使用できる Windows 環境を利用できることも条件となります。
Samba では、さまざまな方法でパスワードおよびアカウント情報をパスワード・バックエンドに保存することができます。これらの方法には、ローカル・ディスク･ストレージを使用する方法もあれば、ネットワークをベースとした方法もあります。さらに、Samba には Linux サーバーが Samba 認証システムを使用してログインするためのメカニズムもあります。
20 年近くの歴史がある Samba では、さまざまな技術が使われてきました。古い認証システムは今でもサポートされていますが、その古い技術は新しい技術に取って代わられています。けれども、Samba のドキュメントを読むと、それらの古い認証システムについて以前と変わらずに説明している箇所を今でも目にします。この混乱をさらに増しているのは、特定の技術と同じような名前が付けられたコマンドライン・ツールです。
パスワード・バックエンドという名前にもかかわらず、このバックエンドにはパスワードだけでなく、アカウント・データやその他の属性も保存されます。データ自体は LDAP サーバーに保存されることもあります。その場合、Samba のパスワード・バックエンドが Samba と LDAP との仲介をすることになります。
さらに興味深いことに、Microsoft デバイスでは、パスワードのハッシュ化に、UNIX のパスワード・フォーマットとは異なるフォーマットを使用することになっています。パスワードがハッシュ化されるということは、一方向の暗号化が行われるということなので、UNIX のパスワード・フォーマットから Samba のパスワード・フォーマットへの変換、あるいはその逆の変換は不可能です。したがって、Samba クライアントを UNIX パスワード・データベースのデータを使用して認証することはできません。
ローカル・パスワード・データベースはネットワークを介して認証を行うのではなく、サーバーに関する情報が保存されたパスワード・バックエンドを参照します。こうした方法は最もパフォーマンスに優れているわけではありませんが、使用するのは簡単です。
平文のバックエンドについて言及した資料を目にすることもあります。かつては、Windows クライアントのクレデンシャルは暗号化されていないフォーマットでサーバーに渡されていましたが、その後、パスワードを UNIX スタイルにハッシュ化し、その結果をローカル・パスワード・データベースと照合することが可能になりました。今では、レジストリーを変更しない限り、Windows クライアントが平文のバックエンドを使用することはありません。暗号化されていないパスワードをネットワークで渡すことを避けられるのであれば、それに越したことはありません。したがって、平文のパスワード・データベースについて書かれていても、実際にそれが使用されている場面に遭遇することはないでしょう。
古いシステムのほとんどは、smbpasswd パスワード・バックエンドを使用します。このバックエンドは単純なフラット・ファイルにアカウント・データを格納します。フラット・ファイル内のデータは、アカウント名、パスワード・ハッシュ、そして基本的なアカウント情報からなります。この基本アカウント情報は単純なもので、Microsoft 管理ツールで使用するような詳細な属性は保存されません。
現在好んで使われているローカル・ストレージ・バックエンドは tdbsam です。主題 310 の目標 310.3 に関する記事で取り上げた簡易データベース (TDB) ファイルを思い出してください (「参考文献」にリンクを記載)。TDB ファイルは、key-value 型の情報に素早くアクセスできる恒久的な手段となります。tdbsam バックエンドが情報を格納するフォーマットは、Microsoft Windows NT の SAM (Security Account Manager) とよく似ており、SAM に保存できるものであれば、そのほとんどを Samba サーバーですることが表現できます。このことから、tdbsam は Microsoft システムとのハイレベルな互換性を提供します。
tdbsam の欠点は、これがバイナリー・フォーマットであることです。そのため、ファイルの内容を調べるのは容易ではありません。「Linux の 302 (Mixed Environments) 試験対策: 簡易データベース (TDB) ファイル」(developerWorks、2011年 3月) では、ファイルからキーと値のペアを取得する方法を紹介しましたが、この情報を意味のあるものに再構成するのはユーザーの仕事です。認証情報を格納するファイルは、passdb.tdb と呼ばれます。
新しく Samba をインストールするときに、バックエンドとして smbpasswd データベースを選択することはないでしょう。けれども、現場でこのバックエンドに遭遇する可能性はあるため、smbpasswd データベースについて理解しておくことは重要です。
パスワード・データベース・バックエンドを構成するには、passdb backend パラメーターを使用します。以下のコードでは、smbpasswd データベースを選択しています。
[global] passdb backend=smbpasswd:/etc/samba/smbpasswd |
上記のコードで使用されている passdb backend というグローバル・パラメーターには、smbpasswd の後をコロン (:) で区切り、passwd ファイルへのパスを続けた値が指定されています。コロンとパスはオプションですが、使用することをお勧めします。この指定を省略すると、Samba が自動的に選択したディレクトリーにファイルを配置します。Samba は再起動時にこのファイルを作成しますが、その時点でのファイルの中身は空です。
ユーザーを追加するには、smbpasswd コマンドを使用します。リスト 1 に、ユーザーを追加すると smbpasswd ファイルの内容はどのようになるかを示します。
リスト 1. smbpasswd ファイルへのユーザーの追加
# smbpasswd -a sean New SMB password: Retype new SMB password: Added user sean. # cat smbpasswd sean:1001:01FC5A6BE7BC6929AAD3B435B51404EE: \ 0CB6948805F797BF2A82807973B89537:[U ]:LCT-4DCDE4D8: |
リスト 1 では最初に -a フラグを使用して sean というユーザーを追加しています。追加するユーザーはローカル UNIX データベースに存在するユーザーでなければなりません。そうでないと、コマンドの実行は失敗します。ユーザーを追加すると、smbpasswd ファイルにはそのユーザーに関する行が 1 行追加されます (リスト 1 では読みやすいように改行されています)。この行は、コロンで区切られたフィールドからなります。これらのフィールドは、以下を指定するものです (記載順にリスト)。
- ユーザー名
- UNIX のユーザー ID
- 従来型の Lanman ハッシュ (このハッシュにはセキュリティーが講じられていないため、実質的には平文のパスワードです。)
- セキュアな Windows NT ハッシュ (最近のクライアントを認証するには、このハッシュが必要です。)
- アカウント・フラグ (上記で使用されているフラグは唯一、ユーザー・アカウントを意味する U だけです。その他のフラグについては、smbpasswd(5) の man ページを参照してください。)
- アカウントの最終変更時刻 (LCT) (UNIX 時間のタイム・スタンプを 16 進の値で表したものです。)
ユーザーが自分のパスワードを変更するには smbpasswd を実行します。root
ユーザーであれば、ユーザー名を指定して別のユーザーのパスワードを変更することができます。-a フラグが必要なのは、アカウントを追加する場合のみです。
平文のファイルには、ファイルの内容を直ちに調べられてしまうという点、そしてアカウントに関して保存できるメタデータが少ないという点が欠点としてあります。そこで作成されたのが、tdbsam データベースです。
tdbsam データベースは、smbpasswd データベースの代わりとなる手段として設計されました。tdbsam データベースを使用することで、アカウントに関して保存できるデータが増えるだけでなく、通常のデータベースを使用するため、速度の点でも大幅に改善されます。
tdbsam データベースが持つ制限に関するガイドラインは固まっていません。公式のドキュメントでは、250 ユーザーを目安に LDAP データベースへのアップグレードを推奨していますが、他の資料では、数千のクライアントをサポートできるという事例証拠を挙げています。これらの数に大きく影響を及ぼす要素としては、同時リクエスト数が挙げられるようですが、同時リクエスト数は、クライアントの数、ワークロード、そしてクライアントとサーバーとの間のレイテンシーに左右されます。ほとんどのアプリケーションと同じく、ネットワークの限界を予測するには、レイテンシー、CPU、ディスク I/O といった重要な要素をモニターするべきです。
tdbsam バックエンドを構成するのは、smbpasswd の場合と同じく簡単で、passdb
backend=tdbsam (オプションでファイル名を指定することもできます) を global セクションに追加して、Samba を再起動するだけの話です。認証情報を格納する TDB ファイルのデフォルト名は、passdb.tdb です。
smbpasswd ツールは、tdbsam データベース内のユーザーを操作する場合にも使用することができます。リスト 2
に示すのは、smbpasswd でユーザーを作成する前と作成した後の tdbsam データベースの内容です。
リスト 2. smbpasswd を使用してユーザーを作成し、tdbsam の内容を表示する
# tdbdump passdb.tdb
{
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"
}
# smbpasswd -a sean
New SMB password:
Retype new SMB password:
Added user sean.
# tdbdump passdb.tdb
{
key(13) = "RID_00000bba\00"
data(5) = "sean\00"
}
{
key(10) = "USER_sean\00"
data(205) = "\00\00\00\00....EC\04\00\00"
}
{
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"
}
|
passdb.tdb の最初の内容は、バージョン・ストリングが含まれる 1 つのキーがあるだけです。この状態で、前とまったく同じ方法でユーザーを追加します。smbpasswd ユーティリティーは、smb.conf を読み取って、ユーザーをどのように追加するべきかを理解するだけの賢さを持ち併せています。ユーザーが作成されると、パスワード・データベースには 2 つのキーが追加されます。最初のキーは Microsoft の相対 ID (RID) をユーザー名にマッピングし、次のキーはユーザーに関する情報を格納します。tdbsam のデータは、ほとんどがバイナリーなので、デコードするには Samba ソース・コードでデータ構造のレイアウトを調べる必要があります。
比較的優れたパフォーマンスを発揮する TDB ファイル・フォーマットは、大抵の小規模な環境に適していますが、TDB ファイルに適した規模を超えてスケーリングするには、LDAP サーバーに対して認証を行う必要があります。LDAP はツリーのような構造を持つことから、認証を行うには適しています。Microsoft の Active Directory ドメイン・サービスも、LDAP を中心に構築されています。
Samba と LDAP を統合するための最初のステップは、LDAP サーバーの構成です。詳しい説明はこの記事ではしませんが、301 試験のための学習用チュートリアルで、LDAP について詳しく取り上げています (「参考文献」を参照)。Samba と LDAP を統合するには LDAP についての知識が必要になるため、上記チュートリアルで改めて LDAP について確認することをお勧めします。
Linux サーバーで最もよく使用されている LDAP サーバーは、OpenLDAP です。リスト 3 に、Samba と統合できる状態の OpenLDAP 構成ファイル、slapd.conf を記載します。
リスト 3. slapd.conf
# Include the core schema files, and the perquisites for samba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema database bdb # Configure the tree and the admin user pidfile /var/run/openldap/slapd.pid suffix "dc=ertw, dc=com" rootdn "cn=admin, dc=ertw, dc=com" rootpw linux directory /var/lib/ldap # Indexes index objectclass eq index cn pres,sub,eq index sn pres,sub,eq # For storing Unix accounts in LDAP index uidNumber eq index gidNumber eq index memberUid eq # Samba specific index uid pres,sub,eq index displayName pres,sub,eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub |
リスト 3 では、すべてのオブジェクトに対して dc=ertw, dc=com という接頭辞を使用しています。最初のセクションは、Samba
との統合に必要なすべてのスキーマ要素をロードします。core.schema は OpenLDAP の基本操作に必要なスキーマで、samba.schema は Samba の
objectClass を取り込むスキーマです。他のスキーマは samba.schema の前提条件であるため、このスキーマよりも前でインクルードする必要があります (これらのファイルのインクルードは、記載されている順に行われるためです)。
database bdb で始まる次のセクションは、Berkeley データベースを使用することを指定し、管理ユーザーとディレクトリーを含め、LDAP ツリーに関する情報を提供します。ファイルの残りの部分は、ツリーの検索を容易にするために索引をセットアップしています。これらの索引は、OpenLDAP のデフォルト構成と Samba 資料から引用されているものです。
次はこの LDAP ツリーに、ユーザー、コンピューター、グループを保存する各種のコンテナーを取り込む必要があります。また、サーバーのセキュリティー ID (SID)
をいくつかのレコードに関連付けなければなりません。これは複雑な作業ですが、幸い、この作業を簡易化する smbldap-tools
というプロジェクトがあります。お使いのディストリビューションには、このプロジェクトのパッケージが付属していると思いますが、そうでない場合には手動でダウンロードしてインストールしてください (「参考文献」のリンクを参照)。
smbldap-tools
ユーティリティーをインストールしたら、構成ファイルをくまなく調べて、ドメインまたはワークグループの名前や LDAP
サーバーに接続するための管理情報など、必要な情報を入力します。その上で smbldap-populate コマンドを実行すると、ツリーが作成されます。リスト 4 に、このコマンドの出力を記載します。
リスト 4. LDAP ツリーへのデータの取り込み
# smbldap-populate Populating LDAP directory for domain BOB (S-1-5-21-2287037134-1443008385-640796334) (using builtin directory structure) entry dc=ertw,dc=com already exist. adding new entry: ou=People,dc=ertw,dc=com adding new entry: ou=Groups,dc=ertw,dc=com adding new entry: ou=Computers,dc=ertw,dc=com adding new entry: ou=Idmap,dc=ertw,dc=com adding new entry: uid=root,ou=People,dc=ertw,dc=com ... adding new entry: cn=Replicators,ou=Groups,dc=ertw,dc=com adding new entry: sambaDomainName=BOB,dc=ertw,dc=com Please provide a password for the domain root: Changing UNIX and samba passwords for root New password: Retype new password: |
リスト 4 には、smbldap-populate コマンドがローカル・マシンの SID とドメインを判別して LDAP にディレクトリー構造を作成するプロセスが示されています。このツールは最後に root パスワードの入力を求めます。入力されたパスワードは、LDAP ツリー内で同期が取られます。
LDAP を使用するように Samba を構成するには、サーバーに LDAP ツリーへのバインド方法を指示する必要があります。リスト 5 に、LDAP 認証に最小限必要な Samba の構成を記載します。
リスト 5. Samba を LDAP で認証するための最小構成
[global] passdb backend = ldapsam:ldap://ldap.ertw.com ldap suffix = dc=ertw,dc=com ldap user suffix = ou=People ldap group suffix = ou=Groups ldap admin dn = uid=samba_service,ou=People,dc=ertw,dc=com |
リスト 5 はグローバル・スコープでの動作の構成であり、ローカル・サーバーが ldap.ertw.com に位置する LDAP サーバーをパスワード・データベース・バックエンドとして指すようにしています。最初に定義されている 3 つの接尾辞は、Samba に対してツリーの基本名、ユーザーのブランチ名、グループのブランチ名をそれぞれ通知するためのものです。リストの最後では、管理ユーザーの DN (Distinguished Name: 識別名) を構成します。このユーザーがツリーに接続するために使用されて、他のユーザーが認証されることになります。リスト 6 に、このユーザーの LDIF (LDAP Data Interchange) 情報を記載します。
リスト 6. 管理ユーザーのの LDIF
dn: uid=samba_service,ou=People,dc=ertw,dc=com
uid: samba_service
objectclass: person
objectclass: uidobject
description: Service account to allow Samba to authenticate
cn: samba_service
sn: samba_service
userPassword: {SSHA}tQNdW/bNxQGz2iGoLz5zFL5wJ8px43v5
|
管理者の DN に対してパスワードを設定するには、smbpasswd -w
コマンドの後にパスワードを続けて入力します。これと同じパスワードに対して slappasswd コマンドによって生成したハッシュが、リスト 6 に示されている userPassword のハッシュです。これで、LDAP を使用するための準備は完了したので、Samba を再起動してください。
通常は、ドメイン SID を考慮しながら UNIX のユーザー ID と Microsoft SID
との間のマッピングを管理しなければなりませんが、この管理作業ではエラーが起こりがちです。そこで役立つのが、smbldap-useradd コマンドです。例えば、sean
というユーザーを追加するには、smbldap-useradd -a sean を実行します。-a パラメーターを指定することで、Samba の objectClass が
LDAP オブジェクトに追加されます。これにより、ユーザー sean は Microsoft ドメインにログインできるようになります。そして最後に、smbldap-passwd コマンドに続けてユーザー名を指定して実行することで、指定したユーザーのパスワードを設定します。
これで、Samba サーバーに接続して、LDAP ツリーに提供したクレデンシャルを使用できるようになるはずです。smbldap-tools パッケージに含まれるその他多くのツールも、ユーザーの管理、そして大規模なマイグレーションの計画を行う上で役に立ちます。
シングル・サインオン、つまり Linux と Microsoft との間でパスワードを同期するのは簡単なことではありません。それは、この 2
つのオペレーティング・システムは、それぞれに異なる方法でパスワードを保存するためです。smbldap-tools パッケージは両方のシステムに同時に作用してこの問題を解決しますが、これ以外にも、パスワードの管理を Microsoft ネットワークに任せるという方法があります。
Linux では、PAM (Pluggable Authentication Module) と呼ばれる概念をサポートしています。PAM を使用すると、アプリケーションについての知識を持たない管理者でも、構成ファイルを操作することによって、サービスの認証方法を構成したり、認証プロセスを変更したりすることができるようになります。アプリケーションがユーザーを認証するために PAM ライブラリーを呼び出すと、PAM はその特定のサービスに対するユーザーからの認証要求を受け入れるかどうかを判断するために構成ファイルを調べ、認証の成功または失敗の結果をアプリケーションに返します。
これまで、ローカル・パスワード・ファイル、LDAP、Kerberos、さらには Microsoft
ネットワークといった他のサービスに対して認証を行えるようにするための認証モジュールが数多く作成されてきました。こうしたサービスは pam_smb というモジュールによって提供されています。
お使いのディストリビューションには最新バージョンの pam_smb が付属しているはずですが、そうでない場合には、Web
サイトからソース・コードをダウンロードすることができます (「参考文献」のリンクを参照)。構成するのは /etc/pam_smb.conf 内のモジュールです。ファイル・フォーマットは至って単純で、ドメインの名前の後に、認証に対応できる 1 つまたは 2 つのサーバーを続けるだけです。以下に、構成の一例を記載します。
MYGROUP ALICE BOB |
上記の例は、MYGROUP ドメインまたはワークグループ内のユーザーを ALICE サーバーと BOB サーバーに照らし合わせて認証します。認証を処理するサーバーが 1 つだけしかない場合には、構成ファイルには、ドメインの行と認証サーバーの行の 2 行だけが含まれることになります。
次に必要な作業は、pam_smb を認証スタックに挿入することです。/etc/pam.d
には、個々のサービスに固有の認証順序を参照するための構成ファイルがいくつか格納されています。これらのファイルでは、多くのファイルで共通する構成内容を直接記述する代わりに、共通ファイルをインクルードするのが通常であるため、ファイルの内容は似ているように見えます。試しに
include キーワードでインクルードされているファイルを探してみてください。例えば Fedora では、共通ファイルに該当するのは password-auth または system-auth のいずれかです。リスト 7 に、password-auth ファイルの認証セクションを抜粋します。
リスト 7. password-auth の認証セクション
auth required pam_env.so # Use samba authentication auth sufficient pam_smb_auth.so debug auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so |
リスト 7 の各行は順に処理されます。先頭の行では、環境変数を設定する pam_env を呼び出しています。2 行目は、pam_smb
が認証要求で追加のデバッグを行えるようにします。認証に成功した場合は、チェックだけで十分であると判断してユーザーをログインさせる一方、認証に失敗した場合には、pam_unix に制御が渡され、UNIX パスワード・ファイルとの照合が行われます。
PAM の操作を試してみるときには、root アカウントをログインしたままにして、有効であることが確実なファイルは閉じておくことが賢明です。システムからロックアウトされたとしても、誤ったファイルに正しいファイルを上書きすることで、簡単にアクセスを取り戻せます。
Linux には、システム・ライブラリーがユーザー ID とグループ ID をそれぞれが表す名前にマッピングする方法を制御する、/etc/nsswitch.conf という名前のファイルがあります。このファイルは、NSS (Name Service Switch) システムを構成します。大抵のシステムが指すのはローカル・ファイル (/etc/passwd や /etc/group)、あるいは LDAP サーバー、NIS (Network Information Service) サーバーなどですが、Winbind というサービスを使用して、システム・ライブラリーに Microsoft ネットワークからマッピングを要求させることもできます。
この話題については、連載の次回の記事で詳しく取り上げます。今のところは、ユーザーは PAM によって認証される一方、ユーザー名とグループ名は NSS システムから認証されるということを理解しておけば十分です。
Microsoft の OS がインストールされているサーバーは、かなり強固なパーミッション一式をサポートすることから、管理者は極めて詳細にファイルやディレクトリーへのアクセスを構成することができます。一方で、一部の UNIX システムにはファイルシステム ACL が提供されているものの、そのサポートは広まっていないため、Linux システムでは Everyone/Group/User アクセスに対し、従来の読み取り/書き込み/実行ビットしか使用できないことは少なくありません。このことから、Samba では Microsoft クライアントに対する ACL インターフェースを提示して、このインターフェースを UNIX ファイルのパーミッションにマッピングし、オプションで情報を TDB ファイルに保存する必要があります。
UNIX と Windows NT の間でファイルのパーミッションをマッピングする方法を制御するパラメーターはいくつかありますが、そのうち重要なのは、force security mode と security mask です。同時に機能するこの 2 つのパラメーターは、ファイルのパーミッション・ビットをそれぞれセット、リセットします。
UNIX でのファイルのパーミッションを示すモードは 8 進数で表され、実行許可の値は 1、書き込み許可の値は 2、読み取り許可の値は 4 です。これらの数値は、8 進数を構成するために必要な 3 つのビットに対応します。3 桁の 8 進数のうち、最初の桁はファイルの所有者のパーミッション、2 番目の桁はファイルの所有グループのパーミッション、そして最後の桁はその他のユーザーのパーミッションです。したがって、モードが 750 のファイルの場合、所有者には読み取り/書き込み/実行が許可され、所有グループには読み取り/実行が許可されますが、その他のユーザーはこのファイルにアクセスできないことになります。
パーミッションを設定したり、設定の解除をしたりするには、8 進数でのバイナリー演算を実行することができます。OR
演算子は該当するビットをセットする一方、AND 演算子はビットをクリアします。例えば、1 OR 4 は 5 になります。これは、初めに 1 を表すビットをセットした後、4 を表すビットをセットするためです。同様に、5 OR 4 も同じく 5 になります。5 は 1 を表すビットと 4 を表すビットをともにセットした組み合わせであり、すでにセットされているビットをセットしても、効果はないからです。
AND は OR
とは対照的な演算子です。セットされているビットの位置を最終結果まで維持するには、そのビットを AND
演算子の両側でセットする必要があります。1 AND 1 は、演算子両側で 1 を表すビットがセットされるため、1
になります。5 AND 1 は 1 になります。1 を表すビットは両側でセットされますが、4
を表すビットは演算子の左側でしかセットされないためです。AND と OR を慎重に使用することによって、ビットが常にセットまたはクリアされた状態にすることができます。
force security mode
は、ファイルの作成時、またはクライアントがファイルのパーミッションを変更しようとしたときに、強制的にパーミッションのビットをセットします。デフォルトではビットは 000 に設定されます。これは、強制的にセットされるビットはないことを意味します。force
security mode を例えば 700 に設定にすると、ファイルの所有者には常に読み取り/書き込み/実行が許可されるように強制されます。そのため、ユーザーがパーミッションを変更して自分のファイルの読み取りを禁止しようとしても、常に読み取りができる状態になります。
同様に、security mask は AND
演算を実行してビットをクリアします。デフォルトでは、このモードは 777
であるため、何もクリアされていません。このファイルのモードを 775 にすると、その他のユーザーからの書き込み許可のビットがクリアされるため、ユーザーは任意のユーザーが書き込みを行えるファイルを作成できなくなります。
security mask と force security mode は、全体に適用することも、共有レベルで適用することもできます。この 2 つのパラメーターは、公開フォルダーとグループ・フォルダーでユーザーが介入しなくても、ファイルに対して所有グループのパーミッション、またはその他のユーザーのパーミッションが適切に設定されるようにする場合に、とりわけ役に立ちます。
学ぶために
- TDB ファイルについて復習するには、「Linux 302 (Mixed
environment) の試験対策: 簡易データベース (TDB) ファイル」(developerWorks、2011年3月) を読んでください。
- LDAP の概念について復習するには、LPI-301 試験のための
developerWorks チュートリアルで取り上げているトピックを読んでください。
force security maskパラメーターとほとんど同じように扱われている、umaskについて学んでください。この説明が、2 進計算を理解するのに役立ちます。- お急ぎの方は、サーバー構成のサンプルを入手してください。
- PAM について初めて学ぶには、Linux-PAM
System Administrator's Guide がお勧めの参考書です。
- Samba マニュアルに、アクセス制御に関する詳細が説明されています。
- LPIC Program サイトでは、LPI の 3 つの Linux
システム管理資格認定レベルについて、詳しい目標、タスクのリスト、そして出題例を調べられます。特に、LPI-302
の具体的な目標とタスクおよび出題例を調べてください。
- developerWorks の連載「LPI exam
prep」をすべて読んで、Linux の基礎を学び、2009年4月以前の LPI 試験の目標に基づくシステム管理者認定試験に備えてください。
- 「Exam
Preparation Resources for Revised LPIC Exams」に、LPI で管理している他の認定の教材がリストされています。
- developerWorks Linux
ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
- Twitter で developerWorks をフォローするか、developerWorks
で Linux に関するツイートのフィードに登録してください。
- さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical
events and webcasts で時代の流れをキャッチしてください。
- 無料の
developerWorks Live! briefing に参加して、IBM 製品およびツール、そして IT 業界の傾向を素早く学んでください。
- developerWorks の
on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
製品や技術を入手するために
smbldap-toolsパッケージは、Samba と LDAP の統合を大幅に簡易化します。pam_smbを使用すると、Microsoft クレデンシャルを使って Linux サーバーにログインできます。- Samba の最新バージョンを入手して、最新機能を追加してください。
- 複数の環境のデータにアクセスするには、IBM Tivoli
Directory Integrator の試用版を検討してください。
議論するために
- My developerWorks
コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
