Bug 1242959
| Summary: | Empty default sysprep password (LocalAdminPassword) | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Alon Bar-Lev <alonbl> |
| Component: | Setup.Engine | Assignee: | Shahar Havivi <shavivi> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Belka <jbelka> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | adahms, bugs, ecohen, gklein, iheim, lsurette, mgoldboi, michal.skrivanek, rbalakri, shavivi, yeylon |
| Target Milestone: | ovirt-3.6.0-rc | Flags: | rule-engine:
ovirt-3.6.0+
ylavi: planning_ack+ rule-engine: devel_ack+ pnovotny: testing_ack+ |
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| Fixed In Version: | 3.6.0-4_alpha3 | Doc Type: | Enhancement |
| Doc Text: |
Previously, the engine admin user's password was used as the default password during the Windows sysprep process. This setting was stored in the LocalAdminPassword configuration option. With this update, the LocalAdminPassword setting has been removed, and the user interface accepts the password users enter in the user interface, including empty passwords.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-04 11:23:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alon Bar-Lev
2015-07-14 13:30:15 UTC
we're now testing empty password The current behavior was not really documented anywhere. For clarity we'll rather have an empty one when one doesn't fill anything in UI, than some magic string. one more patch needed for database upgrade (In reply to Michal Skrivanek from comment #1) > we're now testing empty password > > The current behavior was not really documented anywhere. > For clarity we'll rather have an empty one when one doesn't fill anything in > UI, than some magic string. > > one more patch needed for database upgrade why? setup can encrypt empty password. just modify the patch to use "" instead of "password". Even better, we remove the LocalAdminPassword entirely. Could you please explain how would this influence customers' environments where they used to use LocalAdminPassword in vdc_options for their syspreps? https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=5dac9c3368fa7199aebbb3028a2bab361cec2072#patch5 I suppose if they won't change their work process their VMs would end with empty password even they would expect to have the password set from LocalAdminPassword option value from vdc_options. (IIUC: At least this change should be highlighted so users get informed about change of default behaviour and IIUC they would need to explicitly define password for every initial run.) There is a comment in the doc test. Removed the default password that was stored in LocalAdminPassword. ie the default login to windows is no password. This will break environment using sysprep with LocalAdminPassword value in the DB. I am not sure if LocalAdminPassword removal from the DB (and thus engine-config) was thought through (I'm OK with "unlinking" it with admin@internal password of course). This is going to be regression and it needs re-thinking. The LocalAdminPassword used to be configurable and if anybody known that, it could be used... ok, rhevm-backend-3.6.0.2-0.1.el6.noarch
LocalAdminPassword got removed from db during upgrade (3.5.5 -> 3.6.0-17) and in final sysprep there's empty passwd if not defined in initial run dialogs.
<UserAccounts>
<AdministratorPassword>
<Value><![CDATA[]]></Value>
<PlainText>true</PlainText>
</AdministratorPassword>
<LocalAccounts>
<LocalAccount wcm:action="add">
<Password>
<Value><![CDATA[]]></Value>
<PlainText>true</PlainText>
</Password>
<Group>administrators</Group>
<Name>user</Name>
<DisplayName>user</DisplayName>
</LocalAccount>
</LocalAccounts>
</UserAccounts>
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one. |