#3961 [RFE] Allow multiple Principals per host entry (Kerberos aliases)
Closed: Fixed None Opened 5 years ago by admiyo.

A host can support multiple host names. As such, the LDAP entry for the host can have multiple values:

Unfortunately, an admin user does not have the ACLs set up to do this. In order to run the following command:

dn:
fqdn=ayoung-42.openstack.freeipa.org,cn=computers,cn=accounts,dc=openstack,dc=freeipa,dc=org
changetype: modify
add: krbprincipalname
krbprincipalname: host/valid.openstack.freeipa.org@OPENSTACK.FREEIPA.ORG
-

You need to run ldapmodify as "cn=Directory Manager"

So: to support, the API should support adding,removing kerberos principals from the user (can be done now with setaddr) and the ACLs need to be changed so that a user can edit the krbprincipalname value on the host record.


Polishing Description.

Starting to shape next release

Worth mentioning why this feature is important. If there are multiple principals per host, you can user Kerberos based on the hostname of the machine, or based on other aliases. For a container based system like Docker or OpenShift, this means that a user can user Kerberos to authenticate when connecting to a container based on the container name, regardless of the hostname of the host machine

No, this is exactly the wrong case.
If you have containers it is because you want isolation, so you want a different principal and key for the container. You do not want to share the same key material with the container.

If the container has a different name then the host name of the host is irrelevant, what matters is that "container-name" -> IP address ends up connecting you t a process running in the container.

As a correction: the reason for this request was for the internal/external naming of host; this is an OpenStack, not the Docker use case. The same machine may end up with two different IP address, a non-routable internal that comes up right away, and a routable external one. Both will get Hostnames, but each are likely in a different DNS domains. In order for securely authenticated access on both internal and external hostnames, both principals need to be accepted.

Replying to [comment:9 admiyo]:

As a correction: the reason for this request was for the internal/external naming of host; this is an OpenStack, not the Docker use case. The same machine may end up with two different IP address, a non-routable internal that comes up right away, and a routable external one. Both will get Hostnames, but each are likely in a different DNS domains. In order for securely authenticated access on both internal and external hostnames, both principals need to be accepted.

Yes this is the valid use case, however I will point 2 possible workarounds that may be employed now, and in some cases are a better option:
1. Just use the same DNs name internally and externally, use DNS views to give back the right IP address depending on who's asking.
2. Simply create 2 host objects, one for the internal and one for the external name and get keys for both principals in the same keytab.

HTH

Replying to [comment:10 simo]:

Yes this is the valid use case, however I will point 2 possible workarounds that may be employed now, and in some cases are a better option:
1. Just use the same DNs name internally and externally, use DNS views to give back the right IP address depending on who's asking.
2. Simply create 2 host objects, one for the internal and one for the external name and get keys for both principals in the same keytab.

  1. Split-brain DNS is a pretty big PITA, and IMO is best avoided. When you want to address a specific interface and you have a route to both, you have to go looking up IP addresses, which defeats the point of having DNS in the first place.

  2. This may be a workaround, but it definitely illustrates why this is a worthwhile enhancement.

Two points

  1. The use case is not only OpenStack but Amazon too. In EC2 you do not control DNS so this is no t an option. There is a workaround that was crafted by OpenShift guys but it a workaround that needs to be solidified.
    http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html
    It describes the problem and the solution pretty well. This ticket is to make this happen.

  2. About docker. Actually it seems that the direction this effort is going is that instead of having a container to do a stack of things there will be several containers that are configured to work with each other each of which represent a simple element. In this model one can deploy a container with SSSD that will server other containers, one will be say a DB, another app server and another web server. So the point here is that we can't assume that all that is needed for one application to work would be in one container under one host name. But let us table this use case for now. First one is good enough justification for the effort.

Is this maybe a duplica of #4421?

It seems like #4421 does describe the same phenomenon. Technically, that would be a duplicate of this ticket, as this one is far older.

FreeIPA 4.2.1 was released, moving to 4.2.x.

master:

  • de6abc7 ipapython module for Kerberos principal manipulation and parsing
  • e6fc8f8 Test suite for ipapython/kerberos.py
  • 974eb7b ipalib: introduce Principal parameter
  • c2af032 Migrate management framework plugins to use Principal parameter
  • d151748 Add ACI for admins to modify principal attributes
  • 7e803aa replace an ACI relying on presence of deprecated objectclass
  • 750a392 Allow for commands that use positional parameters to add/remove attributes
  • a28d312 Make framework consider krbcanonicalname as service primary key
  • e6ff83e Provide API for management of host, service, and user principal aliases
  • acf2234 Unify display of principal names/aliases across entities

Metadata Update from @admiyo:
- Issue assigned to mbabinsk
- Issue set to the milestone: FreeIPA 4.4

2 years ago

Login to comment on this ticket.

Metadata