IIS8でRRDTool

時代はWindows Server 2012ですよ。半年もすれば2012R2でIIS8.5になるらしいですけど、まぁ、ここはIIS8でいいや。


気を付けることは、Active Perlの5.10を入手すること。
Perlは32bit版。RRDsが32bit版なので合わせる必要がある。


RRDToolはできれば最新の!!って言いたいけど、Windows版は1.2.30が最新みたい。
まぁ、ここは仕方がないよね。


色々と設定は必要だけど、ほとんどIIS7.5と一緒。
気を付ける必要があるのはアプリケーション プールの詳細設定で32ビットアプリケーションの有効化をTrueに変更すること。
これさえ忘れなければOK。


ActivePerlの5.10さえ入手できれば問題ないってことだね。


?


それにしても、Network系のお仕事をするうえで、Linuxを禁止されているとこういうツールを使うときにつらいよなぁ~優れたツールが無償で利用できるのにね!!Syslog Serverとか・・・



メールの延長

NotesからSharePointへの移行において、大変だよね~といわれるのが、ワークスペース上のアイコンとか未既読の扱い。


未既読。


ユーザー視点で一番目につく最も困るのが未読数と未既読表示だと思います。


Notesではワークスペース上のアイコンに未読数が表示され、どのアイコンを開くべきなのかが一目瞭然。掲示板を開けば未読文書は赤く表示されるので、読むべき文書も一発で分かります。


この未既読機能を中心に業務を行っているといっても過言ではないでしょう。この未既読がないSharePointに移行した時、ユーザーは口をそろえて新しい、更新された文書がどれかわからないと言います。メール通知やOutlook連携など作成や更新の情報を受け取ることができる機能はありますが、Notesのシンプルさはありません。


SharePointを推進する立場からすると、どうにかして乗り越えたい課題です。
どうすれば乗り越えられるのか?


Notesの脅威ともいえる未既読ですが、いくつかの問題を抱えていると考えています。


まず、編集によって未読になるってこと。
普通の編集は便利なんですよ。以前確認した文書が編集されたことを気が付けるので、情報の取得漏れがないんです。でもね、文書の有効期限の変更や非表示項目の変更、何も変更せずに保存したとかでも未読に切り替わるんです。これらの変更はユーザーには一切関係なく、改めて読むものじゃない。作業依頼の文書だったりしたら、その作業を再実施してしまうユーザーもいます。そして問い合わせが来る。未読表示の悪い点です。


次に、メールと掲示板の役割が明確になっていない。
本来、相手に伝えたいことはメールで確実に伝えるべきだと思うのですが、未読表示を使うことで、メールを使わなくても、相手に伝えることができるのです。(はい、便利です)
伝える相手が1人ならメール、複数なら掲示板という感じになります。
掲示板を使うと同時に通知も完了するので、掲示板を使ってすべての情報をNotesに集めようよ!!ってのが簡単に実現できます。それ自体はグループウェアの目的であり問題ないのですが、あまりにも掲示板が便利すぎて、メールで通知すべき内容が掲示板に記載されることが多いのです。
ず~っと使っているユーザーはさほど問題ないのですが、新規ユーザーは有効期限の切れた情報も未読になっており、過去の経緯なんて要らないのに読んでしまいます。そして、過去の間違った情報をもとに行動してしまう可能性もあるのです。


?


Notesを使っていくってのは、ユーザーは未読数を0にすることが仕事で、それがメールだろうが掲示板だろうが何でもよくて、未読文書を読んで仕事をして未読数が0になると仕事が終わる。そういう仕事の仕方を永遠に続けていくってことなんだよ~


今見る必要がない情報だってたくさんあるはず。未既読に依存するってことは、届いたメールはすべて、スパムメールも内容も確認していますってのに似ているんじゃないかと。


情報の伝達と蓄積を分けることができたら、うまく乗り越えられるんじゃないかと思ってます。
どうやって説明し、実現するか。まだ答えは見つかっていないですけど・・・


?


補足:未既読に依存する事が問題では?との仮説であって、Notesがダメってことではありません。



1000ユーザーの役職情報削除の補足

書き忘れたので補足。


PowerShellでActiveDirectoryを操作するとき、
ActiveDirectoryサーバー上で操作する必要はありません。


ActiveDirectoryに参加しているクライアントでOKです。
もちろん、編集など特別な権限が必要な操作は
その権限を持ったユーザーで操作する必要はありますが、
基本はリモート操作です。


あと、 ActiveDirectoryモジュールが必要なので、
リモートサーバー管理ツール(RSAT)をインストールする必要があります。
クライアントOSにあった適切なRSATをMicrosoft Downloadセンターから入手してくださいね。


RSATは参照目的でも便利なのでサーバー管理者は入れておくことをお勧めします。



1000ユーザーの役職情報を削除しなさい

ActiveDirectoryを管理していると、「1,000ユーザーの役職情報を削除しなさい」なんてオーダーが出る可能性はある。
理由は何でもいい。似たような状況に置かれたと考えてほしい。


Q.急いでいるんだけど、いつまでに完了できる?
A.ん~~1ユーザー30秒かからないとして500分程度。大体8時間
 ちょっと残業すれば今日中に終わると思います。


これ、あなたの答えですか?
先日までは私の答えもこれだったかもしれません。


でも、今の私なら、「それなら30分くらいもらえれば終わります」(余裕)
なぜなら私にはPowerShellという武器があるから。


まぁ、以前から便利なのは知ってたんですけどね、使う機会がなくてスクリプトとしては使っていなかったんですよ。やっても「Export-SPWeb」みたいな単発の命令ばっかりで~


じゃぁ、スクリプトっぽくいくよ~


Import-Module ActiveDirectory
$users = Get-ADUser -Filter *
ForEarch($user in $users)
{
Set-ADUser -Identity $user -Clear Title
}

あとはActiveDirectoryを編集できる権限で実行するだけ。
5分で書いて1分実行。
ついでに確認用のコマンドをちょっと打って


まぁ、20分は忙しそうなふりして遊びましょうか?


本当に動かすときは、編集対象に問題がないかとか、ちゃんと編集できた確認とか
やるべきことは色々あるけど、たった6行・・・
いや、最小限でいよく


Import-Module ActiveDirectory
Get-ADUser -Filter * | Set-ADUser -Clear Title

2行で終わるかも・・・
つぶしてもいい環境だったらこれでいいよね。


PowerShellの何がすごいかって、
今までの方法だと、サーバーに接続して・・・って言語すらまともに使えないのに~
って感じだったのが、それぞれのコマンドが勝手に必要な手順をこなしてくれるんですよね。
スクリプトやプログラム言語でActiveDirectoryからユーザー一覧を取得する。
これだけでも結構な行数のプログラムを書かなければならなかった?わけなんですが、
Get-ADuser -Filter *
この一行でActiveDirectoryサーバに接続して、取得して、出力するんですよ。


?


私が言いたいことは、8時間GUIで作業している管理者に
ちょっとした学習時間を確保することでその作業が30分程度に削減できるってことを知ってもらいたいだけ。



注意:このページのスクリプト、コマンドは動作確認を行っておりません。
あくまでイメージですので、動かないからと言って文句を言わないようにお願いします。



セキュリティーを考える「ユーザー認証」

クラウドサービスもいいけど、オンプレミスを公開するパターンもなかなか・・・。
クラウドサービスを使うにしても認証を社内Active Directory とパスワードを合わせたいなどと要求を出すと、どうしても、オンプレミスのサーバーを公開する必要が出てくる。


そういう時、どうやってセキュリティーを高めるのか考えてみる。


ユーザー認証の強化の方法


IDを複雑にするのは運用上問題が多いので、パスワードを強力にするしかないけど現実は難しい。


「大文字、小文字、数字、記号の4種類を使って8文字以上かつ、誕生日、住所、電話番号、家族の名前、家族の生年月日、記念日に関連する情報は使ってはならない。パスワード変更の履歴は5個、同じパスワードを連続して設定できない。パスワードの有効期限は3か月」なんてルールを強制されたら、付箋とかノートにメモするよなぁ~


ワンタイムパスワードや乱数表を使うってのはパスワードをユーザーが覚えなくてよいメリットはあるけど、カードなどの管理や持ち運ぶのが面倒。10個のサービスすべてがワンタイムパスワードを採用して、カードを10枚持ち歩くなんて嫌だよね。


スマートカード、対応機器限られてるし~盗まれたらどうするの?4桁数字のPINなんて・・・


生体認証・・・機械どうするの!!一度複製されたら使えないよね~


などと、複雑化すると問題が出てくるので運用に耐えられない。
個人的には5文字以上で有効期限は40日とかでいいんじゃないかと思う。


銀行とかで使われている数字4桁なんて、だれかの誕生日に設定しろ!!と指示しているのと一緒だよね。それがダメというなら01**~12**、**01~**31の範囲くらいは設定できないようにしとけよ~って思う。なんで5桁にしなかったんだろう?と思う。5桁ならとりあえず誕生日+一文字とかにするので簡単に推測しにくく出来るのにね~~


有効期限も1か月単位で変更しにくいように微妙にずらすとか・・・


0401(mmdd)
130401(yymmdd)
20130401(yyyymmdd)


このパターンを設定しにくいルールを決めれば、それなりの強度を保てると思うんですけどね


パスワードのヒントもやめてほしいよなぁ~「初めて就職した時の初めての上司」??誰だよそれ~



ADFSの名前は一つ!!


ADFSって何?って聞かれそうですが・・・

本来、社内ネットワークに設置される、コンピューターの認証基盤Active Directoryを社外のサーバーでも利用するための仕組みってとこですか?

Office365 とかクラウドサービスを社内のID、パスワードを全く一緒にして利用しようという仕組みです。これがなかったら、同じIDを設定していても、パスワードは別。ユーザーは同じIDを使っていながら、接続相手によって違うパスワードを入力する必要がある状態になります。(別のIDを使うなら大した問題ではありませんが・・・)

どうやってパスワードを使うかというと、認証時にADFS経由でActive Directory認証を行うんですよ。

ってことで、このADFSを使うということは、AD DSは当然ですが、ADFSサーバが停止するとOffice365が利用できないのです。

だから冗長構成を必ず取る必要があるんですね。そして、セキュリティーを高めるために、ADFS Proxyを設置して、これも冗長化。
とにかく、止めない。止まらない構成を構築する必要があるんです。なにせクラウドサービスは基本無停止だから。

でね、このADFSサーバー群なんですけど、もちろん個々のサーバーはそれぞれ別の名前があるんですけど、ADFSサービスとしては一つの名前で動作するんです。当たり前?いやいや、普通じゃないかもしれないけど、内部サーバーと外部公開サーバーは違う名前使うよね。え?一緒?
参照するDNSによって違うゾーンのサーバーを名前解決されるのって気持ち悪くない?ADFS Proxyは自分と同じ名前の内部ネットワークのADFSサーバーと通信するとき困るじゃん!!と思ってしまいましたが、全部同じ名前なんです。

社内のADFSも社外のADFS Proxyも同じ「https://adfs.contoso.com」でアクセスするんです。

もちろん社外のADFS Proxyがユーザーの代理アクセスする社内のADFSに対しても「https://adfs.contoso.com」でアクセスするんだよ。

これって面白いよね。

ちなみにADFS Proxyサーバはhostsファイルに社内のADFSのIPアドレスを記述している。

hostsファイルなんて、使わずにDNSで解決すべき!!なんて思っているのですが、「あぁ、こういう使い方もありなんだ~」と。

今日言いたいのは、「Active Directory Federation Servicesは、たくさんサーバーが必要だけど、FQDNは一つ!!」ってことです。


クラウドを使うためには・・・

最近Office365導入に向けた検証を本格的にやり、Active Directory Federation Services や Active Directory同期、Exchange Serverのハイブリッド構成の構築を行っていて感じること。


オンプレミス状態では考えられないほど、インターネット公開すること。


Proxyやエッジサーバーを用意する前提とはいえ、インターネット上からActive Directory認証が可能になるってことでアカウントのパスワード管理強化がセキュリティーの要だよなぁ~と感じる。


不要なポートは閉じ、セキュリティーホールを一生懸命閉じたとしても、ログイン画面は絶賛公開中。


アカウント名なんて、有効なメールアドレスを探すのと大差ないくらい簡単だろうし、パスワードルールが甘い企業だと、簡単に突破できるんじゃないかと思います。


パスワード変更期限の設定、複雑なパスワード、文字数制限は必須。できればスマートカードのようなユーザーすらパスワードを知らない仕組みを用意するとか、クライアント証明書などを組み合わせた認証が必要なんじゃないかと思います。


そういうことをやっても、公開するって結構きついよなぁ~


まぁ、それ以上のメリットを感じているし、求めるとクラウドって答えになるんだけど、機密情報はオンプレミスだから大丈夫!!なんて言ってられない世の中になっている。


ネットワークの内外関係なく、ちゃんと情報を管理し、保護する必要があるんだよね。



SharePoint アイテム保管ライブラリをのぞいてみよう(2025年12月改訂)

※2025年コンテンツ検索等の機能がリニューアルされましたので修正しました。 ※2023年アカウント移行に失敗し画像を失ったので再度取得し改訂しました。 Office 365 Advent Calendar 2021  の12月16日投稿です。 警告: 個人的な理解に基づく内容、...