Add new ipa passwd-generate command

[redhatrises]

This PR adds a new command line option ipa passwd-generate that uses the refactored ipa_password_generate() function. This is useful for generating secure passwords for service and system accounts or passwords for applications that may not be able to handle all character types. This could also be useful in the future for generating a temporary password for any portal efforts.

[Akasurde]

You can set default value in get function itself.

options.get('entropy', 0)

[stlaz]

Both are wrong approaches. Any subclass of Param has a default argument for such cases.

[Akasurde]

if get with default value is used then this block of code is not required.

[Akasurde]

Adding an example of 'how-to-use` will help user.

[stlaz]

Hello and thank you for the contribution! However, I do not see what's in this for us. I do not think FreeIPA is intended to be used as a password generator. There are other tools that do this just right, pwgen being just an example.

[abbra]

@redhatrises, could you please explain more why you need this command as it is?

FreeIPA allows to have multiple password policies. If you want to generate passwords that conform to a particular policy, it would be more reasonable to retrieve the password policy and use it to supply as arguments of the password generator.

The generated password does not need to be transferred over the network. As you are adding a command to IPA, it could be a client-side plugin because Python client side code always has access to ipapython.util module.

There could be multiple password generators. For example, on Linux systems you can simply use pwqgen utility from passwdqc package to generate passwords compatible with FreeIPA password policies. Granted, a configuration file needs to be created that translates a FreeIPA password policy but this is at least something that a command in IPA could do on the client side after fetching a policy.

If the password generation is based on a particular policy and is moved to the client side, why not creating a plugin to ipa-advise instead? It would actually generate a script that calls pwqgen or other generator tool. This would be more useful to other environments as the script would also contain a reference to the password policy parameters and can be run independent of the FreeIPA infrastructure.

Let me know what do you think about it.

[redhatrises]

Sorry for the delayed response. Been a little ill, so hopefully this makes sense.

This is useful for environments where utilities like pwgen may not be allowed to be installed due to compliance/environment reasons. It is also especially useful for handling service accounts whose passwords have to be changed regularly or for managing passwords for shared user accounts where user's only access to the accounts is through sudo. Plus if no one is logging into the accounts, service or user, which are required to have passwords change regularly, why not have the authentication tool come up with one that is sufficient for the organizational requirements (28 different random different passwords) without having to come up with a password or having to remember x utility (which may not be allowed to be installed) from doing it?

However, the final iteration of this (which I have not added yet) is to add --user and/or --service-account to handle changing those passwords with a generated password for user accounts or service accounts. Another option would be to just add an option that behaves the same way such as --generate to ipa passwd e.g. ipa passwd user1 --generate

[abbra]

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 policy.
• 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).

[redhatrises]

Thanks @abbra

The command would have been ipa passwd-generate --user user1 without piping any commands to it and would have kept the initial password as well as only run as an IPA admin. I also had forgotten about using --random. Will look at ipa-advise at some point in the future. Closing this PR for now.