kerberos

最新推荐文章于 2025-06-27 18:47:07 发布
最新推荐文章于 2025-06-27 18:47:07 发布
阅读量3.7k 收藏 6
点赞数 1
CC 4.0 BY-SA版权
分类专栏： 大数据 文章标签： kerberos
原文链接：https://www.cnblogs.com/artech/archive/2007/07/05/807492.html
Kerberos是一种单点登录(SSO)解决方案，通过中心认证服务器(AS)实现客户端和服务器间的互信认证。本文深入解析Kerberos的工作原理，包括TGT、ST、KDC、AS和TGS的角色与交互流程，以及票证生命周期管理和Kerberos在Hadoop环境中的应用。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

https://blog.youkuaiyun.com/co_zjw/article/details/81974845

https://www.cnblogs.com/artech/archive/2007/07/05/807492.html

https://www.cnblogs.com/-qing-/p/11349134.html

https://ieevee.com/tech/2016/06/07/kerberos-1.html

https://blog.youkuaiyun.com/czz1141979570/article/details/89486864

https://blog.youkuaiyun.com/jewes/article/details/20792021

Kerberos解决什么问题？

简单地说，Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication
Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。

因此，在Kerberos系统中至少有三个角色：认证服务器（AS），客户端（Client）和普通服务器（Server）。客户端和服务器将在AS的帮助下完成相互认证。

在Kerberos系统中，客户端和服务器都有一个唯一的名字，叫做Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器AS知道。

Kerberos的三大要素

KDC

Client

Server

Kerberos 基础概念

Ticket ： 网络对象互相访问的凭证，一个票证仅对一台客户机以及某台特定服务器上的一项特殊服务有效。

票证包含以下内容：

  • 服务的主体名称
  • 用户的主体名称
  • 用户主机的 IP 地址
  • 时间标记
  • 定义票证生命周期的值
  • 会话密钥的副本

KDC：可信任的认证来源，密钥分发中心， KDC负责管理票据、认证票据、分发票据，但是KDC不是一个独立的服务，KDC可以分为Authentication Server （身份验证服务）和Ticket Granting Server （票据授权服务）

Authentication Service (AS）：身份验证服务， 存储着该Domain中所有帐户信息，一般由 Account Database来维护

Ticket Granting Service： 票据授予服务，为client生成某个服务的ticket(简称TGS)

Ticket-Granting Ticket：票据授权票据，由KDC的AS发放；获得这样一张票据后，以后申请其他应用的服务票据（ST）时，就不需要向KDC提交身份认证信息（credential），TGT具有一定的有效期，就像是kerberos进行kinit以后只是具有固定时间的有效期，需要不断的去renew来续约。

ST(service ticket): 服务票据，由KDC的TGS发放，任何一个应用（application）都需要一张有效的服务票据才能访问；如果能正确接受ST，说明client和server之间的信任关系已经被建立，通常为一张数字加密的证书。

Principal： 一个具有唯一标识的实体，可以是一台计算机或一项服务，通过使用KDC颁发的票据来进行通信。Principal可以分为两类: 用户和服务，对于用户主体，实例是可选的 ，但对于服务主体，实例则是必需的。

共由三部分组成 。username(or servicename)/instance@realm

例如：nn/zelda1@ZELDA.COM，zelda1为集群中的一台机器；或admin/admin@ZELDA.COM，管理员账户。

  • username or servicename：在本文里为服务，HDFS的2个服务分别取名为nn和dn，即namenode和datanode
  • instance：在本文里为具体的FQDN机器名，用来保证全局唯一（比如多个datanode节点，各节点需要各自独立认证）
  • realm：域，这里为ZELDA.COM（全大写），Kerberos网络

Hadoop中的每个服务和子服务都必须有自己的主体。在这种情况下，实例名称是运行该服务的主机的FQDN。 由于服务未使用密码登录以获取其票证，因此其主体的身份验证凭据存储在keytab密钥表文件中，该文件从Kerberos数据库中提取并本地存储在服务组件主机上具有服务主体的安全目录中。比如NameNode组件。

在node1.example.com主机上，启用kerberos之后，会自动生成nn.service.keytab文件，并存储在/etc/security/keytabs目录下，用户所有者是hdfs:hadoop，权限为400

Principal和Keytab命名约定

nn/node1.example.com@EXAMPLE.COM 为 /etc/security/keytabs/nn.service.keytab

请注意前面的示例中每个服务主体的主名称。这些主要名称（例如nn或hive）分别代表NameNode或Hive服务。 每个主要名称都附加了实例名称，即运行它的主机的FQDN。此约定为在多个主机（如DataNodes和NodeManager）上运行的服务提供唯一的主体名称。 添加主机名用于区分，例如，来自DataNode A的请求与来自DataNode B的请求。

Keytab：密匙文件， keytab文件对于每个host是唯一的，因为key中包含hostname

krbtgt：每个域控制器DC都有一个”krbtgt”的用户账户,是KDC的服务账户,用来创建票据授予服务(TGS)加密的密钥

Realm：域， 包含KDC和许多客户端的Kerberos网络

Authenticator ：client info加上当前时间的一个Timestamp

Master Key ：在Security的领域中，有的Key可能长期内保持不变，比如你在密码，可能几年都不曾改变，这样的Key、以及由此派生的Key被称为Long-term Key。对于Long-term Key的使用有这样的原则：被Long-term Key加密的数据不应该在网络上传输。原因很简单，一旦这些被Long-term Key加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是可以通过计算获得你用于加密的Long-term Key的——任何加密算法都不可能做到绝对保密。

Session Key：由于被Long-term Key加密的数据包不能用于网络传送，所以我们使用另一种Short-term Key来加密需要进行网络传输的数据。由于这种Key只在一段时间内有效，即使被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已经过期了。

上面几个术语简单说下它们的关系：KDC由AS和TGS组成，AS进行身份认证发放TGT，TGT是用来避免多次请求而需要重复认证的凭证；TGS发放ST，ST用来访问某个service时的凭证，ST相当于告诉service你的身份被KDC认证为合法的一个凭证。

一、 基本原理

Authentication解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。

对于如何进行Authentication，我们采用这样的方法：如果一个密码（secret）仅仅存在于A和B，那么有个人对B声称自己就是A，B通过让A提供这个秘密来证明这个人就是他或她所声称的A。这个过程实际上涉及到3个重要的关于Authentication的方面：

  • Secret如何表示。
  • A如何向B提供Secret。
  • B如何识别Secret。

基于这3个方面，我们把Kerberos Authentication进行最大限度的简化：整个过程涉及到Client和Server，他们之间的这个Secret我们用一个Key（KServer-Client）来表示。Client为了让Server对自己进行有效的认证，向对方提供如下两组信息：

  • 代表Client自身Identity的信息，为了简便，它以明文的形式传递。
  • 将Client的Identity使用KServer-Client作为Public Key、并采用对称加密算法进行加密。

由于KServer-Client仅仅被Client和Server知晓，所以被Client使用KServer-Client加密过的Client Identity只能被Client和Server解密。同理，Server接收到Client传送的这两组信息，先通过KServer-Client对后者进行解密，随后将机密的数据同前者进行比较，如果完全一样，则可以证明Client能过提供正确的KServer-Client，而这个世界上，仅仅只有真正的Client和自己知道KServer-Client，所以可以对方就是他所声称的那个人。

二、认证过程

请求TGT

1. Client—> KDC-AS

KRB_AS_REQ (Kerberos Authentication Service Request) 
KRB_AS_REQ的大体包含以下的内容
1.Pre-authentication data：一般地，它的内容是一个被Client的Master key加密过的Timestamp
2.Client name & realm：简单地说就是Domain name\Client
3.server Name：KDC的Ticket Granting Service（票据授权服务）的server Name

2. KDC-AS—>Client

KDC-AS 通过KRB_AS_REQ中的Client name & realm 从 Account Database中提取Client对应的Master Key，对Pre-authentication data进行解密，如果是一个合法的Timestamp，发放TGT

KRB_AS_REP (Kerberos Authentication Service Response) 
身份验证服务(KDC-AS)会解密时间戳,若解密成功创建票据授予票据(Ticket-Granting Ticket,TGT)
包含2部分数据
kdc随机生成Session Key(kdc与client)，又称为Logon Session Key
1.使用Client的Master Key加密Logon Session Key
2.使用自己的master key（krbtgt）加密 TGT
	TGT又包含以下几部分
	1.Session Key:SKDC-Client
	2.Client name & realm
	3.End time：TGT到期的时间，一般为5分钟

请求 ST

3. Client-A —> KDC-TGS

Client通过自己的Master Key对第一部分解密获得session Key之后，携带着TGT便可以进入下一步：TGS（Ticket Granting Service）

KRB_TGS_REQ (Kerberos Ticket Granting Service Request) 
Client使用AS返回的Session Key构建访问特定服务的请求,再把AS返回的”票据授予票据(TGT)”连同请求一起发送到票据授予服务TGS) 
1.TGT：直接原封不动返回, TGT被KDC的Master Key进行加密，client无法解密TGT
2.Authenticator：client + timestamp，用client的master key加密
3.Client name & realm
4.Server name & realm：client 要 访问的服务名

4. KDC-TGS —>Client

TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个session key(Logon Session Key) ，

再通过这个session key解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response

KRB_TGS_REP (Kerberos Ticket Granting Service Response)
KRB_TGS_REP有两部分组成
kdc随机生成Session Key(Client和Server的Session Key,非Logon Session Key)
1.使用Logon Session Key(SKDC-Client) 加密过 Client和Server的Session Key(SServer-Client)
2.使用Server的Master Key进行加密的Ticket，改Ticket大体包含以下一些内容：
	1.Session Key：SServer-Client
	2.Client name & realm
	3.End time：Ticket的到期时间，一般为8小时

访问

5. Client—>Server

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client），最后连同从KDC获得的被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。

KRB_AP_REQ (Kerberos Application Request) 
1.通过Logon Session Key 解密获取 SServer-Client的 Session Key
2.创建 Authenticator（Client Info + Timestamp）并用Session Key(SServer-Client)对其加密

6.Server—>Client

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。

通过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

票证生命周期

每当主体获取包括票证授予票证 (Ticket–Granting Ticket, TGT) 在内的票证时，可以通过 kinit 的 -l 选项指定的生命周期值。缺省情况下，kinit 使用最长生命周期值。kdc.conf文件中指定的最长生命周期值 (max_life)

可通过 kinit 的 -r 选项指定的可更新生命周期值。kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life)。

Kerberos主体名称

每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称的示例：

主体名称说明
username@EXAMPLE.COM用户的主体
username/admin@EXAMPLE.COMadmin 主体，可用于管理 KDC 数据库。
K/M@EXAMPLE.COM主密钥名称主体,一个主密钥名称主体可与每个主 KDC 关联
krbtgt/EXAMPLE.COM@EXAMPLE.COM生成票证授予票证时使用的主体。
kadmin/host1.example.com@EXAMPLE.COM允许使用 kadmind 访问 KDC 的主 KDC 服务器的主体。
ambari-qa-xxx@EXAMPLE.COMAmbari用于执行服务“冒烟”检查并运行警报健康检查。
HTTP/host1.example.com@EXAMPLE.COM用于访问Hadoop Web UI时用到的principal
安装KDC server
yum install krb5-server krb5-libs krb5-workstation

KDC (Key Distribution Center）密匙分配中心, 其在kerberos中通常提供两种服务：

Authentication Service (AS)：认证服务

Ticket-Granting Service (TGS)：授予票据服务

/etc/krb5.conf
includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
# default_realm = EXAMPLE.COM
 default_realm = EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
# EXAMPLE.COM = {
#  kdc = kerberos.example.com
#  admin_server = kerberos.example.com
# }

EXAMPLE.COM = {
  kdc = ljh1
  admin_server = ljh1
}

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

[logging]：表示server端的日志的打印位置

[libdefaults]：每种连接的默认配置，需要注意以下几个关键的小配置

​ default_realm = EXAMPLE.COM 默认的realm，必须跟要配置的realm的名称一致

​ ticket_lifetime：表明凭证生效的时限，一般为24小时

​ renew_lifetime：表明凭证最长可以被延期的时限，一般为一个礼拜。当凭证过期之后，对安全认证的服务的 后续访问则会失败

[realms]：列举使用的realm

​ kdc：代表要kdc的位置。格式是 机器:端口

​ admin_server：代表admin的位置。格式是机器:端口

[domain_realm]：代表默认的域名

/var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 EXAMPLE.COM = {
  #master_key_type = aes256-cts
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal 
  arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal 
  des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }
创建/初始化Kerberos database

初始化并启动：完成上面两个配置文件后，就可以进行初始化并启动了

/usr/sbin/kdb5_util create -s -r EXAMPLE.COM

[-s]表示生成stash file，并在其中存储master server key（krb5kdc）

[-r]来指定一个realm name —— 当krb5.conf中定义了多个realm时才是必要的

保存路径为/var/kerberos/krb5kdc 如果需要重建数据库，将该目录下的principal相关的文件删除即可

在此过程中，我们会输入database的管理密码。这里设置的密码一定要记住，如果忘记了，就无法管理Kerberos server。

当Kerberos database创建好后，可以看到目录 /var/kerberos/krb5kdc 下生成了几个文件

kadm5.acl kdc.conf principal principal.kadm5 principal.kadm5.lock principal.ok

创建Kerberos管理员（根据提示输入密码）

我们需要为Kerberos database添加administrative principals
(即能够管理database的principals) ——
至少要添加1个principal来使得Kerberos的管理进程kadmind能够在网络上与程序kadmin进行通讯

在maste KDC上执行：

/usr/sbin/kadmin.local -q "addprinc admin/admin"
为database administrator设置ACL权限

在KDC上我们需要编辑acl文件来设置权限，该acl文件的默认路径是 /var/kerberos/krb5kdc/kadm5.acl（也可以在文件kdc.conf中修改）。

Kerberos的kadmind daemon会使用该文件来管理对Kerberos database的访问权限。对于那些可能会对pincipal产生影响的操作，acl文件也能控制哪些principal能操作哪些其他pricipals。

我们现在为administrator设置权限：将文件/var/kerberos/krb5kdc/kadm5.acl的内容编辑为

*/admin@EXAMPLE.COM *

代表名称匹配*/admin@EXAMPLE.COM都认为是admin，权限是 *。代表全部权限

在master KDC启动Kerberos daemons

手动启动

service krb5kdc start
service kadmin start

设置开机自动启动

chkconfig krb5kdc on
chkconfig kadmin on

Kerberos的票据管理

1、登录 kerberos

录到管理员账户: 如果在本机上，可以通过kadmin.local直接登录。其它机器的，先使用kinit进行验证

kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local:

2、查看用户

kadmin.local ： listprincs

3、添加用户

kadmin.local ： addprinc test@EXAMPLE.COM

4、删除用户

kadmin.local ： delprinc test@EXAMPLE.COM

5、创建keytable文件 生成test用户的 keytab 文件到 /root/kerberos 目录(目录由自己随意指定)

ktadd -k /root/kerberos/test.keytab test

6、只导出用户keytab文件(并且不要修改密码) -norandkey

ktadd -k /root/kerberos/test.keytab -norandkey test

7、登录

kinit -kt /root/kerberos/test.keytab test

8、查看登录用户

klist

9、查看keytab文件

klist -ket /root/kerberos/test.keytab

10、注销

kdestroy
kerberos安装配置、配置kerberos server、client、日常操作与常见问题、卸载kerberos、hive整合kerberos
涂作权的博客
10-01 1560
3.3.安装配置 安装kerberos前，要确保主机名可以被解析。 主机名 内网IP 角色 bigdata1 192.168.106.134 master KDC ,kerberos client bigdata2 192.168.106.135 kerberos client 3.4.配置Kerberos Server 3.4.1.确保环境可用 确保所有的clients与servers之间的时间同步以及DNS正确解析。 3.4.2.在bigdata1上安装KDC 在hadoop1主
kerberos：介绍
玉汝于成
04-19 3560
Kerberos是一种计算机网络授权协议，主要用于在非安全网络环境中对个人通信进行安全的身份认证。这个协议由麻省理工学院（MIT）开发，作为Athena项目的一部分，首次发布于1988年。Kerberos协议目前已经从v1发展到v5，其中v5在1993年被确定为标准的Kerberos协议（RFC1510）。Kerberos协议设计思想的核心是引入一个可信任的第三方来实现客户端和服务端的认证。在Kerberos中，这个可信任的第三方被称为密钥分发中心（KDC）。
Kerberos
路雪军 Carl
04-15 2190
Kerberos是由美国麻省理工学院提出的基于可信赖的第三方的认证系统。Kerberos提供了一种在开放式网络环境下进行身份认证的方法,它使网络上的用户可以相互证明自己的身份。　　Kerberos采用对称密钥体制对信息进行加密。其基本思想是：能正确对信息进行解密的用户就是合法用户。用户在对应用服务器进行访问之前，必须先从第三方（Kerberos服务器）获取该应用服务器的访问许可证（ticket
Kerberos 深入详解：原理、认证流程与应用场景
最新发布
PwnGuo的博客
06-27 1204
Kerberos认证协议在企业大数据平台中的应用 Kerberos是一种基于对称密钥加密的网络身份认证协议，通过可信第三方KDC实现安全认证而不传输明文密码。其核心流程包含三个阶段：用户认证获取TGT票据、获取服务票据以及服务端验证。在企业Hadoop集群中，Kerberos被用于实现统一认证，所有客户端访问HDFS前必须经过完整认证流程，包括NameNode和DataNode在内的服务节点都需要配置专属服务主体和keytab文件。该机制通过KDC作为根信任中心，构建了完整的认证信任链，确保只有获得有效票据
单点登录(SSO)的核心－－kerberos身份认证协议技术参考
tanken welcome
12-03 2976
微软Windows Server 2003操作系统实现Kerberos 版本5的身份认证协议。Windows Server 2003同时也实现了公钥身份认证的扩展。Kerberos身份验证的客户端实现为一个SSP（security support provider），能够通过SSPI（Security Support Provider Interface）进行访问。最初的用户身份验证是跟Winlo
kerberos简介
HHFQ的博客
05-04 4189
维护网络内的系统安全性和完整性至关重要，它涵盖了网络基础架构中的每个用户，应用程序，服务和服务器。 它需要了解网络上正在运行的所有内容以及这些服务的使用方式。 维护此安全性的核心是维护对这些应用程序和服务的访问并强制执行该访问。 Kerberos是一种比普通的基于密码的认证更加安全的认证协议。使用Kerberos，即使在其他计算机上访问服务时也永远不会通过网络发送密码。 Kerberos提供了一种机制，允许用户和机器向网络标识自己，并接收对管理员配置的区域和服务的定义的、受限的访问权限。Kerberos通过
Kerberos权威指南 Kerberos The Definitive Guide
05-23
Kerberos权威指南 ，Kerberos The Definitive Guide。Single sign-on is the holy grail of network administration, and Kerberos is the only game in town. Microsoft, by integrating Kerberos into Active ...
三步轻松理解Kerberos协议
06-19
Kerberos协议是一种广泛应用于企业环境的身份验证协议，特别是在Active Directory (AD)域环境中，它为客户端和服务器应用提供了安全的认证服务。该协议的核心在于使用对称加密技术，确保了用户身份的安全验证，防止...
flink写入带kerberos认证的kudu connector
03-24
当Flink需要与Kudu交互时，Kerberos认证机制的引入是为了增强系统的安全性，防止未授权的访问。本文将详细介绍如何在Flink中配置和使用带Kerberos认证的Kudu Connector。 ### 1. Kerberos认证简介 Kerberos 是一种...
kerberos-docker:用于kerberos服务器的轻量级docker映像
05-09
kerberos-docker 基于Alpine Linux的轻量级Kerberos Server docker映像。 用法 Docker映像根据以下环境变量配置kadmind和krb5kdc服务器并启动服务器。 环境变量 默认值 描述 REALM_NAME Example.COM 领域名称 ...
Kerberos从入门到精通以及案例实操系列（一）
prefect_start的博客
06-05 6809
整个kerberos认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的Session Key，即他们只在一次Session会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束，这为整个kerberos认证过程保证了较高的安全性。kerberos认证的整体流图kerberos认证的时序图本地登录（无需认证）远程登录（需进行主体认证，认证操作见下文）退出输入：exit2. 创建Kerberos主体。
Kerberos 服务部署
走向程序的康庄大道
07-06 2710
Kerberos服务部署系统版本：CentOS Linux release 7.2.1511Kerberos简介首先，我们了解下kerberos是个什么东西？Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO(Single Sign ...
Kerberos安装及使用2（Kerberos服务器KDC安装及配置）
u011250186的博客
11-25 4032
Kerberos安装及使用2（Kerberos服务器KDC安装及配置）
Kerberos-密码管理
weixin_33939380的博客
03-12 997
2019独角兽企业重金招聘Python工程师标准>>> ...
一文搞懂Kerberos
聚集机器学习、信息安全
03-13 4345
Kerberos一词来源于古希腊神话中的Cerberus——守护地狱之门的三头犬，Kerberos是为TCP/IP 网络设计的可信第三方鉴别协议，最初是在麻省理工学院(MIT)为Athena 项目而开发的。Kerberos服务起着可信仲裁者的作用，可提供安全的网络鉴别，允许个人访问网络中不同的机器。
kerberos server 安装配置
玩物
04-10 2136
kerberos安装联网安装 kerberossudo apt-get install krb5-kdc krb5-admin-server 安装which kinit 查看是否安装成功一、kerberos配置   默认安装路径为 /etc/ker5kdc1、/etc/krb5.conf 若没有此文件则自己创建[kdc] profile = /etc/krb5kdc/kdc.conf [...
hadoop 3.X 分布式HA集成Kerbos(保姆级教程）
guofei_ok的博客
06-30 1553
前提：先安装Kerbos。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值