の検索結果 ：
×ケルベロスは 暗号ベースの認証プロトコル アプリケーションへのアクセスを保護します。 このプロトコルは、安全でないネットワーク上で安全な認証を提供するように設計されています。 Kerberos の背後にある重要なアイデアは、パスワードがインターネット経由で送信されるのを防ぎながらユーザーを認証することです。
ケルベロス: Kerberos は、シングル サインオン (SSO) の概念をサポートする認証プロトコルです。 HTTP の場合、Kerberos のサポートは通常、「SPNEGO」認証メカニズムという用語を使用して提供されます。
ケルベロスレルム: 認証用の管理ドメインは、レルムという用語で示されます。 その目的は、認証サーバーがユーザー、ホスト、またはサービスを認証できる場合の制限を定義することです。 これは、認証を行うためにユーザーとサービスが同じレルムのメンバーである必要があることを意味するものではありません。XNUMX つのオブジェクトが異なるレルムに属しているにもかかわらず、信頼接続を介して接続されている場合でも、認証は行われます。
メイン： Kerberos システムでは、Kerberos プリンシパルは、Kerberos が Kerberos 対応サービスにアクセスするためのチケットを発行できる個別の ID を表します。 「/」区切り文字は、プリンシパル名を構成するさまざまなコンポーネントを区切るために使用されます。 「@」文字を使用すると、レルムを名前の最後の要素として識別できます。 レルムが指定されていない場合、プリンシパルは krb5.conf ファイルに設定されているデフォルトのレルムに属していると想定されます。
クライアント/ユーザー: ユーザーに代わってサービスにアクセスするプロセス。 レルム内には複数のクライアントまたはユーザーが存在する可能性があります。
サービス： ユーザーがアクセスしたいもの。
SSO: シングル サインオンとは、ユーザーが一度ログインするだけで、ユーザー認証を完了した後、さまざまなサービスにアクセスできるようにする手順です。 プライマリ サービスにログインした後、ユーザーが許可を与えたすべてのサービスへの認証が必要になります。 SSO には多くの利点があります。その XNUMX つは、パスワードやその他の認証システムを使用して ID を繰り返し検証する面倒なプロセスを回避できることです。
GSSAPI: プログラムは、アプリケーション プログラミング インターフェイス (API) である Generic Security Service Application Program Interface(GSSAPI) を通じてセキュリティ サービスにアクセスできます。 IETF 標準は GSSAPI です。 それ自体ではセキュリティは提供されません。 代わりに、GSSAPI 実装はセキュリティ サービス プロバイダーによって提供されます。 実装の詳細を上位レベルのアプリケーションから隠す、不透明なメッセージ (トークン) の交換は、GSSAPI アプリケーションの際立った特性です。
スプネゴ: クライアント サーバー ソフトウェアは、「spen-go」と呼ばれることが多い、シンプルで保護された GSSAPI ネゴシエーション メカニズムを使用して、セキュリティ テクノロジの選択をネゴシエートします。 クライアント アプリケーションがリモート サーバーにログインする必要があるが、どちらの側も他方がサポートしている認証プロトコルが不明な場合は、SPNEGO が使用されます。 擬似メカニズムは、プロトコルを使用して利用可能な共通 GSSAPI メカニズムを識別し、XNUMX つを選択し、その後のすべてのセキュリティ アクションをその選択したメカニズムに割り当てます。
KDC: キー配布センターは、チケットと一時セッション キーを提供するネットワーク サービスです。 またはそのサービスのインスタンス、またはそのサービスが実行されるホスト。 KDC は、最初のチケット要求とチケット認可要求の両方を処理します。 初期チケット部分は、認証サーバー (またはサービス) と呼ばれることもあります。 チケット認可チケット部分は、チケット認可サーバー (またはサービス) と呼ばれることもあります。
Active Directory ドメイン上のリソースへのクライアントのアクセスは、Windows NT LAN Manager (NTLM) として知られるチャレンジ/レスポンス認証プロトコルを使用して認証できます。 クライアントがドメイン関連サービスへのアクセスを要求すると、サービスはクライアントにチャレンジを送信し、認証トークンを使用して数学的演算を実行し、その結果をサービスに提供するように指示します。 結果はサービスによって検証されることも、ドメイン コントローラー (DC) によって検証されることもあります。 DC またはサービスがクライアントの応答が正確であることを確認した場合、サービスはクライアントへのアクセスを許可します。
NTLM は、ユーザーがログイン中に基礎となる認証要素を XNUMX 回だけ入力できるため、一種のシングル サインオン (SSO) です。
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytab注： 確保 Example.COM 大文字にする必要があります。 SPN を持つユーザーがすでに存在する場合は、そのユーザーを使用して新しいユーザーを作成します。 Kerberos 原則では大文字と小文字が区別されます。 keytab コマンドを実行する前に、大文字と小文字の違いを確認してください。
| サーバーのホスト名: | これは、サーバー上でホストされているサイトのホスト名です。 |
| 例.COM: | これは、Active Directory ドメイン名です。 |
| ユーザー名： | これは、Active Directory のサービス アカウントです。 |
| パスワード: | 上記で使用したサービスアカウントのパスワードです。 |
| パス： | キータブ ファイルを保存するローカルの場所へのパス。 (C:\Temp\spn.keytab) |
注： 上記のコマンドは keytab ファイルを作成します。 WordPress サイトがホストされているクライアント サーバーに配置する必要があります。 Apache を実行しているユーザーは、このファイルへの完全なアクセス権を持っている必要があります。 ユーザーには keytab ファイルに対する権限が必要です。
chmod 644 etc/apache2/spn.keytab
sudo apt-get install krb5-user
注： Ubuntu/Debian の最新リリースでは、 mod_auth_kerb は廃止され、次のものに置き換えられました mod_auth_gssapi.
sudo apt-get install libapache2-mod-auth-kerba2enmod auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
[libdefaults]
default_realm = EXAMPLE.COM
# ...
# ...
[realms]
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
注： 置き換える 広告ドメインコントローラーのIP/DNS IP/DNS アドレスを使用してください。 確保する Example.COM 大文字にする必要があります。
置き換える Example.COM Active Directory ドメイン名を使用します。
また、AD ドメイン コントローラーのポート 88 がこのサーバーからアクセスできることを確認してください。
注： 使用する Apache モジュールに応じて、ディレクトリに次のセクションを追加します。 例えば： 「mod_auth_kerb」 or 「mod_auth_gssapi」.
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
<IfModule !mod_auth_gssapi.c>
LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
</IfModule>
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiAllowedMech krb5
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
BrowserMatch Windows gssapi-no-negotiate
Require valid-user
</Directory>
注： 確保 Example.COM 大文字にする必要があります。
上記の構成のコンポーネントは次のとおりです。
| 例.COM: | これは、krb5.conf で構成されている Active Directory ドメインです。 |
| キータブへのパス: | このサーバー上のキータブへのアクセス可能なパス。 (etc/spn.keytab) |
サービス アカウントをお持ちでない場合は、[Active Directory ユーザーとコンピューター] で新しいユーザー アカウント (サービス アカウント) を作成します。 このオブジェクトに SPN エントリが割り当てられていないことを確認してください (servicePrincipalName 属性は空である必要があります)。
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytab注意： 確保 Example.COM 大文字にする必要があります。 Kerberos 原則では大文字と小文字が区別されます。 keytab コマンドを実行する前に、大文字と小文字の違いを確認してください。
| サーバーのホスト名: | これは、サーバー上でホストされているサイトのホスト名です。 |
| 例.COM: | これは、Active Directory ドメイン名です。 |
| ユーザー名： | これは、Active Directory のサービス アカウントです。 |
| パスワード: | 上記で使用したサービスアカウントのパスワードです。 |
| パス： | キータブ ファイルを保存するローカルの場所へのパス。 (C:\Temp\spn.keytab) |
注： 上記のコマンドは keytab ファイルを作成します。 WordPress サイトがホストされているクライアント サーバーに配置する必要があります。 Apache を実行しているユーザーは、このファイルへの完全なアクセス権を持っている必要があります。ユーザーは、keytab ファイルへのアクセス許可を持っている必要があります。
chmod 644 etc/httpd/spn.keytab
yum install -y krb5-workstation krb5-devel krb5-libs mod_auth_gssapi mod_session注： CentOS の最新リリースでは、 mod_auth_kerb は廃止され、次のものに置き換えられました mod_auth_gssapi.
yum install mod_auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
注： 置き換える 広告ドメインコントローラーのIP/DNS IP/DNS アドレスを使用してください。 確保する Example.COM 大文字にする必要があります。
置き換える Example.COM Active Directory ドメイン名を使用します。
また、AD ドメイン コントローラーのポート 88 がこのサーバーからアクセスできることを確認してください。
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
Require valid-user
</Directory>
上記の構成のコンポーネントは次のとおりです。
| キータブへのパス | このサーバー上のキータブへのアクセス可能なパス。 (etc/apache2/spn.keytab) |
| "/プレースホルダー" | ドキュメントルートへのパス |
注： Web サイトが http://machinename および http://machinename.domain.com で応答する必要があるとします。 これらのアドレスをサービス アカウントの SPN 属性で指定する必要があります。
Setspn -S http/<computer-name>.<domain-name> <domain-user-account>例： C:\Users\Administrator> setspn -S HTTP/マシン名.ドメイン.com サービスアカウント
注： ここでの「machinename.domain.com」はコンピュータ名です。 AD サービスを実行している Windows サーバー上で解決可能であることを確認してください。
setspn -l domain or service_account例： C:\Users\Administrator> setspn -l サービスアカウント または C:\Users\Administrator> setspn -l ドメイン名
注： デフォルトでは、Negotiate と NTLM の XNUMX つのプロバイダーが使用可能です。 Negotiate は、最初の認証方法として Kerberos を使用するコンテナーであり、認証が失敗した場合は NTLM が使用されます。 したがって、Negotiate がプロバイダーのリストの最初に来る必要があります。
例：ドメイン.com\サービス_アカウント
注： useAppPoolCredentials を True に設定すると、IIS がドメイン アカウントを使用してクライアントからの Kerberos チケットを復号化できるようになります。
フィドラーを起動し、ブラウザを起動して目的の Web サイトにアクセスします。 ウィンドウの左側にある Web サイトへのアクセスの行を見つけます。 ウィンドウの右側から「検査」タブを選択します。 「認可ヘッダー (ネゴシエート) には Kerberos チケットが含まれているようです。」という行から、IIS Web サイトでの認証に Kerberos が使用されていることは明らかです。
Setspn -s http/<computer-name>.<domain-name> <domain-user-account>例： C:\Users\Administrator> setspn -S HTTP/マシン名.ドメイン.com サービスアカウント
注: ここでの「machinename.domain.com」はコンピューター名です。 AD サービスを実行している Windows サーバー上で解決可能であることを確認してください。
setspn -l domain\service_account
LoadModule authnz_sspi_module modules/mod_authnz_sspi.soLoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_core_module modules/mod_authz_core.so
<Directory "...../xampp/htdocs">
......
......
#Require all granted
AllowOverride None Options None
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
Require valid-user
</Directory>
クライアント側の構成により、それぞれのブラウザーが SPNEGO を使用してブラウザーの Kerberos 認証をネゴシエートできるようになります。 エンド ユーザーのシステム上のブラウザが Kerberos 認証をサポートするように構成されていることを確認する必要があります。
デフォルトでは、一般的なブラウザ構成設定が適用され、Internet Explorer にはそれ以上の追加設定は必要ありません。
デフォルトでは、一般的なブラウザ構成設定が適用され、Google Chrome にはそれ以上の追加設定は必要ありません。
Kerberos プロトコルでは、クライアントとサーバーの時間が一致している必要があります。クライアントのシステム クロックがサーバーのシステム クロックと一致しない場合、認証は失敗します。 システム クロックを同期する最も簡単な方法は、ネットワーク タイム プロトコル (NTP) サーバーを使用することです。
keytab と Kerberos の構成を確認するには、次のコマンドを実行します。
klist コマンドは、Kerberos 資格情報キャッシュまたはキー テーブルの内容を表示します。 このコマンドを使用すると、有効なチケットを取得したかどうかを確認できます。
etc/apache2/spn.keytab キーテーブル内のすべてのエントリをタイムスタンプとともにリストします。
セッションキーとチケットの暗号化タイプを表示し、キーテーブル内のエントリをリストします。
keytab ファイルを使用して Kerberos 認証を検証します。
Linux でこのコマンドを使用すると、ローカル マシン上の Kerberos トークンをリセットできます。 このコマンドは、以前の Kerberos チケットを破棄します。
Windows でこのコマンドを使用すると、ローカル マシン上の Kerberos トークンをリセットできます。 このコマンドは、以前の Kerberos チケットを破棄します。
<?php
var_dump($_SERVER);
?>
注： 構成を確認した後、test.php ファイルを削除してください。 貴重な情報が含まれているので。
ktutil
ktutil: read_kt <keytab_filename_1>
ktutil: read_kt <keytab_filename_2>
ktutil: read_kt <keytab_filename_3>
ktutil: write_kt spn.keytab
ktutil: quit
klist -k spn.keytab
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
ktutil
addent -password -p HTTP/<Server Host Name>@EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96
wkt spn.keytab.
Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
or
kinit: krb5_get_init_creds: Too large time skew
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Key table entry not found).
Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ).
kinit: KDC has no support for encryption type while getting initial credentials
[libdefaults]
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED
or
kinit: Client's entry in database has expired while getting initial credentials
kinit: krb5_cc_get_principal: No credentials cache file found
or
kinit: krb5_get_init_creds: Error from KDC: CLIENT_NOT_FOUND
kinit : Cannot find KDC for requested realm while getting initial credentials
kinit: Preauthentication failed while getting initial credentials
kinit: Client not found in Kerberos database while getting initial credentials
kinit: Client's entry in database has expired
助けが必要？ 私たちはここにいます！
