目录
下面的所有配置,都以centos为基础操作系统进行
yum install krb5-libs krb5-server krb5-workstation
默认路径为/etc/krb5.conf
该配置的主要配置了realm 对应的kdc的host,kadmin所在服务器,以及一些domain到realm的映射关系,以及日志存储文件等信息,一般分为如下四块:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
```
libdefaults 整个kerberos组件相关的默认配置,如果不显示执行相关配置项,则默认这些值
[libdefaults]
default_realm = TEST.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
realms 。其中配置了该realm中kdc、kadmin server对应的host地址
[realms]
TEST.COM = {
kdc = host1.mydomain.nl
admin_server = host1.mydomain.nl
}
domain_realm 配置域名或host映射的realm 。 由于kerberos本身是支持多realm的,这个配置可以用来将不同的host或domain映射到不同的realm
[domain_realm]
.example.com = TEST.COM
example.com = TEST.COM
上述几块组合起来就是完整的配置,总体demo如下
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = TEST.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
TEST.COM = {
kdc = host1.mydomain.nl
admin_server = host1.mydomain.nl
}
[domain_realm]
.example.com = TEST.COM
example.com = TEST.COM
其中realm一般按惯例是所属公司的域名大写,这里做demo写的是TEST.COM ,实际配置需要替换成具体的公司域名
默认路径为/var/kerberos/krb5kdc/kdc.conf
。kdc是整个Kerberos网络的核心,它存储了所有principal的账号数据,并对principal的请求,进行认证,与Principal之间的访问票据分发。
一个典型的kdc.conf配置如下
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[realms]
TEST.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 des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
max_life = 24h 0m 0s
max_renewable_life = 7d 0h 0m 0s
}
kdcdefaults块配置了kdc服务监听的端口
realms 配置了该kdc管辖的realm的相关配置,具体为
kinit -R
, hue就专门有一个续期的服务,定时去调用kinit -R
进行票据续期。一般max_renewable_life 默认值是0,也即不允许续期,所以记得要在kdc中配置该值,否则有些依赖Kerberos的服务会工作不正常,比如hue默认路径/var/kerberos/krb5kdc/kadm5.acl
该文件相当于一个访问列表,其中配置了哪些Principal拥有管理kdc的数据库的名单。比如下属配置
*/admin@TEST.COM *
该配置表示名为TEST.COM的realm 中,为*/admin
的pricipal将拥有所有的权限,第一个星表示用户名通配符,vincent/admin或者tom/admin都能满足这个规则,第二个星表示拥有所有的权限
kdb5_util create -s
该命令会创建一个kdc数据库,该数据库实际存放所有principal的账号。命令敲击后,会类似如下样子
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'TEST.COM',
master key name 'K/M@TEST.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
它会让用户属于一个密码,该密码是用来管理kdc数据库的,访问该数据的用户名为K/M@TEST.COM
。kdc每次重启,都会要求输密码,以访问该数据库,为了跳过这个人工干预,所以这里加了-s
参数,表示将数据登录认证进行暂存,这样下次kdc可以直接启动
在server所在的机器上执行命令kadmin.local -q "addprinc tunde/admin"
,该命令会直接访问kdc的数据库,并在其中创建一个tunde/admin
的principal,该principal显然满足满足kadm5.acl访问控制列表的规范,可以作为kdc的管理员
$ service krb5kdc start #启动kdc
$ service kadmin start #启动kadmin server,该服务使得我们可以远程通过kadmin去管理kdc数据库中的Principal
$ chkconfig krb5kdc on
$ chkconfig kadmin on
上述配置,已经完成了一个kerberos 服务的基本配置。下面来说一些进阶配置
在两个机器上,分别启动kdc。 他们拥有独立的数据库,平时连其中一个,当挂掉后,启动另一个服务器上的kdc。两个kdc之间的数据库需要自己写脚本来复制。这种方式不是真正的高可用,且数据复制较为麻烦。
https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/kdc_conf.html#dbdefaults
上述配置中,kdc默认的数据库是在本地文件系统上的一个文件。可以将kerberos同LDAP整合,实现将用户的账户、甚至组织机构信息存储在ldap中,而不是本地的文件中。一个跟LDAP整合的样例配置如下:
[kdcdefaults]
kdc_ports = 88
[realms]
ATHENA.MIT.EDU = {
kadmind_port = 749
max_life = 12h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = aes256-cts-hmac-sha1-96
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
database_module = openldap_ldapconf
}
[logging]
kdc = FILE:/usr/local/var/krb5kdc/kdc.log
admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
[dbdefaults]
ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
[dbmodules]
openldap_ldapconf = {
db_library = kldap
disable_last_success = true
ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
# this object needs to have read rights on
# the realm container and principal subtrees
ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
# this object needs to have read and write rights on
# the realm container and principal subtrees
ldap_service_password_file = /etc/kerberos/service.keyfile
ldap_servers = ldaps://kerberos.mit.edu
ldap_conns_per_server = 5
}
其中dbdefaults下的ldap_kerberos_container_dn 属性,指定的是整个kerberos管理的Principal所在ldap的父entry地址,它相当于一个容器,装在了所有的Principal账户,所以名字上有container字样体现
db_library = kldap 表示我们整合的数据库类型是LDAP
disable_last_success = true 用户登录的时候,默认会记录用户上次成功登录的时间。但记录这个是有性能开销的。所以可以通过这个选项,禁用掉 对成功登录信息的记录。当然禁用掉会影响管理员去排除登录问题,你都不知道用户上次成功登录时什么时候了。对应的文档地址:https://web.mit.edu/kerberos/krb5-1.14/doc/admin/lockout.html
ldap_kdc_dn 该属性配置 krb5kdc守护进程在ldap中的账号dn(dn也即我们普通理解的id),该节点需要拥有对ldap_kerberos_container_dn entry的读写权限
ldap_kadmind_dn 该属性配置 kadmind进程的账号dn,该节点需要拥有对ldap_kerberos_container_dn entry的读写权限
ldap_service_password_file kerberos本身的守护进程krb5kdc和kadmind在对ldap中的principal信息进行管理时,首先这些守护进程自己需要有权限登录到ldap。而使用交互方式输入密码显然不现实。所以需要将krb5kdc和kadmind对应的ldap密码信息放到一个文件里。该属性就是来配置这个密码认证文件的。kerberos提供了工具kdb5_ldap_util 来将对应的ldap账号,做成文件
kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyfile cn=service-kdc,o=org
这里-f
指定将要用于存储密码的文件,后面紧跟的是对应的ldap dn。该命令会进入交互界面,让我们输入对应账号的密码,认证成功后,将在指定文件生成对应的认证记录。该工具的参考资料为:https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/admin_commands/kdb5_ldap_util.html
ldap_servers 配置LDAP的连接地址
ldap_conns_per_server 配置kerberos同LDAP服务器之间保有的连接数
yum install krb5-workstation krb5-libs
与server不同的是,少了krb5-server组件的安装
一般情况,client的该配置,同服务端一样,所以拷过来即可
kadmin 是通过访问kadmin server进程,来实现对Kdc中的principal进行管理
而kadmin.local是在kdc所在的服务器上,直接访问kdc的数据库,它不依赖kadmin server,只要kdc数据库创建后,即可进行操作。
除此之外,两者功能类似
直接使用kadmin时,kadmin相当一个命令行操作系统,一旦进入后,就可以在里面交互式的执行很多Principal管理命令。命令后面加了中文注释
[root]$ kadmin -p tunde/admin
Authenticating as principal tunde/admin with password.
Password for tunde/admin@TEST.COM:
#list principals -- see which users can get a kerberos ticket
kadmin: list_principals #列出现在kdc中拥有的principal列表
#add a new principal
kadmin: addprinc user1 #添加一个principal
WARNING: no policy specified for user1@TEST.COM; defaulting to no policy
Enter password for principal "user1@TEST.COM":
Re-enter password for principal "user1@TEST.COM":
Principal "user1@TEST.COM" created.
#delete principal
kadmin: delprinc user1 #删除一个principal
Are you sure you want to delete the principal "user1@TEST.COM"? (yes/no): yes
Principal "user1@TEST.COM" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
#let's add the user1 principal back
kadmin: addprinc user1 #再次添加user1这个principal
WARNING: no policy specified for user1@TEST.COM; defaulting to no policy
Enter password for principal "user1@TEST.COM":
Re-enter password for principal "user1@TEST.COM":
Principal "user1@TEST.COM" created.
kadmin: exit #突出整个kadmin的交互session
值得注意的是,上述addprinc user1
,会以交互的方式让用户输入这个principal的密码。如果添加的Principal本身不给用户交互使用,而是直接以keytab文件方式做为认证文件。那么也可以在新建principal的时候加上-randkey
参数,表示给新建的用户随机生成一个密码。这样通过kadmin.local 生成keytab文件时,比如addprinc -randkey user1
再分发给到目的地就好。keytab的创建方式见下文。
当然,如果只是想直接直接执行一个命令,而不想进入上述的交互界面,也可以直接加参数-q
去执行后即退出,比如
kadmin -p tunde/admin -q "list_principals"
直接使用kadmin命令时,默认登录的principal是当前linux登录用户的加realm组合而来的。比如当前登录用户是ops。那么kadmin会试登录用户为ops/admin@TEST.COM
。很可能KDC数据库中,根本就没有这个Principal,所以会报如下错误
Authenticating as principal ops/admin@TEST.COM with password.
解决办法是对kadmin加-p
参数,显示指定实际存在的admin principal来进行登录, 如kadmin -p tunde/admin
在安有kerberos 客户端或服务器的机器上,直接使用kinit user1
命令,即可以交互的形式输入密码,去kdc认证登录。
登录成功后,可以使用klist -e
看下票据的有效期等信息
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user1@TEST.COM
Valid starting Expires Service principal
02/03/14 02:32:42 02/04/14 02:32:42 krbtgt/TEST.COM@TEST.COM
renew until 02/03/14 02:32:42, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
就在登录的那台机器上使用kdestroy
命令,销毁认证的票据。然后使用klist
去看是否销毁成功,销毁成功后显示
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
使用kinit -R
可以实现对已登录认证的票据进行续期,防止失效。hue有一个专门的 Ticket Renewal 实例来做这个事情
前面说过,通过kinit方式认证一个principal是需要用输入密码的方式进行交互。而如果两个互访的Principal本身就是两个机器,显然没办法以交互的方式进行认证。keytab文件就可以解决这个问题,它存储了多个principal及其对应的密码信息。
keytab文件的创建方式为,在kadmin命令行中使用ktadd
命令,命令的完整形式为ktadd -k keytab_file_path principal
。demo如下
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
encryption type aes256-cts-hmac-sha1-96 added to keytab
FILE:/tmp/foo-new-keytab
kadmin:
从keytab中移除对应的principal使用的命令为ktremove
,具体使用方式不再赘述
前面说了max_life是设置票据的生存时长
max_renewable_life是设置票据可以被续期的时长,也即在指定的时间段内,票据可以被续期。当然续期后的票据长度还是max_life。
这两个属性跟principal是绑定的,所以如果配置这两个属性之前,已经创建了许多principal,那修改这两个属性重启kdc后,这两个属性依然不会生效。有两种方式来解决。
第一种,删除数据库后重做,数据库对应的文件,一般在/var/kerberos/krb5kdc
目录下
第二种,直接修改对应Principal的属性值,比如
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable krbtgt/TEST.COM
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable
https://godatadriven.com/blog/kerberos-basics-and-installing-a-kdc/
手机扫一扫
移动阅读更方便
你可能感兴趣的文章