Hi List, TL;DR we have to handle FAST channer establishment when KDC is not issued PKINIT keypair
I have spent some time studying and fixing bugs/regressions caused by incomplete consideration of PKINIT and anonymous principal setup regarding to * replicas standed up against old (3.0.0) masters * domain level 0 topologies * CA-less deployments I want to discuss the impact of these findings on existing functionality and how to fix them so that 4.5.1 release will be more usable and free of subtle but serious bugs (more on this later). >From conversation from Alexander and Simo it follows that anonymous PKINIT feature is supposed to be used in domain level 1 deployments because only these guarantee the presence of the features (CA ACLs and custom certificate profiles) which allow for issuing certificates suitable for PKINIT authentication. This leads to the following considerations: * on DL0 enforce no_pkinit on server/replica deployments * during upgrade of DL0 deployments, do not issue PKINIT certificates * during upgrade of DL1 deployments issue PKINIT certs * extend ipa-server-certinstall to install/issue PKINIT certificates after DL0/DL1 ugrade (have to be manually). However, I found out that the only case when anonymous PKINIT actually works is for fresh DL1 server install and upgrade and install of 4.5.0 replica against 4.5.0 master in DL1. The following use-cases either fail to install or leave the system with unusable password auth (e.g. WebUI login): * setting up 4.5 replica against <4.5 master fails during anonymous principal setup[1] (ticket states domain level 0, but DL1 is also affected) * setting up server-replica with `no_pkinit` option (CA-full or CA-less) leaves the installation without non-working WebUI as anonymous PKINIT does not work (ticket incoming) * If we restrict DL0 installs to force no_pkinit[2] we will be left with whole topologies where anonymous PKINIT does not work, so no WebUI auth for them We now have to decide how to properly support or avoid non-PKINIT deployments. The current code which handles armoring of password auth requests[3] does not actually work without PKINIT certificates, the fallback mechanism still fails to obtain armor ccache[4]. I have concluded that for non-PKINIT cases we have to use the old way to armor TGT request (i.e. establish fast channel by kinit as service principal), but this means that the framewrok has to use a service principal whose keytab it can read and use. After privilege separation, however, we do not have direct access to HTTP keytab so how should we proceed in this case? We definitely need to discuss this further. Please state your suggestions and comments, and sorry for the long mail. [1] https://pagure.io/freeipa/issue/6799 [2] https://github.com/freeipa/freeipa/pull/640 [3] https://github.com/freeipa/freeipa/blob/master/ipalib/install/kinit.py#L100 [4] https://paste.fedoraproject.org/paste/AcM6ymNxg~pipF~1ZIfbdF5M1UNdIGYhyRLivL9gydE=/ -- Martin Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
