Kerberos认证

⑴ 如何取消 office kerberos认证

Kerberos一词源于希腊神话“三头狗——地狱之门守护者”，它是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。而此次Kerberos漏洞却为黑客打开了在企业网络域内自由穿梭的大门。
360企业安全负责人表示，Kerberos漏洞cve - 2014 – 6324主要影响企业级用户，建议网络管理员尽快部署安装微软补丁。针对隔离网的政企用户，360企业安全产品专门提供了隔离网安全更新解决方案，方便企业网管快速修复漏洞。

⑵ 下面描述了kerberos系统认证协议过程，哪一个是正确的

当然是B了。网络协议主要是OSI的TCP/IP协议。分为好几个层，比如说物理层吧，物理层要规定好传输信号的速度了，传输方式（调频条幅多路复用等）。也就是设计出来的一个电脑硬件或软件都遵守的规则。

⑶ 如何访问需要kerberos认证的web-cdh-about云开发

解决热点问题，方法很多，region分配的过多、region分配的过多不知道楼主是如何考虑的，如何去进行预分区，可以采用下面三步：1.取样，先随机生成一定数量的rowkey,将取样数据按升序排序放到一个集合里2.根据预分区的region个数，对整个集合平均分割，即是相关的splitKeys.3.HBaseAdmin.createTable(,byte[][]splitkeys)可以指定预分区的splitKey，即是指定region间的rowkey临界值.

⑷ ldap和kerberos的区别

使用 LDAP 和 Kerberos
在使用 Kerberos 时，在您的本地网络中分发用户信息（如用户 ID、组、主目录）的一种方法就是使用 LDAP。这需要一种强大的身份验证机制来防止包被窃取以及他攻击。一种解决方案是将 Kerberos 也用于 LDAP 通信。
OpenLDAP 通过 SASL（简单身份验证会话层）实现了大部分身份验证功能。SASL 基本上是一种用于身份验证的网络协议。SASL 实施是 cyrus-sasl，它支持许多不同的身份验证方法。Kerberos 身份验证是通过 GSSAPI（通用安全服务 API) 执行的。默认情况下，不安装用于 GSSAPI 的 SASL 插件。请使用 rpm -ivh cyrus-sasl-gssapi-*.rpm 来手动安装它。
为了使 Kerberos 能够绑定到 OpenLDAP 服务器，请创建一个主体 ldap/earth.example.com 并将其添加到 keytab：
默认情况下，LDAP 服务器 slapd 以用户和组 ldap 的身份运行，但只有 root 用户才能读取 keytab 文件。因此，要么更改 LDAP 配置以便使服务器以 root 用户身份运行，要么使组 ldap 可读取 keytab 文件。如果 /etc/sysconfig/openldap 中的 OPENLDAP_KRB5_KEYTAB 变量中指定了 keytab 文件并且 OPENLDAP_CHOWN_DIRS 变量设置成 yes（这是默认设置），则由 OpenLDAP 启动脚本 (/etc/init.d/ldap) 自动执行后一项操作。如果 OPENLDAP_KRB5_KEYTAB 保留为空，则使用 /etc/krb5.keytab 下的默认 keybab 文件，并且您必须如以下描述的那样自己调整优先级。
要以 root 用户身份运行 slapd，请编辑 /etc/sysconfig/openldap。通过在 OPENLDAP_USER 和 OPENLDAP_GROUP 变量前放置一个注释字符来禁用它们。
要使 keytab 对组 LDAP 可读，请执行
chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab

第三个方案（可能是最好的解决方案）是指示 OpenLDAP 使用特殊的 keytab 文件。要完成此操作，启动 kadmin 然后在添加主体 ldap/earth.example.com 后输入以下命令：
ktadd -k /etc/openldap/ldap.keytab ldap/[email protected]

然后，在 shell 上运行：
chown ldap.ldap /etc/openldap/ldap.keytab
chmod 600 /etc/openldap/ldap.keytab

要指示 OpenLDAP 使用不同的 keytab 文件，在 /etc/sysconfig/openldap 中更改以下变量：
OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"

最后，使用 rcldap restart 重启动 LDAP 服务器。
将 Kerberos 身份验证与 LDAP 一起使用
现在应该可以自动将 ldapsearch 等工具与 Kerberos 认证一起使用。
ldapsearch -b ou=people,dc=example,dc=com '(uid=newbie)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# newbie, people, example.com
dn: uid=newbie,ou=people,dc=example,dc=com
uid: newbie
cn: Olaf Kirch
[...]

正如您所看到的，ldapsearch 打印一条消息，表示它已经启动 GSSAPI 身份验证。下一条信息无疑颇具隐蔽性，它实际上表明了安全强度系数（缩写为 SSF）是 56（值 56 有些随意，之所以选择这个数字，很可能因为它是 DES 加密密钥中的位数）。这里要告诉您的是 GSSAPI 认证是成功的，并且该加密要用于为 LDAP 连接提供集成保护和机密性。
在 Kerberos 中，身份验证永远是相互的。这意味着不仅您向 LDAP 服务器身份验证自己，而且 LDAP 服务器本身也向您身份验证。这意味着您是与所需的 LDAP 服务器而不是攻击者设置的假冒服务进行通讯。
Kerberos 身份验证和 LDAP 访问控制
现在，允许每个用户修改他们的 LDAP 用户记录的登录壳层属性。假定在您的纲要中 joe 用户的 LDAP 项位于 uid=joe,ou=people,dc=example,dc=com，请在/etc/openldap/slapd.conf 中设置以下访问控制：

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
by self write
# Every user can read everything
access to *
by users read

第 2 个语句授予已通过身份验证的用户对他们自己的 LDAP 项的 loginShell 属性进行写访问的权限。第 3 个语句授予所有已通过身份验证的用户对整个 LDAP 目录进行读访问的权限。
这里还有个不太重要的方面未明确，即 LDAP 服务器如何能够得知 Kerberos 用户 [email protected] 与 LDAP 判别名 uid=joe,ou=people,dc=example,dc=com 相对应。这种映射必须使用 saslExpr 指令进行手动配置。在本例中，则是将以下语句添加到 slapd.conf：

authz-regexp
uid=(.*),cn=GSSAPI,cn=auth
uid=$1,ou=people,dc=example,dc=com

要了解它的工作原理，您需要知道，当 SASL 身份验证用户时，OpenLDAP 将使用 SASL 为它指派的名称（如 joe）和 SASL 功能的名称 (GSSAPI) 构成一个判别名。结果是uid=joe,cn=GSSAPI,cn=auth。
如果已经配置了 authz-regexp，它会将第一个参数用作常规表达式来检查从 SASL 信息构成的判别名。如果此常规表达式匹配，就用 authz-regexp 语句的第 2 个参数替换此名称。占位符 $1 被替换为 (.*) 表达式所匹配的子字符串。
可能有更复杂的匹配表达式。如果您的目录结构或纲要更加复杂（其中用户名不是判别名的一部分），则甚至可以使用搜索表达式来将 SASL 判别名映射为用户判别名。

⑸ 什么叫kerberos

Kerberos是由美国麻省理工学院提出的基于可信赖的第三方的认证系统。Kerberos提供了一种在开版放式网权络环境下进行身份认证的方法,它使网络上的用户可以相互证明自己的身份。

Kerberos采用对称密钥体制对信息进行加密。其基本思想是：能正确对信息进行解密的用户就是合法用户。用户在对应用服务器进行访问之前，必须先从第三方（Kerberos服务器）获取该应用服务器的访问许可证（ticket）。

⑹ Kerberos模型认证原理是什么

Kerberos的认证原理：

Kerberos采用可信赖第三方服务器进行密钥分发和身份确认，包括：

① 对用户认证
② 对应用服务的提供者进行认证。

此外，还可根据用户要求提供客户/服务器间的数据加密与完整性服务。

RFC1510协议文件对V5作了如下说明：

Kerberos提供了在开放型网络中进行身份认证的方法，认证实体可以是用户或用户服务。这种认证不依赖宿主机的操作系统或主机的IP地址，不需要保证网络上所有主机的物理安全性，并且假定数据包在传输中可被随机窃取篡改。

2

⑺ kerberos认证和ssl的区别

Keberos是为TCP/IP网络系统设计的可信的第三方认证协议，属于票据授权服务。
SSL是HTTPS加密专协议，是为网络通信提供属安全及数据完整性的一种安全协议，比如网络搜索就是HTTPS传输。
总结：两者完全不同的产品，SSL是目前最权威最广泛使用的。

⑻ Windows安全认证是如何进行的[Kerberos篇]

如果时间允许，我很乐意写一系列的文章与广大网友分享、交流。对于很多读者来说，今天讨论的可能是一个既熟悉、又陌生的话题——Windows认证。目录
一、Kerberos认证简介
四、凭票入场一、Kerberos认证简介Windows认证协议有两种NTLM（NT LAN Manager）和Kerberos，前者主要应用于用于Windows NT 和 Windows 2000 Server（or Later） 工作组环境，而后者则主要应用于Windows 2000 Server（or Later） 域（Domain）环境。Kerberos较之NTLM更高效、更安全，同时认证过程也相对复杂。Kerberos这个名字来源于希腊神话，是冥界守护神兽的名字。Kerberos是一个三头怪兽，之所以用它来命名一种完全认证协议，是因为整个认证过程涉及到三方：客户端、服务端和KDC（Key Distribution Center）。在Windows域环境中，KDC的角色由DC（Domain Controller）来担当。某个用户采用某个域帐号登录到某台主机，并远程访问处于相同域中另一台主机时，如何对访问者和被访问者进行身份验证（这是一种双向的验证）？这就是Kerberos需要解决的场景。接下来我尽量以比较直白的语言来介绍我所知道的Kerberos认证的整个流程。Kerberos实际上是一种基于票据（Ticket）的认证方式。客户端要访问服务器的资源，需要首先购买服务端认可的票据。也就是说，客户端在访问服务器之前需要预先买好票，等待服务验票之后才能入场。在这之前，客户端需要先买票，但是这张票不能直接购买，需要一张认购权证。客户端在买票之前需要预先获得一张认购权证。这张认购权证和进入服务器的入场券均有KDC发售。右图（点击看大图）一张图基本揭示了Kerberos整个认证的过程。二、如何获得“认购权证”？首先，我们来看看客户端如何获得“认购权证”。这里的认购权证有个专有的名称——TGT（Ticket Granting Ticket），而TGT的是KDC一个重要的服务——认证服务（KAS：Kerberos Authentication Service）。当某个用户通过输入域帐号和密码试图登录某台主机的时候，本机的Kerberos服务会向KDC的认证服务发送一个认证请求。该请求主要包括两部分内容，明文形式的用户名和经过加密的用于证明访问者身份的Authenticator（我实在找不到一个比较贴切的中文翻译没，Authenticator在这里可以理解为仅限于验证双反预先知晓的内容，相当于联络暗号）。当KDC接收到请求之后，通过AD获取该用户的信息。通过获取的密码信息生成一个秘钥对Authenticator进行解密。如果解密后的内容和已知的内容一致，则证明请求着提供的密码正确，即确定了登录者的真实身份。KAS成功认证对方的身份之后，会先生成一个用于确保该用户和KDC之间通信安全的会话秘钥——Logon Session Key，并采用该用户密码派生的秘钥进行加密。KAS接着为该用户创建“认购权证”——TGT。TGT主要包含两方面的内容：用户相关信息和Logon Session Key，而整个TGT则通过KDC自己的密钥进行加密。最终，被不同密钥加密的Logon Session Key和TGT返回给客户端。（以上的内容对应流程图中的步骤1、2）三、如何通过“认购权证”购买“入场券”？经过上面的步骤，客户端获取了购买进入同域中其他主机入场券的“认购凭证”——TGT，以及Logon Session Key，它会在本地缓存此TGT和Logon Session Key。如果现在它需要访问某台服务器的资源，它就需要凭借这张TGT向KDC购买相应的入场券。这里的入场券也有一个专有的名称——服务票据（ST：Service Ticket）。具体来说，ST是通过KDC的另一个服务TGS（Ticket Granting Service）出售的。客户端先向TGS发送一个ST购买请求，该请求主要包含如下的内容：客户端用户名；通过Logon Session Key加密的Authenticator；TGT和访问的服务器（其实是服务）名。TGS接收到请求之后，现通过自己的密钥解密TGT并获取Logon Session Key，然后通过Logon Session Key解密Authenticator，进而验证了对方的真实身份。TGS存在的一个根本的目有两点：其一是避免让用户的密码客户端和KDC之间频繁传输而被窃取。其二是因为密码属于Long Term Key（我们一般不会频繁的更新自己的密码），让它作为加密密钥的安全系数肯定小于一个频繁变换得密钥（Short Term Key）。而这个Short Term Key就是Logon Session Key，它确保了客户端和KDC之间的通信安全。TGS完成对客户端的认证之后，会生成一个用于确保客户端-服务器之间通信安全的会话秘钥——Service Session Key，该会话秘钥通过Logon Session Key进行加密。然后出售给客户端需要的入场券——ST。ST主要包含两方面的内容：客户端用户信息和Service Session Key，整个ST通过服务器密码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST回复给客户端。（以上的内容对应流程图中的步骤3、4）四、凭票入场客户端接收到TGS回复后，通过缓存的Logon Session Key解密获取Service Session Key。同时它也得到了进入服务器的入场券——ST。那么它在进行服务访问的时候就可以借助这张ST凭票入场了。该Serivce Session Key和ST会被客户端缓存。但是，服务端在接收到ST之后，如何确保它是通过TGS购买，而不是自己伪造的呢？这很好办，不要忘了ST是通过自己密码派生的秘钥进行加密的。具体的操作过程是这样的，除了ST之外，服务请求还附加一份通过Service Session Key加密的Authenticator。服务器在接收到请求之后，先通过自己密码派生的秘钥解密ST，并从中提取Service Session Key。然后通过提取出来的Service Session Key解密Authenticator，进而验证了客户端的真实身份。实际上，到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。谈到认证，很多人都认为只是服务器对客户端的认证，实际上在大部分场合，我们需要的是双向验证（Mutual Authentication）——访问者和被访问者互相验证对方的身份。现在服务器已经可以确保客户端是它所声称的那么用户，客户端还没有确认它所访问的不是一个钓鱼服务呢。为了解决客户端对服务器的验证，服务要需要将解密后的Authenticator再次用Service Session Key进行加密，并发挥给客户端。客户端再用缓存的Service Session Key进行解密，如果和之前的内容完全一样，则可以证明自己正在访问的服务器和自己拥有相同的Service Session Key，而这个会话秘钥不为外人知晓（以上的内容对应流程图中的步骤5、6）以上的内容仅仅讲述的是基于Kerberos的Windows认证的大体流程，并不涉及到一些细节的东西，比如如何确保时间的同步，如何抵御Replay Attack等。此外，由于本文对Windows底层的知识有限，不能确保所有的内容都是完全正确，如有错误，还往不吝指正。Windows安全认证是如何进行的？[NTLM篇]

⑼ hive怎么配置kerberos客户端认证

<property>
<name>hive.hwi.war.file</name>
<value>lib/hive-hwi-0.10.0-cdh4.3.0.war</value>
<description>,relativeto${HIVE_HOME}.
</description>
</property>
<property>
<name>hive.hwi.listen.host</name>
<value>0.0.0.0</value>
<description>
on</description>
</property>
<property>
<name>hive.hwi.listen.port</name>
<value>9999</value>
<description></description>
</property>

⑽ Kerberos认证的介绍

Keberos是为TCP/IP网络系统设计的可信的第三方认证协议。网络上的Keberos服务基于DES对称加密算法，但也可以用其他算法替代。因此，Keberos是一个在许多系统中获得广泛应用的认证协议，Windows2000就支持该协议。