Bug 980965 - PRD35 - [RFE][AAA] Support anonymous bind for authn/authz
PRD35 - [RFE][AAA] Support anonymous bind for authn/authz
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap (Show other bugs)
3.2.0
Unspecified Unspecified
medium Severity high
: ---
: 3.5.0
Assigned To: Alon Bar-Lev
Ondra Machacek
infra
: FutureFeature
Depends On: 1090517
Blocks: oVirt-AAA-LDAP rhev3.5beta 1156165
  Show dependency treegraph
 
Reported: 2013-07-03 12:54 EDT by Wesley Duffee-Braun
Modified: 2016-02-10 14:08 EST (History)
16 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-11 13:12:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wesley Duffee-Braun 2013-07-03 12:54:42 EDT
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 03:00:30 EDT
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 03:13:29 EDT
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 15:08:43 EDT
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 09:50:57 EDT
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 11:35:54 EDT
> 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 03:28:46 EDT
(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 03:32:33 EDT
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 10:36:13 EDT
This will be solved only for generic LDAP provider (Bug 1083736)
Comment 10 Alon Bar-Lev 2014-06-11 09:25:22 EDT
supported in new ldap implementation.
Comment 14 errata-xmlrpc 2015-02-11 13:12:32 EST
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.