Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 607827

Summary: Anaconda needs separate username/password fields for iSCSI Discovery Sessions
Product: Red Hat Enterprise Linux 6 Reporter: Dax Kelson <dkelson>
Component: anacondaAssignee: Ales Kozumplik <akozumpl>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: atodorov, hdegoede, jzeleny, mganisin
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-13.21.84-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 12:30:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dax Kelson 2010-06-25 00:11:33 UTC
Description of problem:

iSCSI supports authentication at two different phases:

1. Discovery Session
2. Operational Session

The username and password for may be (and usually is) different.

Additionally, mutual authentication can be enabled for target -> initiator authentication.

This leads to many different possible scenarios. Anaconda is currently broken in that it only supports a (weak sauce) subset.

Scenario A - (very common - aka best practice):
Discovery Authentication enabled
Operation Session Authentication enabled, with DIFFERENT username/password
Mutual Authentication enabled or rarely disabled

Scenario B - (very common due to tgt limitation):
Discovery Authentication disabled
Operation Session Authentication enabled
Mutual Authentication enabled 

Scenario C - (common for insecure folks):
Discovery Authentication enabled
Operation Session Authentication enabled, with SAME username/password
Mutual Authentication enabled or possibly disabled

Scenario D - (common in non-production/testing environments):
Discovery Authentication disabled
Operation Session Authentication disabled

Most security conscious folks WANT to A but are forced to B when working with a RHEL target (because tgt doesn't currently do Discovery Authentication).

Anaconda only asks for a single pair of usernames and passwords (4 fields) and attempts to use it BOTH for Discovery and Session. This means that only Scenarios C and D are supported and not the desired A or B scenarios.

To fix this, Anaconda needs to ask for TWO pairs of usernames and passwords (8 fields) so that Discovery Session and Operation Session authentication can be configured separately. 

This problem exists in RHEL5 and RHEL6 (I checked beta 1)

Comment 2 RHEL Program Management 2010-06-25 00:42:52 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Hans de Goede 2010-06-25 06:37:39 UTC
Thanks for the bug report.

I agree with your analysis that we should allow using separate passwords for
discovery and target log in. This is however not something which we can fix for RHEL-6.0. I'll propose changing this for RHEL-6.1 .

Comment 5 Ales Kozumplik 2010-10-19 13:49:57 UTC
Fixes are available rawhide now, see bug 469382.

Comment 6 RHEL Program Management 2010-10-29 21:30:50 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 9 Ales Kozumplik 2010-11-23 13:20:07 UTC
Patches for separate discovery/login credentials for both the GUI and the TUI have been merged, most importantly:

66302e6bb41805c368b46647206328cfd86509e5 (GUI)
193a7af18f8fb01d5757802d8ee82a168db2b0be (TUI)

Comment 11 Alexander Todorov 2011-03-30 11:52:02 UTC
In anaconda 13.21.107 both text and GUI mode there is the option to specify different credentials for the discovery and login authentication when adding iSCSI targets. The user is also able to re-use the credentials from the discovery step when logging into the target.

Comment 12 errata-xmlrpc 2011-05-19 12:30:33 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0530.html