[ovirt-users] [ATN] LDAP Users please read
Jason Keltz
jas at cse.yorku.ca
Fri Aug 7 13:12:40 UTC 2015
On 08/06/2015 01:50 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Jason Keltz" <jas at cse.yorku.ca>
>> To: users at ovirt.org
>> Sent: Thursday, August 6, 2015 7:47:26 PM
>> Subject: Re: [ovirt-users] [ATN] LDAP Users please read
>>
>> On 04.08.2015 09:56, Alon Bar-Lev wrote:
>>>> Hello LDAP Users,
>>>>
>>>> If you migrated from 3.4 or if you used engine-managed-domains to add LDAP
>>>> support into engine - this message is for you.
>>>>
>>>> In 3.5 we introduced a new LDAP provider[1][2], it is superset of the
>>>> previous implementation, highlights includes:
>>>> * Better response times.
>>>> * Simplicity, Use of LDAP protocol only - kerberos is no longer needed.
>>>> * More LDAP implementations are supported.
>>>> * Flexible configuration, can be customized on site to support special
>>>> setups.
>>>> * Supportability, better logs and feedbacks to enable remote support.
>>>> * Variety of fallback policies, examples: srvrecord, failover,
>>>> round-robin and more.
>>>> * Active Directory: supports multiple domain in forest.
>>>>
>>>> In 3.5 the previous LDAP provider is marked as legacy, users' issues will
>>>> be resolved by migration to the new provider.
>>>>
>>>> Upgrade to 4.0 will not be possible if legacy provider is being used.
>>>>
>>>> The new provider is working without any issue for quite some time, we
>>>> would like to eliminate the remaining usage of the legacy provider as
>>>> soon as possible.
>>>>
>>>> A tool was created[3] to automate the process, it should perform
>>>> everything in safe and automatic process, while enables customization if
>>>> such required. The one prerequisite that we could not automate easily is
>>>> obtaining the CA certificate used by the LDAP server to communicate using
>>>> SSL/TLS, you should acquire this manually and provide it as parameter.
>>>>
>>>> We (Ondra CCed and I) will help anyone that is experiencing issues with
>>>> the process, please do not delay migration to the point it becomes
>>>> emergency.
>>>>
>>>> Let's define a virtual goal -- in 1 month no legacy LDAP usage anywhere.
>>>>
>>>> Regards,
>>>> Alon Bar-Lev.
>>>>
>>>> [1] http://www.ovirt.org/Features/AAA
>>>> [2]
>>>> https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0
>> Sorry Alon..
>>
>> I'm puzzled. I setup RHEL IPA server to act as an authentication
>> front-end for my ovirt installation. It also acts as an IPA server for
>> all the servers involved in my ovirt installation.
>>
>> I enabled my engine installation to authenticate with my IPA server like
>> this:
>>> engine# engine-manage-domains add --domain=EECS.YORKU.CA --provider=ipa
>>> --user=ovirtadmin
>> Your new system refers to only LDAP, and not Kerberos, other than saying
>> that it "obsoletes the legacy Kerberos/LDAP implementation". Will
>> Kerberos support now be obsolete? Since I've already invested the time
>> to get engine working with IPA and Kerberos, I don't really see the
>> point in changing things now, but I'd also rather deal with this now,
>> rather than down the line when I want to upgrade and find that my
>> existing installation is no longer compatible. Sooo -- does this
>> change still affect my current installation? Should I migrate? What do I
>> migrate to? and How?
> Not at all.
>
> The IPA provides several services, at least LDAP, DNS, Kerberos:
>
> These two are not actually related and used for two different purposes:
>
> 1. LDAP - a protocol to access a repository (database) holding entity information.
>
> 2. DNS - a protocol to locate resources within network.
>
> 3. Kerberos - single sign on infrastructure, enables to create trust between entities and single server, while after successful authentication, entity can access other entities without presenting credentials.
>
> Why do we use LDAP? LDAP is standard [simple(?)] protocol to acquire entity information.
>
> Why do we use Kerberos? Mainly for users will not require to enter their passwords over and over to access services (SSO), and to not expose their credentials to services.
>
> For various of incorrect reasons the legacy LDAP provider implementation used Kerberos to authenticate between the engine machine and the LDAP server. This actually breaks one of the major kerberos principals - do not expose the credentials to service. In our case the engine machine is the service and the user and password are sent to the engine machine so it can issue Kerberos ticket instead of it accepting restricted ticket from the user.
>
> Moreover, using two protocols in order to perform authentication and authorization introduces complexity, performance impact and probably depend on one other service DNS srvrecord. So we need true services to be configured correctly and operating in order to be able to perform a task that can be performed using LDAP only.
>
> In practice, if a service has access to user credentials (user/password) it can communicate directly using LDAP to the entity repository to very if these correct. This is similar to how Kerberos behaves in IPA environment, as password is actually stored in the repository.
>
> The new implementation does exactly that, it uses only LDAP protocol to perform authentication of users and authorization of users, much simpler and performs much better.
>
> After we got it right, we could also provide a solution of using actual Kerberos SSO using apache configuration[1], this enables users to use the ovirt-engine without presenting their credentials if they already authenticated with kerberos.
>
> The only difference in your environment is how ovirt-engine interacts with the IPA.
>
> I hope I answered your question.
>
> Regards,
> Alon Bar-Lev.
>
> [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#l255
Hi Alon.
Thanks for your detailed response.
I decided to give the new system a try. Rather than migrate, I prefer
to re-add from scratch, so I did:
# engine-manage-domains delete --domain=EECS.YORKU.CA
# systemctl restart ovirt-engine
# yum install ovirt-engine-extension-aaa-ldap
... but I ran into my first trouble when I tried the following as per
your AAA-LDAP documentation:
> QUICK START
> -----------
>
> USING INSTALLER
>
> Install ovirt-engine-extension-aaa-ldap-setup and execute:
>
> # ovirt-engine-extension-aaa-ldap-setup
>
> The setup will guide you throughout the process of most common use cases.
There's no command ovirt-engine-extension-aaa-ldap-setup. I checked the
repository, and I can't find any package that includes that command. I
guess that's something in 3.6 only. I don't want to use the manual
installation method. The method that I use should match the simplicity
of "engine-manage-domains".
I re-add back my existing domain so that I can "migrate" it. So..
# engine-manage-domains add --domain=EECS.YORKU.CA --provider=ipa
--user=ovirtadmin
Enter password:
I downloaded the ovirt-engine-kerlab-migration-1.0.2-1.el7ev.noarch.rpm
from
https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases and
installed it:
# rpm -i ovirt-engine-kerbldap-migration-1.0.2-1.el7ev.noarch.rpm
I need to provide to the tool the domain, and the cacert. It's too bad
about having to provide the cacert -- the previous method of specifying
a provider, username, password, and auto-downloading the cert seemed
more user friendly. The documentation doesn't tell me where I might
find the cacert. Without much experience using the Red Hat IPA product,
it's buried. Is it the /root/cacert.p12 file? I copied that file to
/tmp on my engine server, and then:
# ovirt-engine-kerbldap-migration-tool --domain EECS.YORKU.CA --cacert
/tmp/cacert.p12
sh-4.2# ovirt-engine-kerbldap-migration-tool --domain EECS.YORKU.CA
--cacert /home/jas/cacert.p12
[INFO ] tool: ovirt-engine-kerbldap-migration-1.0.2
(ovirt-engine-kerbldap-migration-1.0.2-1.el7ev)
[INFO ] Connecting to database
[INFO ] Sanity checks
[INFO ] Loading options
[ERROR ] Conversion failed: Domain EECS.YORKU.CA not exists in
configuration.
(minor correction in that last line: "does not exist" instead of "not
exists").
Of course the domain does actually exist. I can login to engine with my
domain login.
Jason.
More information about the Users
mailing list