【问题标题】:SPNEGO uses wrong KRBTGT principal nameSPNEGO 使用了错误的 KRBTGT 主体名称
【发布时间】:2020-07-01 23:23:16
【问题描述】:

我正在尝试为我们的网站启用 Kerberos 身份验证 - 想法是让登录到 Windows AD 域的用户自动登录(并创建初始帐户)

在我处理 Windows 方面的问题之前,我想让它在本地工作。 所以我使用 git@github.com:ist-dsi/docker-kerberos.git 做了一个测试 KDC/KADMIN 容器

您的网络服务器位于本地 docker 容器中,其中包含 nginx 和编译的 spnego 模块。 KDC/KADMIN 容器位于 172.17.0.2,可从我的网络服务器容器访问。

这是我本地的 krb.conf:

default_realm = SERVER.LOCAL

[realms]
SERVER.LOCAL = {
                kdc_ports = 88,750
                kadmind_port = 749
                kdc = 172.17.0.2:88
                admin_server = 172.17.0.2:749
        }

[domain_realms]
  .server.local = SERVER.LOCAL
  server.local = SERVER.LOCAL

以及 webserver 容器上的 krb.conf

[libdefaults]
  default_realm = SERVER.LOCAL
  default_keytab_name  = FILE:/etc/krb5.keytab
  ticket_lifetime      = 24h
  kdc_timesync         = 1
  ccache_type          = 4
  forwardable          = false
  proxiable            = false

[realms]
  LOCALHOST.LOCAL = {
    kdc_ports = 88,750
    kadmind_port = 749
    kdc = 172.17.0.2:88
    admin_server = 172.17.0.2:749
  }

[domain_realms]
  .server.local = SERVER.LOCAL
  server.local = SERVER.LOCAL

这里是principals和keytab配置(keytab被复制到/etc/krb5.keytab下的web容器中)

rep ~/project * rep_krb_test $ kadmin -p kadmin/admin@SERVER.LOCAL -w hunter2
Authenticating as principal kadmin/admin@SERVER.LOCAL with password.
kadmin:  list_principals
K/M@SERVER.LOCAL
kadmin/99caf4af9dc5@SERVER.LOCAL
kadmin/admin@SERVER.LOCAL
kadmin/changepw@SERVER.LOCAL
krbtgt/SERVER.LOCAL@SERVER.LOCAL
noPermissions@SERVER.LOCAL
rep_movsd@SERVER.LOCAL
kadmin:  q

rep ~/project * rep_krb_test $ ktutil
ktutil:  addent -password -p rep_movsd@SERVER.LOCAL -k 1 -f
Password for rep_movsd@SERVER.LOCAL:
ktutil:  wkt krb5.keytab
ktutil:  q

rep ~/project * rep_krb_test $ kinit -C -p rep_movsd@SERVER.LOCAL
Password for rep_movsd@SERVER.LOCAL:

rep ~/project * rep_krb_test $ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: rep_movsd@SERVER.LOCAL

Valid starting     Expires            Service principal
02/07/20 04:27:44  03/07/20 04:27:38  krbtgt/SERVER.LOCAL@SERVER.LOCAL

相关的nginx配置:

server {

  location / {
    uwsgi_pass  django;
    include     /usr/lib/proj/lib/wsgi/uwsgi_params;

    auth_gss on;
    auth_gss_realm SERVER.LOCAL;
    auth_gss_service_name HTTP;
  }
}

终于等/hosts有

# use alternate local IP address
127.0.0.2 server.local server

现在我尝试使用 curl 访问它:

*   Trying 127.0.0.2:80...
* Connected to server.local (127.0.0.2) port 80 (#0)
* gss_init_sec_context() failed: Server krbtgt/LOCAL@SERVER.LOCAL not found in Kerberos database.
* Server auth using Negotiate with user ''
> GET / HTTP/1.1
> Host: server.local
> User-Agent: curl/7.71.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
....

如您所见,它正在尝试使用 SPN“krbtgt/LOCAL@SERVER.LOCAL”,而 kinit 使用“krbtgt/SERVER.LOCAL@SERVER.LOCAL”作为 SPN

如何让它工作?

提前谢谢..

【问题讨论】:

  • Kerberos 默认将主机名解析为 IP 地址,然后再解析为主机名。可能是某些原因导致 IP 地址解析为 local 而不是 server.local。
  • 我应该在 hosts 文件中添加什么以避免这种情况?

标签: linux nginx kerberos spnego gssapi


【解决方案1】:

原来我需要

auth_gss_service_name HTTP/server.local;

遇到问题的一些其他提示:

  1. 确保使用 www-data 用户或任何用户的 Web 服务器进程可以读取 keytab 文件
  2. 确保 keytab 主体的顺序正确
  3. 使用export KRB5_TRACE=/dev/stderr 和 curl 进行测试 - kerberos 提供了非常详细的日志,记录了它正在做什么以及失败的原因

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-01-24
    • 1970-01-01
    相关资源
    最近更新 更多