9. その他
9.1. 詳細項目一覧
項目 |
説明 |
|---|---|
AppName |
操作を実行したアプリケーション名 |
AuditUser |
ユーザーがsudoやsuを行った場合の、最初にログインしたユーザー名 |
AuthType |
認証の種類
- Kerberos = Kerberos認証
- NTLM = NTLM認証
|
ClientIP |
操作を実行したクライアントPCもしくは接続先PCのIPアドレス |
ClientName |
操作を実行したクライアントPCもしくは接続先PCのコンピューター名 |
Count |
ログ変換処理によってマージされたイベントログ（生ログ）のレコード数
※イベントログの特性として、ユーザーによる1回の操作に対し、同じ内容を示すログレコードが複数行出力されることがあり、ALogでは、「ユーザー」、「サーバ」、「対象」および「詳細（Countを除く）」が同じログレコードにおいて、5秒以内に同じ「操作」のレコードが連続して発生した場合、これらを1レコードにマージしている
|
CurrentDir |
コマンドを実行したときのカレントワーキングディレクトリ |
DB |
アクセスしたデータベース名 |
DBID |
接続したデータベースのデータベースID |
ErrorCause |
for Windows：認証失敗の理由
for Linux：認証だけでなく、各操作の失敗の理由
|
EventID |
操作が記録されたWindowsイベントログID |
LogonType |
ログオン処理の種類
- RemoteInteractive = リモートデスクトップ接続
- Script = ログオン/ログオフスクリプトのログである場合
※Windowsで定義されているログオンタイプと完全に一致するものではない
|
OSUser |
データベース接続時にOSへのログオンに利用したユーザーアカウント名 |
Pages |
印刷対象となったページ数（印刷部数、印刷枚数は出力されない） |
Printer |
印刷を行ったプリンター名 |
Protocol |
「SMB」以外の通信プロトコル名 |
RowCounts |
SELECTコマンド実行時にヒットしたレコード件数 |
Schema |
アクセスしたデータベーススキーマ名 |
SesId |
データベース接続時のセッションID |
To |
ファイル・フォルダーの名前変更/移動/コピー操作を行った場合の、RENAME/COPY/MOVE後ファイル・フォルダーのパス |
Tty |
レコードに紐づけられた仮想コンソール名（Tty名） |
Zone |
アクセスゾーン名 |
AccessList |
WindowsイベントログのAccessList |
AccessMask |
WindowsイベントログのAccessMask |
注意
ヒント
対象サーバ |
ログ種別 |
収集可能な項目 |
|---|---|---|
Windows |
すべてのログ |
Count |
ファイルアクセスログ |
ClientName / ClientIP / AppName / To |
|
ログオンログ |
AuthType / LogonType / ErrorCause / ClientIP / ClientName |
|
管理者操作ログ |
EventID / ClientIP / ClientName |
|
プリントログ |
Printer / Pages |
|
ログオン/ログオフログ(スクリプト) |
LogonType / ClientIP / ClientName |
|
アプリケーション起動ログ |
AppName / ClientIP / ClientName |
|
アクセス権変更ログ |
ClientName / ClientIP /AppName |
|
NetApp |
すべてのログ |
Count / ClientIP |
ファイルアクセスログ |
To(RenameTo) |
|
EMC |
すべてのログ |
Count / ClientIP / ClientName |
PowerScale |
すべてのログ |
Count / ClientIP / Protocol / To / Zone |
SQL Server |
すべてのログ |
Count / AppName / DB |
RAWSQLログ以外 |
ClientIP ※SQL Server 2017以降 |
|
RAWSQLログ |
ClientName / RowCounts |
|
Oracle |
すべてのログ |
Count / ClientName / AppName / Schema / SesId / OSUser / DBID |
DBログオンログ |
Count / ClientIP / ClientName / AppName / Schema / SesId / OSUser / DBID |
|
Linux |
すべてのログ |
Count |
ファイルアクセスログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / To(RenameTo) / Tty |
|
アクセス権変更ログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / Tty |
|
コマンド実行ログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / CurrentDir / Tty |
|
ログオンログオフログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause |
|
EVA |
(ログ種別なし) |
任意指定可能 |
Amazon FSx for Windows File Server |
すべてのログ |
Count / AccessList / AccessMask |
Amazon FSx for NetApp ONTAP |
すべてのログ |
Count / ClientIP |
ファイルアクセスログ |
To |
9.2. Windows「LOGON」に関する補足情報
ログオンログの基本的な考え方について 「Windows「LOGON」のアクセスログについて」 で解説していますが、「ユーザーが行った操作 ─ その場合のアクセスログへの出力結果」をケースごとに解説します。 この中から、どのようなLOGONログを取得したいか確認し、『どのサーバを対象サーバとして登録すべきか』 を明確にします。
ケースは計9ケースあります。同じ対象サーバに対して「ログオンログ」と「ログオン/ログオフログ(スクリプト)」を同時に設定することも可能です。
ログ種別「ログオンログ」を取得する方法：6ケース
ログ種別「ログオン/ログオフログ(スクリプト)」：3ケース
ケース図解の読み方
ケースごとの図解の中で赤い枠で示すサーバが、 対象サーバとして登録対象となり得るサーバ です。
吹き出しの中に、そのサーバから取得できるアクセスログの内容を示します。
このあとの説明の際、省略名を使用しています。以下の表を確認してください。
FSとPCはいずれもそのドメインに参加しているマシンであることを前提としています。
省略名
意味
DC
ドメインコントローラー
FS
ファイルサーバ
MS
マネージャーサーバ
RDP
リモートデスクトップ接続
WG
ワークグループ
9.2.1. ログ種別「ログオンログ」を取得するときのケース
9.2.1.1. PCの認証のログを取りたい場合
9.2.1.2. FSへのローカルログオンログを取りたい場合
9.2.1.3. FSの共有へのアクセスログを取りたい場合（ドメインユーザー）
- ※1
- AuthTypeがKerberosになるかNTLMになるかはネットワーク通信の仕方による。「\\サーバ名」と入力してアクセスした場合：Kerberos認証としてイベントログに記録される。「\\IPアドレス」と入力してアクセスした場合：NTLM認証としてイベントログに記録される。
- ※2
- FSとPCが同一ドメインの場合、認証が発生するケースとしてはPC自体へのログインをローカルユーザーで行いFSへのアクセス時にドメインユーザーを指定するケースが想定される。また、FSとPCが別ドメインの場合や、PCのみWGの場合も、認証は発生する。
- ※
- 「\\IPアドレス」（NTLM認証）でアクセスして認証失敗した場合のイベントログには、ドメイン名やNTLM or Kerberos等の必要な情報が書き込まれない。そのためこのケースによる「LOGON-Failure」のアクセスログにおいては、ユーザー名欄は「ADサーバのホスト名認証で入力したユーザー名」を表示している。これは通常の「LOGON」や「LOGON-Failure」のアクセスログとは異なる特別な対応である。
9.2.1.4. FSの共有へのアクセスログを取りたい場合（ローカルユーザー）
9.2.1.5. RDP接続でFSの共有へ接続したときのアクセスログを取りたい場合（ドメインユーザー）
9.2.1.6. RDP接続でFSの共有へ接続したときのアクセスログを取りたい場合（ローカルユーザー）
9.2.2. ログ種別「ログオン/ログオフログ(スクリプト)」を取得するときのケース
※基本的なスクリプトの作成については「ログオン/ログオフログ(スクリプト)」 を参照してください。ここではスクリプト設定のうち、以下に示す2画面の選択について補足します。
9.2.2.1. ログの書き込み先：DC （ドメインユーザー）
ドメインユーザーのログオン/ログオフを取得する際の一般的なケース
【スクリプト生成時の設定】
「ログの書き込み先サーバの指定」画面 |
「ログオン先のドメインコントーラーに書き込む」を選択する |
「アカウントの指定」画面 |
「ドメインユーザー権限で書き込む」を選択するのが一般的
(この場合はレジストリを変更する必要がある)
「以下の管理者アカウント権限で書き込む」を選択しても良い
|
9.2.2.2. ログの書き込み先：マネージャーサーバ or ファイルサーバ（ドメインユーザー）
【スクリプト生成時の設定】
「ログの書き込み先サーバの指定」画面
「マネージャーサーバまたは任意のサーバに書き込む」を選択する
「アカウントの指定」画面
9.2.2.3. ログの書き込み先：ローカル （ローカルユーザー）
【スクリプト生成時の設定】
「ログの書き込み先サーバの指定」画面 |
「マネージャーサーバまたは任意のサーバに書き込む」を選択する |
「アカウントの指定」画面 |
「ドメインユーザー権限で書き込む」を選択する 1
(「ドメインユーザー権限で書き込む」とすると、スクリプトの使い回しが可能になる)
|
- 1
「ドメインユーザー権限で書き込む」という選択肢は、ログオンしたユーザーで書き込み動作をする。そのためローカルユーザーでログオンしてもスクリプトは動作する。
9.3. レポート-アラート機能「外部連携」の詳細情報
「外部連携」 の アラートSyslog通知 に関する詳細情報を記載します。
9.3.1. syslog通知に関する基本情報
RFC3164に基づきUDP送信を行います。syslogのメッセージの内容が200文字を超える場合は、超過分がカットされた上で送信されます。
1度の動作では最大で10000件しか送信されません。1度に10000件を超えるアクセスログがヒットした場合は、警告を発して10000件分を送信した時点で送信を完了します。
アクセスログのソート設定や表示項目設定は適用されません。syslogの送信はアクセスログの日時について昇順で行われます。syslogのメッセージ内容はsyslog本文の設定項目により決まります。
受信されるsyslogの日時は、アクセスログの日時ではなくsyslogを受信した日時です。
syslogのメッセージ内容は、受信するsyslogサーバ側の設定によっても異なります。
9.3.2. 「syslog本文」欄の設定について
この項目に指定する文字列は、Microsoft C#の補間文字列として扱われます。そのため、｛｝で関数を括ることで、その評価結果を表示することが可能です。文字種によってエスケープシーケンスで入力する必要があります。エスケープに関する詳細は「特別な文字列のエスケープ方法」を参照してください。
「syslog本文」欄で使えるALog用の関数は以下の通りです。また、以下に記載した関数以外にも Microsoft C# が用意する関数の一部を使用できます。
関数
説明
使用例
AccessTime()
アクセスログの日時項目を文字列として取得する
{AccessTime()}
User()
アクセスログのユーザー項目を取得する
{User()}
Server()
アクセスログのサーバ項目を取得する
{Server()}
Object()
アクセスログの対象項目を取得する
{Object()}
Operation()
アクセスログの操作項目を取得する
{Oration()}
Detail(string key)
アクセスログの詳細項目の中で、指定された詳細キーの値を取得する
{Detail("ClientIP")}
Details()
アクセスログの詳細項目を全て文字列として取得する
{Details()}
AccessTime(string format)
{AcecssTime("yyyy-MM-dd")}
ToCSV(params object[] objects)
指定したオブジェクトをCSV形式の文字列に変換して取得する
{ToCSV(User(), Server())}
9.3.3. 「syslog本文」欄を変更する場合の例
「syslog本文」欄の変更によってどのようにsyslogが変更されるかを解説します。
(アラートでヒットしたアクセスログの例) "2020/06/23 14:08:57.000","user1","server1","file1","READ","Count:1 ClientIP:192.168.1.111"
(syslog本文欄の指定) ALog alert. [User:{User()}] ↓ (受信するsyslogの例) Jun 23 14:09:35 <ローカルホスト名> ALog alert. [User:user1] ※<ローカルホスト名>は、「ローカルホスト」欄に指定した値が入る
(syslog本文欄の指定) ALog alert. [User:{User()}][IP:{Detail("ClientIP")}] ↓ (受信するsyslogの例) Jun 23 14:09:35 <ローカルホスト名> ALog alert. [User:user1][IP:192.168.1.111]
(syslog本文欄の指定) {ToCSV(AccessTime(), User(), Server(), Object(), Operation(), Details())} ↓ (受信するsyslogの例) Jun 23 14:09:35 <ローカルホスト名> "2020/06/23 14:08:57","user1","server1","file1","READ","ClientIP:192.168.1.111 Count:1"
9.4. マネージャーサーバのバックアップ・リストア手順
9.4.1. バックアップ
【事前準備】
Webコンソールの[管理]-[ステータス]を確認し、ALogの各タスクが実行されていないことを確認する
実行されているタスクを停止したい場合1. [ステータス]-[ALogタスクスケジューラー]の[停止]ボタンをクリックする2. 「実行中のタスクを停止する」にチェックをつけて［OK］ボタンをクリックする
すべてのタスクが停止されたことを確認し、サービス「ALog ComputeEngine」を停止する
1.プログラムインストール先フォルダー 例）「X:\ALog」（既定のフォルダー名称）※ 通常は必要なし。該当フォルダー配下の設定ファイルを変更している場合はバックアップが必要2. アプリケーションデータ用フォルダー 例）「X:\ALogData」（既定のフォルダー名称）3. アクセスログ/イベントログバックアップ出力先フォルダー※ 通常は必要なし。出力先をアプリケーションデータ用フォルダー以外に変更している場合はバックアップが必要※ 出力先フォルダーの設定は[管理]-[出力設定]から確認できる4. レポートファイル出力先フォルダー※ 通常は必要なし。出力先をアプリケーションデータ用フォルダー以外に変更している場合はバックアップが必要※ 出力先フォルダーの設定は各レポート設定から確認できる
9.4.2. リストア
【リストア手順】
1. ALogをインストールする2. Webコンソールの[管理]-[ステータス]を確認し、ALogのタスクが実行されていないことを確認する実行されているタスクを停止したい場合1. [ステータス]-[ALogタスクスケジューラー]の[停止]ボタンをクリックする2. 「実行中のタスクを停止する」にチェックをつけて［OK］ボタンをクリックする3. すべてのタスクが停止されたことを確認し、サービスの「ALog Compute Engine」を停止する4. バックアップしたフォルダーのうち、アプリケーションデータ用フォルダー以外を元の場所に上書きコピーする5. 現在のアプリケーションデータ用フォルダーを削除し、バックアップしたアプリケーションデータ用フォルダーに差し替える6. サービス「ALog Compute Engine」を開始する
注意
注意
9.5. マネージャサーバのOSシャットダウンやALogサービスを停止する手順
マネージャーサーバのOSシャットダウンやALogのサービスを停止する場合は、事前にALogの全タスクを停止してください。
注意
データベース更新中にOSシャットダウンやサービス停止が行われると、データベースが破損する可能性があります。
Webコンソールの[管理]-[ステータス]-「ALog タスクスケジューラー」を開き、「実行中のタスクを停止する」にチェックをつけて「OK」をクリックする
詳しい機能説明は『 ステータス 』を参照してください
全てのタスクが停止されていることを確認し、OSシャットダウンやサービス停止を実行する
ALogサービス名：ALog Compute Engine
9.6. アンインストール
9.6.1. Step1．対象サーバの削除
登録されている対象サーバを以下の手順ですべて削除します。
Webコンソールの[管理]-[対象サーバ]をクリックする
「対象サーバ」ページの一覧に表示されているすべての対象サーバにチェックを入れ、 [削除]をクリックする
Windows、NetAppを選択して削除した場合は、削除確認ダイアログに「監査設定を無効化する」チェックボックスが表示されるので、必要に応じてチェックを入れて削除する
(Windows/NetAppを削除する場合の削除確認ダイアログ)
製品
監査設定に対するその後の作業について
Windows
NetApp
EMC
PowerScale
SQL Server
対象サーバ削除時に自動で解除する。特別な作業は必要ない 2
Oracle
Linux
対象サーバ削除時に自動で解除する。特別な作業は必要ない
EVA
対象サーバとなる機器ごとに異なるため、それぞれの機器にあわせて解除する
Amazon FSx for Windows File Server
Amazon FSx for Windows File Serverの管理画面からファイルアクセスの監査設定の管理のチェックを外す
Amazon FSx for NetApp ONTAP
9.6.2. Step2．ALogの削除
マネージャーサーバのスタートメニューから[コントロールパネル] ‐ [プログラムと機能]を開く
一覧から「ALog ConVerter」を選択して[アンインストール]をクリックする
アンインストール後、マネージャーサーバの以下のフォルダーに設定ファイルやデータ等が残るので、必要に応じて手動で削除する
プログラムインストール先フォルダー X:\ALog （既定のインストール先フォルダーにインストールした場合）
アプリケーションデータ用フォルダー X:\ALogData （既定のアプリケーションデータ用フォルダーにインストールした場合）
注意
アクセスログバックアップやレポート出力先を個別に指定している場合は、上記のフォルダーを削除してもファイルが残ります。 必要に応じて手動で削除してください。
9.7. 制限事項
ALog ConVerterでは、以下の制限事項があります。
9.7.1. ログ変換に関する制限事項
ログ変換に関する制限事項を記載します。製品ごとの出力ログ種別や出力パターンについては 「アクセスログの種別」 を参照してください。
9.7.1.1. 実際の操作と異なるファイルアクセスログが記録されることがある場合について (Windows/NetApp/EMC/PowerScale)
ALogは、対象サーバのイベントログを収集し、アクセスログに変換するシステムです。収集したイベントログの内容によってアクセスログの内容が決まるため、対象サーバやクライアントPCのOS、ユーザーが利用するアプリケーションの制約などにより、ユーザーが行った操作通りのログが出力されないことがあります。
ファイルアクセスのログ変換ロジックは、以下のアプリケーションによるファイル操作が正しく反映されるよう作成されています。
エクスプローラー / メモ帳 / ペイント / Microsoft Word, Excel, Power Point / Adobe Acrobat Reader
※その他のアプリケーションを利用した操作によるアクセスログは、実行されたシステムコールの内容を識別して、ユーザーの操作に近いログに置き換えますが、対象サーバやクライアントPCのOS、ユーザーが利用するアプリケーションの組み合わせによっては、ユーザーが行った操作どおりのログが出力されない場合があります。
(Windowsのみ）
ALogでは、コピー元/コピー先双方のログがイベントログに書き込まれ、それぞれの関連性が読み取れる場合に「COPY」として出力します。「COPY」は、アプリケーションの状況や処理により、実際にユーザーがCOPY操作を行っていなくても出力される場合があります。この場合の「COPY」は、「READ」および「WRITE」が行われたことを示します。
9.7.1.2. COPY/MOVE操作のログ出力について (Windows/NetApp/PowerScale)
「COPY」や「MOVE」のユーザー操作は、イベントログ上は「COPY」や「MOVE」という形では記録されません。ALogではアクセスログの可読性を上げるため、以下の通り特定の条件が合致した場合に「COPY」「MOVE」としています。ユーザー操作ではコピー、移動をした場合でも、イベントログに、条件に合致するログが出力されていない場合は「COPY」、「MOVE」と出力されない場合があります。[COPY]コピーしたファイルに対しREADもしくはWRITEが特定の条件で出力され、関連が読み取れる場合に、「COPY」とします。[MOVE]移動したファイルは「RENAME」として記録されているため、移動元(名前変更前)と移動先(名前変更後)でファイル名が維持された「RENAME」の場合に「MOVE」として出力します。
(Windowsのみ）
ファイルを移動した際、移動先の情報がイベントログに記録されない場合があります。このような場合はALogの変換において移動元で「MOVE」、移動先で「WRITE」とすることができません。ALogの変換では以下のような出力になります。
移動元…「RENAME」として出力され、詳細項目の[To]欄は非表示になる
移動先…何も出力されない
9.7.1.3. 「ClientName」、「ClientIP」が表示される条件について (Windows/NetApp/EMC/PowerScale)
アクセスログの詳細項目である「ClientName」、「ClientIP」が表示されるか否かは、元となるイベントログの情報に基づき決定されます。
ログオンログ … 元となるログオンのイベントログに付与されている情報に応じて「ClientName」、「ClientIP」のいずれかが出力されます。
ファイルアクセスログ … ファイルアクセスのイベント前にログオン情報が記録されている場合のみ表示されます。
※(Windowsのファイルアクセスログのみ)リモートホストからのWindowsファイルアクセスについて「ClientName」、および「ClientIP」が出力されるのは、以下の全ての条件を満たしたときのみです。
ファイルアクセスログ、管理者操作ログ、アプリケーション起動ログ、ログオンログ、のうち１つでも取得する設定が事前にされているとき （これらはセキュリティログを読み込むログ種別となります。）
事前に上記アクセスログに変換されるイベントがイベントログに発生しているとき
9.7.1.4. ファイルアクセスログにおいて成功操作でFailureが出力されることがある場合について (Windows/NetApp/EMC/PowerScale)
ファイルアクセスログ(READ/WRITE/RENAME/DELETE)におけるFailureの出力は、当該ファイル/フォルダーに対するアクセス権の確認に失敗したことを示しています。しかし、『Failureのアクセスログが出力された』ことは、必ずしも『ファイルへのアクセスに失敗した』ことを意味するものではありません。ユーザーがファイル/フォルダーにアクセスした際、OSは権限チェックを行い、アクセスしようとしているユーザーに紐づいた複数のアクセス権を順番にチェックします。Failureが出力されているケースでは、いくつか行われたアクセス権チェックにおいて、「失敗」（権限がない）の判定が出たことを意味しています。しかし、このあと次の権限チェックを行う中で、ファイル/フォルダー操作に対して必要な権限を持っていることが判明した場合、ユーザー操作としては成功します。この場合、ログの読み方としては、最終的にそのファイルへのアクセスに成功したログが出力されていれば、実際にはファイルアクセスは成功しています。
9.7.1.5. ファイルアクセスログにおいて期待したFailureが出力されないことがある場合について (Windows/NetApp/EMC/PowerScale)
実際のユーザー操作でファイルアクセスに失敗した場合、イベントログに「失敗」が記録されていないとアクセスログでFailureのログを出力することは出来ません。ファイル破損等の権限以前の問題でファイルが開けないような場合も同様です。また、何らかの障害でファイル操作に失敗した場合は、操作の途中で処理が中断されるため、失敗操作の種類を特定することができません。実行されたシステムコールの内容をアクセスログに変換しますが、『書き込み処理でREAD-Failureになる』『削除処理でWRITE-Failureになる』など、実際の操作と異なるアクセスログが出力されることがあります。
9.7.1.6. フォルダーのアクセス失敗（READ-Failure）を出力しない場合について (Windows/NetApp/EMC/PowerScale)
フォルダー”folder1”とそのサブフォルダー”folder2”があり、ユーザーは”folder1”を開くことができるが、”folder2”はアクセス権がなく開けないとします。このとき、このユーザーが”folder1”を開くと、”folder2”に対するREAD-Failureの履歴がイベントログに出力されます。このイベントログをそのままアクセスログに変換すると、実際には”folder2”を開こうとした訳ではないのにREAD-Failureのログが記録されてしまうことから、ALogはフォルダーのアクセス失敗（READ-Failure）の履歴をアクセスログに出力しません。なお、ファイルへのアクセスが失敗した場合（ユーザーがファイルを開こうとしたがアクセス権が無く開けなかった、等）はアクセスログに出力されます。
9.7.1.7. フォルダーを開くだけで配下のファイルのREADが出力されることがある場合について (Windows/NetApp/EMC/PowerScale)
対象サーバは、フォルダーを開いた時に「フォルダー内にあるすべてのファイルの情報」を読み取り、すべてのファイルのイベントログを出力します。ALogは、この「フォルダーを開いた時のファイルのREAD」のイベントログと「実際にファイルを読み込んだ」時に発生するイベントログの違いを識別し、フォルダーを開いただけではファイルのREADを出力しないよう処理しています。しかし、イベントログの問題により、稀にこの判別を行うことが出来ない場合があります（この問題は一度現象が起こると連続的に発生する場合があります）。その場合は以下の条件によって目視で「フォルダーを開くだけで起きるファイルのREAD」を識別します。
フォルダー内のすべてのファイルがREADと記録されている
アクセスログの「ユーザー」と「時刻」がほとんど同じ内容になっている
表 9.2 例 時刻
ユーザー
対象
操作
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\業務受託案件リスト.doc
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\社員名簿.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\受注登録シートマスター.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\090430運営委員会議事録.doc
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\（社外秘）新卒採用シート.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\2008下期営業部業績.xls
READ
なお、ファイルの縮小版の表示や、フォルダー内のファイルのマイナー属性項目の表示などは、実際にファイルを操作しているとみなされ、READが記録されます。
9.7.1.8. 0byteのファイル/フォルダー操作について (Windows/NetApp/PowerScale)
サーバ内のファイルやフォルダーの操作では、中身のあるファイル/フォルダーの操作(nbyteの操作)と、中身のないファイル/フォルダーの操作(0byteの操作)で、変換の元となるイベントログに記録される内容が異なります。ALogの変換は、nbyteの操作を優先したログ変換ロジックとなっており、0byteの操作はnbyteの操作と同じアクセスログにならない場合があります。例1：0byteのファイルを開いた場合、操作したアプリケーションによってはアクセスログが出力されないことがあります。例2：0byteのファイルをコピーした場合、元ファイルのCOPYもしくはREADが出ず、新ファイルのWRITEだけが出力されることがあります。例3：0byteのWordファイルを移動した場合、MOVEおよびWRITEが2回出力されることがあります。例4：0byteのフォルダーを別ドライブに移動した場合、元フォルダーのCOPYが出力されることがあります。
9.7.1.9. 拡張子の無いファイルはフォルダーとして扱われる可能性がある場合について (Windows/NetApp/EMC)
イベントログの解析によりファイルかフォルダーかの判断がつかないファイルアクセスに関しては、その判断を拡張子の有無で行っているため、拡張子のないファイルアクセスはフォルダーアクセスと見なされてREADが出力されないことがあります。
9.7.1.10. ユーザー名の末尾が「$」となるログの出力について (Windows/NetApp/EMC/PowerScale)
ローカルシステムアカウント（ドメイン名\コンピューター名$と表記されるアカウント）によるアクセスは、ユーザーの操作によるログとみなさないため、末尾が「$」となるユーザーによるアクセスログは出力されません。ただし、Windowsの管理者操作ログでは、この仕様は適用されず、出力されます。
9.7.1.11. RENAME先のファイル名の確認方法 (Windows)
「RENAME」操作が行われた際の変更後のファイル名は、「RENAME」のアクセスログ行の詳細項目「To」欄に記録されます。 また、直後に「WRITE」のアクセスログが出力されます。但し、「RENAME」先のファイル名がイベントログに出力されないケースを確認しており、この場合はアクセスログに出力できません。
「RENAME」先のファイル名がイベントログに記録されるケース では「RENAME」行の後に「WRITE」が出力されます。
表 9.3 正しく出力される例 対象
操作
詳細
C:\XX\ファイル名A
RENAME
To:C:\XX\ファイル名B
C:\XX\ファイル名B
WRITE
「RENAME」先のファイル名がイベントログに記録されない、関連が明確にならないケースでは、アクセスログが正しく出力できません。
9.7.1.12. RENAME先のフォルダーREADの出力について (EMC)
RENAME先のフォルダーREADは、RENAMEのイベント発生から5秒以内に以下のREADイベントが発生した場合にのみ出力されます。なお、以下の条件でREADイベントが発生していない場合は、RENAME先のREADは出力されません。
同じサーバ/同じユーザーで、同じフォルダーパス配下に異なるフォルダー名のアクセスがあった場合
同じサーバ/同じユーザーで、異なるフォルダーパスに、同名のフォルダー名のREADアクセスがあった場合
また、RENAME先のREADが出力されても、フォルダーパスがRENAME先のパスにならず、全く異なるフォルダーパスとして出力されることがあります。これも上記の(a)または(b)の状況の場合に発生します。
9.7.1.13. ファイルアクセス時のアプリケーション名（詳細フィールド AppName)の表示について (Windows)
リモートアクセスの場合イベントログにAppName相当の情報が出力されないため、AppNameは表示されません。ファイルアクセスにおけるAppNameの表示は、ローカルアクセスの場合のみに限定されます。
9.7.1.14. 対象サーバ内のファイル操作に関するファイルアクセスログについて (Windows)
対象サーバ内でのファイル操作では、共有経由でのファイル操作とは異なるイベントログが出力されるため、アクセスログの出力結果も異なる場合があります。以下のようなケースを確認しています。
ケース
操作：OfficeのアプリケーションにおいてPDF形式で保存するアクセスログの出力：「WRITE」を期待するが「DELETE」と出力される
9.7.1.15. プリントログのユーザーのドメイン名の表示について (Windows)
イベントログによるプリントのイベントには、ユーザーのドメイン名情報が含まれていないため、プリントログのユーザーのドメイン名は表示されません。
9.7.1.16. アクセスログに「UnknownXXX(User/Workstation/PrintDocument)」と出力されることがある場合について (Windows)
アクセスログのユーザー名欄に「(UnknownUser)」、対象欄に「(UnknownWorkstation)」、「(UnknownPrintDocument)」と出力される場合があります。これらの出力は、収集したイベントログ内にユーザー名、ワークステーション名またはプリントドキュメント名が無かった事を意味しています。
9.7.1.17. PowerScaleで失敗の操作(READ-Failureなど)が出力されない場合がある (PowerScale)
以下のバージョンでは失敗の操作(READ-Failureなど)が出力されません。これは、PowerScale側のOS仕様によるものです。OneFS 7.2.0～7.2.1
9.7.1.18. PowerScaleで変換対象となる領域について (PowerScale)
PowerScaleの変換エンジンはCIFS領域の監査ログを変換することを想定しています。監査ログにNFS領域のログが出力された場合も変換対象としますが、精度については保証していません。NFS領域の監査ログを変換した場合、アクセスログでは詳細項目欄に「Protocol:NFS」と出力されます。
9.7.1.19. RAWSQLログ内のSQL文にマスクがかかる場合について (SQL Server)
RAWSQLログ内のSQL文にマスクがかかるケースが存在します。マスクがかかるケースは以下のとおりです。[条件]PASSWORDのパラメータを持つSQL文、システムストアドプロシジャの場合[影響と対処方法]ログインの追加、削除などに影響します。RAWSQLログ内のSQL文でパスワードやオプションとして指定した 内容が表示されません。DB管理者操作ログとしてはログイン名を確認することができます。
9.7.1.20. 監査情報を変換するための情報不足によりDB管理者操作ログが出力できない場合について (SQL Server)
トレースログに出力されている情報が不足しているため、DB管理者操作ログが出力できない制限事項が存在します。[条件]オブジェクト種別とオブジェクト名称から内容が特定できないイベントが発生するシステムストアドプロシジャの場合[影響と対処方法]リンクサーバの追加、削除などの操作を行った場合、DB管理者操作ログが表示されません。SQLログにて確認する必要があります。
9.7.1.21. Windows + OS出力設定の組み合わせで、2byte文字の文字化けが発生するケースについて (Oracle)
Windows上にOracleがインストールされておりトレースログの出力形式を「OS出力」に設定していた場合、Oracleインスタンスの「キャラクタ・セット」が「デフォルトを使用」もしくは「Unicode(AL32UTF8)を使用」以外に設定されていると、2byte文字が文字化けした状態でイベントログに書き込まれます。そのためALog側で回避することが出来ず、文字化けした状態で表示されます。
9.7.1.22. syslogの変換時の日付の規則について (Linux)
1つのログ内に複数の時刻フォーマットやロケールが混在している場合、複数のフォーマット、ロケールの指定は出来ません。また、syslogに年情報が無い場合、収集したログの最終行の日付に年情報を付加します。収集した1ファイルの中に1年以上古いログが出力されていた場合、自動的に1年前と判断して変換します。
2017年に収集したファイル内のログ
アクセスログの結果
4/3 XXXX
2016/04/03
4/4 XXXX
2016/04/04
・・・
4/1 XXXX
2017/04/01
4/2 XXXX
2017/04/02
9.7.1.23. コマンド実行ログの失敗操作EXEC-Failureログにおいて対象欄に引数が出ない仕様について (Linux)
コマンド実行ログの失敗操作EXEC-Failureの場合、アクセスログの対象欄に表示されるのはプログラム名となります。プログラムに渡された引数は表示されません。これは失敗操作の場合、引数がauditログの中に含まれていないためです。
9.7.1.24. 実行されたコマンドにより、絶対パスではなく相対パスやファイル名で出力されるケースについて (Linux)
ファイルアクセスログやアクセス権変更ログの中には、パスが絶対パスではなく相対パスやファイル名で出力されるものがあります。これはauditログの中に、システムコールの種類によって絶対パスではなく相対パスやファイル名で記録されるものがあるためです。(現象例)ディレクトリ内に下位ディレクトリやファイルが含まれた状態でディレクトリを削除(rmコマンド)したときファイル名しか記録されない
9.7.1.25. 追記リダイレクト実行時にWRITEログが出力されない仕様について (Linux)
追記リダイレクトコマンドを実行してファイルに書き込み処理をした場合、WRITEのログは出力されません。これは当該コマンド実行時のauditログにパス名が記録されていないためです。(例) $ echo add_line >> /tmp/targetfile(auditログ) 「name="/tmp/"」と記録される
9.7.1.26. 実行時にディレクトリの末尾に「/」(スラッシュ)を付与してコマンド実行した場合のログについて (Linux)
コマンド実行時にディレクトリの末尾に「/」(スラッシュ)を付与すると、auditログにパスの記録が行われない現象を確認しています。パスのないログについてはアクセスログに変換しません。(現象例)「mv testdir testdir2」 変更前も変更後も「/」がないため、どちらのauditログも記録された結果、正常なRENAMEログになる「mv testdir/ testdir2」 変更前に「/」を付けたため、変更後しかパスが記録されずWRITEのログになる「mv testdir testdir2/」 変更後に「/」を付けたため、変更前しかパスが記録されずRENAMEログになるがTo欄が出ない「mv testdir/ testdir2/」 どちらもログにパスが記録されないため、アクセスログの変換結果がなしとなる
9.7.1.27. Sambaの「アクセス権変更ログ」について (Linux)
Sambaのアクセス権変更ログ(エクスプローラー経由の権限操作)は出力されません。
9.7.1.28. Auditログの変換ロジックについて (Linux)
LinuxのAuditログ(ファイルアクセスログ、アクセス権変更ログ、コマンド実行ログ)は、コマンド操作(CUI)を想定した変換ロジックです。 GUIの操作についてはユーザーが行った操作どおりのログが出力されない場合があります。
9.7.2. その他の制限事項
9.7.2.1. 監査ポリシーの自動設定について(Windows)
1. エージェント方式とエージェントレス方式で、監査ポリシーの設定箇所、内容が異なります。エージェントレス方式の場合は、WindowsOSに従来からある監査ポリシーで設定しており、エージェント方式の場合は詳細なセキュリティ監査ポリシーで設定しています。2. エージェント方式の対象サーバに対して監査ポリシーの自動設定をする場合、「監査ポリシーの詳細な構成」をWin32APIにて変更します。その際、APIの仕様上、変更した結果をローカルセキュリティポリシー画面(secpol.msc)で確認することができません。実際のポリシーの値（変更した結果）を確認する場合のコマンド「auditpol.exe/get /category:*」3. 監査ポリシーの変更は、対象サーバのローカル設定をWin32APIにて更新しています。このため、以下の制限があります。a. エージェント方式/エージェントレス方式共に、対象サーバがActive Directoryドメインに所属している場合、ドメインのグループポリシーの設定によってはポリシーの上書きが発生します。b. エージェント方式の場合、secpol.msc(=ローカルセキュリティポリシー。ローカルグループポリシーオブジェクトのセキュリティ設定部分)の「監査ポリシーの詳細な構成」を変更していると、グループポリシーの更新のタイミングでポリシーの上書きが発生します。
9.7.2.2. イベントログが破損している場合におけるタスクへの影響と変換について(Windows)
Windowsのイベントログは、希にOSから出力されている時点で既に破損している事があります。 破損の程度は、ファイル全体が破損しているケースから、1行の特定レコードが破損しているケース、または特定レコードの中の特定のパラメータが破損している等、様々です。
ALogでは完全に破損している場合、収集タスクでエラーが発生し収集することが出来ません。 また、収集の際、収集対象となるイベントログファイルの先頭30行、および末尾30行の中に破損があれば、破損の行をスキップして収集します。 このときに、該当する先頭・末尾行以外に破損があってもエラーとはなりませんが、当該ログの変換時に、その破損レコードが変換対象となった場合には変換をスキップして処理を継続するため、アクセスログに変換できないレコードが発生します。 また、破損の状況によっては破損と認識せずに、その破損したデータをそのまま利用して変換等を行う場合があります。 その場合はアクセスログにその壊れたデータがそのまま表示されることがあります。
9.7.2.3. イベントログのOS設定について (Windows/Oracle(Windows))
1. 対象サーバ設定がエージェントレス方式、かつ収集対象のイベントログのパスが以下の場合、イベントログ収集タスクで対象サーバのイベントログをリモート収集する処理や、対象サーバ設定編集ダイアログでイベントログのOS設定を変更する処理などが正常に動作しません。a. %SystemRoot% 以外の環境変数が含まれているb. %SystemRoot% 環境変数が含まれており、かつその値が C:\Windows でない2. エージェント方式で、収集ユーザーにAdministratorsグループに属するAdministrator以外のユーザーを指定するとイベントログOS設定の取得が正常に動作しません。これを回避するためには対象サーバのUACを無効にする必要があります。3. イベントログの出力先を変更した際、変更先のフォルダーに既に過去のイベントログが存在していると、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となります。重複したログの収集を避けるためには、変更先のフォルダーの中のイベントログを退避する必要があります。
9.7.2.4. クラスタ構成の場合について (SQL Server)
対象サーバがクラスタ構成でフェールオーバー発生時に以下の条件に当てはまる場合は、トレースログの欠落が発生する可能性があります。
主機のトレースログがRAM上に保存されていて、トレースファイルに書き込まれる前にフェールオーバーした場合
フェールオーバー発生後に副機の監査設定を実施した場合（フェールオーバーが発生してから副機の監査設定が完了するまでの間はトレースログを取得することができません）
9.7.2.5. 初期化パラメータ・ファイル(PFILE)をご利用の場合について (Oracle)
初期化パラメータ・ファイル(PFILE)をご利用の場合、以下のとおりファイルの書き換えが必要になります。ファイルの書き換えは対象サーバ追加後に実施してください。1. 初期化パラメータ・ファイルのバックアップ2. 下記の行を追加するaudit_trail = OS audit_sys_operations=TRUE audit_file_dest='D:\alogora_trace\ORCL'
3. 設定を反映するため、Oracleインスタンスを再起動する設定を確認するには、sqlplusでOracleへ接続後 下記SQLを実行し確認する【SQL】show parameters audit_trail 【SQL】show parameters audit_sys_operations 【SQL】show parameters audit_file_dest注意
対象Oracleサーバを追加後に「SYSDBAログ」、「RAWSQLログ」を変更する場合は、Oracleインスタンスの再起動が必要になります。注意
「audit_trail = OS」の指定はOS出力時の設定例です。出力設定に合わせて置き換えて設定してください。( 例：audit_trail = XML,EXTENDED )
9.7.2.6. Oracle起動プロセス以外のアカウントを使用する場合について (Oracle)
Oracle起動プロセス以外のアカウントを使用する場合は下記の手順で実施し変更してください。
1. 一度、Oracle起動プロセスのアカウントで対象Oracleサーバを追加する2. Oracle起動プロセスのアカウントでOracleサーバにtelnet等で接続し、下記chmodコマンドでアクセス権を変更するchmod –R 775 トレースファイル出力先フォルダー
3. Oracle起動プロセス以外のアカウントで、マネージャーサーバから対象Oracleサーバへftp/sftp接続し、トレースファイル出力先フォルダーのファイル受信/削除ができることを確認する4. サーバ編集画面で、FTPアカウントを変更する
9.7.2.7. 複数のアクセスログ/イベントログ出力設定(バックアップ)で、同じ保存先フォルダーを指定すると、保存や自動削除が正しく動作しない場合について (Webコンソール)
アクセスログ/イベントログ出力設定において、複数の出力設定同士で同じ保存先フォルダーを重複して指定してしまうと、保存や自動削除の機能が正しく動作しません。 アクセスログ/イベントログ出力設定を複数にする際は、それぞれ保存先フォルダーを分けてください。 また、すでに作成している出力設定の内容を変更する場合も、出力先を変更するか、それまで出力していたデータを事前に別フォルダーに退避させてください。
9.7.2.8. レポートファイルの削除の際、特定のケースで誤判断によりレポートファイルが削除される場合について (Webコンソール)
出力されたレポートファイルを削除する際、<レポートタイトル> + <->でファイルを検索し、ヒットしたものを削除します。そのため、以下の様なケースの場合、誤判断をしてしまい、意図しないレポートファイルも削除してしまいます。
「ファイルランキング」 3ヶ月で削除 c:\reportに出力
「ファイルランキング-2」 5ヶ月で削除 c:\reportに出力
上記のケースでは、「ファイルランキング」で検索した結果、「ファイルランキング-2」も条件にヒットしてしまい、「ファイルランキング-2」が5ヵ月ではなく、3ヵ月で削除されてしまいます。このような誤判断を回避するためには、レポートタイトルを異なる名称に変更するか、レポートファイルの出力先を異なるパスにする必要があります。なお、共通設定の場合は削除期間と出力パスが共通のため影響はありません。この制限事項は、個別設定のレポートが共通設定や他の個別設定と出力パスが同じ場合に起こる可能性があります。
9.7.2.9. レポートタイトルの不適合な文字を「_」に置換するため、ファイル名が重複し、意図しない処理が行われる場合について (Webコンソール)
レポートタイトルにファイル名として不適合な文字があった場合、レポートファイルを出力する際に不適合文字を「_」に置換します。その結果、ファイル名が重複してしまう可能性があります。ファイル名が重複した場合、ファイル作成時に上書きをしたり、削除時に削除してしまいます。このような場合は、個別設定で出力先を変更するか、レポートタイトルを変更する必要があります。
9.7.2.10. 検索画面でアクセスログの各項目に表示できる上限値について (Webコンソール)
検索画面においてアクセスログの各項目で表示できる上限値は以下のとおりです。上限値以上の場合、検索用DBへのインポート時にカットされます。
ユーザー：1000文字
サーバ：1000文字
対象：utf-8形式の4000バイト
操作：1000文字
詳細：utf-8形式の4000バイト
9.7.2.11. ALogで扱えるフォルダー、ファイルのパスの長さの制限について (Webコンソール)
ALogにおいて収集/変換/レポート作成等で様々なファイル処理が発生しますが、.NET Frameworkの制限により、フォルダーパスが「248文字以上」および、ファイルパスが「260文字以上」に該当する場合、エラーとなり扱えません。
9.7.2.12. バックアップ機能やアンチウィルスソフトがデータファイルを排他で開き、エラーとなる場合について
ALogのアプリケーションデータ用フォルダーをバックアップ機能(robocopy等)のコピー対象や、アンチウィルスソフトのリアルタイムスキャンの対象にしている場合、バックアップ機能やアンチウィルスソフトがALogのデータファイルを排他で開き、各種処理がデータファイルを開けずエラーになることがあります。アプリケーションデータ用フォルダーはバックアップ機能やアンチウィルスソフトの対象外にしてください。
9.7.2.13. レポートタスクを「停止」(キャンセル)した場合のファイル出力について
レポートタスクをステータス画面から「停止」した場合、ファイル出力の設定によって出力処理の途中でキャンセルされたファイルは作成されません。必要な場合は、レポート画面から「再作成」を行うことでファイルを作成してください。
9.7.2.14. データベースの運用について
データベース更新中にOSシャットダウンやサービス停止が行われると、データベースが破損する可能性があります。安全に運用するために、OSシャットダウンやサービス停止の際はタスクが動作していないことを確認してください。手順は『 マネージャサーバのOSシャットダウンやALogサービスを停止する手順 』を参考にしてください。
9.7.3. ALog EVAの制限事項
ALog EVAに関する制限事項を記載します。
9.7.3.1. ログ収集に関する制限事項
ログ収集に関する制限事項は、収集方式より異なります。 制限事項に該当する方式をリストで記載します。
|
|
|
|
9.7.3.1.1. BOM(byte order mark)を含む収集対象のファイルの処理
|
|
|
収集対象ファイルが先頭にBOM（byte order mark）を含むファイルであった場合、差分収集したファイルはBOM（byte order mark）のないファイルになります。 また、ファイルの分割が行われた場合、差分収集のような、単純なバイトカットではないため、以下のような処理結果になります。
分割後のファイルの改行コードは、「CR/LF」になる。 utf-8またはutf-16などで分割した場合は、BOM（byte order mark）が必ず付加される。
9.7.3.1.2. 特定の条件下において対象サーバからのイベントログ収集処理が正常に動作しない
|
対象サーバから収集の対象としているイベントログのパスが以下のような状況にある場合、ログ収集タスクで対象サーバのイベントログを収集する処理が正常に動作しません。
%SystemRoot% 以外の環境変数が含まれている。
%SystemRoot% 環境変数が含まれており、かつその値が C:\Windowsではない。
収集対象となるログが格納されているフォルダーパスに対し、管理共有経由でアクセスできない。
9.7.3.1.3. 変更後の収集対象パスに過去のイベントログが存在する場合そのイベントログも収集されてしまう
|
収集対象としているイベントログのパスを変更した際、変更後のパスのフォルダーに過去のイベントログが存在している場合、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となり、結果重複したログ収集となってしまいます。 なお、この重複したログ収集を避けるためには、変更後のパスのフォルダー内のイベントログを退避する必要があります。
9.7.3.2. 対象サーバ管理に関する制限事項
9.7.3.2.1. 収集対象となるログのフォーマットが変わった場合、ログ変換時にエラーとなる可能性がある
ALog EVAにおいて、収集対象となっているログのフォーマットが途中で変更された場合、ログ変換時にエラーが発生する可能性があります。 例として、以下のようなケースがあります。
ファイル形式がCSVのログを収集するために、マッピングの設定で、「CSV/TSV/DSV」を選択し、カンマ区切りを指定した
その後、出力されるログのファイル形式がSyslogに変更となったため、対象サーバのマッピングの設定を「CSV/TSV/DSV」から「Syslog」に変更した
上記の場合、次のログ変換タスクにおいて、一部のログ（直前までのログ収集で「eLogC」フォルダーに格納したCSVのzipファイル）の翻訳処理でエラーが発生する可能性があります。 このようなエラーを抑制するために、ログ変換タスクを実行し、「eLogC」フォルダーにある変更前のフォーマットのファイルをすべて処理し終えてから、マッピング設定にて、収集するファイル形式を変更してください。
9.7.3.2.2. ログ変換時のマージ処理について
ALog EVAにおいて、[マッピング設定-出力]設定のオプション「重複する行を1行にマージする」にチェックをつけるとマージ処理が動作しますが、この処理はファイル内のレコードに対して行われるため、別ファイルに分かれる場合はマージ処理を行いません。またファイル内のレコードにおいて、時刻フィールドの記録順にマージ処理を行います。時刻フィールドを変換処理時に並び替えすることは行いませんので、場合によっては期待するマージが行われない場合があります。
9.7.4. Amazon FSx for Windows File Serverの制限事項
9.7.4.1. ログ変換に関する制限事項
Amazon FSx for Windows File Serverのログは、ALogでは全て「ObjectAccess」操作として出力します。ファイルの新規作成、書き込み、削除、どのような操作も「ObjectAccess」になります。基本的に「何らかのファイル操作があった」と読み取ります。(理由)Amazon FSx for Windows File Serverは出力するイベントログの絞り込みをしており、ALogで操作を判断するための情報が不足しているためです。「ファイルを書き込み」したイベントログに「削除」の情報が付与されているケースがありますが、これを「書き込み」の操作であると判断する材料がありません。詳細フィールドにAccessList、AccessMaskを出力していますので、それらの情報から判断できる情報があります。詳細についてはAmazon FSx for Windows File Serverの監査ログの説明ページを参照してください。
9.7.5. WorkTimeの制限事項
9.7.5.1. WorkTimeの仕様について
WorkTimeは日本国内向けに開発しています。
ALogの変換時刻はマネージャーサーバの地域設定に依存します。 日本の地域設定であれば、変換タスク動作時にUTC+9:00で変換しています。そのログをWorkTimeで使用します。
9.7.5.2. 複数のファイル出力設定で、同じ保存先フォルダーを指定すると、保存や自動削除が正しく動作しない場合について
ファイル出力設定において、複数の出力設定で同じ保存先フォルダーを指定してしまうと、保存や自動削除の機能が正しく動作しません。 ファイル出力設定を複数設定する際は、保存先フォルダーを分けてください。
また、すでに作成しているファイル出力設定の内容を変更する場合も、出力先を変更するか、それまで出力していたデータを事前に別フォルダーに退避させてください。
9.7.5.3. 勤怠データ作成処理時のユーザー区別について
WorkTimeの勤怠データ作成処理は、アクセスログ上のユーザー単位で行われます。 AD情報による置換名が同名であっても、アクセスログのユーザー名が異なる場合は、別のユーザーとして扱われます。