<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font size="-1">Hey Vernon,</font></p>
    <p><font size="-1">There are a few points about IPMI User accounts
        where more details are needed.<br>
      </font></p>
    <p><font size="-1">a) IPMI User configuration(password/privilege) is
        done for a per channel basis. How do you plan to implement where
        the same user would have different passwords/privileges?</font></p>
    <p><font size="-1">b) IPMI user accounts are mapped to User ID, and
        all user account related commands refer to user id to identify
        an account. I hope we need to consider that when we design.</font></p>
    <p><font size="-1">c) User ID 1 account has no user name. Would we
        support this account?</font></p>
    <p><font size="-1">d) Can you add API's to map enable/disable IPMI
        accounts, so that IPMI user accounts can be enabled/disabled by
        retaining all other properties?</font></p>
    <p><font size="-1">Regards,</font></p>
    <p><font size="-1">Tom</font><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On Wednesday 06 December 2017 06:19 AM,
      Vernon Mauery wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20171206004931.GI113334@mauery">On
      04-Dec-2017 05:02 PM, Vernon Mauery wrote:
      <br>
      <blockquote type="cite">On 04-Dec-2017 05:06 PM, Brad Bishop
        wrote:
        <br>
        <blockquote type="cite">multi configuration images / runtime
          configurability
          <br>
          user management
          <br>
          secure coding guidelines
          <br>
          <br>
          —————————
          <br>
          Monday, 10:00pm EDT
          <br>
          888-426-6840
          <br>
          password: 85891389
          <br>
        </blockquote>
        <br>
        For the discussion on user management.
        <br>
        <br>
        Overview:
        <br>
        1. User management is done via PAM.
        <br>
        2. If IPMI is being used, PAM loads the pam_ipmi.so password
        module.
        <br>
         a. pam_ipmi.so intercepts password changes and saves the
        password
        <br>
            for IPMI-enabled users to a file that can be read at a later
        time
        <br>
            to initiate an RMCP+ session. (encrypted or obfuscated with
        a      per-BMC key so no passwords are written directly in
        flash.)
        <br>
         b. pam_ipmi.so implements a method to decrypt passwords and
        provide
        <br>
            them to host-ipmi (for test password command) and net-ipmi
        (for
        <br>
            session initiation)
        <br>
        3. If a user is not enabled for IPMI, their password will not be
        saved
        <br>
         in the ipmi database, and thus must be reset if/when that user
        gains
        <br>
         IPMI capability.
        <br>
        4. If a user loses IPMI capability, their password is reset to
        force a
        <br>
         password change so their password is secure again.
        <br>
        5. Capabilities is done via unix groups
        <br>
         a. Groups like ipmi, webserver, redfish, ssh, sol can provide
        login      or 'channel' access.
        <br>
         b. Groups like user-manager, media, power, sensor, etc., can
        provide
        <br>
            fine-grained access for various capabilities. Providers
        of      capabilities should check to see that accessors (users)
        have the      required permission.
        <br>
        6. Admin-defined 'super-groups'
        <br>
         a. Provide a set of pre-defined groups of capabilities that can
        be
        <br>
            assigned to users: Admin, User, Operator or similar that
        each have
        <br>
            groups associated with them.
        <br>
         b. Changes to groups via APIs can make sure that if a user
        is      assigned to a 'super-group' will stay assigned to the
        sub-groups
        <br>
         c. Changes made to users via manual commands may override API
        groups
        <br>
      </blockquote>
      <br>
      Items yet to be decided:
      <br>
      1. How providers of services export the service/permission pairs
      so the user manager can manage the permission groups.
      <br>
      2. How to manage the permissions groups (is there a PAM group
      mechanism?)
      <br>
      3. How to create users (call adduser?)
      <br>
      4. Do we force users to have different passwords for RMCP+ and
      other logins because RMCP+ passwords are insecurely stored? Or is
      this a policy thing that we allow system administrators to choose?
      <br>
      <br>
      <br>
      --Vernon
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Methods:
        <br>
          1. CREATE_USER
        <br>
              Privilege-required: USER-MANAGER
        <br>
              Args:
        <br>
                  UserName - STRING (16 bytes only - else role change to
        IPMI can't be done)
        <br>
                  Password - Byte Array (Max of 20 bytes if IPMID is
        chosen. For
        <br>
                             others can send more bytes, but change role
        to IPMI will
        <br>
                             request password again under 20 bytes)
        <br>
                  Roles - STRING with comma separated
        <br>
              Return:
        <br>
                  SUCCESS ERR_USERNAME_EXIST ERR_PASSWORD_FAILS
        ERR_ROLE_FAILS
        <br>
                  ERR_PASSWORD_ROLE_FAIL ERR_NO_RESOURCE ERR_UNKNOWN
        <br>
                  ERR_AUTHORIZATION_FAIL
        <br>
        <br>
          2. DELETE_USER
        <br>
              Privilege-required: USER-MANAGER
        <br>
              Args:
        <br>
                  UserName - STRING
        <br>
              Return:
        <br>
                  SUCCESS ERR_USERNAME_NOT_EXIST ERR_UNKNOWN
        ERR_AUTHORIZATION_FAIL
        <br>
        <br>
          3. CHANGE ROLE / CHANGE_PASSWORD (OTHERS)
        <br>
              Privilege-required: USER-MANAGER
        <br>
              Args:
        <br>
                  UserName - STRING
        <br>
                  New Password (if changed) - Byte Array
        <br>
                  New Role (if changed) - Array of STRING
        <br>
              Return:
        <br>
                  SUCCESS ERR_USERNAME_NOT_EXIST ERR_UNKNOWN
        ERR_AUTHORIZATION_FAIL
        <br>
                  ERR_PASSWORD_FAILS ERR_PASSWORD_ROLE_FAIL
        ERR_NO_RESOURCE
        <br>
        <br>
          4. CHANGE_PASSWORD (SELF)
        <br>
              Privilege-required: Any Valid user
        <br>
              Args:
        <br>
                  New Password - Byte Array
        <br>
              Return:
        <br>
                  SUCCESS ERR_PASSWORD_FAILS ERR_PASSWORD_ROLE_FAIL
        ERR_UNKNOWN
        <br>
        <br>
          5. LIST_USER_DETAILS
        <br>
              Privilege-required: USER-MANAGER
        <br>
              Args:
        <br>
                  NULL
        <br>
              Return:
        <br>
                  Array of:
        <br>
                      USER_NAME (String)
        <br>
                      ROLES (String)
        <br>
        <br>
        Signals:
        <br>
          1. UPDATED_USER_SIGNAL
        <br>
              Args:
        <br>
                  UserName of updated user
        <br>
                  UpdateType:
        <br>
                      Role changed / User Deleted / User created /
        Password Changed etc.
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>