我有一台 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 -u
和getent passwd
列出了域中的用户。同样,wbinfo -g
和getent 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
因此我登录另一台有问题的服务器并启用了pac
SSSD 中的服务,祈祷问题能够得到解决。
不幸的是,这并不那么容易......我仍然遇到奇怪的身份验证问题......
我刷新了 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 服务。