アカウントロックの原因を特定する方法

Yuki21 · ‎12-23-2021

特定のServiceNowユーザのアカウントロックが頻発しております。

イベントログを確認したところ、「login.failed」となっているレコードが大量にあることを確認しました。

イベントログのパラメータ１にはユーザID、パラメータ2にはIPアドレスが出力されているのですが、パラメータ2は何を示すものなのでしょうか？

どこからの認証が失敗していることによりアカウントロックがされているか特定する方法をご存じの方がいましたらご教示いただければと思います。

＜イベントログ画面＞

Hitoshi Ozawa · ‎12-23-2021

parm2はremoteAddrです。一般の場合はユーザが利用されているプロバイダのグローバルアドレスだと思います。

Hitoshi Ozawa · ‎12-23-2021

parm2はremoteAddrです。一般の場合はユーザが利用されているプロバイダのグローバルアドレスだと思います。

Takuya Kadowak2 · ‎12-23-2021

このスレッドが参考になるかと思います。

MID Server user connectivity issues

Parm2にIP addressが入っているのは、接続をトライしている端末のIPではないでしょうか？下記のように記載があるのでParm2はログインが試行されたIPアドレスになります。

> Filter for login.failed in the Name field. You can view the attempted login name, date, and IP address logged for the attempt.

Specify lockout for failed login attempts

もし以前は問題なくログインできていて、急にできなくなった場合、このユーザーはログインできることが本来の動きであれば、サポートケースの起票も検討されてはどうでしょうか？

Yuki21 · ‎12-26-2021

ご返信いただきありがとうございます。

接続元のIPというのは分かりましたが、Parm2に設定されているIP addressが特定できず、対処ができない状況です。

トランザクションログエントリーを確認したところ、Parm2のIP addressのレコードを確認できました。

ユーザーエージェント、URLが以下の通りとなっておりますが、これらの情報からどのような可能性があるか、お分かりでしたらご教示いただければと思います。

また他にこのような情報があれば等、ございましたらご意見いただければと思います。

ユーザーエージェント：remote_glide_record_client

URL：/ecc_queue.do?redirectSupported=true&SOAP&displayvalue=all

Hitoshi Ozawa · ‎12-26-2021

MIDサーバを介してでどのようなジョブを走らしているのでしょうか？

例えばITOM Discoveryを実行しているとか、LDAP連携しているとか、他システム連携とか。

そんなに走らしているジョブはないと思います。認証エラーが発生していたらその中のジョブがエラー終了しているはずです。認証エラーから辿るよりも実行されているジョブが行うデータ更新がされていないジョブを探した方が早いと思います。

例えばDiscoveryでエラーが発生していたら新規機器がServiceNowに登録されません。

LDAP連携が失敗していたら新しいユーザが追加されません。