kadmind - Kerberos administration daemon
/usr/lib/krb5/kadmind [-d] [-m] [-p port-number] [-r realm] -x db_args]...
kadmind runs on the master key distribution center (KDC), which stores the principal and policy databases. kadmind accepts remote requests to administer the information in these databases. Remote requests are sent, for example, by kpasswd(1), gkadmin(1M), and kadmin(1M) commands, all of which are clients of kadmind. When you install a KDC, kadmind is set up in the init scripts to start automatically when the KDC is rebooted.
kadmind requires a number of configuration files to be set up for it to work:
/etc/krb5/kdc.conf
/etc/krb5/kadm5.keytab
/etc/krb5/kadm5.acl
The kadmind daemon will need to be restarted to reread the kadm5.acl file after it has been modified. You can do this, as root, with the following command:
# svcadm restart svc:/network/security/kadmin:default
After kadmind begins running, it puts itself in the background and disassociates itself from its controlling terminal.
kadmind can be configured for incremental database propagation. Incremental propagation allows slave KDC servers to receive principal and policy updates incrementally instead of receiving full dumps of the database. These settings can be changed in the kdc.conf(4) file:
sunw_dbprop_enable = [true | false]
sunw_dbprop_master_ulogsize = N
The kiprop/<hostname>@<REALM> principal must exist in the master's kadm5.keytab file to enable the slave to authenticate incremental propagation from the master. In the principal syntax above, <hostname> is the master KDC's host name and <REALM> is the realm in which the master KDC resides.
Kerberos client machines can automatically migrate Unix users to the default Kerberos realm specified in the local krb5.conf(4), if the user does not have a valid kerberos account already. You achieve this by using the pam_krb5_migrate(5) service module for the service in question. The Kerberos service principal used by the client machine attempting the migration needs to be validated using the u privilege in kadm5.acl(4). When using the u privilege, kadmind validates user passwords using PAM, specifically using a PAM_SERVICE name of k5migrate by calling pam_authenticate(3PAM) and pam_acct_mgmt(3PAM).
A suitable PAM stack configuration example for k5migrate would look like:
k5migrate auth required pam_unix_auth.so.1 k5migrate account required pam_unix_account.so.1
The following options are supported:
-d
-m
-p port-number
-r realm
-x db_args
binddn=binddn
bindpwd=bindpwd
dbname=name
nconns=num
port=num
/var/krb5/principal
/var/krb5/principal.ulog
/var/krb5/principal.kadm5
/var/krb5/principal.kadm5.lock
/var/krb5/kadm5.dict
/etc/krb5/kadm5.acl
/etc/krb5/kadm5.keytab
/etc/krb5/kdc.conf
See attributes(5) for descriptions of the following attributes:
|
kpasswd(1), svcs(1), gkadmin(1M), kadmin(1M), kadmin.local(1M), kdb5_util(1M), kdb5_ldap_util(1M), kproplog(1M), svcadm(1M), pam_acct_mgmt(3PAM), pam_authenticate(3PAM), kadm5.acl(4), kdc.conf(4), krb5.conf(4), attributes(5), kerberos(5), krb5envvar(5), pam_krb5_migrate(5), smf(5)
The Kerberos administration daemon (kadmind) is now compliant with the change-password standard mentioned in RFC 3244, which means it can now handle change-password requests from non-Solaris Kerberos clients.
The kadmind service is managed by the service management facility, smf(5), under the service identifier:
svc:/network/security/kadmin
Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |