isLandcenter 非番中

Certificate Authority サーバを交換する方法

Certificate　Authority　これが何だと言われると正直わからないのですが．．．．

NetWare5.0以降、認証サービスが実装され、一番最初にインストールされたサーバが Certificate Authoriry となっています。つまり NetWare 5.0//5.1 を最初にインストールして、認証サーバをインストールした一番古いサーバということです。

古いサーバですからハードウェアの交換を考えなければなりません。



リンク切れ
Certificate Server Issues-Removing a Server from a Tree

こちら
Certificate Server Issues-Removing a Server from a Tree

iManager から行う場合
How do I move the Organizational CA to another server?

このサーバも古くなったので新しいものに入れ替えたいと思うところですが、簡単には行きません。上の文書によると Migration Wizard を使えば問題ないということですが、あのプログラムは一発屋のプログラムなので、途中で失敗した場合は悲惨なことになります。

したがって、Certificate Authority のハードウェアの交換は、一応上の文書にしたがってやることにしましょう。

まずは Root の Security コンテナにある W0 オブジェクトを削除します。



次にサーバコンテナにある SAS, Certifitate DNS, Certificate IP 各オブジェクトを削除します。



Security コンテナの Organization CA オブジェクトも削除します。

この状態から新しいハードウェアに NetWare サーバをインストールします。



Autorityのない状態でインストールしたサーバに Organization CA が作成されます。



できれば、CA局を持つサーバは仮想化して動かしたいところです。Xen でもいいのですが、xenは NetWareは対応していないので VMware などで動かしておいて、ハードウェエアのトラブルがある場合は別な装置で動かすのが理想かもしれません。

非番のエンジニア

ZENworks アプリケーション配布をチューニングする。

SnapShot で作成したアプリケーションは通常ではそのまま配布に適さないことがあります。適さないまでも、さらに細かくチューニングすることでいくらでも応用が利くことを覚えておけば、SnapShot を作るまでもなく、必要であればショートカットの配布やレジストリの変更などもできるようになります。

-余分なレジストリの削除

アプリケーションの配布オプションタブの中に「レジストリ」タブがあります。



ここには SnapShot で取得したレジストリの変更箇所がすべて収まっています。つまり、ＳｎａｐＳｈｏｔ取得中に変化したレジストリの変化すべてですから、エクスプローラのウィンドウの変化だとか余分なレジストリデータがあります。アプリケーションにとって必要なレジストリの変化は全て削除してしまいましょう。

というより、ここにコツがあるのですが、snapshotをとるときにあわててセットアッププログラムを探しちゃいけないということ。セットアップのショートカットをあらかじめデスクトップに用意しておくとか、SnapShotを起動する前にセットアッププログラムを立ち上げておいてもいいかもしれない。

モノによっては再起動をする場合もあるから注意は必要です。

このレジストリの変更機能を利用して、逆にレジストリだけを配布したり削除するアプリケーションオブジェクトも作ることができます。

-強制配布



通常、アプリケーションを割り当てると、 Nal ラウンチャの中にアイコンがあり、これをクリックすることでインストールされるようになります。割り当ての左端のチェックボックスは「強制実行」です。このチェックを入れるとラウンチャが起動すると自動的にインストールされるようになります。

実際の運用では、アプリケーションのアップデート、パッチの配布、レジストリの修正などですから、ほとんどのケースでは「強制実行」チェックを入れることが多いでしょう。テスト段階ではチェックしないほうがよいでしょう。

応用すれば、たとえば学校の授業で強制的に授業で使うスプレッドシートのネタを開かせたり、組織で必要な「■重要-必ずお守りください■.txt」などをログイン直後にメモ帳で開かせるなどというテクニックもあるでしょう。


-ログの取得

配布の結果をログとして記録することができます。



たいていログはサーバ上のディレクトリを指定することになりますから、ディレクトリにはユーザの書き込みの権限が必要です。

-配布のソースパス

初めてアプリケーション配布にチャレンジして失敗して頭を悩ますのはここです。



まず、SnapShotを取得して書き込んだ先のディレクトリが Source_Path として指定されています。実際には SnapShot を D: に取得したとか、ITのチームが使っているテスト用サーバを指定しているとか、あと、一番間違え易いケースが、SnapShotの元ディレクトリにユーザのアクセス権限がないというケースでしょう。

この部分は一番最初にチェックするところです。

-ショートカット

アプリケーションによっては、余計な自社のウェブサイトに誘導する URL や Uninstall のショートカットを丁寧に作ってくれるものがあります。



こういった余分なショートカットは削除してしまいましょう。また、アプリケーションをアップデートするような場合、古いバージョンのショートカットを削除することもできます。標準機として配ったPCに余計なショートカットがある場合、ショートカットを削除するだけのアプリケーションも作ることができます。

-ファイルの配布

SnapShot は aaaa.exe というファイル名を nnn.fil という名前に加工して格納します。



もし hosts だけを変更したいというアプリケーションを作りたい場合、 hostsを 1.fil に変えて配布すればよいことになります。

またアプリケーションによっては ini ファイルによって初期設定を行う場合がありますので、 ini ファイルが snapshot のどのファイルに相当するか確認して直接 ini ファイルを配布するというテクニックも使えます。

- AXT ファイルの加工

これらの元となるネタは全て AOT/AXT ファイルに記述されていることです。もし、アプリケーションを実装する段階になり、全てのアプリケーションオブジェクトをこのように加工して実装するのは非常に面倒なことです。

小規模な組織であれば、アプリケーションの実装は一度で済みますが、拠点がたくさんあり、実装を複数のサーバに行いたい場合、もっと簡単な方法はないのでしょうか。

ということで実際に取得して作った SnapShot のアプリケーションには実装手順 AOT/AXT ファイルがあります。直に AXT ファイルを修正して、余分なレジストリを削除したり、インストール先を標準のインストール先から代えたり、ショートカットの作成を制御することができます。

多くの外資系企業ではそのような SnapShot を事前に作成して、世界の各拠点のITメンバーに配布して運用しています。

非番のエンジニア

SnapShot でアプリケーションやレジストリを配信

SnapShot アプリケーションがインストールされるのは NetWare サーバ版だけです。OES Linux へは残念ですがインストールできません。

NetWare 版へ、 Desktop Management をインストールすると自動的に SYS:Public\SnapShot が作成されるので、これを OES Linux にコピーするなどして利用するしかないようです。不便で不親切ですがまぁこれも仕方ないでしょう。次のバージョンで改善してほしいところです。SnapShot を使ってアプリケーション配信を行いたい場合は NetWare 版をとりあえずインストールして利用するしか今のところなさそうです。

SnapShot というのは、アプリケーションのインストール前、後のC:ドライブの変化、ファイルの更新、レジストリの更新を差分として記録するアプリケーションです。

この差分をアプリケーションオブジェクトとして登録しておけば、ネットワークへのアプリケーション配信が実に簡単に実現できます。



SnapShot を起動します。いくつかウィザードがあるので、必要事項をセットすると、「アプリケーションをインストールする前」の状態をスキャンします。



スキャンが終了するとアプリケーションのインストールを開始してください。



アプリケーションのインストールが終わると「インストールした後」の状態をスキャンします。



スキャンが終わると xxxx.fil と AOT(バイナリ) AXT(テキスト)のインストールファイルが作成されます。 ConsoleOne からアプリケーションオブジェクトの作成を行います。



いくつか必要なウィザードに答えて、アプリケーションオブジェクトに割り当てます。



Windows ワークステーションの Application Explorer を開くと、作成されたアプリケーションアイコンが出ます。



ユーザはこのアイコンをクリックして実行すれば、アプリケーションは自動的にインストールされます。



SnapShot を作成するには「クリーンな」ワークステーションが必要です。 XEN でクリーンなワークステーションディスクイメージを作って、XEN のディスクイメージからアプリケーション配布のテストを行うのが良いでしょう。

アプリケーションはとりあえず作成すること。作成した後のアプリケーションはさまざまに修正できます。

非番のエンジニア

ZENworks のユーザポリシー（グループポリシー）

ZENworks が　Active Directory のポリシーと最大に違うところは、ポリシーの適用がOU単位だけではなく、グループ、ユーザに対しても適用できる点です。たとえば、AD も併用して使っている組織では Dynamic Local User を使用しないポリシーを作らなければならないでしょうし、そういうグループのためのポリシーを別に作ることができます。通常の企業ではそういったユーザは混在して存在することも多いでしょうし、人事異動というのはシステムが考えた以上に頻繁に行われるものです。

また、いくつものOUが存在する組織であれば、ひとつのポリシーでグループに対して適用させることもできるわけで、いくつものポリシーを管理する必要がありません。またIT部門であっても一般のユーザ（たとえば開発系）のユーザとヘルプデスク、システムオペレータ、技術運用部門とでは適用すべきポリシーが異なる場合があるでしょう。

また、学校などでは、教職員、生徒、システム管理＋ヘルプデスクなどの３種類程度のポリシーを作ります。

ここでは主に、一般ユーザのポリシーと、管理者向けのポリシーをどのように設計すればよいかを考えてみることにします。



ユーザポリシーオブジェクトを作って、グループポリシーをチェックしてプロパティを開くと出てくるのがこの画面です。
「ユーザのログアウト時にポリシーを無効にしない」というチェックボックスがあります。このチェックを入れると最初に読み込まれたグループポリシーが次のログインでも有効になるということです。

-一般ユーザのポリシー
一般ユーザのポリシーではこのチェックはオンにしておきます。次のユーザ（一般ユーザ）がこのワークステーションを利用するときも同じポリシーが自動的に適用されます。

-管理者、ヘルプデスク
管理者、ヘルプデスクのポリシーはこのチェックを必ず解除します。解除するためのポリシーがダウンロードされて、自由にユーザのワークステーションを操作して変更することができます。また、このポリシーはログアウト後、無効になるため、一般ユーザが再びログインすると、一般ユーザ用のポリシーが適用されます。

一般には「ユーザの環境設定をキャッシュする」はチェックしない方が無難なようです。このあたりはヘルプをよく読んでください。

-グループポリシーの編集

ユーザのグループポリシーは、ユーザがログインして誰でもアクセスできるディレクトリに作成します。SYS:Login の下でも構いませんし、NetWare 版の場合は SYS:Public\ConsoleOne 以下がデフォルトで選択されます。

「編集」ボタンを押して、MMCを起動します。


「ユーザの構成」から、Internet Explorer の設定、管理用テンプレートなどをそれぞれ「構成」してゆきます。

一般ユーザ用テンプレート

たとえば、IE の設定など、特定のプロクシを通さない限りインターネットに出られないように設定したり、デフォルトで社内のポータルサイトを開くように設定するのがよいでしょう。
また、プログラムの追加と削除、コントロールパネルへのアクセス、スクリーンセーバーの設定が変えられないようにタブを削除する、ネットワークコンピュータをエクスプローラから削除する。特定のドライブを見せないようにする。 Regedit を使用できないようにするなどを「構成」します。

-管理者用テンプレート
管理者用テンプレートは「一般ユーザ」で制限されたポリシーを全て「無効」にする設定にしなければなりません。「未構成」のままではユーザが「制限」されたポリシーをそのまま引き継いでしまうため、修復したり問題解決することができなくなります。

-特定のドライブのみ見せる
この方法は別な項で説明していますが、必要によってはネットワークにマップされたドライブだけを見せる方法を使うことで、セキュリティ上の問題をずいぶん軽減させることができます。たとえば、P:(Private) と S:(Shared) ドライブだけがマイコンピュータに表示されなければ、いくらUSBドライブを挿してもエクスプローラからは認識させることができません。また、C:ドライブへの保管ができませんから、ほとんどのユーザはデータをマップされたドライブに保存するようになります。
必ずしも完璧ではありませんが、このようにユーザを誘導することで、データの損失やPCの紛失などから発生するセキュリティインシデントの頻度を低くすることができます。

非番のエンジニア

ノベル、アジア太平洋地域にも Novell Linux Champions Club を発足

ノベル、アジア太平洋地域にも Novell Linux Champions Club を発足

ノベル、アジア太平洋地域でNovell Linux Champions Clubを発足 プレスリリース

プレスリリースだけで、あまり具体的な参加方法とか活動内容、方針はなし。ロケット花火みたいなものかな。

グループポリシーを作る（ワークステーションパッケージ）

ワークステーションポリシーパッケージのグループポリシーは、ワークステーションの起動中にダウンロードされます。まだユーザ認証を行っていない時点でダウンロードされるため、基本的には、「誰でもアクセスできる」読み込み専用のロケーションに作っておくことが望ましいでしょう。

推奨できるのは SYS:Login の下です。

OES Linux でグループポリシーを作るとしたら /usr/novell/sys/LOGIN/ の下が良いと思います。ここに Workstations, GeneralUserDLU, AdminUserDLU などのディレクトリをあらかじめ作成します。

ワークステーションパッケージからグループポリシーをチェックしてプロパティボタンを押すと、次の画面が起動します。



ここでマップ済みの SYS:Login の下のディレクトリを指定すると、自動的にパスはUNCパスをセットされます。

「ワークステーション設定を保持する」は必ずチェックしておきます。

この状態から「ポリシーの編集」ボタンを押して MMC を起動します。

ここで設定するのは「コンピュータの設定」です。
「管理用コンポーネント」＞「システム」の下にさまざまに設定する内容があります。

特に「ログインスクリプトを同期的に実行する」を有効にしておくべきでしょう。これは eDirectory のログインスクリプトの実行を待ってから Explorer の起動を待つ機能です。



Windows の起動は遅くなりますが、ドライブマップが終わってからコンポーネントが起動できるので、例えば My Document をネットワークにリダイレクトするような場合は有効に機能させなければなりません。

移動プロファイルを使用する場合「低速回線を検出しない」もチェックしておきます。



右上の×マークを押してグループポリシーの設定を終了すると Login ディレクトリにグループポリシーが保存されます。

グループポリシーの設定に関してはここでは詳細に述べることはしません。 Windows に関するさまざまなテキストが出ているのでそちらを参考にしたほうが良いでしょう。

あとは、ポリシースケジュールタブからイベントのスケジュールを設定します。通常はシステム起動時でOKですが、スケジュールでポリシーのダウンロードが実施されるまで、若干のタイムラグがあるようで、当初は奇妙な動作をするかもしれません。

ZENworks で壁紙、スクリーンセーバー、ローミングプロファイルの設定

多くの企業のセキュリティポリシー運用のひとつとして、スクリーンセーバーによるパスワードロックを実施しています。ユーザが離籍している間、スクリーンセーバーが起動してパスワードがないと解除できない機能ですね。

-壁紙とスクリーンセーバーの設定

ZENworks ではこの機能はユーザポリシーとして定義されています。

ユーザポリシーから、「Windows デスクトップ初期設定」をチェックしてプロパティを開きます。「デスクトップ初期設定」タブから「設定」タブを開くとこの項目が出ます。

「eDirectory 認証時に常にデスクトップを更新する」チェックは必ずチェックします。



「表示」ボタンを押すと、壁紙とスクリーンセーバーの設定画面が現れますので任意のスクリーンセーバー、壁紙をセットすることができます。



デフォルトは０分なので１５分程度にセットします。

このスクリーンセーバーの設定はグループポリシーにも同様にセットする箇所があり、どちらを設定しても同様に効果があるようですがどちらが有効なのかは判りません。一応同じ設定をグループポリシーに対しても設定しておくことをお勧めします。

壁紙やスクリーンセーバーは Windows のデフォルトのものが利用できますが、企業として自社のロゴや自社製のスクリーンセーバーを利用しているところが多いようです。

もっとも、壁紙はあくまでも初期設定なので、ブラウザなどで読み込んだ画像をユーザが勝手に壁紙に変更することは阻止できません。

壁紙の設定はユーザポリシーなので、ユーザポリシーが正しくダウンロードできない場合、壁紙も変更されません。ユーザポリシーが正しく動いているかどうかは壁紙の動きでチェックします。

-ローミングプロファイルの設定

ローミングプロファイルは、"c:\Document and Settings"の内容をサーバにコピーして、どのワークステーションでユーザがログインしてもその内容をC:ドライブにコピーしてくれる機能です。



デフォルトで有効にすると、ローミングプロファイルはユーザのホームディレクトリに作成されます。学校のコンピュータ室のように、不特定多数のユーザが同じ環境で利用したいといった場合には便利な機能です。

ある意味、ユーザが My Document に保存したデータをログオフする際にサーバにバックアップする機能ですからユーザデータのバックアップという意味では便利な機能には違いません。ただし、 My Document に大量のデータを保管している場合、ログインからドキュメントのリロードまで時間がかかるため、問題もあります。グループポリシーと微妙な調整が必要になります。

また、My Document のプロパティから、保存先をネットワークにマップされたドライブにしておくなどの工夫が必要になります。

ZENworks のリモート管理 - ヘルプデスクの必殺技

ヘルプデスクにとっては、ユーザからの問い合わせほどうっとうしいものはありません。訳のわからないユーザの言い訳、意味不明のオペレーション、不正確な報告。

ああ、その時のユーザのデスクトップがちらりとでも見れればなぁと思ったことはありませんか。そうすれば、わざわざ非常階段を走り回ることもなければ、自席を外して他のインシデントを逃すこともありません。ある程度事象を調べてから対策に赴くこともできる筈です。

ユーザにとっても、ヘルプデスクが自分の席にしがみついてトラブルシューティングする姿は仕事の邪魔者でしかありません。口には出さなくても少なくとも現象調べてから来いよ、って言いたくなることもあるでしょう。

ということで ZENworks Desktop Management にはリモート管理の機能が付いています。リモート管理のポリシーは有効にチェックを入れるだけで、他にはほとんど必要な設定はありません。リモート管理ポリシーは、ユーザポリシーとワークステーションポリシーのどちらにも設定があります。



あとは、インシデントの発生したユーザ、またはワークステーションオブジェクトをポイントして「アクション」からリモート管理を実行するだけです。



ConsoleOne からリクエストがワークステーション側へ飛びます。



ユーザがこのリクエストに対してOKを出せばリモートコントロールを行うことが出来ます。

例えば「ファイル名を指定して実行」から

> runas /user:MyPC\administrator cmd

を実行すれば、ユーザPCの管理者として操作することができます。この状態から Notepad で Hosts を書き換えたりはヘルプデスクの自由です。当然プリントスクリーンも取れます。



使えないことも多いのですが、Shiftキーを押しながら右ボタンを押すと「別なユーザで実行」のメニューが出る場合もあります。必要であれば、この方法で設定を変更することも可能でしょう。

リモートコントロールを許可/不許可できるユーザを指定することができます。例えば一般スタッフのヘルプデスクは派遣社員に許可して、VIPや管理部門の重要なPCは正社員が実施できるというような運用や、ヘルプデスクがやっている操作を一切ユーザには見せない（ブランクスクリーン化する）などのオプションがあります。

ヘルプデスクの仕事は走り回ることでもなく、ユーザが問いかけた謎解きをすることではありません。ひとつでも多くのインシデントを解決することがヘルプデスクの本来の姿です。

実際には全米、数十拠点の営業所のヘルプデスクを ZENworks により一箇所にまとめてしまったマーケティング会社の事例や、ゼネコンの地方の現場監督事務所のヘルプデスクを ZENworks を使ってサポートしている事例などがあります。

Dynamic Local User(DLU) ZENworks の夢の機能

Novell 製品を使っていながら ZENworks を導入していないネットワークはつくづく不幸だと思います。外資系で Novell 製品を使っているところは例外なく ZENworks を使っていると言っていいでしょう。

その最大の機能が Dynamic Local User (DLU) と呼ばれる機能です。

普通、 Windows XP でローカルユーザを管理しようとします。



当然、管理者か制限ユーザしか作ることが出来ません。管理者では全ての機能がユーザにとって自由だし、制限ユーザではあまりにも出来ることができません。プリンタの設定ですら管理者がイチイチ現場に赴いて作業をしなければならないのです。

また、ネットワークに入るときは .myname.myou.myorg でログインして、ローカルには user というアカウントでログインするという奇妙な運用を実施しているところもありました。つくづく ZENworks を知らないということは不幸なことだなと思います。

なぜ ZENworks を入れないのか

そういう運用をしているネットワーク管理者には声を大にして言いたいところです。かつて NetWare 5.1 にはスタータパックが標準添付されていましたが、この理由だけで NetWare 6 ではなくわざわざ 5.1 を導入したこともあるくらいなのです。それくらい ZENworks の DLU 機能は価値があるということです。

仮にシステムのヘルプデスクの雇用コストが年間１０００万かかったとしましょう。ZENworks は確実にその運用コストを半分にしてしまいます。１ライセンス１万４０００円程度ですが、従業員２００～３００人程度の企業規模であれば、わずか１年でそのコストを吸収できるパフォーマンスを持っているのです。

-Dynamic Local User(DLU)を有効にする

ヘルプにはワークステーションまたはターミナルサーバのSAM (Security Access Manager)データベースに一時的または永続的に常駐するユーザオブジェクトを作成します。とあります。つまり eDirectory に認証されたユーザ名のアカウントを自動的にローカルに作成する機能なのです。

これだけではわかりにくいかもしれませんが、もし、新しいPCをセットアップして、eDirectory のユーザアカウントに DLU を設定しておけば、ローカルアカウントを作成して配布する必要もなければ、ローカルアカウントのパスワード管理も eDirectory まかせなので、夢の Single Sign On が実現できるのです。ローカルアカウントは自動的に作成されます。

DLU を有効にするにはユーザポリシーを作成します。例えば PowerUserDLU などの名前をつけてユーザポリシーを作成しましょう。ポリシータブから例えば Windows XP などのオペレーティングシステムを選択します。デフォルトでは DLU はチェックされていないので、 ダイナミックローカルユーザにチェックを入れてプロパティを開きます。



「ダイナミックローカルユーザを有効にする」「既存のユーザアカウントを管理する」「eDirectory アカウント情報を使用する」にチェックを入れます。

「一時的ユーザ(Volatile)」はチェックしてはいけません。このチェックはローミングプロファイルを使う場合にチェックする場合があります。チェックを入れるとログアウトした後キャッシュされたユーザの「お気に入り」や My Document は削除されてしまいます。

下の「所属」ボックスに Windows グループを登録します。システム管理者やヘルプデスクの場合は Administrator グループを登録すればよいし、一般ユーザの場合は Power User グループに所属させます。

Windows XP のローカルアカウント作成ではできなかった PowerUser の設定はここで行うことが出来ます。

あとは、 PowerUserDLU グループなどを作成し、そのグループ、あるいはOUに対して関連付け(associate)し、ユーザをグループやOUに登録するだけです。

ここで PC へ NWGINA にログインすれば、自動的に Windows のローカルアカウントが作成されます。

Policy の適用方法

ZENworks が Active Directory とは一番異なる点は、

ポリシーをグループ、個人、OU単位で細かく設定できる点にあります。 AD の場合は OU 全体にポリシーを適用することが出来ません。したがってOUの設計は必ずポリシーの設計を考えた上で考慮しなければならないところです。

これに対してZENworks のポリシーは、グループオブジェクトやOU、さらには個人に対して適用できるため、OUのどこにユーザが居ようと任意のポリシーを自由に与えることができるのです。



例えば、General Policy を Users 全体に与えた上で、HelpDesk 用の管理者ポリシーを HelpDesk グループに与えるということが容易に出来ます。Active Directory の大雑把な管理方法とは異なり、非常に細やかな管理ができる（ある意味では煩雑になる場合もあり得る）点は大いに評価していいでしょう。

連結子会社が多かったり、グループ企業が複雑な組織の都合などにより、全社的なポリシー運用ができない組織においては、単一のポリシー運用ができ、さらに細かなポリシー例外を設けることができる ZENworks は充分検討するに値するシステムなのです。



この方法はワークステーション管理にも有効です。登録されたワークステーションをグループ化して、グループに対してワークステーションポリシーを適用させることにより、利用者や内部のデータに応じたポリシーを適用させることができるのです。

Active Directory を導入したいが、全体のポリシー設計が難しい、あるいはAD導入自体が難しい、全体をワークグループ運用している、連結対象の企業をひとつのポリシーで運用したいといった組織にはぜひ ZENworks の導入をお勧めしたいところです。

非番のエンジニア