1387093 – [Sat6.2] Active Directory LDAP authentication using login name with space/s is treated as an invalid name in foreman

Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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 1387093 - [Sat6.2] Active Directory LDAP authentication using login name with space/s is treated as an invalid name in foreman

Summary: [Sat6.2] Active Directory LDAP authentication using login name with space/s i...

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Satellite
Classification:	Red Hat
Component:	Docs Server Administration Guide
Sub Component:
Version:	6.2.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	Unspecified
Assignee:	Zac Dover
QA Contact:	Russell Dickenson
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2016-10-20 05:11 UTC by jalviso
Modified:	2020-04-15 14:44 UTC (History)
CC List:	10 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-01-31 02:40:05 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Foreman Issue Tracker	8339	0	None	None	None	2016-10-20 06:47:31 UTC
Red Hat Knowledge Base (Solution)	2819191	0	None	None	None	2016-12-19 00:24:46 UTC

Description jalviso 2016-10-20 05:11:52 UTC

Description of problem:

LDAP authentication with Active Directory using login name with space/s is treated as an invalid user in foreman. 

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

6.2


How reproducible:

Steps to Reproduce:
1. Configure Satellite 6.2 with LDAP authentication (Microsoft Active Directory)
   Per 9.1.1 Satellite Server Guide documentation

2. Login using the AD username that has white spaces
3. Failed with error:

==> /var/log/foreman/production.log <==
2016-10-18 11:29:23 [app] [I] Started POST "/users/login" for xxx.xxx.26.76 at 2016-10-18 11:29:23 +1100
2016-10-18 11:29:23 [app] [I] Processing by UsersController#login as HTML
2016-10-18 11:29:23 [app] [I]   Parameters: {"utf8"=>"?", "authenticity_token"=>"mlTcuRFt5syjmeIiDlz2CbSlU4y8GWI+/PalN1Ofi08=", "login"=>{"login"=>"shane wallace.au", "password"=>"[FILTERED]"}, "commit"=>"Login"}
2016-10-18 11:29:23 [app] [W] Action failed
 | ActiveRecord::RecordInvalid: Validation failed: Username is invalid

Actual results:

Failed when using login name attribute "sAMAccountName".

Expected results:

Satellite 6.2 should accept username with white spaces
Reference Upstream bugzilla:
http://projects.theforeman.org/issues/8339


Additional info:

Workaround:

Use login name attribute "userPrincipalName" instead of "sAMAccountName".

Comment 1 Alexey Masolov 2016-10-21 01:51:59 UTC

I would say that using userPrincipalName is a better approach than allowing spaces in sAMAccountName. sAMAccountName is supposed to be used for backwards compatibility with legacy Microsoft systems. UPN contains user login name, so I would suggest using userPrincipalName instead of sAMAccountName in our documentation.

Comment 3 Marek Hulan 2016-11-09 09:44:32 UTC

Does the solution described in comment 1 resolves the issue for the customer?

Comment 4 Ashfaqur Rahaman 2016-12-01 07:05:40 UTC

Hi Marek,

Yes it resolved the issue for that customer.

Comment 5 Marek Hulan 2016-12-01 07:54:34 UTC

Thanks for letting me know. I'm closing this now as resolved. A KB article that covers this would be appreciated. If you write one, please attach the link here.

Comment 6 Shane Wallace 2016-12-12 21:59:46 UTC

Hi all,

I have another customer affected by a similar problem (case 01756050) but their spaces exist within the DN path leading to the required ldap attribute that we are searching for.

eg. When we search for the following the group cannot be found
Group Name:   Role-Unix_Admin
DN Path:      OU=Role Groups,OU=Delegation Groups,OU=Admin,DC=example,DC=com

When I got a test group created with the following path without spaces it worked

Group Name:   ACL_Resource_Managers_WOL
DN Path:      OU=Permission,OU=Groups,OU=Client,DC=example,DC=com

I don't think that this is a case of which specific attribute that they use but removing foreman's inability to use white space as a valid character.

Can I request that we re-open this bug and resolve the actual problem please?

Thanks

Shane

Comment 7 Marek Hulan 2016-12-15 19:02:54 UTC

Hello Shane, I think it would be better to report as a new issue since all linked cases and upstream issues would be misleading. Another reason is that seems to be an issue with different object attribute (LDAP Auth source in this case) where it make sense to support white spaces. If you agree please create a new BZ with also the trace that customer find in a production log and set See Also to this BZ. Thanks a lot for searching existing bugzilla before opening new ones, it is highly appreciated.

Comment 8 Ashfaqur Rahaman 2016-12-19 01:00:33 UTC

Hi Marek and Shane, 

I have created kbase solution 2819191 and linked with this bz. 

As Alexyem has suggested in Comment#1, "userPrincipalName" is a better approach than allowing spaces in sAMAccountName. To move forward, I think we have two options : 

1. Create an RFE to allow "Blank space" in any attributes regardless it is Groups or login name.   

Or  

2. a. Report a Bug for Documentation change for "login" attributes: 
      - use userPrincipalName instead of sAMAccountName in our documentation 
   b. Create RFE for allowing blank space in "Groups" 
    
Please provide your feedback on this.

Comment 9 Shane Wallace 2016-12-19 01:03:33 UTC

Thanks Marek & Ashfaqur,

Another bug has been created for the other case, bug ID 1404114, which relates to spaces in the DN path causing issues.

Lukas is currently working on a patch for it. I would be interested to see if it resolves this issue too :)

Thanks

Shane

Comment 10 Marek Hulan 2016-12-19 07:08:17 UTC

Thank you Shane. Ashfaqur, I know it might not look like that but allowing spaces in login is bigger change than in DN. You suggestion 2b. was created as bz 1404114, I'm reopening this and moving to Docs - server administration guide. Table 9.2 should change the login attribute to userPrincipalName and ideally explain the difference.

Comment 11 Andrew Dahms 2017-01-16 04:29:51 UTC

Assigning to Zac for review.

Zac - see comment #10 for directions on what is required. In terms of explaining the difference, I suspect the notes in comment #1 and a short explanation that using the UPN allows spaces, etc. would be sufficient in this case.

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