4 Replies Latest reply on Sep 28, 2012 12:35 PM by historicalshavlikcustomer

    Inconsistency in V8 shared credentials

      VMware vCenter Protect Advanced 8.0.1
          Build: 3965
      I'm actually working wit a trial version before upgrading our v7.8 environment.
      The new shared credential system looks like the way to solve the multi user management we have so after getting used with the new version, I've logged on with a different user to check what settings are shared and what needs to be set individually.

      If at first look credentials seemed to be shared, I found that it depends where I'm looking.

      With the initial login, I created and shared the following credential (naming is pretty obvious):
      - SrvAdmin
      - WksAdmin
      - ProxyUser
      - DSUser

      Those are available for this login in the following parts:
      - Credentials Manager
      - Options / Proxy / Console credentials
      - Options / Proxy / Service credentials
      - Options /ITScripts / Local Administrator credential ...
      - Machine groups / Group Set credentials
      - Machine groups / Members Set Admin credentials
      - Distribution Servers / Machine Credentials
      - Distribution Servers / Console Credentials
      - Schedule Task Manager / Scheduler Servide / Install/Uninstall

      Once logged with the second user the credentials availability is the following:
      - Credentials Manager: Empty
      - Options / Proxy / Console credentials: Empty
      - Options / Proxy / Service credentials: Full List
      - Options /ITScripts / Local Administrator credential ...: Full List
      - Machine groups / Group Set credentials: Empty
      - Machine groups / Members Set Admin credentials: Empty
      - Distribution Servers / Machine Credentials: Full List
      - Distribution Servers / Console Credentials: Full List
      - Schedule Task Manager / Scheduler Servide / Install/Uninstall: Empty

      Of course, where the list is unavailable, the settings is back to None.

      When trying to recreate one of those shared credential from the second login and check the Shared option I receive a warning message:
      Another user has created a credential with the same name and marked it as shared. If you save this credentail as shared, you will overwrite their shared credential.
      -> Overwrite other user's shared credential
      -> Save this credentail without sharing it

      After saving it, it's the only one available in the list.
      Deleting it from the second login remove it from the list. For the initial user the account remains but is no longer shared.

      After sharing an extra test user from login 2 then switching back to login 1, it appears in the combo lists but not in the Credentials Manager window.

      This is what I experienced with only one console so I expect additional undesired behaviour once usins two consoles as it is in the production environment.

      As 7.8 support is about to expire, I have to upgrade the prod before it so I can wait a fix but there is not much time.
        • 1. Re: Inconsistency in V8 shared credentials
          Credentials are stored, encrypted, on a per-user basis. Setting a stored credential to 'shared' allows the credential to be made available to the machine's service accounts for use. Credentials are not intended to be shared between users, and each unique user will need to create their own 'set' of credentials. Due to the way in which the credentials are 'shared' with the services, the naming convention used for shared credentials will need to be unique for each user (as indicated by the message received when naming the credential).

          If you still feel that there is an issue which you would  like us to address, we would urge you to contact Support directly for further assistance.
          • 2. Re: Inconsistency in V8 shared credentials
            After digging into the help, it is now clearer fro me how shared credentials are intended to be used.
            I have to admit that it first seemed so obviously the solution to my recurring credential management issue that I didn't expect it to work another way.

            Still I'm a bit confuse about why some can be used for some but not for others:
            - In the proxy options, why is it available for the service but not the console
            - in the credential manager, I expect the shared credentials to appear as it could be an issue as only the creator account can update them easily

            Anyway, it will still be a great improvement for me.

            So now my concern is more about how to properly use shared and unshared creds but keeping the per user custom creation as low as possible in a multi user environment.

            Here is what I plan to implement:
            - Default Credentials: UserX (not shared, maintained per user, cred name not generic)
            - Machine groups / Group Set credentials: None
            - Machine groups / Members Set Admin credentials:
            - Distribution Servers / Machine Credentials: DSUser (shared, generic account, have limited UNC access only)
            - Distribution Servers / Console Credentials: DSUser (shared, generic account, have limited UNC access only)
            - Schedule Task Manager / Scheduler Servide / Install/Uninstall: UserX (not shared, maintained per user, cred name not generic)
            - Options / Proxy / Service credentials:  ProxyUser (shared, generic account, have limited web access only)
            - Options /ITScripts / Local Administrator credential ... :
            UserX (not shared, maintained per user, cred name not generic)

            The one which is a bit problematic for me would be this one:
            - Options / Proxy / Console credentials
            My first choice would be to use
            ProxyUser but it can't be as a shared cred can't be used for this setting.
            Second choice would be 
            UserX        but as our policy is to have a distinct account for IT task (admin accounts) and a common account (Mail, Internet, Office....) for non-IT tasks, this one won't go through the proxy.

            I can either get everyone create their own non shared ProxyUser which will match the shared ProxyUser cred, which mean that every user needs to update its own cred when password change occurs.
            Or I have to grant admin accounts internet access (even limited) which will break our compliance rules.

            If you could help to find the best way to implement it.

            PS: 2 extra questions:
            - could you explain the difference between the Proxy console cred and the Proxy Service cred
            - as we use 2 console pointing to the same dB, will user A on console 2 see the unshared cred he created on console 1 ?

            Once again, the support provided here is greatly appreciated.
            • 3. Re: Inconsistency in V8 shared credentials
              Credential storage is architected so as to provide the greatest level of security possible for each user, while still allowing simplicity of usage and management (although this can present some challenges when  multiple users are involved (such as in the circumstances which you have described). We have made numerous changes to this architecture over the years, and the credential manager has thus far proven to be our best implementation to date.

              Credential usage and storage can still prove confusing at times, and can be very difficult to explain in an economy of words.
              Although you have certainly provided a great deal of descriptive detail, it is not entirely clear how to provide you with the most useful information. We would certainly love to assist you further in your implementation, and would urge you to contact Support directly (i.e. via telephone) for immediate assistance. Support contact telephone numbers are as follows:


              • 4. Re: Inconsistency in V8 shared credentials
                Thanks for the feedback, I'll get in touch with the support.
                Unfortunately the trial expired today so I need to renew it first to keep working int the lab.