Skip to main content

Enforce SHA-2 on administrator account passwords

Contributors netapp-ahibbard
PDFs

Administrator accounts created prior to ONTAP 9.0 continue to use MD5 passwords after the upgrade, until the passwords are manually changed. MD5 is less secure than SHA-2. Therefore, after upgrading, you should prompt users of MD5 accounts to change their passwords to use the default SHA-512 hash function.

About this task

The password hash functionality enables you to do the following:

  • Display user accounts that match the specified hash function.

  • Expire accounts that use a specified hash function (for example, MD5), forcing the users to change their passwords in their next login.

  • Lock accounts whose passwords use the specified hash function.

  • When reverting to a release earlier than ONTAP 9, reset the cluster administrator's own password for it to be compatible with the hash function (MD5) that is supported by the earlier release.

ONTAP accepts pre-hashed SHA-2 passwords only by using NetApp Manageability SDK (security-login-create and security-login-modify-password).

Steps

  1. Migrate the MD5 administrator accounts to the SHA-512 password hash function:

    1. Expire all MD5 administrator accounts: security login expire-password -vserver * -username * -hash-function md5

      Doing so forces MD5 account users to change their passwords upon next login.

    2. Ask users of MD5 accounts to log in through a console or SSH session.

      The system detects that the accounts are expired and prompts users to change their passwords. SHA-512 is used by default for the changed passwords.

  2. For MD5 accounts whose users do not log in to change their passwords within a period of time, force the account migration:

    1. Lock accounts that still use the MD5 hash function (advanced privilege level): security login expire-password -vserver * -username * -hash-function md5 -lock-after integer

      After the number of days specified by -lock-after, users cannot access their MD5 accounts.

    2. Unlock the accounts when the users are ready to change their passwords: security login unlock -vserver svm_name -username user_name

    3. Have users log in to their accounts through a console or SSH session and change their passwords when the system prompts them to do so.