订阅内容

Enrolling a client system into Identity Management (IdM) can be done with a single command, namely: ipa-client-install. This command will configure SSSD, Kerberos, Certmonger and other elements of the system to work with IdM. The important result is that the system will get an identity and key so that it can securely connect to IdM and perform its operations. However, to get the identity and key, the system should

be trusted else any other system would be able to register and interact with the server. To confirm trust there are four different options:

1. Enrollment by a High Privileged Admin

If ipa-client-install command is executed by a high privileged admin and this admin uses his or her password to run the command, the client will first use Kerberos to authenticate the admin and will then send a request to the server to perform a client registration as admin. There server will check what administrator is allowed to do. There are two different permissions at play in this sequence: one is the right to create a host entry and the other one is to provision the key. Since this admin has high privileges, the server will create a new host entry for the client and return a generated Kerberos key that the client will store in a file called keytab. Once this operation is complete other configuration steps will continue but they are the same in all four provisioning options.

2. Enrollment by a Low Privileged Admin

If an admin does not have privileges to create a client host entry but has the permission to provision the key to the client, the host entries need to be pre-created. To pre-create entries you will need to define a special account and allow it to only register clients (i.e. create host entries) and not give it permissions to do any other administrative activity. You can then use this account in your scripts or with automatic provisioning tool of your choice. This account, or the high level admin, will first pre-create host entries in IdM and then the script or low privileged admin can actually “do” the job of provisioning the keys to the client systems. This approach works fine except that it leads to a password being stored verbatim in the scripts or somewhere in a file or in a source control system. Needless to say - from security point of view - this is not the best approach.

3. Enrollment Using One Time Password

An improvement over the previous option is to use a one time registration password. This approach mostly targets an automated provisioning as completed by a provisioning system. Red Hat Satellite 6, for example, is capable of provisioning systems and enrolling them with IdM automatically using this method. The flow of operations includes:

  • User initiates the provisioning operation
  • Provisioning server (e.g. Satellite 6) connects to IdM and registers a future host. It is implied that the server has permission to do so.
  • IdM returns a registration password that can be used only once.
  • Provisioning server passes the registration password to the system being deployed.
  • The system being deployed is synthesized and booted.
  • During this first boot the ipa-client-install script is invoked with the registration password.
  • The IdM server recognizes the code and completes enrollment returning the key.
  • After this a normal flow of client configuration continues.

A similar approach is being implemented in Nova component of the OpenStack targeting OpenStack 12. In OpenStack case this procedure is used to give identity to the OpenStack nodes so that they can automatically acquire certificate from IdM for all point-to-point communication between services inside OpenStack.

There is also a community effort to build a set of Ansible modules that would use the same method and enroll clients leveraging Ansible as an orchestration engine.

4. Re-enrollment

Finally, in some cases, an already provisioned system needs to be re-enrolled. This usually happens when the system is re-imaged and re-installed. In this case, going through a registration sequence again is an overhead. Instead - the file with the Kerberos key can be backed up and used once the system is re-imaged and restored. The client will then authenticate using the old key and then request a new key. Please note that the configuration files will also be brought into a canonical state, so if you did some manual or automated customization of the configuration, these changes will be lost. This method is also handy when seeking to repair the configuration of a client and to perform client key rotation if your policies require periodic key rotation.

As a part of the Ansible effort another use case case has been identified. What if a client system was lost? It was, for example, a virtual machine in a cloud and was killed for some reason. The server would think that the system is fully functional but in reality the keys are gone on the client side. In this situation one first has to disable the host before attempting to enroll this host again. Such step complicates the provisioning sequence which should be idempotent to be effective in automation tools like Ansible. This limitation will be addressed in later versions of IdM allowing the enrollment procedure to be less cumbersome.

Questions? Comments? Are you using an entirely different workflow for client enrollment? As always - I look forward to hearing your thoughts.


关于作者

UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事