Bug 1247787 - Cannot configure external authentication (httpd) with non-generic server domain
Cannot configure external authentication (httpd) with non-generic server domain
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
5.4.0
Unspecified Unspecified
high Severity high
: GA
: 5.6.0
Assigned To: Tim Wade
amogh
: Reopened
Depends On:
Blocks: 1290187
  Show dependency treegraph
 
Reported: 2015-07-28 17:25 EDT by Jared Deubel
Modified: 2016-06-29 10:59 EDT (History)
9 users (show)

See Also:
Fixed In Version: 5.6.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1290187 (view as bug list)
Environment:
Last Closed: 2016-06-29 10:59:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jared Deubel 2015-07-28 17:25:44 EDT
Description of problem:
Trying to setup external authentication, as I want to back my Cloudform appliance to IDM.

In the appliance console, I choose 10) to configure external authentication, then:
-----------------------------------------------
Configure External Authentication (httpd)


IPA Server Parameters:

Enter the IPA Server Hostname: test1.domain
Enter the IPA Server Domain: |domain|  
Please provide a valid Domain.
?  
----------------------------------------------

The problem seems to come from the fact that the domain is : "douane" without any extension, such as: "domain.fr"

But this is likely to be a CFME issue rather than an IDM issue, as we have successfully backed RHEVM to IDM with the same "douane" domaine.

Hide Section - Tags

Version-Release number of selected component (if applicable):
5.4.x

How reproducible:
100%
Comment 1 Jared Deubel 2015-07-28 17:26:49 EDT
This appears to be a limitation in the appliance console for the prompt that is used for the external authentication. 

This might be a standard that is set in place with the code used to authentication. The requirement comes from the appliance console prompt code 
 DOMAIN_REGEXP = /^[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,13}$/ for the method 

   def ask_for_domain(prompt, default = nil, validate = DOMAIN_REGEXP, error_text = "a valid Domain.", &block)
      just_ask(prompt, default, validate, error_text, &block)
    end
Comment 3 Felix Dewaleyne 2015-09-03 06:32:09 EDT
is there a way to temporarily remove that limitation? I am afraid though that if there is, it will be editing code that would be in the end changed to change the behaviour, and thus a hotfix / test package might be preferred here. is that correct?
Comment 4 Felix Dewaleyne 2015-09-03 10:18:22 EDT
customer is going to deploy 3.1 and use local authenticatoin for now, but wants to track the resolution of this issue
Comment 5 Tim Wade 2015-09-09 13:44:58 EDT
Jared Deubel: Is there any way we could have more information here? To me, it seems right that 'douane' should not be valid. Is it a top-level domain? Forgive my ignorance, but I don't see how that could work. The fix should be trivial but I'd like to better understand the problem before proceeding. Is there any documentation you could point me to?
Comment 6 Felix Dewaleyne 2015-09-16 07:27:41 EDT
douane is officially what they use as a top level domain, but it might be misconfigured as it looks like it should be douane.gouv.fr (http://www.douane.gouv.fr/)

douane is definitely not in http://www.iana.org/domains/root/db

I don't know if in their setup the usage of a pseudo-TLD would be any good (.localdomain)

the real question is, do we want to allow users to use misconfigured domains like this one? most providers (including microsoft) recommend to attach to a valid top level domain your domain...
Comment 7 Felix Dewaleyne 2015-09-16 10:40:52 EDT
the customer did bring the point that the current rules wouldn't allow the .academy domain either - in fact, I think the rules would prevent cfme from using this model of authentication if in an organization that uses a top level domain. 

arguably, it is also unlikely that a top level domain would be used without a sub level domain.
Comment 11 Tim Wade 2015-11-03 13:41:49 EST
Jared: I'm going to close this as it looks like no action is being taken at this time.
Comment 12 Felix Dewaleyne 2015-11-04 12:31:44 EST
I'm going to reopen and comment that for now that I know what happened in more details. They weren't allowing the httpd-auth service to authenticate in their IPA, the setup they have works with cfuser@douane even through it is not recommended.

given that ipa does work with TLD we may have the interest to allow non-full domain usernames though and to just raise a warning that the domain is malformed instead.
Comment 13 Tim Wade 2016-01-05 13:54:44 EST
PR: https://github.com/ManageIQ/manageiq/pull/5812
Comment 14 amogh 2016-06-08 17:15:28 EDT
VERSION: 5.6.0.10-rc2.1

It is accepting the hostname/domain name in the format, 
e.g domain.fr
test.domain
applianceipa.cfme

Configure External Authentication (httpd)

IPA Server Parameters:

Enter the IPA Server Hostname: applianceipa.cfme
Enter the IPA Server Domain: |cfme| cfme
Enter the IPA Server Realm: |CFME| CFME
Enter the IPA Server Principal: |admin| admin
Enter the IPA Server Principal Password: *******

External Authentication (httpd) Configuration:
IPA Server Details:
  Hostname:       applianceipa.cfme
  Domain:         cfme
  Realm:          CFME
  Naming Context: dc=cfme
  Principal:      admin

Proceed? (Y/N):
Comment 16 errata-xmlrpc 2016-06-29 10:59:02 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1348

Note You need to log in before you can comment on or make changes to this bug.