我在一家小公司工作，没有专门的系统管理员。我的任务是将我们的文件和日历服务器升级到 10.8，我通过升级操作系统然后从应用商店安装服务器工具（按照 Apple 的建议）来完成此操作。
Kerberos 无法正常工作。服务器在 Open Directory 中存储了大量网络用户。当我尝试屏幕共享服务器时，服务器在后台使用 Kerberos 进行身份验证，我收到密码无效的提示。
最初它在 时失败Got a canonicalize request for a LKDC realm from local-ipc，并指出找不到 LKDC 领域。我按照以下说明在服务器上重新生成 LKDC：
- 重复 sudo rm -rf /var/db/krb5kdc
- sudo rm -rf /etc/krb5.keytab
- 打开钥匙串访问并搜索“kdc”，然后删除 3 个 com.apple.kerberos.kdc 项。
- 运行命令重新安装 LKDC sudo /usr/libexec/configureLocalKDC，这是非破坏性的，因此可以在不影响任何内容的情况下重新运行。
- 将客户端重新绑定到服务器。
此后，当我尝试从另一台 Mac 登录屏幕共享时，系统日志显示以下内容：
kdc[48]: AS-REQ amy@LKDC:SHA1.3489A33F133BAF273138432326E52616444378EA from fe80::cabc:c8ff:fec5:4b93%en0:53175 for krbtgt/LKDC:SHA1.3489A33F133BAF273138432326E52616444378EA@LKDC:SHA1.3489A33F133BAF273138432326E52616444378EA
kdc[48]: UNKNOWN -- amy@LKDC:SHA1.3489A33F133BAF273138432326E52616444378EA: no such entry found in hdb
screensharingd[582]: Authentication: FAILED :: User Name: amy :: Viewer Address: 192.168.1.44 :: Type: DH
opendirectoryd 日志中的内容看起来很可疑：
38.938 - Client: opendirectoryd, UID: 0, EUID: 0, GID: 0, EGID: 0
38.938, Module: AppleODClientLDAP - unable to create LDAP connection context - no server specified
38.938 - Client: opendirectoryd, UID: 0, EUID: 0, GID: 0, EGID: 0
38.938, Module: AppleODClientLDAP - unable to open connection to LDAP server - unable to create connection context
另外，在系统日志中启动时，我得到了
servermgrd[107]: servermgr_accounts: got error 5000 trying to auth to local LDAP node
如果我拨打kinit终端，它会要求我输入密码，然后验证密码（如果密码不正确，它会告诉我）。此时我会收到此日志（我已将我们公司的域名替换为 OURCOMPANY，但它是正确的）：
kdc[48]: AS-REQ [email protected] from 127.0.0.1:59175 for krbtgt/[email protected]
kernel[0]: Sandbox: kcm(690) deny mach-lookup com.apple.networkd
kdc[48]: UNKNOWN -- [email protected]: no such entry found in hdb
kinit[693]: krb5_sendto_context is called on main thread, its a blocking api
编辑：
如果我kinit现在尝试，我会得到：
kinit
[email protected]'s Password:
kinit: krb5_get_init_creds: Client ([email protected]) unknown
有人能建议我如何让 Kerberos、Open Directory 和 LDAP 再次协作吗？
答案1
从 Snow Leopard 升级到 Mountain Lion 既棘手又麻烦，最坏的情况下甚至会造成灾难性后果。考虑到您遇到的问题，我建议您从头开始构建新的 ML 并转移服务。
从服务器上的时间机器备份进行恢复通常效果很好。