VSC 5 - Account locked when try to access or edit Backup Jobs

[haven2008]

Hi all,

running vSphere 5.5 and found an Issue.

when i try to access, edit a Backup Job or click the Backup Section in vSphere Web Client, the Account comes locked immediately.

this Account is a Domain Account with full Privilege to Datacenter and all Objects in vSphere Client

i was able to create Backup Jobs for any existing VM and the Jobs running fine in the Background.

Currently, i could not found what exact the Problem is.

Mysterious . . .

cheers,

Mario

[haven2008]

some more Informations :

NetApp Ontap 8.2 - 7-Mode

VMware 5.5

NetApp VSC 5.0X6

Domain Account has Admin Rights to NetApp and vCenter Administrator Role.

cheers,

[AdamBergh_Veeam]

I am also seeing this issue. VSC is causing the domain account of the logged in user in the VMware Web Client to become locked out. This is a pretty big problem. Any one have a clue on what's causing this?

-Adam

[kingj]

I am working on a similar issue internally and here is what I know that might help:

Symptom: Account used to login to vCenter web GUI is locked out in AD when VSC is used.

Troubleshooting:

 - Veryfy that SMVI/VSC services are using local system account to run (VSC was should be administrator@vsphere.local with vCenter)
 - Stop SMVI/VSC services
 - Set SVMI/VSC services to run as an AD service account
 - Restart SMVI/VSC services
 - Re-register VSC plugin with vCenter server with credentials for an AD account.
 - If issue continues, open a case with NetApp Support and provide full AD event logs showing logins leading up to account being locked to from VSC)

This procedure is now defunct.  (5/8/14)  It's a known bug  http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=821600

Message was edited by: Jeff King

[CANDERSSON1982]

Hello!

I'm also having this problem. I installed the production release of vsc 5.0 earlier this week. My AD account is being locked immediately when I access the Backup Jobs section. I have full administrator privilegies in vsphere/vsc as well.  I've tried the mentioned possible solution in this post, which didn't help. Any other ideas?

cheers, Christian

[CANDERSSON1982]

There are no problems with lockouts when I use a @vsphere.local account instead. It only occurs with AD admin accounts.

-Christian

[haven2008]

i can confirm when using the vsphere system account i can used the VM Guest Backup Section.

but this is still not working when you have setup Role based Management and give an AD Account Restore Rights to VMs.

it seems to be an permission Issue, because just the Creator (or vSphere System Account) of the Backup Jobs can execute Restores.

VM Backups running fine in the Background until they are not touched from any ohter account.

also found the same Issue when using a local Server account, it`s locked immediately too.

however, still have no solution but hope to find a solution . . .

-Mario

[CANDERSSON1982]

This is what my domain controller says repeatedly when I enter the VSC´s Backup Jobs with my AD domain account:

The error code 0xc00000x6a means that the validation failed because my account is using a bad password. I know for sure that the password is not bad! It works everywhere else.

It seems like a software bug to me...

Well, I´ve created a case to Netapp about this issue. Hopefully they will come up with a solution.

-Christian

[trftech01]

Same issue. Any user who launches the vSphere web client and logs in using their AD account soon has their account locked. I have a ticket open with NetApp, but here's what I'm seeing in smvi.log that looks to be the culprit (%Program Files%\NetApp\Virtual Storage Console\log). AD user omitted but in bold. AD lockout times match up with log entry times.

[2014-04-21 10:52:39,210] [qtp1348652814-27] [DEBUG] inside getBackupJobCount : moref = VirtualMachine:vm-6132

[2014-04-21 10:52:39,241] [qtp1348652814-27] [DEBUG] Instantiating service url 'https://localhost:8043/smvi/services/SnapManager' for class 'com.netapp.smvi.api.SnapManagerService' using user 'USER'

[2014-04-21 10:52:39,787] [qtp1348652814-27] [DEBUG] SmviApiServiceImpl.getBackupJobCount() : Calling a backup job list web service

[2014-04-21 10:52:40,739] [qtp1348652814-27] [DEBUG] SmviApiServiceImpl.getBackupJobCount() : Job list OPERATION ID: e488c0d616e53d84118c2523fe923e83

[2014-04-21 10:52:41,987] [qtp1348652814-27] [DEBUG] result.id e488c0d616e53d84118c2523fe923e83result.state  RUNNING

[2014-04-21 10:52:43,141] [qtp1348652814-27] [DEBUG] result.id e488c0d616e53d84118c2523fe923e83result.state  COMPLETE

[2014-04-21 10:52:43,656] [qtp1348652814-27] [DEBUG] inside getBackupCount : moref = VirtualMachine:vm-6132

[2014-04-21 10:52:43,687] [qtp1348652814-27] [DEBUG] Instantiating service url 'https://localhost:8043/smvi/services/SnapManager' for class 'com.netapp.smvi.api.SnapManagerService' using user 'USER'

[2014-04-21 10:52:44,171] [qtp1348652814-27] [DEBUG] SmviApiServiceImpl.getBackupCount() moref VirtualMachine:vm-6132

[2014-04-21 10:52:44,311] [qtp1348652814-27] [DEBUG] SmviApiServiceImpl.getBackupCount() ID cd1a1669d0b021233115db2a3d98dcdd

[2014-04-21 10:52:44,701] [qtp1348652814-24] [DEBUG] inside getBackupJobCount : moref = VirtualMachine:vm-6132

[2014-04-21 10:52:44,717] [qtp1348652814-24] [DEBUG] Instantiating service url 'https://localhost:8043/smvi/services/SnapManager' for class 'com.netapp.smvi.api.SnapManagerService' using user 'USER'

[2014-04-21 10:52:45,606] [qtp1348652814-24] [DEBUG] SmviApiServiceImpl.getBackupJobCount() : Calling a backup job list web service

[2014-04-21 10:52:45,777] [qtp1348652814-27] [DEBUG] result.id cd1a1669d0b021233115db2a3d98dcddresult.state  COMPLETE

[2014-04-21 10:52:45,949] [qtp1348652814-24] [DEBUG] SmviApiServiceImpl.getBackupJobCount() : Job list OPERATION ID: 25a60a36f51b83250ebf47715eaa8c8a

[2014-04-21 10:52:47,166] [qtp1348652814-24] [DEBUG] result.id 25a60a36f51b83250ebf47715eaa8c8aresult.state  COMPLETE

[2014-04-21 10:52:47,369] [qtp1348652814-24] [DEBUG] inside getBackupCount : moref = VirtualMachine:vm-6132

[2014-04-21 10:52:47,400] [qtp1348652814-24] [DEBUG] Instantiating service url 'https://localhost:8043/smvi/services/SnapManager' for class 'com.netapp.smvi.api.SnapManagerService' using user 'USER'

[2014-04-21 10:52:47,899] [qtp1348652814-24] [DEBUG] SmviApiServiceImpl.getBackupCount() moref VirtualMachine:vm-6132

[2014-04-21 10:52:48,008] [qtp1348652814-24] [DEBUG] SmviApiServiceImpl.getBackupCount() ID 474ea80f9a442ae4cebdd4569f510032

[2014-04-21 10:52:49,319] [qtp1348652814-24] [DEBUG] result.id 474ea80f9a442ae4cebdd4569f510032result.state  COMPLETE

[2014-04-21 11:16:28,353] [qtp1348652814-23] [DEBUG] inside getBackupJobCount : moref = null

[trftech01]

Turning off the service NetApp SnapManager for Virtual Infrastructure seems to be the workaround for right now. I'll post any more info I get.

[AlexWuFromPMC]

See this article. 

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2083566

[lucienorrin]

I am having the same issue as described in the OP.

I tried Jeff King's solution from above with no luck. Disabling the SMVI service did allow us to continue working within vCenter without getting locked out, but prevents making any changes to backups or performing any restores.

Any solutions?

[kingj]

Hi Lucien:

We are actively still working on this, however, try this newer procedure.  It may yield a bit more movement forward to a solution:

The Procedure:

•       Stop the VSC service

•       Delete the following files controllerconfigurations.dat, info.x, info.xout

•       Create a new RBAC user using this tool: https://communities.netapp.com/docs/DOC-19074/

•       The “vscadmin” user is invalid as an admin for VSC or other ZAPI products

•       Restart the VSC service

•       Wait until all discoveries complete

•       Modify credentials of all controllers/clusters using the new RBAC admin user created above

•       Confirm whether the account becomes locked out while using the plugin

This procedure is now defunct.  (5/8/14)  It's a known bug  http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=821600

[CANDERSSON1982]

Hi Jeff!

I'm already using the RBAC admin (created with the tool) for the controllers. The AD account is still being locked though.

Regards, Christian

[CANDERSSON1982]

When I enter VSC and the Backup Jobs, this is what the vxpd.log says exactly on that time point:

2014-04-22T09:22:21.424+02:00 [13516 error 'SoapAdapter']

--> Required parameter password is missing

-->

--> while parsing call information for method Login

--> at line 1, column 81

-->

--> while parsing SOAP body

--> at line 1, column 70

-->

--> while parsing SOAP envelope

--> at line 1, column 0

-->

--> while parsing HTTP request for method login

--> on object of type vim.SessionManager

--> at line 1, column 0

[STEPHAN_H]

Hello,

same Problem! Any solution yet?

greetz

[alexmattes]

Hello folks,

I had the same issue after upgrading the VSC from version 4.2.1 to 5.0. My issue was gone after I set the default credential for the storage systems again. You can find this setting in the webclient when clicking on the NetApp-Icon -> Configuration -> Set default credentials

After setting the correct credentials for your storage systems please run the a discovery task afterwards. (Storage Systems -> Update all)

There was a similar issue in earlier releases. Your AD-Account was locked once you entered invalid credentials for the storage systems.

Please let me know if it solves your issue.

Cheers!

[STEPHAN_H]

Hello,

Thanks for help but it doesnt work for me.

The think i worry about is, that the backup work fine and creating new

jobs too. But the domain account im logged in the WebClient getting locked

emediatly. This happens only with domain accounts, not with

administrator@vsphere.local.

The bad request comes from the Server where is the VSC installed, not from

vCenter Server (appliance). On the Server VSC is installed (Windows) i can

see the bad request in the logfile.

Sry for my bad english!

Mit freundlichen Grüßen

Stephan Hübenthal

Von: alexmattes <xdl-communities@communities.netapp.com>

An: Stephan Hübenthal <stephan.huebenthal@bg-phoenics.de>

Datum: 06.05.2014 13:55

Betreff: - Re: VSC 5 - Account locked when try to access

or edit Backup Jobs

Re: VSC 5 - Account locked when try to access or edit Backup Jobs

created by alexmattes in VMware - View the full discussion

Hello folks,

I had the same issue after upgrading the VSC from version 4.2.1 to 5.0. My

issue was gone after I set the default credential for the storage systems

again. You can find this setting in the webclient when clicking on the

NetApp-Icon -> Configuration -> Set default credentials

After setting the correct credentials for your storage systems please run

the a discovery task afterwards. (Storage Systems -> Update all)

There was a similar issue in earlier releases. Your AD-Account was locked

once you entered invalid credentials for the storage systems.

Please let me know if it solves your issue.

Cheers!

Reply to this message by replying to this email -or- go to the message on

NetApp Community

Start a new discussion in VMware by email or at NetApp Community

[CANDERSSON1982]

Hello!

I have a case with the Netapp support and they have confirmed that this is a bug (Bug ID 821600).

You may follow it here:   http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=821600

At the present time there is no public information available. This is where it will be published when more information becomes available.

At the moment the only workaround is to use a local account to login to vCenter.

Regards, Christian

[kingj]

Thanks Christian for this post! 

What we need is everyone on this thread to do is create a case (if you haven't already) with NetApp Support and explain that you have likely encountered Bug 821600.

What this does is helps us put more resources from engineering on the problem to get it fixed. 

The more people that officially call in to our support line and get a case set up, the more likely it will be fixed faster!

Cheers all,

-Jeff

[ALAN_COBB]

Same issue here. I've found that it happens anytime a NetApp view or screen loads. More specifically, it is during the several seconds it is taking for them to load. It also happens as soon as you click on “vCenter” in the web client. During this time you will notice the NetApp “Storage Systems” and “Backup Jobs” are blank or dashes. After several seconds they will show the number of NetApps and Backup jobs.

I assume this delay is when it's busy retrying (something) with your domain account name and an incorrect password. I say "something" since the screens will load. If the screens still load OK, it could probably skip the step that's busy locking out your account.

You will have to keep unlocking your account in between switching to the different VSC screens. This is a major issue and am a bit surprise the version was released or not fully tested.

I signed up for the Bug watch and will see if NetApp has a work around. Until then, we will try to avoid using the vSphere Web Client. Thankfully the backups still work.