Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 05/13/2016 12:07 PM, Alexander Bokovoy wrote: On Thu, 12 May 2016, Martin Babinsky wrote: We should not allow anything after @ not belonging to the list of realm domains. We also will need to extend realm domains to include non-domain-based UPN suffixes. This actually flies close to what I need to finish in my AD trust UPN patches, so I need to make sure we have the same approach there. Does this mean that we would not be able to implement e-mail as principal alias [1]? Why? I have not said that. I have said that you should not be able to specify UPN with a suffix that does not belong to us. I don't want us to allow to have Kerberos principals aliased to a trusted forest namespaces as this is violation of a forest trust. I see that my reading comprehension skills are slowly declining over time :D. I now hope that I understand what you mean: the alias suffix MUST NOT overlap with any UPN suffix of a trusted forest. We then need to add these checks onto alias manipulation commands and add this to the design document. 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. We should never allow to specify alias from the realm we don't own. This means the code needs to look into the namespaces associated with any of the trusted domains and reject them. So if I understand correctly we should reject tickets incoming from trusted domains if they do not contain canonical principal name (i.e. UPN)? Again, no, this is not what I said. For UPNs from trusted domains I already have code to detect them and issue correct referral for clients to go to the proper KDC. OK so it seems that we will need to coordinate our respective efforts. -- Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On Thu, 12 May 2016, Martin Babinsky wrote: We should not allow anything after @ not belonging to the list of realm domains. We also will need to extend realm domains to include non-domain-based UPN suffixes. This actually flies close to what I need to finish in my AD trust UPN patches, so I need to make sure we have the same approach there. Does this mean that we would not be able to implement e-mail as principal alias [1]? Why? I have not said that. I have said that you should not be able to specify UPN with a suffix that does not belong to us. I don't want us to allow to have Kerberos principals aliased to a trusted forest namespaces as this is violation of a forest trust. 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. We should never allow to specify alias from the realm we don't own. This means the code needs to look into the namespaces associated with any of the trusted domains and reject them. So if I understand correctly we should reject tickets incoming from trusted domains if they do not contain canonical principal name (i.e. UPN)? Again, no, this is not what I said. For UPNs from trusted domains I already have code to detect them and issue correct referral for clients to go to the proper KDC. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 05/09/2016 08:26 AM, Alexander Bokovoy wrote: On Fri, 06 May 2016, Martin Babinsky wrote: On 05/05/2016 02:58 PM, Milan Kubík wrote: On 04/08/2016 05:10 PM, 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! 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? Both krbPrincipalName and krbCanonicalName will be guarded by uniqueness plugin so this should raise an error in the DS backend. It will need some more investigation though and will probably warrant a separate test case in the future test plan. 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 lifetime? 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. 3. Will there be any constraints on what string can be used as an alias? (The document mentions email address as one use case) 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. We should not allow anything after @ not belonging to the list of realm domains. We also will need to extend realm domains to include non-domain-based UPN suffixes. This actually flies close to what I need to finish in my AD trust UPN patches, so I need to make sure we have the same approach there. Does this mean that we would not be able to implement e-mail as principal alias [1]? 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. We should never allow to specify alias from the realm we don't own. This means the code needs to look into the namespaces associated with any of the trusted domains and reject them. So if I understand correctly we should reject tickets incoming from trusted domains if they do not contain canonical principal name (i.e. UPN)? [1] https://fedorahosted.org/freeipa/ticket/5413 -- Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On Fri, 06 May 2016, Martin Babinsky wrote: On 05/05/2016 02:58 PM, Milan Kubík wrote: On 04/08/2016 05:10 PM, 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! 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? Both krbPrincipalName and krbCanonicalName will be guarded by uniqueness plugin so this should raise an error in the DS backend. It will need some more investigation though and will probably warrant a separate test case in the future test plan. 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 lifetime? 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. 3. Will there be any constraints on what string can be used as an alias? (The document mentions email address as one use case) 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. We should not allow anything after @ not belonging to the list of realm domains. We also will need to extend realm domains to include non-domain-based UPN suffixes. This actually flies close to what I need to finish in my AD trust UPN patches, so I need to make sure we have the same approach there. 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. We should never allow to specify alias from the realm we don't own. This means the code needs to look into the namespaces associated with any of the trusted domains and reject them. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 05/05/2016 02:58 PM, Milan Kubík wrote: On 04/08/2016 05:10 PM, 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! 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? Both krbPrincipalName and krbCanonicalName will be guarded by uniqueness plugin so this should raise an error in the DS backend. It will need some more investigation though and will probably warrant a separate test case in the future test plan. 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 lifetime? 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. 3. Will there be any constraints on what string can be used as an alias? (The document mentions email address as one use case) 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. 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. Regards, -- Milan Kubik Thank you for the review. -- Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 05/06/2016 02:57 PM, Martin Kosek wrote:
On 04/18/2016 10:31 AM, Martin Kosek wrote:
On 04/08/2016 05:10 PM, 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
Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also
see that you are using the Kerberos attributes in the raw name
("--krbprincipalname"). This is not consistent with the CLI form when they are
used in other commands:
...
Str('krbprincipalname?', validate_principal,
cli_name='principal',
label=_('Kerberos principal'),
default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm),
autofill=True,
flags=['no_update'],
normalizer=lambda value: normalize_principal(value),
),
DateTime('krbprincipalexpiration?',
cli_name='principal_expiration',
label=_('Kerberos principal expiration'),
),
...
IMO, it should be rather "--principal" and "--principal-alias".
Martin
Bump.
I have fixed the CLI API a while ago so it should now be more conformant
with the rest of the framework. I just forgot to notify the list about
the change.
Other parts of the design were also revised but we are not there yet
since we have to investigate a discrepancy in handling of kinit using
alias without canonicalization between AD and MIT Kerberos.
We have discussed this with Simo (cc'ed) who promised to ask MIT guys
about this. We should restart the discussion about the design.
--
Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/18/2016 10:31 AM, Martin Kosek wrote:
> On 04/08/2016 05:10 PM, 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
>
> Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also
> see that you are using the Kerberos attributes in the raw name
> ("--krbprincipalname"). This is not consistent with the CLI form when they are
> used in other commands:
>
> ...
> Str('krbprincipalname?', validate_principal,
> cli_name='principal',
> label=_('Kerberos principal'),
> default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm),
> autofill=True,
> flags=['no_update'],
> normalizer=lambda value: normalize_principal(value),
> ),
> DateTime('krbprincipalexpiration?',
> cli_name='principal_expiration',
> label=_('Kerberos principal expiration'),
> ),
> ...
>
> IMO, it should be rather "--principal" and "--principal-alias".
>
> Martin
>
Bump.
--
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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/08/2016 05:10 PM, 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! 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? 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 lifetime? 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) Otherwise the document looks good from my POV as QE. Regards, -- Milan Kubik -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On Tue, 2016-04-19 at 12:37 +0200, Martin Babinsky wrote:
> On 04/19/2016 10:11 AM, David Kupka wrote:
> > 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.
Yep, this is what we had for a long time, I see no reason for changing,
no any inconsistency.
> > 2) Allow renaming of all objects.
> > 3) Do not allow renaming of anything.
> >
> We already support renaming of user entries and the MODRDN plugin
> handles the rename of krbPrincipalName attribute. In this case we need
> to retain this behavior to be backwards compatible. Moreover, we would
> *have* to rename krbCanonicalName for the
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/19/2016 10:11 AM, David Kupka wrote:
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.
We already support renaming of user entries and the MODRDN plugin
handles the rename of krbPrincipalName attribute. In this case we need
to retain this behavior to be backwards compatible. Moreover, we would
*have* to rename krbCanonicalName for the same reason. The question
remains what to do if there are already some other aliases in place and
the user is renamed. I will investigate this further.
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?
For now I'do go with option 1.). It kind of preserves the current status
quo (users have --rename but
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
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.
> 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.
> 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/08/2016 05:10 PM, 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
Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also
see that you are using the Kerberos attributes in the raw name
("--krbprincipalname"). This is not consistent with the CLI form when they are
used in other commands:
...
Str('krbprincipalname?', validate_principal,
cli_name='principal',
label=_('Kerberos principal'),
default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm),
autofill=True,
flags=['no_update'],
normalizer=lambda value: normalize_principal(value),
),
DateTime('krbprincipalexpiration?',
cli_name='principal_expiration',
label=_('Kerberos principal expiration'),
),
...
IMO, it should be rather "--principal" and "--principal-alias".
Martin
--
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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/13/2016 07:50 AM, 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.
When requesting TGS search is always case-sensitive and principal from
request is used.
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?
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
I will definitwly add this constraints into the design.
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.
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.
I have added the commands to the design.
Will {user,host,service}-{show,find} display krbCanonicalName by default
or only with --all option?
IIRC it should be printed out only when '--all' is requested.
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.
I will test this but I expected that 'kinit -C' will get back TGT with
different principal for different replica (old vs. new) for newly added
entries (the old entries will behave the same as before). That may not
be what we want, but I can not think of any way to amend this.
What we forgot to discuss is the handling of krbCanonicalName during
MODRDN operation, e.g. when username is changed.
Currently the design assumes that when uid changes the MODRDN plugin
will change krbCanonicalName attribute to reflect this change, e.g.
uid: jsmith->johns
krbCanonicalName: jsmith@REALM -> krbCanoncialName: johns@REALM
I remember talking with Simo (CC'ed) that this is the desired behavior
but I am not sure if this still holds.
--
Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
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.
When requesting TGS search is always case-sensitive and principal from
request is used.
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?
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
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.
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.
--
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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 11.4.2016 16:58, thierry bordaz wrote: > > > On 04/11/2016 04:51 PM, Simo Sorce wrote: >> On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: >>> On 04/08/2016 05:10 PM, 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 Martin, >>> >>> Currently DS is enforcing that 'krbPrincipalName' and >>> 'krbCanonicalName' are unique. >>> krbPrincipalName is caseExactIA5Match. >>> Is it possible to imagine entries having the same (IgnoreCase) alias: >>> >>> dn: uid=user_one,cn=users,cn=accounts, >>> ... >>> krbCanonicalName: user_one@ >>> krbPrincipalName: user_one@ >>> krbPrincipalName: user_ONE@ >>> >>> dn: uid=user_two,cn=users,cn=accounts, >>> ... >>> krbCanonicalName: user_two@ >>> krbPrincipalName: user_two@ >>> krbPrincipalName: user_TWO@ >>> krbPrincipalName: *user_**One*@ >>> >>> So KDB, searching as case insentive >>> "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will >>> retrieve user_one and user_two ? >> Yes, but it is an error to have the same alias (differing just by case) >> on two distinct principals. So this is an error condition not an >> expected use case. >> >> Simo. >> > I agree. > At uniqueness plugin, this could be prevented if we add the support of > matchingRule for uniqueness lookup. Sounds like a good idea to me! -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/11/2016 04:51 PM, Simo Sorce wrote: On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: On 04/08/2016 05:10 PM, 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 Martin, Currently DS is enforcing that 'krbPrincipalName' and 'krbCanonicalName' are unique. krbPrincipalName is caseExactIA5Match. Is it possible to imagine entries having the same (IgnoreCase) alias: dn: uid=user_one,cn=users,cn=accounts, ... krbCanonicalName: user_one@ krbPrincipalName: user_one@ krbPrincipalName: user_ONE@ dn: uid=user_two,cn=users,cn=accounts, ... krbCanonicalName: user_two@ krbPrincipalName: user_two@ krbPrincipalName: user_TWO@ krbPrincipalName: *user_**One*@ So KDB, searching as case insentive "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will retrieve user_one and user_two ? Yes, but it is an error to have the same alias (differing just by case) on two distinct principals. So this is an error condition not an expected use case. Simo. I agree. At uniqueness plugin, this could be prevented if we add the support of matchingRule for uniqueness lookup. thanks thierry -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: > > On 04/08/2016 05:10 PM, 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 Martin, > > Currently DS is enforcing that 'krbPrincipalName' and > 'krbCanonicalName' are unique. > krbPrincipalName is caseExactIA5Match. > Is it possible to imagine entries having the same (IgnoreCase) alias: > > dn: uid=user_one,cn=users,cn=accounts, > ... > krbCanonicalName: user_one@ > krbPrincipalName: user_one@ > krbPrincipalName: user_ONE@ > > dn: uid=user_two,cn=users,cn=accounts, > ... > krbCanonicalName: user_two@ > krbPrincipalName: user_two@ > krbPrincipalName: user_TWO@ > krbPrincipalName: *user_**One*@ > > So KDB, searching as case insentive > "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will > retrieve user_one and user_two ? Yes, but it is an error to have the same alias (differing just by case) on two distinct principals. So this is an error condition not an expected use case. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/08/2016 05:10 PM, 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 Martin, Currently DS is enforcing that 'krbPrincipalName' and 'krbCanonicalName' are unique. krbPrincipalName is caseExactIA5Match. Is it possible to imagine entries having the same (IgnoreCase) alias: dn: uid=user_one,cn=users,cn=accounts, ... krbCanonicalName: user_one@ krbPrincipalName: user_one@ krbPrincipalName: user_ONE@ dn: uid=user_two,cn=users,cn=accounts, ... krbCanonicalName: user_two@ krbPrincipalName: user_two@ krbPrincipalName: user_TWO@ krbPrincipalName: *user_**One*@ So KDB, searching as case insentive "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will retrieve user_one and user_two ? thanks thierry | ||| -- 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On Mon, 2016-04-11 at 12:50 +0200, Martin Babinsky wrote:
> On 04/11/2016 11:05 AM, Petr Spacek wrote:
> > On 8.4.2016 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
> >
> > I cannot say much about the implementation, but I would appreciate following
> > information:
> >
> > CLI
> > ===
> > 1) {user,host,service}-add operate with canonical name, right? This could be
> > made clear so normal user understands the text.
> >
> The *-add commands operate on both, they will set krbCanonicalName
> attribute and copy the same value to the krbPrincipalName. I will update
> the design to made this clear.
>
> > 2) Is it possible to change the canonical name?
> For users the canonical name will be changed during 'rename' operation,
> since the principal is generated from the primary key. I'm not sure
> about hosts/services since their primary keys are currently immutable.
>
> If we make them mutable, then the behavior shall be consistent with the
> user entries.
>
> >
> > 3) Can Web UI work with aliases without --principal-alias parameter?
> >
> Probably not and we would require to add this options to users and
> services. Hosts already have '--principalname' option currently
> restricted to single value, we may change it to multi-valued and add it
> also to other two entities.
>
> >
> > Upgrade
> > ===
> >> The backward compatibility with older machines will be kept while the new
> >> attributes will be replicated to older master when new
> >> host/service/entries will be created on new ones. No special upgrade
> >> procedure shall be necessary.
> >
> > It would be good to explicitly mention that old attributes will be still
> > populated => old and new replicas can work in the same topology.
> >
> Ok I will make this more clear.
Old attributes should not be populated, we are abandoning them because
they can't work, they will simply not be removed from the schema to
avoid constraints violations, but they will rapidly be deprecated and
not used anymore.
We need to assess the impact on keeping older replicas running for long,
with old framework and KDC code, but I do not think there will be issues
in the general case.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 04/11/2016 11:05 AM, Petr Spacek wrote:
On 8.4.2016 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
I cannot say much about the implementation, but I would appreciate following
information:
CLI
===
1) {user,host,service}-add operate with canonical name, right? This could be
made clear so normal user understands the text.
The *-add commands operate on both, they will set krbCanonicalName
attribute and copy the same value to the krbPrincipalName. I will update
the design to made this clear.
2) Is it possible to change the canonical name?
For users the canonical name will be changed during 'rename' operation,
since the principal is generated from the primary key. I'm not sure
about hosts/services since their primary keys are currently immutable.
If we make them mutable, then the behavior shall be consistent with the
user entries.
3) Can Web UI work with aliases without --principal-alias parameter?
Probably not and we would require to add this options to users and
services. Hosts already have '--principalname' option currently
restricted to single value, we may change it to multi-valued and add it
also to other two entities.
Upgrade
===
The backward compatibility with older machines will be kept while the new
attributes will be replicated to older master when new host/service/entries
will be created on new ones. No special upgrade procedure shall be necessary.
It would be good to explicitly mention that old attributes will be still
populated => old and new replicas can work in the same topology.
Ok I will make this more clear.
Other than that it seems reasonable.
Thank you for your comments.
--
Martin^3 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
Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling
On 8.4.2016 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
I cannot say much about the implementation, but I would appreciate following
information:
CLI
===
1) {user,host,service}-add operate with canonical name, right? This could be
made clear so normal user understands the text.
2) Is it possible to change the canonical name?
3) Can Web UI work with aliases without --principal-alias parameter?
Upgrade
===
> The backward compatibility with older machines will be kept while the new
> attributes will be replicated to older master when new host/service/entries
> will be created on new ones. No special upgrade procedure shall be necessary.
It would be good to explicitly mention that old attributes will be still
populated => old and new replicas can work in the same topology.
Other than that it seems reasonable.
--
Petr^2 Spacek
--
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
[Freeipa-devel] [DESIGN] Kerberos principal alias handling
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 -- Martin^3 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
