!== !== PROFILES.txt for Samba release 2.0.7 26 Apr 2000 !== 寄稿者: Bruce Cook Copyright (C) 1998 Bruce Cook John Terpstra Copyright (C) 1998 John H. Terpstra Wolfgang Ratzka Copyright (C) 1998 Wolfgang Ratzka 作成日: April 11, 1998 更新日: April 11, 1998 翻訳者: 中野武雄 (nakano@apm.seikei.ac.jp) 翻訳日: November 3, 1998 主題: ユーザプロファイルにについて (User Profiles) =========================================================================== From BC3-AU@bigfoot.com Sat Apr 11 13:36:05 1998 Date: Sat, 11 Apr 1998 17:13:49 +1000 From: Bruce Cook To: Multiple recipients of list Subject: RE: A question about NT Domains Luke Kenneth Casson Leighton writes: > On Fri, 10 Apr 1998, Jean-Francois Micouleau wrote: > > > On Fri, 10 Apr 1998, Luke Kenneth Casson Leighton wrote: > > > > > えっと、もう少し詳しく説明する必要がありそうですね。二人以上 > > > のユーザーが同じプロファイルを使う場合です。例えば、一人のユー > > > ザーがプログラムをインストールして、その結果レジストリにキーが > > > 追加されたとします。このようなキーは、次のユーザーがログインし > > > たときにも HKEY_LOCAL_USER からは削除され*ない* と理解している > > > んですが。 > > > > W95 ですか、それとも NT ？ > > 私の経験は Win 95 でのものですが、多分 NT でも同じたと思います。 > NT の管理者養成コースを経営している人からもそのように聞いたことが > あります。 > > > あと、なぜ一つのプロファイルを複数のユーザで共有したいのでしょうか？ > > いえ、共有しなくてもいいんです。　共有したい、といったつもりはありま > せんでした。　言いたかったのは、複数のユーザーが「同一の」プロファイ > ルを持つことに関してであって、「一つの」プロファイルを共有することで > はありません。 私の経験 (Win95 と NT の両方) では、HKEY_LOCAL_USER の情報は USER.dat (NT の場合は NTuser.DAT) に保存されます。これ以下のブランチの全てが このファイルに保存されるので、別々のユーザーの間で重複が生じることは ないはずです (もちろん 95 で、共通のプロファイルを使うように設定した 場合は別です)。 [lkcl: 重なりが生じ得る条件については、 jht のコメントを参照のこと] HKEY_LOCAL_MACHINE のブランチはマシンに関連したものですから、その マシンを用いる全てのユーザによって共有されます。 [では以下このあたりを詳細に] 1. ユーザのスタートメニューのパスは、(当然ですが) レジストリには保存 されていません。これはディレクトリ構造そのもので、HKEY_LOCAL_USER が設定している場所に置かれています。 「スタートメニュー」や「デスクトップ」「お気に入り」をユーザごとに 別々にしたければ、ユーザレジストリを編集して、これらの示す先が ユーザごとに異なるようにする必要があります。これを最も簡単に行うには、 ポリシーエディタを用いるのが良いでしょう。 2. Windows 95 にログインが行われると、 95 はそのユーザーのレジストリを 見つけなければなりません。 プロファイルを共有するように指定してある場合は、"default user" の USER.DAT が用いられます。 各々のユーザごとに別個のプロファイルを使用するように指定してある 場合には、次の手順にしたがって用いられる USER.DAT が決定されます。 1. スタートアップで NET USE x: /HOME が実行された場合には、 x:\USER.DAT を読み込もうとします (x: はドライブレターで、 A から Z までの一文字です)。ここに USER.DAT がない場合は、 ステップ 3 に進みます。 2. ドライブのマッピングで home が指定されなかった場合は、 ...\windows\profiles\username\USER.DAT が用いられます。 ここに USER.DAT がない場合はステップ 3 に進みます。 3. 上記の二つのステップで USER.DAT が見つけられなかった場合は、 USER.DAT のプロトタイプをオープンします。　そして、後にユーザ がログアウトすると、上記で指定したようなパスに更新された USER.DAT を保存します。 ここで注意すべきことは、プロトタイプとして用いられる USER.DAT は、このマシンで最後に用いられた USER.DAT である、 ということです。 (これが、オリジナルの投稿にあったような現 象の原因でしょう) 4. 先に述べたように、スタートメニューとデスクトップは、 USER.DAT に含まれているレジストリに書かれています。プロトタ イプから新しい USER.DAT が生成されるときに、スタートメニュー やデスクトップに対応する新しいディレクトリも作成されるわけ ですが、これは「コピーされたプロトタイプの指定にしたがって」 行われます。 したがって、 USER.DAT のプロトタイプには「スタートメニューは H:\Start Menu である」と書いてあるのに、実際のプログラムフォ ルダが C:\widows\start menu\programs であるような場合には、 H:\start menu が作成され、そのマシンの (すでに存在している) programs フォルダが用いられます。 つまり roaming な profile (システム間で共有されるプロファイル) を作成する際には、以下のようにすることが重要だということです。 まず USER.DAT のプロトタイプと一般的なユーザのディレクトリ 構造を、望むように設定します。そしてそれらを変更されない 場所に保存しておきます。新しいユーザを作るときには、この プロトタイプを新しいユーザの領域にコピーするのです。そうすれば、 新しいユーザが直前のユーザの環境を引き継がずにすみます。 3. Windows NT にログオンする際には、NT がユーザレジストリを見つけられ るようになっていなければなりません。 NT では何が起こっているかがもうちょっとわかりやすくなっていますが、 基本的なルールは 95 と同じです。大きな違いは『NT はプロファイルの 置き場所をログインしたときにサーバから取得する』ということです。 (NT システムで、ユーザマネージャ/ユーザプロファイルを見てごらん なさい - ユーザプロファイルのパスを指定できるようになっていることが わかるでしょう。) NT 3.51 では、このプロファイルのパスは NTuser.DAT へのパスでした。 4.0 では、ディレクトリ構造の置かれているパスに なっているようです (NT4 サーバはあまり使ったことがないんです)。 これが samba の場合どのように動作するか、はっきりしたところを私は知り ません。まだ NT_DOMAIN 機能を試したことがないからです。 (Luke: 適当 なキーワードはないでしょうか？) [lkcl: NT ワークステーションは、 samba でも他の SMB サーバ (NT サーバ 含む) でも、まったく同じところを見に行くようです。その SMB サー バが NT と同じように見えれば、ですが。何かうまくいかないことが あったら、 samba@samba.org まで知らせて下さい。調べ てみます。] NT システムが NTuser.DAT を持たないユーザを発見すると、プロトタイプ をコピーしてきます。このプロトタイプは専用に用意されているものなの で、 95 の場合とは異なり、そのユーザは、マシンで最後に行われていた 動作に関りなく、適切な最小限度の設定を受け継ぎます。 [[jht: Win95 マシンが NT ドメインにログオンすると、その Win95 マシンは Config.Pol というファイルを、以下の場所から見つけようとします。 \\"Authenticating Server"\NETLOGON 95 マシンはこのファイルを読んで、デスクトップ環境と %WinDir%\Profiles\%USERNAME%\User.DAT の双方を修正します。 NT の場合のように、このファイルはログアウトの際にプロファイルサーバに 書き戻され、プロファイル共有の %USERNAME% ディレクトリに書き込まれます。 :jht]] 4. Windows マシンが USER.DAT を見つけることができず、デフォルトのプロ トタイプを用いてしまう原因には、非常に多くのものがありえます。 1. ログオンスクリプトを実行できず、したがって /HOME をマッピン グできなかった (最もよくある原因です)。 ・スクリプトがあるかどうか確認して下さい。 ・ログオンスクリプトのセットは正しいでしょうか？ ・netlogon 共有が存在していますか？ ・スクリプトと共有のプロテクション・所有者は適切でしょうか？ 2. ログオンスクリプトに /HOME のマッピングがない。 3. /etc/smb.conf で、home パスが指定されていない (または NT の ユーザマネージャで、そのユーザの home マッピングがされてい ない)。 4. ユーザディレクトリのプロテクション・所有者が正しくない。 5. USER.DAT のプロテクション・所有者が正しくない。 6. 基本的なネットワークの問題 ・ネットワークは利用可能になっていますか？ (user 共有と netlogon を手でマッピングできるか試してみましょう) ・ログオンの段階で、ネットワークはちゃんと動作しているでしょ うか?　 7. 以前にプロトタイプがデフォルトのものになってしまったことが あり、そのあとにホームディレクトリのマップを行いましたか？ - こうすると性質の良くないプロトタイプが、そのユーザの home に書き込まれてしまい、そのせいでうまく行かなくなる場合があ ります (もう一度 USER.DAT を置き換えてみましょう) 5. その他の注意点 95 がログオンスクリプトを実行しているあいだには、 HKEY_LOCAL_USERS は USER.DAT からマップされません。この段階で マップされるのは、プロトタイプのレジストリ (最後に用いられた もの) なのです。 おそらくこの理由は、ログオンスクリプトの実行が完了し、ユーザの ホームディレクトリの場所がわかるようになるのを 95 が待っている からではないかと思います。 この段階で USER レジストリを用いる作業を行おうとすると (例えば 何かをインストールしたり、ユーザレジストリから何か情報を読み 出そうとすると)、ユーザプロファイルではなく、マシンに保存された プロトタイプのプロファイルが操作の対象になってしまいます。 すなわち、そのユーザの設定には何もおこらないのです (メニュー アイテム、設定、その他)。 この問題を避けるには、プロセスを HKEY_LOCAL_MACHINE ブランチの "run once" エントリに登録する方法があります。これらの "run once" プロセスはUSER.DAT がロードされた後で実行されるので、ユー ザのディレクトリすべてにアクセスできます。 以上まとめます: NET USE H: /HOME は、ユーザプロファイルをサーバからロードするために重要な作業です。 NET USE H: \\server\homes では、ちゃんと動かすのには余計な手間がたくさんかかってしまいます。 Windows 95 では、ユーザプロファイルを取ってくる前に、多くの作 業が行われます。そして、この段階で何か問題が起きると、そのマシ ンで直前に使われていたプロファイルを、それが何であれ使うように なってしまうのです。 From samba@aquasoft.com.au Sat Apr 11 13:48:54 1998 Date: Sat, 11 Apr 1998 09:34:08 +1000 From: Samba Bugs To: Multiple recipients of list Subject: Re: A question about NT Domains 重箱の隅ですが、ちょっとだけ追加したほうが良いかと思いました。 レジストリの変更に (あるいは内容に) どのファイルが関与しているのかを 明らかにしておきましょう。 NT で、コマンドプロンプトのインターフェースを開いて下さい。 cd %SystemRoot%\System32\config dir 標準のレジストリファイル群は、以下のようなものです: Default - デフォルト設定のすべて System - HKLM\System エントリのすべて Software - HKLM\Softoware エントリのすべて Security ドメインやマシンに関連したユーザ権限・特権 SAM - セキュリティアクセスマネージャ (Security Access Manager) のデータベース (パスワードなど) [[jht: SAM と Security 関連のファイルだけが、Windows NT ドメインコントローラと 同期して変更されます。 :jht]] これらは「すべて」に用いられます!! ユーザがログインすると、以下のファイルがチェックされます: 1) \\"Authenticating Server"\NETLOGON\NTConfig.Pol 2) %SystemRoot%\Profiles\Policies\NTConfig.Pol これは (1) によってダウンロードされた最後の NTConfig.Pol のコピーになります - もしそれが可能であれば、ですが。 3) %SystemRoot%\Policies\%UserName%\NTUser.DAT [[jht: Windows NT のシステムポリシーエディタは、Windows 95 の "Config.Pol" ファイルの作成にも、また Windows NT の "NTConfig.Pol" の作成にも用いる ことができます。 Windows 95 のポリシーファイルを作成するには、 Config.Pol ファイルを作成する「前に」、 Windows 95 のポリシー テンプレートをロードしなければなりません :jht]] 最後のファイルは、まずプロファイルサーバから取得されます。ただし ドメインログオンサーバから渡された User_Init_Info で、移動プロファイル (roaming profile) が指定されていることが必要です。上記 (3) が存在しな い場合、またはデフォルトのプロファイルが取得できない場合には、システムの デフォルト設定と、上記 (2) で最後にロードされたファイルとから プロファイルが生成されます。 HKCU は現在ログインしているユーザに対して常にユニークです。しかし、 もしそのユーザが排他的に作成されたものではない共有プロファイルを用いて いる場合には、ログアウトの際に、HKCU がソースファイル群に上書きされます。 これが、強制プロファイル (mandatory profile) が移動プロファイルの共有 に際して重要だ、という理由なのです。 On Sat, 11 Apr 1998, Wolfgang Ratzka wrote: > Luke Kenneth Casson Leighton wrote: > > > 私の経験は Win 95 でのものですが、多分 NT でも同じたと思います。 > > NT の管理者養成コースを経営している人からもそのように聞いたことが > > あります。 > > NT では、全く異なります。 HKCU は常に、全体がユーザの NTuser.dat ファ > イルからロードされ、ログアウトのあとに再びアンロードされます。実は > HKCU は正しいレジストリの巣ではなく、カレントユーザに対応したサブキー > HKEY_USERS のシンボリックな参照なのです。もし複数のユーザが一台の NT > マシンに入ると (素のままの NT でシステムユーザ以外の権限でサービスが > 走っていると、このようなことが起こることがあります。 WinFrame や > Hydra では、複数のユーザがログインすることができます)、それらのユーザに > 対応して、 HKU のサブキーが複数現れるはずです。これらはお互いに > 干渉しません。 > > もちろんユーザが変更可能な設定には、 HKCU ではなく HKLM に入るような > ものもあります。特に例をあげれば、スクリーンの解像度と色数がそうです > (これらを変更できないようなポリシーを用いることもできます)。 > アプリケーションによっては、HKCU に入れるべき情報を HKLM に入れてし > まうようなものもあります (そのようなものの殿堂: Netscape > Communicator, Microsoft Office 97 [ユーザー辞書]...)。 > また、古きよき INI ファイルをプログラムディレクトリ (ひどい場合には > \WINNT\SYSTEM32) に置いて使うだけのものもあります。これらでは、変更 > 内容はユーザごとには行うことができず、マシン単位になります。またこの > ようなプログラムを WinFrame や Hydra から実行すると、トラブルのもと > になります... :-) > > 以上まとめます: > > Q: 次のユーザは、前のユーザが HKCU レジストリへ追加した内容を > 継承するのですか？ > A: いいえ、そんなことはありません。 そのとおり、正しいです。 > > Q: あるユーザが、その次にログオンするユーザの設定を混乱させてしまう > ことはありますか？ > A: はい、そのとおり。あります！ 上記を参照して下さい。あります。でもそれは設定が正しくない場合です。 > > Q: このような議論は samba-ntdom の ML にはふさわしくないでしょうか？ > A: うーん... そうでしょうか？私はふさわしいと思いますよ。他の人が samba を安定して、 いろいろな作業に用いることができれば嬉しいでしょう？違います？ > -- > Wolfgang Ratzka (家からダイアルインです) では。 John H Terpstra (私も家からです!!) ============================================================================= さらに Bruce Cook より寄せられた情報。 Date: Sun, 12 Apr 1998 14:12:22 +1000 From: Bruce Cook Subject: Re: Win95 / NT Profiles (was: RE: A question about NT Domains) あーはいはい、何か忘れているのはわかってます。 さらに完全を期すために、以下を。 ============================================================================= ユーザーが特定のマシンに最初にログインすると、そのマシンには以前にログ インしたことがないといわれ、今後のためにユーザ設定を保存するか、という ことを尋ねられます。 ここでユーザが「いいえ」と答えると、「はい」と答えるまで毎回ログインす るたびに、同じ内容をうるさく尋ねられます。(これはもうちょっとなんとか できないもんなんでしょうかね) ユーザが「はい」と答えると、その後マシンからログアウトするときに、 ユーザのプロファイルがそのマシンのローカルディスクに書き込まれ、 次の時から利用されます。 以前に自分のプロファイルがセーブされたマシンにログインすると、 そのマシンに保存されているプロファイルのコピーの日付が、サーバに 保存されているプロファイルの日付と比較されます。理論的には サーバの日付のほうが新しい、少なくとも両者の日付は一致する、 はずです。 ローカルマシンの日付がサーバのものより新しいと、クライアントマシンは 『ローカルな設定のほうがサーバのものより新しいが、そちらを使うことに するか』という内容をユーザに尋ねてきます。 これが起こる理由としては、以下の二つが考えられます。 1. ログアウトの時にサーバに接続できなかった。 2. サーバとクライアントの時刻が合っていない。 (私は常にログオンスクリプトで NET TIME \\server /SET /YES を用いるようにしていますが) サーバに一つも接続できない場合でも、ログインを行うことは可能です。 場合によっては、サーバがまったくないネットワークにログインする必要が 生じることもあります (モバイルマシンをオフィスの外で使う場合や、サーバが 死んでいる場合など)。 これが可能なのは、サーバーからのパスワードで認証された場合にのみアクセ スを許すような設定を、管理者がして「いない」場合です。(こうなっている 場合でも、なんとかすることはできます。マシンをセーフモードで再起動し、 poledit か regedit でこの機能を無効にすればよいのです。) サーバが使えない場合にもログインできる場合には、二つの選択肢があります。 1. 直前にプロファイルを保存したユーザとしてログインする (そのマシンにパスワードが保存されるような設定になっていなけ れば、パスワードはマッチしなくても大丈夫です) 2. デフォルトのユーザとしてログインする (キャンセルボタンか エスケープキーを押す)。 プロファイルをローカルなマシンに保存することにした場合は、いくつか面倒 なことが生じます。 1. マシンに保存されたプロファイルは、「その」マシンに最後に ログインしたときに用いられたプロファイルのコピーになります。 もしかしたら、すごく古いプロファイルをつかまされるかもしれ ません。 2. ログアウトの際に、そのローカルなプロファイルはサーバのもの よりも新しいとされます。したがってサーバが利用可能な場合や、 または以降のログインでサーバが利用可能になっている場合には、 サーバの正しいプロファイルを、古いしょーもないプロファイル で上書きしてしまうかもしれません。 ちょっとしたテクニック: 私はモバイルコンピュータでは、移動プロファイルを用いないで、そ のマシンで保存されるプロファイルだけを使うように設定してありま す。これによって、ユーザはどこでも同じ look & feel のデスクトッ プを使えるようになります。これは、ラップトップは一人のユーザに しか利用されない、という哲学に従ったものです。