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

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?

customer is going to deploy 3.1 and use local authenticatoin for now, but wants to track the resolution of this issue

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?

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...

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.

Jared: I'm going to close this as it looks like no action is being taken at this time.

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.

PR: https://github.com/ManageIQ/manageiq/pull/5812

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):

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