Title: #403: Add new ipa passwd-generate command
Sorry for another delay too. We have discussed this proposal again and would
like to have an ipa-advise implementation instead of IPA CLI command. There are
multiple reasons for this:
* If an IPA CLI implementation would be done, from your last comment it looks
like you would be interested in supplying a generated password to another IPA
command call, like 'ipa passwd'. However, to get access to password policy
object, one has to have administrative privileges, while it is supposed that
'ipa passwd' command is executed under user privileges. Thus, 'ipa foobar
--generate | ipa passwd' is not possible as that would require two different
auth identities run in the same session space.
* Implementation that only uses user's identity will see no password policy
settings at all. Thus it would not be able to follow any specific password
* Existing 'ipa user-add --random' and 'ipa host-add --random' which set
user/host password to a random value apply to situations where the passwords
are of one-time use and will get changed on the first use.
* Any administratively set password for IPA users will cause its change on the
first authentication attempt. This is not going to change. Thus, setting a
generated password as administrator is not going to honor the password that was
just set. As result, a sequence of events "administrator calls IPA CLI to
generate password and then sets this password to a user" is not going to work
in practice to retain the generated password.
* For system accounts we want to have an overall proper management. When it is
implemented, we can add there an option to generate passwords. Given that
system accounts aren't handled by the IPA framework right now, the source of a
policy compliant password can be anything, as additing the account is done
externally (via ldapadd/ldapmodify) with administrative privileges.
Thus, we'd still prefer to use 'ipa-advise' plugin approach. A script that
'ipa-advise' would generate, can be run on any machine. If it couldn't be run
on the target machine, it can always be run on an IPA client. An important part
of this solution is that 'ipa-advise' plugins can be run with administrative
privileges (ipa-advise is always run as root) and thus can read password policy
settings for a specific user (or a specific password policy).
See the full comment at
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code