Bug 1322069

Summary: Login fails for user when using aaa-ldap
Product: [oVirt] ovirt-engine-extension-aaa-ldap Reporter: Marcus Sundberg <devel>
Component: ExtensionAssignee: Martin Perina <mperina>
Status: CLOSED WONTFIX QA Contact: Gonza <grafuls>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.1.2CC: bugs, devel, omachace
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-31 08:54:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Log from failed login
none
Log from successful login none

Description Marcus Sundberg 2016-03-29 17:48:51 UTC
Created attachment 1141366 [details]
Log from failed login

Description of problem:
Login after configuring aaa-ldap fails for one user but works for another.

How reproducible:
Always

Steps to Reproduce:
1. Try to login with user

Actual results:
Login fails with "General command validation failure."

Expected results:
Successful login.

Comment 1 Marcus Sundberg 2016-03-29 17:49:35 UTC
Created attachment 1141367 [details]
Log from successful login

Comment 2 Marcus Sundberg 2016-03-29 17:51:32 UTC
Login for the failing user works fine using the old example.local profile,
for both user portal and admin portal, but for neither using
example.local-new. Login for the working user works fine using both
profiles and both portals.

Comment 3 Ondra Machacek 2016-03-29 18:16:40 UTC
Can you please also share your properties files?
Also, can you please run following commands:

$ ldapsearch -x -H ldap://example.local -D marcuss.admin -W -b DC=example,DC=local "(samAccountName=marcuss)" userPrincipalName

$ ldapsearch -x -H ldap://example.local -D marcuss.admin -W -b DC=example,DC=local "(samAccountName=marcuss.admin)" userPrincipalName

Most probably your issue is that marcus is using different domain suffix then user marcuss.admin. So you should use UPN to login properly with both users.

Comment 4 Marcus Sundberg 2016-03-29 18:51:31 UTC
Thanks! And sorry for wasting your time! It was indeed the case that
marcuss has an UPN of marcuss due to the user having a
mailbox, but users without a mailbox like the marcuss.admin user have
an UPN of <user>@example.local. When using marcuss as user
name login works fine.

Comment 5 Marcus Sundberg 2016-03-29 18:55:21 UTC
Hmm, on the other hand I don't see why the extension can't match the
entered user name against the uid and/or SAMAccountName attributes?
That worked fine using the old pre-3.5 LDAP authentication.

Comment 6 Ondra Machacek 2016-03-29 19:01:06 UTC
Yes, that worked with legacy manage-domains, but it doesn't work with aaa-ldap, because SAMAccountName 
supports max. 15 characters, so it was decided to use UPN usernames only, so we can support longer 
usernames.

Comment 7 Martin Perina 2016-03-31 08:54:10 UTC
Using UPN usernames is the only correct and standardized solution to support long usernames