Bug 1387093
| Summary: | [Sat6.2] Active Directory LDAP authentication using login name with space/s is treated as an invalid name in foreman | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | jalviso <jalviso> |
| Component: | Docs Server Administration Guide | Assignee: | Zac Dover <zdover> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Russell Dickenson <rdickens> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2.2 | CC: | adahms, airey.andy, amasolov, arahaman, bbuckingham, dhlavacd, jalviso, jcallaha, mhulan, shwallac |
| Target Milestone: | Unspecified | Keywords: | Reopened, Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-31 02:40:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Does the solution described in comment 1 resolves the issue for the customer? Hi Marek, Yes it resolved the issue for that customer. 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. 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 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. 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. 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 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. 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. |
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".