[ovirt-users] Extension aaa: No search for principal

Tue Sep 15 20:09:45 UTC 2015

On 15.09.2015 19:23, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: Users at ovirt.org
>> Sent: Tuesday, September 15, 2015 2:41:02 PM
>> Subject: Re: [ovirt-users] Extension aaa: No search for principal
>>
>>
>>
>> On 11.09.2015 17:00, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: Users at ovirt.org
>>>> Sent: Friday, September 11, 2015 5:33:21 PM
>>>> Subject: Re: [ovirt-users] Extension aaa: No search for principal
>>>>
>>>> sorry, forgot one:
>>>>
>>>> On 11.09.2015 12:48, Alon Bar-Lev wrote:
>>>>> Hi!
>>>>>
>>>>> Thank you for the information, for some reason the administrator user
>>>>> cannot be resolved to userPrincipalName during login, is it specific for
>>>>> Administrator or any user?
>>>> This is the default domain administrator account witch exits in any
>>>> forest. But just in case I created a new domain user just for the
>>>> purpose; same outcome
>>>
>> Sorry for the delay, Alon.
>>
>>> I am unsure what actually happens...
>> I might have an idea, at least from the commands you supplied.
>>
>>> Something in global catalog is out of sync.
>>> Usually - you do not add domain administrator to external application...
>>> there is no need to expose it.
>>> By default Administrator does not have "login from network" and "user
>>> principal suffix".
>>>
>>> Also in my environment I do not get result for administrator, but I do get
>>> one for regular user that has upn suffix in user record, you can see these
>>> fields in user and domain manager.
>>>
>>> So please use regular unprivileged users which belongs to "Domain Users"
>>> from now on.
>>>
>>> To test if user has userPrincipalName use the following command (assuming
>>> we search for user at int.corp.de):
>>>
>>> $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H
>>> ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'bind at int.corp.de' -w
>>> PASSWORD -b '' '(userPrincipalName=user at int.corp.de)' cn userPrincipalName
>> It seams with Active Directory (at least) the search base cannot be
>> empty (-b '') but needs to be provided.
>>
>> In my case, the above command fails with:
>>> # search result
>>> search: 2
>>> result: 32 No such object
>>> text: 0000208D: NameErr: DSID-03100213, problem 2001 (NO_OBJECT), data 0,
>>> best match of:
>>
>> While adding the most basic search path it succeeds:
>>
>> $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H
>> ldap://int.corp.de:389/ -x -D 'bind at int.corp.de' -w PASSWORD -b
>> 'dc=int,dc=corp,dc=de' '(userPrincipalName=administrator at int.corp.de)'
>> cn userPrincipalName
>>> # search reference
>>> ref:
>>> ldap://ForestDnsZones.int.corp.de/DC=ForestDnsZones,DC=int,DC=corp,DC=de
>>>
>>> # search reference
>>> ref:
>>> ldap://DomainDnsZones.int.corp.de/DC=DomainDnsZones,DC=int,DC=corp,DC=de
>>>
>>> # search reference
>>> ref: ldap://int.corp.de/CN=Configuration,DC=int,DC=corp,DC=de
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>> control: 1.2.840.113556.1.4.319 false DDDDDDDSSSDDMM=
>>> pagedresults: cookie=
>>>
>>> # numResponses: 4
>>> # numReferences: 3
> 
> But I asked to query a specific port... the global catalog, port 3268, see my command above.
> 
>>
>> It succeeds with every user I tried.
> 
> what we see is not a success... :(
> I also asked not to use administrator as a reference user, please create a standard non privileged user for these tests, so skip oddness of builtin administrator for now.

Ok, sorry; thought this was for me change as part of the ldap URL.

> 
> 
>> I would set the search base; but i am not sure where to do so.
>>
>>>
>>> This should find the user (return one result), if not, please checkout user
>>> in Users and Domains manager for the domain suffix, maybe it is empty.
>>>
>>> To find user without userPrincipalName such as Administrator use the
>>> following command:
>>>
>>> $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H
>>> ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'bind at int.corp.de' -w
>>> PASSWORD -b '' '(sAMAccountName=user)' cn userPrincipalName
>>>
>>> For example, the above will work for Administrator, but for kerberos to
>>> work properly user principal name must be defined, so these users will not
>>> work.
>>>
>>> You can dump entire GC and send me a user record if no result so I can
>>> determine what is different from expectations:
>>>
>>> $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H
>>> ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'bind at int.corp.de' -w
>>> PASSWORD -b '' > /tmp/dump.out
>>
>> If you still require a dump (its even a small one..) please drop a mail.
> 
> I will be happy to receive a complete dump of your gc, please send me privately, so we can progress.
> Please use this exact command just replace qa1.qa.lab.tlv.redhat.com with your dc, bind at int.corp.de with your bind user and PASSWORD with bind user password.

I did; this now works as expected using GC port.

I think I did find the issue here;

my domain is named int.corp.com

I have defined several UPN aliases and our real world users do use the UPN @corp.com.

Using some internal user with UPN int.corp.com the authentication works as expected; while my real world users fail.

I tried to create a new profile for that; but it fails to load off course because the domain corp.com cannot be connected.

> 
> Thanks!
>  
>>>
>>> Regards,
>>> Alon
>>>
>>
>> --
>> Daniel Helgenberger
>> m box bewegtbild GmbH
>>
>> P: +49/30/2408781-22
>> F: +49/30/2408781-10
>>
>> ACKERSTR. 19
>> D-10115 BERLIN
>>
>>
>> www.m-box.de  www.monkeymen.tv
>>
>> Geschäftsführer: Martin Retschitzegger / Michaela Göllner
>> Handeslregister: Amtsgericht Charlottenburg / HRB 112767
>>
> 

-- 
Daniel Helgenberger
m box bewegtbild GmbH

P: +49/30/2408781-22
F: +49/30/2408781-10

ACKERSTR. 19
D-10115 BERLIN

www.m-box.de  www.monkeymen.tv

Geschäftsführer: Martin Retschitzegger / Michaela Göllner
Handeslregister: Amtsgericht Charlottenburg / HRB 112767