subject:"Re\: \[ovirt\-users\] Extension aaa\: No search for principal"

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

2015-09-16 Thread Daniel Helgenberger



On 15.09.2015 22:55, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Daniel Helgenberger" <daniel.helgenber...@m-box.de>
>> To: "Alon Bar-Lev" <alo...@redhat.com>
>> Cc: Users@ovirt.org
>> Sent: Tuesday, September 15, 2015 11:09:45 PM
>> Subject: Re: [ovirt-users] Extension aaa: No search for principal
>>
>> 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.
>>
> 
> the user is upn, users should specify their full upn if this non default 
> domain suffix.

Hello Alon,
> 
> you do not need a new profile.
> 
> in your case it would probably be us...@corp.com for user1.

right ... should have tried that in the first place. Works very well now.

Thanks for helping me sort that through!

> 

-- 
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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2015-09-15 Thread Alon Bar-Lev



- Original Message -
> From: "Daniel Helgenberger" <daniel.helgenber...@m-box.de>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: Users@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.helgenber...@m-box.de>
> >> To: "Alon Bar-Lev" <alo...@redhat.com>
> >> Cc: Users@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 u...@int.corp.de):
> >
> > $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H
> > ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'b...@int.corp.de' -w
> > PASSWORD -b '' '(userPrincipalName=u...@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: 208D: 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 'b...@int.corp.de' -w PASSWORD -b
> 'dc=int,dc=corp,dc=de' '(userPrincipalName=administra...@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 DDDSSSDDMM=
> > 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.


> 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 'b...@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

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

2015-09-15 Thread Daniel Helgenberger



On 11.09.2015 17:00, Alon Bar-Lev wrote:
>
>
> - Original Message -
>> From: "Daniel Helgenberger" <daniel.helgenber...@m-box.de>
>> To: "Alon Bar-Lev" <alo...@redhat.com>
>> Cc: Users@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 u...@int.corp.de):
>
> $ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H 
> ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'b...@int.corp.de' -w PASSWORD 
> -b '' '(userPrincipalName=u...@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: 208D: 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 'b...@int.corp.de' -w PASSWORD -b 
'dc=int,dc=corp,dc=de' '(userPrincipalName=administra...@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 DDDSSSDDMM=
> pagedresults: cookie=
>
> # numResponses: 4
> # numReferences: 3

It succeeds with every user I tried.

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 'b...@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 'b...@int.corp.de' -w PASSWORD 
> -b '' > /tmp/dump.out

If you still require a dump (its even a small one..) please drop a mail.

>
> 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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2015-09-15 Thread Alon Bar-Lev



- Original Message -
> From: "Daniel Helgenberger" <daniel.helgenber...@m-box.de>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: Users@ovirt.org
> Sent: Tuesday, September 15, 2015 11:09:45 PM
> Subject: Re: [ovirt-users] Extension aaa: No search for principal
> 
> 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.
> 

the user is upn, users should specify their full upn if this non default domain 
suffix.

you do not need a new profile.

in your case it would probably be us...@corp.com for user1.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

2015-09-11 Thread Alon Bar-Lev

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?

Can you please attach the extension configuration for both authn/authz as well?

I will also need debug log with ALL level, see [1] for instructions.

Thanks!
Alon

[1] 
https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0#l377

- Original Message -
> From: "Daniel Helgenberger" 
> To: Users@ovirt.org
> Sent: Friday, September 11, 2015 1:28:10 PM
> Subject: [ovirt-users] Extension aaa: No search for principal
> 
> Hello,
> 
> I am stuck in configuring ovirt-engine-extension-aaa-ldap with AD for
> ovirt 3.5.4. I am following the [readme.md] and so far it was quite
> strait forward:
> > include = 
> >
> > #
> > # Active directory domain name.
> > #
> > vars.domain = int.corp.de
> >
> > #
> > # Search user and its password.
> > #
> > vars.user = bind@${global:vars.domain}
> > vars.password = [redacted]
> >
> > #
> > # Optional DNS servers, if enterprise
> > # DNS server cannot resolve the domain srvrecord.
> > #
> > #vars.dns = dns://dc1.${global:vars.domain} dns://dc2.${global:vars.domain}
> >
> > pool.default.serverset.type = srvrecord
> > pool.default.serverset.srvrecord.domain = ${global:vars.domain}
> > pool.default.auth.simple.bindDN = ${global:vars.user}
> > pool.default.auth.simple.password = ${global:vars.password}
> >
> > # Uncomment if using custom DNS
> > #pool.default.serverset.srvrecord.jndi-properties.java.naming.provider.url
> > = ${global:vars.dns}
> > #pool.default.socketfactory.resolver.uRL = ${global:vars.dns}
> >
> > # Create keystore, import certificate chain and uncomment
> > # if using ssl/tls.
> > #pool.default.ssl.startTLS = true
> > #pool.default.ssl.truststore.file =
> > ${local:_basedir}/${global:vars.domain}.jks
> > #pool.default.ssl.truststore.password = changeit
> 
> 
> 
> The config seems to work; at least the domain and binddn part. I can
> browse and add users to ovirt as suggested in step (3). All quotes are
> from engine.log:
> 
> > 2015-09-11 11:54:50,261 INFO
> > [org.ovirt.engine.core.bll.AddSystemPermissionCommand]
> > (org.ovirt.thread.pool-8-thread-24) [73bff0e9] Running command:
> > AddSystemPermissionCommand internal: false. Entities affected :  ID:
> > aaa0----123456789aaa Type: SystemAction group
> > MANIPULATE_PERMISSIONS with role type USER,  ID:
> > aaa0----123456789aaa Type: SystemAction group
> > ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER
> > 2015-09-11 11:54:50,268 INFO
> > [org.ovirt.engine.core.bll.aaa.AddUserCommand]
> > (org.ovirt.thread.pool-8-thread-24) [21867e72] Running command:
> > AddUserCommand internal: true. Entities affected :  ID:
> > aaa0----123456789aaa Type: SystemAction group
> > MANIPULATE_USERS with role type ADMIN
> > 2015-09-11 11:54:50,301 INFO
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > (org.ovirt.thread.pool-8-thread-24) [21867e72] Correlation ID: 21867e72,
> > Call Stack: null, Custom Event ID: -1, Message: User 'Administrator' was
> > added successfully to the system.
> > 2015-09-11 11:54:50,379 INFO
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > (org.ovirt.thread.pool-8-thread-24) [21867e72] Correlation ID: 73bff0e9,
> > Call Stack: null, Custom Event ID: -1, Message: User/Group Administrator
> > was granted permission for Role SuperUser on System by admin@internal.
> 
> Yet, when loging in as a user administrator I get:
> 
> > {Extkey[name=EXTENSION_INVOKE_RESULT;type=class
> > java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2,
> > Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class
> > java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=No
> > search for principal 'administra...@int.corp.com'}
> 
> Followed by a java stack trace.
> I did not find any configurable search path.
> 
> The config seems to load:
> > 2015-09-11 12:01:34,897 INFO
> > [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
> > thread 1-2) Loading extension 'builtin-authn-internal'
> > 2015-09-11 12:01:34,903 INFO
> > [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
> > thread 1-2) Extension 'builtin-authn-internal' loaded
> > 2015-09-11 12:01:34,905 INFO
> > [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
> > thread 1-2) Loading extension 'internal'
> > 2015-09-11 12:01:34,907 INFO
> > [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
> > thread 1-2) Extension 'internal' loaded
> > 2015-09-11 12:01:34,919 INFO
> > [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
> > thread 1-2) Loading extension 'corp-authn'
> > 2015-09-11 12:01:34,967 INFO
> >

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

2015-09-11 Thread Daniel Helgenberger



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?

Thanks for getting back to me Alon.

>
> Can you please attach the extension configuration for both authn/authz as 
> well?

here you go, but I did northing apart form changing the profile naming. 
Please note I performed anonymization and replaced my domain with 'corp' 
(as you might have guessed). If this had any side effects I can mail you 
the original logs as well.

# cat /etc/ovirt-engine/extensions.d/corp-authn.properties
> ovirt.engine.extension.name = corp-authn
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = 
> org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = 
> org.ovirt.engineextensions.aaa.ldap.AuthnExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
> ovirt.engine.aaa.authn.profile.name = corp
> ovirt.engine.aaa.authn.authz.plugin = corp-authz
> config.profile.file.1 = ../aaa/corp.properties

# cat /etc/ovirt-engine/extensions.d/corp-authz.properties
> ovirt.engine.extension.name = corp-authz
> ovirt.engine.extension.bindings.method = jbossmodule
> ovirt.engine.extension.binding.jbossmodule.module = 
> org.ovirt.engine-extensions.aaa.ldap
> ovirt.engine.extension.binding.jbossmodule.class = 
> org.ovirt.engineextensions.aaa.ldap.AuthzExtension
> ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
> config.profile.file.1 = ../aaa/corp.properties

>
> I will also need debug log with ALL level, see [1] for instructions.
please find engine log with debugging on attached. I did a number of 
logins in the logged timeframe as well as engine restarts; and hope it 
is sufficient.

Thanks!

>
> Thanks!
> Alon
>
> [1] 
> https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0#l377
>
> - Original Message -
>> From: "Daniel Helgenberger" 
>> To: Users@ovirt.org
>> Sent: Friday, September 11, 2015 1:28:10 PM
>> Subject: [ovirt-users] Extension aaa: No search for principal
>>
>> Hello,
>>
>> I am stuck in configuring ovirt-engine-extension-aaa-ldap with AD for
>> ovirt 3.5.4. I am following the [readme.md] and so far it was quite
>> strait forward:
>>> include = 
>>>
>>> #
>>> # Active directory domain name.
>>> #
>>> vars.domain = int.corp.de
>>>
>>> #
>>> # Search user and its password.
>>> #
>>> vars.user = bind@${global:vars.domain}
>>> vars.password = [redacted]
>>>
>>> #
>>> # Optional DNS servers, if enterprise
>>> # DNS server cannot resolve the domain srvrecord.
>>> #
>>> #vars.dns = dns://dc1.${global:vars.domain} dns://dc2.${global:vars.domain}
>>>
>>> pool.default.serverset.type = srvrecord
>>> pool.default.serverset.srvrecord.domain = ${global:vars.domain}
>>> pool.default.auth.simple.bindDN = ${global:vars.user}
>>> pool.default.auth.simple.password = ${global:vars.password}
>>>
>>> # Uncomment if using custom DNS
>>> #pool.default.serverset.srvrecord.jndi-properties.java.naming.provider.url
>>> = ${global:vars.dns}
>>> #pool.default.socketfactory.resolver.uRL = ${global:vars.dns}
>>>
>>> # Create keystore, import certificate chain and uncomment
>>> # if using ssl/tls.
>>> #pool.default.ssl.startTLS = true
>>> #pool.default.ssl.truststore.file =
>>> ${local:_basedir}/${global:vars.domain}.jks
>>> #pool.default.ssl.truststore.password = changeit
>>
>>
>>
>> The config seems to work; at least the domain and binddn part. I can
>> browse and add users to ovirt as suggested in step (3). All quotes are
>> from engine.log:
>>
>>> 2015-09-11 11:54:50,261 INFO
>>> [org.ovirt.engine.core.bll.AddSystemPermissionCommand]
>>> (org.ovirt.thread.pool-8-thread-24) [73bff0e9] Running command:
>>> AddSystemPermissionCommand internal: false. Entities affected :  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> MANIPULATE_PERMISSIONS with role type USER,  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER
>>> 2015-09-11 11:54:50,268 INFO
>>> [org.ovirt.engine.core.bll.aaa.AddUserCommand]
>>> (org.ovirt.thread.pool-8-thread-24) [21867e72] Running command:
>>> AddUserCommand internal: true. Entities affected :  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> MANIPULATE_USERS with role type ADMIN
>>> 2015-09-11 11:54:50,301 INFO
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (org.ovirt.thread.pool-8-thread-24) [21867e72] Correlation ID: 21867e72,
>>> Call Stack: null, Custom Event ID: -1, Message: User 'Administrator' was
>>> added successfully to the system.
>>> 2015-09-11 11:54:50,379 INFO
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]

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

2015-09-11 Thread Daniel Helgenberger

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

>
> Can you please attach the extension configuration for both authn/authz as 
> well?
>
> I will also need debug log with ALL level, see [1] for instructions.
>
> Thanks!
> Alon
>
> [1] 
> https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0#l377
>
> - Original Message -
>> From: "Daniel Helgenberger" 
>> To: Users@ovirt.org
>> Sent: Friday, September 11, 2015 1:28:10 PM
>> Subject: [ovirt-users] Extension aaa: No search for principal
>>
>> Hello,
>>
>> I am stuck in configuring ovirt-engine-extension-aaa-ldap with AD for
>> ovirt 3.5.4. I am following the [readme.md] and so far it was quite
>> strait forward:
>>> include = 
>>>
>>> #
>>> # Active directory domain name.
>>> #
>>> vars.domain = int.corp.de
>>>
>>> #
>>> # Search user and its password.
>>> #
>>> vars.user = bind@${global:vars.domain}
>>> vars.password = [redacted]
>>>
>>> #
>>> # Optional DNS servers, if enterprise
>>> # DNS server cannot resolve the domain srvrecord.
>>> #
>>> #vars.dns = dns://dc1.${global:vars.domain} dns://dc2.${global:vars.domain}
>>>
>>> pool.default.serverset.type = srvrecord
>>> pool.default.serverset.srvrecord.domain = ${global:vars.domain}
>>> pool.default.auth.simple.bindDN = ${global:vars.user}
>>> pool.default.auth.simple.password = ${global:vars.password}
>>>
>>> # Uncomment if using custom DNS
>>> #pool.default.serverset.srvrecord.jndi-properties.java.naming.provider.url
>>> = ${global:vars.dns}
>>> #pool.default.socketfactory.resolver.uRL = ${global:vars.dns}
>>>
>>> # Create keystore, import certificate chain and uncomment
>>> # if using ssl/tls.
>>> #pool.default.ssl.startTLS = true
>>> #pool.default.ssl.truststore.file =
>>> ${local:_basedir}/${global:vars.domain}.jks
>>> #pool.default.ssl.truststore.password = changeit
>>
>>
>>
>> The config seems to work; at least the domain and binddn part. I can
>> browse and add users to ovirt as suggested in step (3). All quotes are
>> from engine.log:
>>
>>> 2015-09-11 11:54:50,261 INFO
>>> [org.ovirt.engine.core.bll.AddSystemPermissionCommand]
>>> (org.ovirt.thread.pool-8-thread-24) [73bff0e9] Running command:
>>> AddSystemPermissionCommand internal: false. Entities affected :  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> MANIPULATE_PERMISSIONS with role type USER,  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER
>>> 2015-09-11 11:54:50,268 INFO
>>> [org.ovirt.engine.core.bll.aaa.AddUserCommand]
>>> (org.ovirt.thread.pool-8-thread-24) [21867e72] Running command:
>>> AddUserCommand internal: true. Entities affected :  ID:
>>> aaa0----123456789aaa Type: SystemAction group
>>> MANIPULATE_USERS with role type ADMIN
>>> 2015-09-11 11:54:50,301 INFO
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (org.ovirt.thread.pool-8-thread-24) [21867e72] Correlation ID: 21867e72,
>>> Call Stack: null, Custom Event ID: -1, Message: User 'Administrator' was
>>> added successfully to the system.
>>> 2015-09-11 11:54:50,379 INFO
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (org.ovirt.thread.pool-8-thread-24) [21867e72] Correlation ID: 73bff0e9,
>>> Call Stack: null, Custom Event ID: -1, Message: User/Group Administrator
>>> was granted permission for Role SuperUser on System by admin@internal.
>>
>> Yet, when loging in as a user administrator I get:
>>
>>> {Extkey[name=EXTENSION_INVOKE_RESULT;type=class
>>> java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2,
>>> Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class
>>> java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=No
>>> search for principal 'administra...@int.corp.com'}
>>
>> Followed by a java stack trace.
>> I did not find any configurable search path.
>>
>> The config seems to load:
>>> 2015-09-11 12:01:34,897 INFO
>>> [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
>>> thread 1-2) Loading extension 'builtin-authn-internal'
>>> 2015-09-11 12:01:34,903 INFO
>>> [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
>>> thread 1-2) Extension 'builtin-authn-internal' loaded
>>> 2015-09-11 12:01:34,905 INFO
>>> [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
>>> thread 1-2) Loading extension 'internal'
>>> 2015-09-11 12:01:34,907 INFO
>>> [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (MSC service
>>>

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

2015-09-11 Thread Alon Bar-Lev

- Original Message -
> From: "Daniel Helgenberger" <daniel.helgenber...@m-box.de>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: Users@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

I am unsure what actually happens...
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 u...@int.corp.de):

$ ldapsearch -E pr=1024/noprompt -o ldif-wrap=no -H 
ldap://qa1.qa.lab.tlv.redhat.com:3268/ -x -D 'b...@int.corp.de' -w PASSWORD -b 
'' '(userPrincipalName=u...@int.corp.de)' cn userPrincipalName

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 'b...@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 'b...@int.corp.de' -w PASSWORD -b 
'' > /tmp/dump.out

Regards,
Alon
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

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

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

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

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

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

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

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

8 matches

Site Navigation

Mail list logo

Footer information