Bug 1387024

Summary:	changing admin password via command line breaks existing accounts
Product:	Red Hat CloudForms Management Engine	Reporter:	Roderick Moore <rmoore>
Component:	Appliance	Assignee:	Gregg Tanzillo <gtanzill>
Status:	CLOSED WORKSFORME	QA Contact:	luke couzens <lcouzens>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.6.0	CC:	abellott, jhardy, ncarboni, obarenbo
Target Milestone:	GA
Target Release:	cfme-future
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	cli
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-11 21:37:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Roderick Moore 2016-10-20 01:25:11 UTC

Description of problem: I tried to create a CF v5.6.1 appliance with an exported database. After importing the database, I verified that I could log in as cloudops and clouduser. I then ran a command to change the admin password. After doing so I could no longer log in as cloudops or clouduser. I repeated the process with the v5.6.0 appliance and was able to change the admin password without breaking clouduser or cloudops. 


Version-Release number of selected component (if applicable):vsphere appliance v5.6.1


How reproducible:


Steps to Reproduce:
1. import CF v5.6.1 appliance
2. import the offline database provided by the management bu on the following mojo page: https://mojo.redhat.com/docs/DOC-1093580
3. verify that you can login as cloudops with a password of Redhat1!
4. after importing the database, follow the steps to change the admin password in CF 4.x as detailed in the following knowledgebase article: https://access.redhat.com/solutions/801103
5. attempt to login as cloudops

Actual results: incorrect password error encountered


Expected results:


Additional info: same procedure works with CF v5.6.0

Comment 2 Roderick Moore 2016-10-31 15:51:48 UTC

I've repeated this process with the 5.6.2 appliance and it works as expected. In all honesty, I think that this issue may have been caused by disabling the webservices role when attempting to connect to the appliance.

Comment 3 Nick Carboni 2017-01-11 21:37:24 UTC

Closing this as the bug can not be reproduced as originally described.

I believe the failure to log in when the webservices role is disabled is expected behavior, but that should probably be a separate bug if that is an issue.