[Freeipa-devel] [DESIGN] Kerberos principal alias handling

[David Kupka]

On 18/04/16 21:42, Simo Sorce wrote:
> On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote:
>> On 08/04/16 17:10, Martin Babinsky wrote:
>>> Hi list,
>>>
>>> I have put together a draft [1] 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
>>> https://fedorahosted.org/freeipa/ticket/3961 and
>>> https://fedorahosted.org/freeipa/ticket/5413 .
>>>
>>> Since much of the plumbing was already implemented,[2] 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 bit
>>> rusty.
>>>
>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
>>> [2]
>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html
>>>
>>
>> Hi,
>> after reading the designs following thoughts comes to my mind.
>>
>> 1) Just to be sure that I understand the new ticket obtaining process
>> correctly I'd like to summarize.
>> We need to always search all krbPrincipalName values, krbCanonicalName
>> and ipaKrbPrincipalAlias (for backward compatibility).
>> For TGT request case sensitivity of the search and principal in returned
>> ticket depends on canonicalization. When canonicalization is requested
>> the search is case-insensitive and krbCanonicalName is used otherwise
>> case-sensitive search is performed and principal from request is used.
>
> Yes.
>
>> When requesting TGS search is always case-sensitive and principal from
>> request is used.
>
> No, this sounds wrong to me, I think we want a case-insensitve search
> for TGS requests.
>
>> In pseudo-code:
>>
>> get_tgt(principal, secret, canonicalization)
>>       if canonicalization
>>           if principal case-insensitive-in {krbPrincipalName +
>> ipaKrbPrincipalAlias + krbCanonicalName}
>>               # verify secret, perform various other checks...
>>               return TGT(krbCanonicalName)
>>       else
>>           if principal case-sensitive-in {krbPrincipalName +
>> ipaKrbPrincipalAlias + krbCanonicalName}
>>               # verify secret, perform various other checks...
>>               return TGT(principal)
>>
>> get_tgs(service_principal, TGT)
>>       if service_principal case-sensitive-in {krbPrincipalName +
>> ipaKrbPrincipalAlias + krbCanonicalName}
>>           # verify TGT, perform various other checks...
>>           return TGS(service_principal)
>>
>> Do I understand it right?
>
> I do not think the TGS part is right.
> A case insensitive search in TGS would allow to match upper case service
> or host names which are sometime mistakenly used, especially in Windows
> born software, given that the AD KDC is case insensitive.
>

Ok, thanks for correcting me.

>> 2) I would like to add following constrains for
>> krb{Canonical,Principal}Name attributes:
>>
>> when user/host/service is created krbCanonicalName is set to the same
>> value as krbPrincipalName
>> krbCanonicalName cannot be modified
>> krbPrincipalName with the same value as krbCanonicalName cannot be
>> removed/modified
>> krbPrincipalName must be case-insensitively unique in whole DB
>> krbPrincipalName attributes can be added and/or removed
>
> +1
>
>> This will allow us to keep the first krbPrincipalName as RDN for
>> services/hosts and give the flexibility of adding/removing aliases.
>>
>> 'Change of username' use case is also solvable with this approach. When
>> username is changed we add krbPrincipalName with the new username. That
>> will allow user to login with either old or new name.
>
> -1 for users a rename means we change the principal and the canonical
> name and we do not retain any old principal name.
>

But this is inconsistent with the constrains above, especially
"krbCanonicalName cannot be modified". We have the following options:

1) Do not allow rename for hosts and services but allow it for users.
2) Allow renaming of all objects.
3) Do not allow renaming of anything.

I don't like 1) because it is inconsistent. User renaming is nice 
feature so we probably don't want 3). Which leaves us with different set 
of constrains:

there always needs to be krbPrincipalName with the same value as 
krbCanonicalName
krbPrincipalName must be case-insensitively unique in whole DB
krbPrincipalName attributes can be added and/or removed

Is this what we want? Is it wise to allow renaming of hosts and 
services? Is there a use case? Is there any potential danger?

>> 3) ad CLI:
>> {user,host,service}-add - Can canonicalname be specified? Or will it
>> take principal argument/option value?
>> Can we add {user,host,service}-{add,remove}-principal set of commands
>> for principal manipulation? I really don't want to use
>> --{add,set,del}-attr unless necessary.
>> Will {user,host,service}-{show,find} display krbCanonicalName by default
>> or only with --all option?
>>
>> 4) ad Upgrade:
>> I think it would be worth to check and document what happens during
>> upgrade of multiple replicas. There may be confusing behavior when
>> obtaining tickets. KDC behavior will differ among servers and since
>> autodiscovery is in use we don't know if we are talking to the old or
>> new server. I'm not sure what exactly will happen but I suspect it won't
>> be nice.
>
> Yes, this is a problematic point, I am wondering if we should have a way
> to tell if all KDCs are at a specific level before allowing to turn on
> this behavior, but then we need to make it conditional and this all
> starts to sound a lot like a new domain level.
> OTOH only alias resolution fails on older KDCs, so that may be ok in
> some cases.
>
> Are there any strong opinions?
> Should we make this change optional and activate it only when enough
> features come up that demand a new domain level ?
> We can always generate the canonicalName now to be ready, but prevent
> adding aliases until a new domain level is created ?
> Any other idea ?

I would not go for a new domain level, it will just add a lot of 'if' 
statements all over the code. I believe it will be enough to document 
that canonicalization and other new features can be used only after all 
replicas in topology are upgraded.

>
> Simo.
>


-- 
David Kupka