Please review/comment: [389 Project] #48833: 389 showing inconsistent values for shadowMax and shadowWarning in 1.3.5.1

[Noriko Hosoi]

https://fedorahosted.org/389/ticket/48833

There are 2 proposals.  I'd like to have your thoughts which one would 
be preferable.

https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
git patch file (master) -- second proposal -- this patch allows the 
password policy values and shadow account values in sync.
If we choose this option, DS Console Password Policy panel needs to be 
modified to support the larger value than INT_MAX.

https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
git patch file (master) -- first proposal -- shadow account values won't 
be touched if they already exist in an entry.
Restrictions:
1. If objectclass: shadowaccount is set and there is no shadow account 
values in an entry, the shadowmax, min, and warning are filled by 
calculating them from the password policy values.  The maximum value of 
calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)).
2. Even if the values of the password policy are updated, shadow account 
values are not effected.

[William Brown]

On Tue, 2016-05-31 at 17:48 -0700, Noriko Hosoi wrote:
>  https://fedorahosted.org/389/ticket/48833
>  
>  There are 2 proposals.  I'd like to have your thoughts which one would 
>  be preferable.
>  
>
> https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
>  git patch file (master) -- second proposal -- this patch allows the 
>  password policy values and shadow account values in sync.
>  If we choose this option, DS Console Password Policy panel needs to be 
>  modified to support the larger value than INT_MAX.
>  
>
> https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
>  git patch file (master) -- first proposal -- shadow account values won't 
>  be touched if they already exist in an entry.
>  Restrictions:
>  1. If objectclass: shadowaccount is set and there is no shadow account 
>  values in an entry, the shadowmax, min, and warning are filled by 
>  calculating them from the password policy values.  The maximum value of 
>  calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)).
>  2. Even if the values of the password policy are updated, shadow account 
>  values are not effected. 

I'm for option 1. I believe our shadow and password policy should be in sync. This
prevents admins making mistakes, and allows
clients to gain functionality. 

There is no reasonable benefit IMO to having shadow and ldap policy out of sync. 

It also means that a seamless upgrade occurs, where existing sites, with existing (bad)
shadow data, well begin to get the
benefit of a now *working* shadow value.


Thanks,

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[Noriko Hosoi]

Thanks for your comments, William.

On 05/31/2016 07:22 PM, William Brown wrote:
>  On Tue, 2016-05-31 at 17:48 -0700, Noriko Hosoi wrote:
> > https://fedorahosted.org/389/ticket/48833
> >
> > There are 2 proposals.  I'd like to have your thoughts which one would
> > be preferable.
> >
> >
> https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
> > git patch file (master) -- second proposal -- this patch allows the
> > password policy values and shadow account values in sync.
> > If we choose this option, DS Console Password Policy panel needs to be
> > modified to support the larger value than INT_MAX.
> >
> >
> https://fedorahosted.org/389/attachment/ticket/48833/0001-Ticket-48833-38...
> > git patch file (master) -- first proposal -- shadow account values won't
> > be touched if they already exist in an entry.
> > Restrictions:
> > 1. If objectclass: shadowaccount is set and there is no shadow account
> > values in an entry, the shadowmax, min, and warning are filled by
> > calculating them from the password policy values.  The maximum value of
> > calculated shadowMax is 24855 (== 2^31-1 / (24 * 60 * 60)).
> > 2. Even if the values of the password policy are updated, shadow account
> > values are not effected.
>
>  I'm for option 1. I believe our shadow and password policy should be in sync. This
> prevents admins making mistakes, and allows
>  clients to gain functionality.
>
>  There is no reasonable benefit IMO to having shadow and ldap policy out of sync.
I'm worried there could be administrators who want to have a full 
control on the shadow values with no interest on the DS password 
policy...  I guess the reporter of this ticket is one of them.

Thanks,
--noriko
>  It also means that a seamless upgrade occurs, where existing sites,
> with existing (bad) shadow data, well begin to get the
>  benefit of a now *working* shadow value.
>
>
>  Thanks,
>
>
>
>  --
>  389-devel mailing list
>  389-devel(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/admin/lists/[e-mail]...