Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 980965 - PRD35 - [RFE][AAA] Support anonymous bind for authn/authz
Summary: PRD35 - [RFE][AAA] Support anonymous bind for authn/authz
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 3.5.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On: 1090517
Blocks: oVirt-AAA-LDAP rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2013-07-03 16:54 UTC by Wesley Duffee-Braun
Modified: 2018-12-02 16:27 UTC (History)
16 users (show)

Fixed In Version: ovirt-engine-3.5.0_rc1
Doc Type: Enhancement
Doc Text:
The new generic LDAP provider implementation ovirt-engine-extension-aaa-ldap supports anonymous bind. You can now perform anonymous access to search for user information and no longer need to set up a specific user to perform directory search.
Clone Of:
Environment:
Last Closed: 2015-02-11 18:12:32 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0174 normal SHIPPED_LIVE new package: ovirt-engine-extension-aaa-ldap 2015-02-11 22:40:02 UTC

Description Wesley Duffee-Braun 2013-07-03 16:54:42 UTC
Description of problem:
Customer is requesting a way to be able to allow internal users to use RHDS/Kerberos/LDAP servers for RHEV authentication/authorization without having to set up LDAP/Kerberos accounts for their RHEV servers.

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

Additional info:

Generic Kerberos/LDAP would be nice, but RHDS would be fine.

Comment 1 Itamar Heim 2013-07-05 07:00:30 UTC
sorry, i don't understand the request, can you please elaborate?
(we need credentials to access the directory, hence we need an account)

Comment 2 Mark Chappell 2013-07-05 07:13:29 UTC
Hey Itamar,

I'm to blame for the request so I'll answer directly.  With an RHDS implementation frequently you don't need credentials to access the directory, that's our point.

Unlike Microsoft's default AD LDAP implementation,  most RHDS implementations actually expose things like group membership even when you use an anonymous bind, and even for things that we don't expose by default we'd be much happier granting IP address based read access ACLs to the LDAP server than creating full LDAP accounts: Full LDAP/Kerberos accounts frequently grant access to far more outside of the LDAP server, rather than just access to the LDAP server, this is something which in general we try to avoid since it makes abuse of other systems harder to track.

So what we'd like is simply the ability to use an anonymous bind rather than a user/password bind.

With AD you would I assume bind using the "computer" account, which AD locks down for you and also automatically performs key/password rotation, making credential abuse significantly harder.

Hope this explains what we're after better.


Mark

Comment 3 Alon Bar-Lev 2013-07-05 19:08:43 UTC
Hi,

If I understand you want to customize the LDAP bind method.

This is within the scope of the re-write of the authentication and authorization of the engine, and the generic ldap provider.

It is planned that you will be able to specify different configuration for authorization, including:

1. bind user: specific user / anonymous.
2. bind method: simple, digest-md5, sasl, gss-api(maybe).
3. transport: plain, tls, startTLS.
4. servers: <list>
5. server policy: first available, round-robbing, random, dns srv record.

Note: I do not know what the schedule of the ldap generic provider is.

What I do not understand from your description is how do you expect users to perform authentication.

Thanks,
Alon

Comment 4 Wesley Duffee-Braun 2013-07-10 13:50:57 UTC
Hello Alon,

Apologies for the delay here in responding to the needinfo. Mark, can you assist with the questions above?

Thanks,
Wesley

(In reply to Alon Bar-Lev from comment #3)
> Hi,
> 
> If I understand you want to customize the LDAP bind method.
> 
> This is within the scope of the re-write of the authentication and
> authorization of the engine, and the generic ldap provider.
> 
> It is planned that you will be able to specify different configuration for
> authorization, including:
> 
> 1. bind user: specific user / anonymous.
> 2. bind method: simple, digest-md5, sasl, gss-api(maybe).
> 3. transport: plain, tls, startTLS.
> 4. servers: <list>
> 5. server policy: first available, round-robbing, random, dns srv record.
> 
> Note: I do not know what the schedule of the ldap generic provider is.
> 
> What I do not understand from your description is how do you expect users to
> perform authentication.
> 
> Thanks,
> Alon

Comment 5 Mark Chappell 2013-07-10 15:35:54 UTC
> What I do not understand from your description is how do you expect users to
> perform authentication.

Performing User authentication with LDAP binds/kerberos calls/whatever is done today is fine (being able to do that using GSSAPI would be fantastic).

What we want to avoid is the need for a full account for RHEV-M it's self, since these are far to easily abused.  Once a user has authenticated into RHEV anonymous binds to get things like group information should be doable.

Comment 7 Itamar Heim 2013-07-14 07:28:46 UTC
(In reply to Mark Chappell from comment #5)
> > What I do not understand from your description is how do you expect users to
> > perform authentication.
> 
> Performing User authentication with LDAP binds/kerberos calls/whatever is
> done today is fine (being able to do that using GSSAPI would be fantastic).
> 
> What we want to avoid is the need for a full account for RHEV-M it's self,
> since these are far to easily abused.  Once a user has authenticated into
> RHEV anonymous binds to get things like group information should be doable.

actually, this is how the system worked in the past for any access done on behalf of the user to the directory.
however, we still had a cache updating process, refreshing once an hours the details on users and groups in the system for the webadmin search to work (we always refresh on user login for security considerations).

the problem with using user's credentials became an issue with multiple domains without trusts between them.
since we already had a per domain account for the cache refresh, we moved to using only it.

Comment 8 Mark Chappell 2013-07-14 07:32:33 UTC
I'm not suggesting that the users credentials be used for the information refresh, I'm suggesting that we can grant IP based anonymous access to any information required for the refresh, so we'd rather that was an option instead of a hard requirement for a system account.  Simply allow us to state that we want that refresh done with an anonymous bind.

Comment 9 Barak 2014-04-29 14:36:13 UTC
This will be solved only for generic LDAP provider (Bug 1083736)

Comment 10 Alon Bar-Lev 2014-06-11 13:25:22 UTC
supported in new ldap implementation.

Comment 14 errata-xmlrpc 2015-02-11 18:12:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0174.html


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