none
初めての共有フォルダ接続時に、ユーザー認証画面が表示されず、ネットワークエラーになる。 RRS feed

  • 質問

  •  共有フォルダアクセス時に資格情報を保存する(自動ログインさせる)方法や、資格情報をリセット(削除)する方法は、よく目にいたします。

     しかし、初めて共有フォルダにアクセスした際(資格情報は何も保存されていないのに)、ユーザー認証画面も表示されず、ネットワークエラーが発生してしまい困っております。 

    【環境】

     ファイルサーバ : Windows Server 2012R2 (Active Directory 環境)

     クライアント : Windows 7 Professional SP1 (ワークグループ環境)

    【現象】

     ファイルサーバに共有フォルダを作成し、クライアントからアクセスすると、

     「ネットワークエラー \\ファイルサーバ\共有フォルダ に対するアクセス許可がありません。ネットワーク管理者にアクセス許可を要求してください。」

     とエラーになってしまいます。

     AD環境のファイルサーバに、ワークグループ環境のクライアントから初めてアクセスしているため、当然、ユーザー認証画面(ユーザーIDとパスワード入力)が表示されると想定しておりましたが、ユーザー認証画面は表示されず、エラーメッセージが出力されてしまいます。

    【確認したこと】

     (1) クライアントでネットワークドライブの割り当てで、「別の資格情報を使用して接続する」でアクセスすれば、共有フォルダに接続することができます。

      ただし、net use * /delete でネットワークエラーとなった接続を、削除してからネットワークドライブを作成しないと、上手くいきません。

     (2) net use コマンドを使用すれば、共有フォルダに接続することができます。

    【知りたいこと】

     (1) 共有フォルダに初めてアクセスした際に、ユーザー認証画面を表示させ、ユーザーIDとパスワードを入力させる方法(この後は、資格情報を保存して、自動ログインでも構いませんが、初めに入力させたいのです)

     (2) ネットワークエラーになったとき、一体、どのユーザーの資格情報を使用して接続していたのか?(クライアントのログインユーザーなのか?Guestユーザーなのか?)

     (3) この現象が発生するクライアントと、発生しないクライアントが存在しており、その違いが分かりません。チェックすべき箇所は何でしょうか?

    もしかすると、すごく基本的な設定で解決してしまうのかも知れませんが、有用な情報に辿り着けなかったため、ご教示いただければ、ありがたいです。

    以上です。よろしくお願いいたします。





    2016年6月15日 11:14

回答

  • チャブーンです。

    この件ですが、発生する原因は、ワークグループによるWindows認証の「事実上の」制限事項によるものです。

    ワークグループの場合、アクセスする側は「ローカルログオンしているユーザアカウント名とパスワード」で認証を試行します。アクセスされる側(サーバ)は、自分自身のSAM(ローカルユーザ情報と理解してください)に同名のアカウントの有無を確認し、同名アカウントがあればそのパスワードが一致しているかを確認し、なければ明示的にアカウント情報を入力するよう、アクセスする側に要求します。

    ですから、この件ではクライアントのユーザアカウント(同名のアカウント名)がサーバにも存在するが、そのパスワードが一致しないため、認証に失敗している状態、になります。この作業は自動的に行われるため、「同名のアカウントが存在しても、必ず資格情報の確認を求める」ということはできません。

    どうしてもやめさせたい場合は、サーバのローカルユーザ一覧を確認し、クライアントと同名のアカウントがあれば削除してください。サーバがドメインコントローラ自身であれば、[Active Directoryユーザーとコンピューター]から同じことをする必要があります。サーバ側の情報はいじりたくない、という場合は、クライアント側のユーザアカウント名を別の名前に変更するしかありません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク てんろく 2016年6月16日 8:21
    2016年6月16日 1:44

すべての返信

  • チャブーンです。

    この件ですが、発生する原因は、ワークグループによるWindows認証の「事実上の」制限事項によるものです。

    ワークグループの場合、アクセスする側は「ローカルログオンしているユーザアカウント名とパスワード」で認証を試行します。アクセスされる側(サーバ)は、自分自身のSAM(ローカルユーザ情報と理解してください)に同名のアカウントの有無を確認し、同名アカウントがあればそのパスワードが一致しているかを確認し、なければ明示的にアカウント情報を入力するよう、アクセスする側に要求します。

    ですから、この件ではクライアントのユーザアカウント(同名のアカウント名)がサーバにも存在するが、そのパスワードが一致しないため、認証に失敗している状態、になります。この作業は自動的に行われるため、「同名のアカウントが存在しても、必ず資格情報の確認を求める」ということはできません。

    どうしてもやめさせたい場合は、サーバのローカルユーザ一覧を確認し、クライアントと同名のアカウントがあれば削除してください。サーバがドメインコントローラ自身であれば、[Active Directoryユーザーとコンピューター]から同じことをする必要があります。サーバ側の情報はいじりたくない、という場合は、クライアント側のユーザアカウント名を別の名前に変更するしかありません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク てんろく 2016年6月16日 8:21
    2016年6月16日 1:44
  • チャブーンさん

    ピッタリな、ご回答ありがとうございます。

    ご指摘のとおり、同名アカウントが存在していますね。

    ワークグループ上に存在する PC は、すべて同じアカウント名を使用しております。

    そして、AD上にも、同名のアカウントを作成しております。

    手っ取り早いのは、AD 上のアカウントを削除するのが良さそうです。

    助かりました。ありがとうございます。

    2016年6月16日 8:32