K5Wiki - User contributions [en]

Projects/StartRealmCCconfig

2015-03-17T19:02:55Z

Nico: New page: = Background = When using referrals, the TGS client starts the referrals chasing process at the client principal's realm. That is, the desired service principal's realm is replaced with ...

= Background =

When using referrals, the TGS client starts the referrals chasing process at the client principal's realm. That is, the desired service principal's realm is replaced with the client principal's and a TGS-REQ is sent to that realm's TGS.

There are two cases where this choice of "start" realm are inappropriate:

- when the client principal's realm is a WELLKNOWN realm (e.g., the anonymous realm)
- when the client has a "root TGT" (krbtgt/REALM@REALM) but not for its own realm

The latter is used at some sites as a form of constrained credential delegation: a client at realm A forwards a ticket for krbtgt/B@B to a service in realm B, thus that service cannot reach realm A services (because of loop detection at A's TGSes), but it can still authenticate as the client @A. (The services in realm B can probably also not reach other realms that are reachable from A.)

The TGS client really needs a way to record the "start" realm where the TGT for that realm is stored: in the ccache.

= Recording the start realm in the ccache =

Searching for a root TGT in the ccache is not a good way to find a start realm: there is no guarantee that there will be only one such TGT, and there is no guarantee that the ccache preserves insertion order, therefore such a search could yield non-deterministic results.

The proposed solution is: record the start realm in a "cc config" ccache entry. Any process that initializes a ccache should add this cc config entry along with the TGT that it stores in the ccache. This should be done automatically by the krb5 library. When trying referrals, the client should search for this cc config entry, and if it finds it, it should use the realm recorded in it as the "start realm".

The new cc config name should be "start_realm", and the value stored there should be the start realm's name. (XXX NUL-terminated or not?)

Projects/Extensible Policy

2012-07-24T21:50:27Z

Nico:

{{project-review|2012-07-27}}
{{project-target|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; allowed_keysalts : key/salt type list that the principal is allowed to have keys of
; tl_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -allowedkeysalts keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that, as with the change in 1.8, it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner; by using TL data for future extensions, we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

A candidate implementation can be seen here:

* [https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts-squashed2 Implementation with history squashed.]
* [https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts Implementation with complete history]

Add "?w=1" to get the github equivalent of diff(1)'s -w flag.

We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the allowed_keysalts field.

==Testing==

One test is added: tests/t_allowed_keysalts.py. All tests pass.

NOTE: dump/load of policy TL data is not tested for lack of any policy elements that use TL data.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T23:08:49Z

Nico: /* Implementation */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

A candidate implementation can be seen here:

* [https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts-squashed2 Implementation with history squashed.]
* [https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts Implementation with complete history]

Add "?w=1" to get the github equivalent of diff(1)'s -w flag.

We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the keygen_enctypes field.

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

NOTE: dump/load of policy TL data is not tested for lack of any policy elements that use TL data.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T23:05:43Z

Nico: /* Testing */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

See:

[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts-squashed2 Implementation with history squashed.]
[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts Implementation with complete history]

We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the keygen_enctypes field.

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

NOTE: dump/load of policy TL data is not tested for lack of any policy elements that use TL data.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T23:04:25Z

Nico: /* Implementation */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

See:

[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts-squashed2 Implementation with history squashed.]
[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts Implementation with complete history]

We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the keygen_enctypes field.

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T22:59:20Z

Nico: /* Implementation */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

See:

[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts-squashed Implementation with history squashed.]
[https://github.com/nicowilliams/krb5/compare/kadm5_policy_exts Implementation with complete history]

TODO:

* Cherry-pick latest commits from the squashed brnach into the other, re-squash, and leave re-formatting changes to kadmin.c in a separeate commit.

We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the keygen_enctypes field.

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T22:53:17Z

Nico: /* Implementation */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T22:53:00Z

Nico: /* Description and Architecture */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T22:52:19Z

Nico: /* Description and Architecture */

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)

; max_life : holds max ticket life (not implemented at this time)

; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)

; keygen_enctypes : key/salt type list that the principal is allowed to have keys of

; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.

* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number

* Added fields to kadm5_policy_ent_

* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.

Projects/Extensible Policy

2012-07-19T22:51:50Z

Nico: New page: {{project-rel|1.11}} This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension. ==Background== kadmin's p...

{{project-rel|1.11}}

This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.

==Background==

kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.

We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").

==Description and Architecture==

We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:

; attributes : holds attributes of principals that are policy-like (not implemented at this time)
; max_life : holds max ticket life (not implemented at this time)
; max_renewable_life : holds max ticket renewable lifetime (not implemented at this time)
; keygen_enctypes : key/salt type list that the principal is allowed to have keys of
; tk_data : sequence of {type, length, octet string} values just as in principal records

User interface changes:

* The kadmin addpol and modpol commands get a new argument: -kegenenctypes keysalt-list.
* The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).

API changes:

* New kadm5 version number
* Added fields to kadm5_policy_ent_rec
* Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions

Note that as with the change in 1.8 it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner: by using TL data for future extensions we can obtain the same downgrade semantics as for the principal database.

==Implementation==

* Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
* Extend the relevant structures (see above)
* Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
* Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
* Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
* Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c

==Testing==

One test is added: tests/t_keygen_enctypes.py. All tests pass.

==Documentation==

The kadmin.M and kdb5_util.M manpages are updated.

==Release notes==

Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.