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
--
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
