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.
sorry, i don't understand the request, can you please elaborate? (we need credentials to access the directory, hence we need an account)
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
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
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
> 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.
(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.
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.
This will be solved only for generic LDAP provider (Bug 1083736)
supported in new ldap implementation.
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