On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> wrote: > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote: >> Hello, >> >> >> >> I would like to better understand why IPA requires SAN (subject alternative >> name) entries to have a backing host record. In order to sign a certificate >> with a SAN that corresponded to a user friendly CNAME I had to add a host >> record (ipa host) for that DNS name (use force option to create without an >> A/AAAA record) as well as a service principle. >> >> >> >> I'm sure I'm not alone when I say I don't like doing that because it means >> that a "Host" in FreeIPA is not a computer, it's a host record that may or >> may not be the only record that corresponds to a computer. It gets >> confusing. >> >> >> >> I assume things are this way to ensure integrity at some level. But I can't >> picture it. What is the potential danger of simply bypassing the >> host/principal checks and just signing the certificate with whatever SAN >> field we like? >> > In this specific case, it is because certmonger requests service > certificates with host credentials. Therefore it is not just human > administrators issuing certs. And we MUST validate SAN against > information in the directory (the only "source of truth" available > to the CA / IPA cert-request command). Otherwise you could put e.g. > `google.com' into SAN, and we would issue the cert, and that would > be Very Bad. >
In my case it's always human administrators issuing certs. I can see how validation is a great way to prevent a scenario like the one you described. But couldn't that be accommodated by tinkering with the roles/privileges so that you could impose the restriction on external, less-trusted applications but allow a trusted human administrator to bypass it? Admin group by default would be nice. It would be unfortunate if someone added a service account to the admin group, but I don't see that as justification for ruling it out. How many other poor security decisions has someone made already before they decided to add a service account to the domain admin group? To that I would say that degree of administrative negligence is not something that the project should design around. But, I don't work at RedHat and I don't have to take the support calls so my opinion means nothing. But if I'm an admin, enforcing the SAN restriction doesn't prevent me from doing anything I couldn't already do by creating a couple host records. It's just making things difficult for admins who ultimately are securely deploying a service. > The problem is slightly exacerbated in that 99% of the time you > really want to issue service certs, but FreeIPA does not permit the > creation of a service entry without a corresponding host entry. So > you end up with spurious host entries that do not correspond to > actual hosts. I have previously asked about relaxing this > restriction. The idea was rejected (for reasons I don't remember). To be fair, I don't think I ever read specifically that a Host in IPA was supposed to represent a single computer. But I imagine that the majority of people who are using it thought that was the case, at least at first. I don't think it would take much abstraction to maintain that logical representation for administrators. >> If this actually is a necessity and is not likely to change, I think it >> would be beneficial to administrators to be able to manage "Hosts" that >> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that >> are actually enrolled computers. They could be managed in a similar fashion >> to SUDO rules, like maybe: >> >> >> >> Alias Hosts = a single name >> >> Alias Host Groups = groups of names >> >> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups >> >> >> >> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity >> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab >> under policy. >> > Now that we have kerberos principal aliases, we might be able to > leverage that, perhaps even directly for service principals. Any > devs want to chime in on this idea? > > Cheers, > Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project