web-dev-qa-db-ja.com

IIS証明書認証にマップされたWindowsアカウントの構成

1つ（Linuxスタック）がcronベースのジョブを使用して他の（Windowsスタック）にHTTP定期リクエストを発行するために、異なる場所にある2つのサーバーを接続する必要があります。

Windowsマシンでは、自己署名証明書を使用してIIS）を設定し、（証明書を固定することによって）クライアントに対して認証し、SSLを介して接続を暗号化します。

また、IISを構成して、Linuxサーバーを認証するためのクライアント証明書を要求します。証明書をユーザーアカウントにマッピングすることを含む、証明書認証を構成するチュートリアルを完了しました。

私は、リモートサーバー用にユーザーアカウントを作成するという考えには満足していません。そのアカウントで（Windows）サーバーにログインする人はいないからです。

これを念頭に置いて、本当にWindowsマシンでアカウントを作成する必要がある場合、LinuxサーバーからのIISの要求を認証するためにのみ使用できるように、それをどのように構成する必要がありますか？

authenticationwindowsiiscertificate-pinning
3
Juan

このタスクのためだけに新しいユーザーアカウントを作成することについて心配するのは当然です。より簡単な方法は、リクエストヘッダーに挿入されたアプリケーションキーを使用することです。自己署名証明書を使用しているので、これは1回限りのソリューションであり、数百のクライアントに拡張することはできないと私に思わせます。これを実現する手順は次のとおりです。

更新：この代替ソリューションは、IISホストされているアプリケーションに影響を与えません。URLリライトがアプリケーションの前に要求を処理するためです。失敗した試行を直ちに破棄するには、actionURL書き換えルールのセクションを以下に変更します。これにより、失敗した要求がIISログに表示されなくなります。

<action type="AbortRequest" />

IISにURL Rewriteをインストールする

これは、デフォルトではインストールされないMicrosoftモジュールであり、mod_rewriteと同様の機能を提供します。

https://www.iis.net/downloads/Microsoft/url-rewrite#additionalDownloads

URL書き換えルールを作成

アプリケーションのweb.configに次のルールを追加します。 AppAuthKey（変更/パーソナライズ可能）のリクエストヘッダーとjoshua（大文字と小文字を区別せず、より複雑なものにする必要があります）。どちらも存在しない場合は、401.4が返されます。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
                    </conditions>
                    <action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

カール編集コマンド

次のようにリクエストヘッダーを含めるようにcurlコマンドを更新します。

curl -H "AppAuthKey: joshua"

クライアント証明書は不要

この方法を使用する場合、クライアント証明書は必要ありません。強力な暗号を使用している限り、通常のSSL（TLS1.2にする必要があります）で十分です。これに関する詳細は、次のOWASPページにあります。

https://www.owasp.org/index.php/Hardening_IIS#Ensure_TLS_cipher_suites_are_correctly_ordered

アップデート＃2

@AlphaDは、アカウントをさらに制限するために使用できるさまざまなポリシー設定に関する優れた点を示しています。構成管理に反するため、これはお勧めしません。そのアプローチを採用すると、他のサービスに影響を与える可能性のあるWebアプリケーションをホストするシステムの構成要件が発生します。推奨される方法は、移植性のためにWebアプリを設計することです。そのため、ホスティングシステムはほとんど必要ありません。 IISのローカルユーザーアカウントまたはドメインユーザーアカウントではなく、このインスタンスでアプリケーションキーを使用する方が望ましい理由について、いくつかの重要なポイントを強調することが理にかなっていると想定します。

ローカルユーザー

ユーザーがIISをホストするWebサーバーだけにローカルである場合、そのアカウントは、そのサーバーがホストする他のWebサイトやサービスに対して認証を行うことができます。デフォルトではアカウントは驚くほど幅広いローカル "Users"グループのメンバーになるため、他のすべてのリソースに対する権限が確認されていることを確認してください。さらに、このアカウントにはファイルシステム（NTFS）に対する読み取りアクセス権があります。別のWebサイトが正しく構成されていない場合、このユーザーを使用して認証し、そのコンテンツを読み取ることができます。このアカウントによる認証では、基本認証が使用される可能性が高くなります。つまり、資格情報はBase64でエンコードされ（暗号化されず）、すべてのリクエストヘッダーに配置されます。 （認証のためにカスタムリクエストヘッダーを追加するという私の推奨事項と同じです。）最後に、ローカルユーザーアカウントを使用すると、システム管理が難しくなります。 Webサイトを新しいサーバーに移行する場合、新しいアカウントを作成して、権限を更新し、適切にスコープを設定する必要があります。次に、そのログオン情報を、消費するcurlスクリプトで更新する必要があります。アプリケーションを移植可能にするものではありません。

ドメインユーザー

ローカルユーザーと同じように、このユーザーが認証できる範囲がドメイン全体に拡大されました。これには、環境でアドバタイズされたActive Directoryおよびその他のサービスの多くに対する読み取りアクセスが含まれます。 ADがアクセス可能で、LinuxホストがAD認証用に構成されている限り、NTLMまたはKerberosを使用できるため、このユーザーでの認証は少し安全になります。それ以外の場合は、おそらく基本認証が使用されます。アカウント管理は、システムアカウント管理ではなくドメインアカウント管理の領域に分類され、しばしば（常にではない）ドメインアカウント管理の確立された手順があるため、少し簡単になります。

アプリケーションキー

ユーザーアカウントは不要であり、スコープをこのアプリケーションのみに制限するため、推奨される方法です。弱点を通信チャネル（TLSと強力な暗号で保護）と、とにかくアクセスを制限する必要があるコンテンツディレクトリ。

1
user2320464

あなたの質問について私が理解できることから、ログインやその他の通常許可されている権限を許可せずにWindowsサーバーユーザーを生成する方法を求めています。

その場合は、[コントロールパネル]> [管理ツール]> [ローカルセキュリティポリシー]でそのユーザーのローカルポリシーを設定してください。左側のメニューで、[ローカルポリシー]> [ユーザー権利の割り当て]に移動します。 「ローカルでログオンを拒否する」「リモートデスクトップサービスを介してログオンを拒否する」ポリシー（およびその他の該当するもの）にユーザーを追加します。

ユーザーがログイン画面にサービスアカウントを表示しないようにするためだけにこれを試したため、ここにいくつか欠けている可能性があることに注意してください。

1
AlphaD