Bug 1594641 - AD authentication failing cross region.
Summary: AD authentication failing cross region.
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Replication
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.0
Assignee: Joe Vlcek
QA Contact: Antonin Pagac
Whiteboard: auth:miqldap:ad
Depends On:
Blocks: 1578510 1603058
TreeView+ depends on / blocked
Reported: 2018-06-25 05:06 UTC by Nikhil Gupta
Modified: 2019-08-22 00:54 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1603058 (view as bug list)
Last Closed: 2019-02-11 14:05:01 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)
Authentication User Type User Principal Name (80.24 KB, image/png)
2018-07-09 19:41 UTC, Joe Vlcek
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3525081 None None None 2018-07-10 03:58:02 UTC

Description Nikhil Gupta 2018-06-25 05:06:02 UTC
Description of problem:

Not able to order a service in a global region via AD user. 

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

How reproducible:

Steps to Reproduce:
1. Integrate AD to authenticate Global and subordinate region on CFME appliance 
2. Login on Global region via AD user and order a service.

Actual results:
Error: "Invalid System Authentication Token specified"

Expected results:
VM should be provisioned.

Additional info:
Refer https://bugzilla.redhat.com/show_bug.cgi?id=1514607

Comment 9 Joe Vlcek 2018-06-29 19:43:48 UTC
I've reviewed this case it seems the issue may be rooted in the groups configured for the user and what roles they are assigned to.

Please do this experiment:
  - Log into the non-Global region and navigate to "Configuration", expand the "Access Control" drop down and select "Groups".

  - Select the "Configuration" tab and select "Add a new Group"

  - Select " (Look up LDAP Groups)", Specify the user in question in the "User to Look Up" box and fill in the "Username" and "Password", Click the "Retrieve" button.

  - A new dropdown should appear near the top of the page "LDAP Groups for User"

  - Expand the "<Choose>" drop down and select one of the groups returned for this user.

  - Next to the "Role" dropdown select "EvmRole-super_administrator"

  - Select a valid Tenant'

  - Add the group.

  - Ensure none of the other groups returned for the user are configured in Cloudforms to ensure this is the correct group and role used for this user.

  - Repeat this on the other region.

At this point there should only be a single group configured with Role "EvmRole-super_administrator" for this user on both the Global and other region.

  - Attempt to log directly in to the non-Global region as the user in question and attempt to perform the operation in question.

  - Attempt to log directly in to the Global region as the user in question and attempt to perform the operation in question.

Please report the results of this experiment.

Thank you, JoeV

Comment 11 Joe Vlcek 2018-07-03 21:01:22 UTC

I am attempting to reproduce this locally. While I am working on that could you please ask the customer to enable debugging log level on both appliances then attempt to Login on Global region via AD user and order a service from the subordinate region.

In the evm.log file on the subordinate region there should now be logged entires for "External Group:" and "Internal Group:".

To enable the debugging log level please navigate to "Configuration/Advanced"
Search for ":level:" and set it to ":level: debug". Then run the above test.

I will continue to research.


Comment 17 Joe Vlcek 2018-07-09 19:41:57 UTC
Created attachment 1457570 [details]
Authentication User Type User Principal Name

Comment 18 Joe Vlcek 2018-07-09 19:43:00 UTC
Hello Niks,

I have a workaround that I would like you to ask the customer to try. This will
work if, in the "Configuration/Authentication" page on both the Global and
remote region, the "User Type" is set to "User Principal Name".

See the screen shot I've attached.

Please let me know if this workaround is acceptable.

Thank you, JoeV

Comment 19 Nikhil Gupta 2018-07-10 03:12:54 UTC
Hi JoeV,

After changing "User Type" to "User Principal Name", AD user is able to order a service from Global region.


Comment 20 Joe Vlcek 2018-07-10 12:50:48 UTC
(In reply to Nikhil Gupta from comment #19)
> Hi JoeV,
> After changing "User Type" to "User Principal Name", AD user is able to
> order a service from Global region.
> Regards,
> Niks

Thank you Niks,

So can this BZ be closed now or at least the priority be lowered?


Comment 22 Nikhil Gupta 2018-07-10 23:25:37 UTC
Hi JoeV,

Thank you for your help on this bug.

I will lower down the severity. 


Comment 23 CFME Bot 2018-07-17 17:50:55 UTC
New commit detected on ManageIQ/manageiq/master:

commit 2c9d3ef0328eb8b58142152d4cc9844bcd748230
Author:     Joe VLcek <jvlcek@redhat.com>
AuthorDate: Tue Jul 10 17:00:05 2018 -0400
Commit:     Joe VLcek <jvlcek@redhat.com>
CommitDate: Tue Jul 10 17:00:05 2018 -0400

    Force user_type to UPN when username is a UPN

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1594641

 lib/miq_ldap.rb | 11 +-
 spec/lib/miq_ldap_spec.rb | 51 +
 2 files changed, 59 insertions(+), 3 deletions(-)

Comment 25 Mike Shriver 2019-01-10 19:32:05 UTC
Tested in CFME

Auth configuration:
Active Directory endpoint
UPN and CN user type configurations
Group fetched from Active Directory

Two regions configured with replication, both with above auth settings.

Openstack provider added to subordinate region appliance.

Catalog item for openstack instance provisioning created and attached to catalog in subordinate region appliance.

Service catalog ordered from global region appliance, logged in as Active Directory user.

Request was submitted, approved, and executed on the subordinate region, provisioning an openstack instance.

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