On 05/05/2016 02:58 PM, Milan Kubík wrote:
Both krbPrincipalName and krbCanonicalName will be guarded by uniqueness
plugin so this should raise an error in the DS backend.
On 04/08/2016 05:10 PM, Martin Babinsky wrote:
I have put together a draft  outlining the effort to reimplement
the handling of Kerberos principals in both backend and frontend
layers of FreeIPA so that we may have multiple aliases per user, host
or service and thus implement stuff like
Since much of the plumbing was already implemented, the document
mainly describes what the patches do. Some parts required by other use
cases may be missing so please point these out.
I would also be happy if you could correct all factual inacurracies, I
did research on this issue a long time ago and my knowledge turned a
I went through the design document and the related email thread here on
the list and I have few questions:
1. Is there any progress on what's to happen if MODRDN would colide with
an existing alias on a different entry?
It will need some more investigation though and will probably warrant a
separate test case in the future test plan.
I didn't think about staged users when designing/doing patches. Thank
you for pointing this out. The principal name is assigned when creating
the staged user and it is also checked during activation and again added
if it is not present. We will need to handle both of these cases. I will
update the design to reflect this.
2. How does this RFE change the behavior of stage user plugin? Is the
principal (as in the canonical name) assigned at this stage of user
The e-mail case can be tricky, since having two '@' in the principal
name can break parsing/unparsing of principal name in KDB DAL. We will
likely have to implement some sort of escaping to handle this correctly.
This should be discussed in more detail with Simo/Alexander/Sumit.
3. Will there be any constraints on what string can be used as an alias?
(The document mentions email address as one use case)
4. Will this RFE have any impact on AD trust (possibility of cross realm
routing, RFC 6806 section 9)
IIRC there should be no impact on trusts.
Otherwise the document looks good from my POV as QE.
Thank you for the review.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code