
Apache HTTP Kerberos モジュールの設定は次のとおりです/etc/apache2/sites-available/my.server.tld.conf
。
# ...
<Location />
Authname "SSO Authentication"
AuthType Kerberos
KrbAuthRealms MY.DOMAIN.TLD
KrbServiceName HTTP/[email protected]
Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
KrbMethodNegotiate On
KrbMethodK5Passwd On
Require valid-user
</Location>
# ...
Kerberos 構成は次のとおりです/etc/krb5.conf
:
[libdefaults]
default_realm = MY.DOMAIN.TLD
# ...
[realms]
MY.DOMAIN.TLD = {
kdc = my.ad.server.1.tld
kdc = my.ad.server.2.tld
admin_server = my.ad.server.1.tld
}
# ...
[domain_realm]
friendly.domain.tld = MY.DOMAIN.TLD
.friendly.domain.tld = MY.DOMAIN.TLD
# ...
Apache HTTP Web サーバーは Debian GNU/Linux 10 にインストールされています。
キータブ ファイルはmy.ad.server.1.tld
、コマンドを使用して、Windows Server上で生成されましたktpass
。
この構成では、MY.DOMAIN.TLD
ドメイン内の Windows マシン上の Edge と Firefox の両方ですべて正常に動作します。
私の問題は、ドメイン外の Windows マシンで Microsoft Edge (Chromium エンジンを搭載した新しいもの) または Google Chrome を使用するクライアントから発生します。
への最初の接続時にmy.server.tld
、ブラウザは およびWWW-Authenticate: Negotiate
ヘッダーを受信しますWWW-Authenticate: Basic realm="SSO Authentication"
。
Microsoft Edge では、Firefox とは異なり、ポップアップ表示される認証ダイアログはWWW-Authenticate: Negotiate
ブラウザーのものではなく、Windows 認証ダイアログであり、何を入力しても機能しません。
最初のログイン試行が失敗すると、ブラウザによって 2 回目の要求が発行されますが、今回はヘッダーのみが受信されますWWW-Authenticate: Basic realm="SSO Authentication"
。ブラウザの認証ダイアログがポップアップ表示され、正常に機能します。その後、内部をさらにナビゲートするmy.server.tld
と、バックグラウンドで多数の Windows 認証ダイアログが生成されます。たとえば、ページに画像がある場合は、その画像に対する認証ダイアログが表示されます。
Windows マシンが内部ネットワークに接続されていてMY.DOMAIN.TLD
、Windows 認証ダイアログでドメインを明示的に指定すると、同様に正常に機能することに気付きました (つまり、[email protected]
ユーザー名として)。
上記のすべてを念頭に置いて、私は今疑問に思います...
- Windows マシンの統合 Windows 認証ダイアログで実際に動作させることは可能ですか?
[email protected]
ドメインを認証に使用するように「強制」し、ドメイン外のマシンのようにドメインを明示的に指定する必要性をなくす方法はありますかMY.DOMAIN.TLD
?
すでに Kerberos レルム構成内に追加したり、 Debian GNU/Linux 10 サーバーでdefault_domain = my.domain.tld
Kerberos TGT を取得したりしようとしましたが、成功しませんでした。kinit
あらゆる状況で Apache HTTP のログを読むとLogLevel trace8
、Windows 認証ダイアログがポップアップ表示され、NTLM トークンが返され、正しく動作しないように見えます。
うまくいくとき
Firefoxがあればどこでも
または
ドメイン内のコンピューター、内部ネットワーク(Edge または Chrome)
または
ドメイン外のコンピューター、外部ネットワーク、[email protected]
(Edge または Chrome) を使用する場合:
mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1754): GSS-API token of length 180 bytes will be sent back
mod_authz_core.c(820): AH01626: authorization result of Require valid-user : granted
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: granted
うまくいかないとき
ドメイン外のコンピューター、外部ネットワーク (Edge または Chrome) の場合:
mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1763): Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
これらすべての中で厄介なのは、Firefox では完璧に動作するが、最近の Chromium エンジンを搭載したブラウザでは動作しないという点です。これは、Basic 認証ではなく NTLM 認証にフォールバックするためでしょうか?
答え1
間違っているかもしれませんが、私の場合、ナビゲータは信頼できるサイトにのみ Kerberos 認証情報を送信します。したがって、ドメイン内のコンピュータの場合、ナビゲータは Web サーバーを「イントラネット」サイト (= 信頼できる、= 認証情報を送信できる) と見なします。ただし、他のコンピュータの場合、Web サーバーによる認証情報の要求は破棄されます。したがって、外部コンピュータの信頼できるサイトに Web サーバーの FQDN を追加すれば、うまくいくのではないでしょうか。