无法在 Samba AD DC 服务器上进行身份验证

无法在 Samba AD DC 服务器上进行身份验证

我有一台 Raspberry Pi 3B+,用作家庭服务器。

我已经从 Raspbian 软件包(4.5.12+dfsg-2+deb9u4)安装并设置了 Samba AD DC。

我已经在 AD DC 服务器上配置了 SSSD 来验证本地用户。

我的设置以前运行良好,但是从 12 月初开始,我开始遇到各种身份验证问题。现在几乎所有问题都解决了,除了我无法使用 AD 帐户在本地服务器上进行身份验证。

我可以在我的网络上的另一个作为域成员加入并配置了 SSSD 的 Raspberry Pi 上进行身份验证。

我在网上搜索解决方案,但我无法找到答案。

以下是相关配置文件的内容:

/etc/主机名

pitaya

/etc/resolv.conf

search gggm.int
nameserver 192.168.2.26

/etc/krb5.conf

[libdefaults]
    default_realm = GGGM.INT
    dns_lookup_realm = false
    dns_lookup_kdc = true

[domain_realm]
    .gggm.int = GGGM.INT

/etc/samba/smb.conf

[global]
    netbios name = PITAYA
    realm = GGGM.INT
    workgroup = GGGM
    server role = active directory domain controller
    dns forwarder = 192.168.2.1
    idmap_ldb:use rfc2307 = yes
    log level = 2
    server string = Pitaya
    winbind enum users = yes
    winbind enum groups = yes
    template homedir = /home/%U
    template shell = /bin/bash
    username map = /etc/samba/user.map
    kerberos method = secrets and keytab

    tls enabled = yes
    tls keyfile = /var/lib/samba/private/tls/sambaKey.pem
    tls certfile = /var/lib/samba/private/tls/sambaCert.pem
    tls cafile = /var/lib/samba/private/tls/crt.ca-chain.pem

<Share configuration skipped...>

/etc/sssd/sssd.conf

[sssd]
services = nss, pam, sudo, ssh
config_file_version = 2
domains = GGGM.INT
full_name_format = %1$s

[domain/GGGM.INT]
ad_domain = gggm.int
id_provider = ad
auth_provider = ad
access_provider = ad
sudo_provider = ad
use_fully_qualified_names = false
ldap_id_mapping = false
ldap_referrals = false
override_homedir = /home/%u
enumerate = true
ldap_sudo_search_base = OU=sudoers,OU=gggm.int,DC=gggm,DC=int
ad_gpo_access_control = permissive
dyndns_update = false

uname -a 的输出

Linux pitaya 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

DNS 解析工作正常

root@pitaya ~ # host pitaya
pitaya.gggm.int has address 192.168.2.26
root@pitaya ~ # host 192.168.2.26
26.2.168.192.in-addr.arpa domain name pointer pitaya.gggm.int.
root@pitaya ~ # host -t SRV _ldap._tcp.gggm.int
_ldap._tcp.gggm.int has SRV record 0 100 389 pitaya.gggm.int.
root@pitaya ~ # host -t SRV _kerberos._tcp.gggm.int
_kerberos._tcp.gggm.int has SRV record 0 100 88 pitaya.gggm.int.
root@pitaya ~ #

我可以使用 Kerberos 以域用户身份进行身份验证:

root@pitaya ~ # kinit ghigad
Password for [email protected]:
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting     Expires            Service principal
03/01/19 12:38:35  03/01/19 22:38:35  krbtgt/[email protected]
        renew until 04/01/19 12:38:32
root@pitaya ~ #

我可以在本地服务器上列出共享:

root@pitaya ~ # smbclient -k -L pitaya
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]

        Sharename       Type      Comment
        ---------       ----      -------
        netlogon        Disk
        sysvol          Disk
        IPC$            IPC       IPC Service (Pitaya)
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
root@pitaya ~ #

我可以使用机器主体登录。

root@pitaya ~ # kdestroy
root@pitaya ~ # kinit -k PITAYA$
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting     Expires            Service principal
03/01/19 12:43:17  03/01/19 22:43:17  krbtgt/[email protected]
        renew until 04/01/19 12:43:17
root@pitaya ~ #

smbclient -k -L pitaya我还可以使用此票列出服务器的共享(与上面的输出相同)。

此外,wbinfo -ugetent passwd列出了域中的用户。同样,wbinfo -ggetent group列出了域中的组。

输出wbinfo -P

checking the NETLOGON for domain[GGGM] dc connection to "pitaya.gggm.int" succeeded

我尝试检查我的域名的数据库,并没有发现任何错误...

root@pitaya ~ # samba-tool dbcheck
Processing section "[netlogon]"
Processing section "[sysvol]"
pm_process() returned Yes
schema_fsmo_init: we are master[yes] updates allowed[no]
schema_fsmo_init: we are master[yes] updates allowed[no]
Checking 400 objects
Checked 400 objects (0 errors)

这是 krb5.keytab 的内容。

root@pitaya ~ # klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 31/12/18 12:16:18 host/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 host/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 host/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 host/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 host/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 host/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 host/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 host/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 host/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 host/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 gc/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 gc/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 gc/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 gc/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 gc/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 gc/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 gc/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 gc/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 gc/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 gc/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 ldap/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 ldap/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 ldap/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 ldap/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 ldap/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 ldap/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 ldap/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 ldap/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 ldap/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 ldap/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 restrictedkrbhost/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:18 krbtgt/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 krbtgt/[email protected] (des-cbc-crc)
   3 31/12/18 12:16:18 krbtgt/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 krbtgt/[email protected] (des-cbc-md5)
   3 31/12/18 12:16:18 krbtgt/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 krbtgt/[email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 krbtgt/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 krbtgt/[email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 krbtgt/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:19 krbtgt/[email protected] (arcfour-hmac)
   3 31/12/18 12:16:19 [email protected] (arcfour-hmac)
   3 31/12/18 12:16:19 [email protected] (aes256-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 [email protected] (aes128-cts-hmac-sha1-96)
   3 31/12/18 12:16:19 [email protected] (des-cbc-md5)
   3 31/12/18 12:16:19 [email protected] (des-cbc-crc)

但是,如果我尝试对域进行身份验证,则纯文本身份验证会成功,但质询/响应会失败。

root@pitaya ~ # wbinfo -a ghigad
Enter ghigad's password:
plaintext password authentication succeeded
Enter ghigad's password:
challenge/response password authentication failed
wbcAuthenticateUserEx(GGGM\ghigad): error code was NT_STATUS_WRONG_PASSWORD (0xc000006a)
error message was: Wrong Password
Could not authenticate user ghigad with challenge/response
root@pitaya ~ #

我尝试重置我的用户密码(samba-tool user setpassword ghigad),但没有任何改变。

我无法使用 SSH 和域帐户登录到我的服务器(在我的其他服务器上我可以......)。

另一个奇怪的行为,kinit -k失败了:

root@pitaya ~ # kinit -k
kinit: Preauthentication failed while getting initial credentials
root@pitaya ~ #

通过查阅日志文件,我发现了这个...

[2019/01/03 12:51:23.391820,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed to decrypt PA-DATA -- host/[email protected] (enctype aes256-cts-hmac-sha1-96) error Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96
[2019/01/03 12:51:23.392318,  5] ../source4/dsdb/common/util.c:5252(dsdb_update_bad_pwd_count)
  Not updating badPwdCount on CN=PITAYA,OU=Domain Controllers,DC=gggm,DC=int after wrong password
[2019/01/03 12:51:23.392435,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed to decrypt PA-DATA -- host/[email protected]

另外,请注意,我的 Windows 计算机都运行正常。用户可以登录并使用共享驱动器。我还可以使用 RSAT 工具(GPO、DNS、用户、打印机等)。

我觉得我的问题来自服务级别的 Kerberos 身份验证,但我陷入了困境……我不知道如何解决这个问题……

有人可以帮忙吗?

如果你们需要更多日志,我也可以添加摘录......

编辑

我一直在寻找解决方案并做了一个实验。

我将另一台 Linux 机器设置为 PDC ( samba-tool domain join gggm.int DC --dns-backend=SAMBA_INTERNAL --option='idmap_ldb:use rfc2307 = yes')。一切顺利,只是在我加入域后,这台机器的行为开始有点像第一台……

getent passwd返回用户列表,getent group返回组列表,但login ghigad总是失败。

我最终发现pac在 SSSD 中启用服务可以解决问题......

sssd.conf

[sssd]
services = nss, pam, sudo, ssh, pac, ifp

因此我登录另一台有问题的服务器并启用了pacSSSD 中的服务,祈祷问题能够得到解决。

不幸的是,这并不那么容易......我仍然遇到奇怪的身份验证问题......

我刷新了 SSSD 缓存 ( sssctl cache-remove),getent passwd不再能列出我的域用户,并且我的域在 SSSD 中处于离线状态。

root@pitaya /usr/sbin # sssctl domain-status gggm.int
Online status: Offline

Active servers:
AD Global Catalog: not connected
AD Domain Controller: pitaya.gggm.int

Discovered AD Global Catalog servers:
None so far.

Discovered AD Domain Controller servers:
- pitaya.gggm.int

我尝试重新生成我的机器的 Keytab,希望它有帮助。

root@pitaya ~ # rm /etc/krb5.keytab
root@pitaya ~ # net ads keytab create -P
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database
root@pitaya ~ # net ads keytab create -U ghigad
Enter ghigad's password:
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database
kerberos_kinit_password [email protected] failed: Client not found in Kerberos database

我重新创建 Keytab 的唯一方法是首先使用 Kerberos 进行身份验证。

root@pitaya ~ # kinit ghigad
Password for [email protected]:
root@pitaya ~ # net ads keytab create -k
root@pitaya ~ # klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 host/[email protected] (des-cbc-crc)
   3 host/[email protected] (des-cbc-crc)
   3 host/[email protected] (des-cbc-md5)
   3 host/[email protected] (des-cbc-md5)
   3 host/[email protected] (aes128-cts-hmac-sha1-96)
   3 host/[email protected] (aes128-cts-hmac-sha1-96)
   3 host/[email protected] (aes256-cts-hmac-sha1-96)
   3 host/[email protected] (aes256-cts-hmac-sha1-96)
   3 host/[email protected] (arcfour-hmac)
   3 host/[email protected] (arcfour-hmac)
   3 gc/[email protected] (des-cbc-crc)
   3 gc/[email protected] (des-cbc-crc)
   3 gc/[email protected] (des-cbc-md5)
   3 gc/[email protected] (des-cbc-md5)
   3 gc/[email protected] (aes128-cts-hmac-sha1-96)
   3 gc/[email protected] (aes128-cts-hmac-sha1-96)
   3 gc/[email protected] (aes256-cts-hmac-sha1-96)
   3 gc/[email protected] (aes256-cts-hmac-sha1-96)
   3 gc/[email protected] (arcfour-hmac)
   3 gc/[email protected] (arcfour-hmac)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-crc)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-crc)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-md5)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (des-cbc-md5)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes128-cts-hmac-sha1-96)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes128-cts-hmac-sha1-96)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes256-cts-hmac-sha1-96)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (aes256-cts-hmac-sha1-96)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (arcfour-hmac)
   3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/[email protected] (arcfour-hmac)
   3 ldap/[email protected] (des-cbc-crc)
   3 ldap/[email protected] (des-cbc-crc)
   3 ldap/[email protected] (des-cbc-md5)
   3 ldap/[email protected] (des-cbc-md5)
   3 ldap/[email protected] (aes128-cts-hmac-sha1-96)
   3 ldap/[email protected] (aes128-cts-hmac-sha1-96)
   3 ldap/[email protected] (aes256-cts-hmac-sha1-96)
   3 ldap/[email protected] (aes256-cts-hmac-sha1-96)
   3 ldap/[email protected] (arcfour-hmac)
   3 ldap/[email protected] (arcfour-hmac)
   3 restrictedkrbhost/[email protected] (des-cbc-crc)
   3 restrictedkrbhost/[email protected] (des-cbc-crc)
   3 restrictedkrbhost/[email protected] (des-cbc-md5)
   3 restrictedkrbhost/[email protected] (des-cbc-md5)
   3 restrictedkrbhost/[email protected] (aes128-cts-hmac-sha1-96)
   3 restrictedkrbhost/[email protected] (aes128-cts-hmac-sha1-96)
   3 restrictedkrbhost/[email protected] (aes256-cts-hmac-sha1-96)
   3 restrictedkrbhost/[email protected] (aes256-cts-hmac-sha1-96)
   3 restrictedkrbhost/[email protected] (arcfour-hmac)
   3 restrictedkrbhost/[email protected] (arcfour-hmac)
   3 krbtgt/[email protected] (des-cbc-crc)
   3 krbtgt/[email protected] (des-cbc-crc)
   3 krbtgt/[email protected] (des-cbc-md5)
   3 krbtgt/[email protected] (des-cbc-md5)
   3 krbtgt/[email protected] (aes128-cts-hmac-sha1-96)
   3 krbtgt/[email protected] (aes128-cts-hmac-sha1-96)
   3 krbtgt/[email protected] (aes256-cts-hmac-sha1-96)
   3 krbtgt/[email protected] (aes256-cts-hmac-sha1-96)
   3 krbtgt/[email protected] (arcfour-hmac)
   3 krbtgt/[email protected] (arcfour-hmac)
   3 [email protected] (des-cbc-crc)
   3 [email protected] (des-cbc-md5)
   3 [email protected] (aes128-cts-hmac-sha1-96)
   3 [email protected] (aes256-cts-hmac-sha1-96)
   3 [email protected] (arcfour-hmac)

然后我重启了 SSSD 并检查了状态。仍然处于离线状态。

我尝试使用 samba-tool 导出 Keytab。

root@pitaya ~ # rm /etc/krb5.keytab
root@pitaya ~ # samba-tool domain exportkeytab /etc/krb5.keytab --principal=PITAYA$
Export one principal to /etc/krb5.keytab
root@pitaya ~ # klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 [email protected] (arcfour-hmac)
   3 [email protected] (aes256-cts-hmac-sha1-96)
   3 [email protected] (aes128-cts-hmac-sha1-96)
   3 [email protected] (des-cbc-md5)
   3 [email protected] (des-cbc-crc)
root@pitaya ~ # service sssd restart
root@pitaya ~ # sssctl domain-status gggm.int
Online status: Online

Active servers:
AD Global Catalog: pitaya.gggm.int
AD Domain Controller: pitaya.gggm.int

Discovered AD Global Catalog servers:
- pitaya.gggm.int

Discovered AD Domain Controller servers:
- pitaya.gggm.int

之后,getent passwd列出了我的域用户,但我的 Keytab 的其余部分都搞砸了。

kinit -k仍然不起作用,因为不在 Keytab 中,但可以正常工作。host/[email protected]kinit -k PITAYA$

之后就smbclient -kL pitaya可以工作了。

我确实需要在我的 Keytab 中拥有所有 SPN,但却net ads keytab create无法生成有效的 SPN。

我如何生成有效的 Keytab?

我会继续努力让它发挥作用并在这里发布我的进展...任何帮助都将不胜感激。

答案1

我终于解决了我的问题......

在 SSSD 中启用 pac 服务肯定有帮助。

sssd.conf

[sssd]
services = nss, pam, sudo, ssh, pac, ifp

此外,重新生成机器的密钥解决了剩余的问题。这里的挑战是,有问题的机器是域的 AD DC。所以我不能直接重新加入域。

下面的命令重新生成了机器的密钥,并生成了新的Keytab。

adcli update --verbose  --computer-password-lifetime=0 --domain=gggm.int

然后,检查密钥表:

root@pitaya ~ # klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
4 [email protected]
4 [email protected]
4 [email protected]
4 [email protected]
4 [email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 host/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 ldap/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 gc/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 RestrictedKrbHost/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]
4 krbtgt/[email protected]

您可以看到我的 Keytab 现在包含我机器的所有 SPN 的 KVNO 4。因此,以下命令现在有效!

root@pitaya ~ # kinit -k
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_500_ChLPIV
Default principal: host/[email protected]
Valid starting     Expires            Service principal
24/01/19 21:18:54  25/01/19 07:18:54  krbtgt/[email protected]
renew until 25/01/19 21:18:54
root@pitaya ~ # kinit -k PITAYA$
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_500_ChLPIV
Default principal: [email protected]
Valid starting     Expires            Service principal
24/01/19 21:19:00  25/01/19 07:19:00  krbtgt/[email protected]
renew until 25/01/19 21:19:00
root@pitaya ~ # smbclient -kL pitaya
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]
Sharename       Type      Comment
---------       ----      -------
netlogon        Disk
sysvol          Disk
home            Disk
IPC$            IPC       IPC Service (Pitaya)
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]
Server               Comment
---------            -------
Workgroup            Master
---------            -------

现在,身份验证有效(login ghigad有效、dovecot 身份验证有效等),我可以使用 GSSAPI 登录到 SSH 服务。

相关内容