----- Original Message -----

From: "Daniel Helgenberger" <daniel.helgenberger@m-box.de> To: "Alon Bar-Lev" <alonbl@redhat.com>, "users" <users@ovirt.org> Sent: Thursday, August 6, 2015 1:24:23 PM Subject: Re: [ovirt-users] [ATN] LDAP Users please read

Hello Alon,

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...

Sorry for the ignorance on my part,

but I tried one more and could not find any qualified docs/howtos on the new AAA feature.

This readme is the only thing witch comes close so far, but running Engine 3.5.3 at least my installation is missing

/usr/share/ovirt-engine-extension-aaa-ldap*/examples

Does the tool run without them?

The new provider is distributed as standalone and optional package, please install ovirt-engine-extension-aaa-ldap and you will be set up.

As for my part, I only need engine authentication domains; I used: engine-manage-domains add --domain ...

Should I migrate to the new provider?

Yes, this is exactly the reason why I sent this message, all 3.5 installations should migrate to the new provider so we can provide better service and support. I will be happy to assist. Regards, Alon

Thanks;

...

[3] https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

-- 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

Hi, On 08/06/2015 03:28 PM, Joop wrote:

Hi Alon,

I'll take the bait :-)

I have just installed the extension and the examples are there. I also installed the migration tool. Now it comes. We use Samba4 as our AD provider and have succesfully connected Foreman-1.8 to it using the cert that I got from the server. The same cert doesn't work with the migration tool. So either I'm confused or .. The first possibility is most likely. I always trip over certs and terminology. Error I got: [root@mgmt01 ~]# ovirt-engine-kerbldap-migration-tool --debug --domain ad.nieuwland.nl --cacert ad02.pem [INFO ] tool: ovirt-engine-kerbldap-migration-1.0.2 (ovirt-engine-kerbldap-migration-1.0.2-1.el6ev) [INFO ] Connecting to database [INFO ] Sanity checks [INFO ] Loading options [INFO ] Using ldap URI: ldap://ad01.ad.nieuwland.nl:389 [ERROR ] Conversion failed: {'info': "TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.", 'desc': 'Connect error'}

Can you try run command: LDAPTLS_CACERT=ad02.pem ldapsearch -ZZ -H ldap://ad01.ad.nieuwland.nl:389 -x -D "@user@" -W @password@ -b "@basedn@" If it fail, it's problem with certificate(please notice - ad02 vs ad01) Anyway would be nice if you sent the debug log. (append parameter --log=debug.log) Thanks, Ondra

And now...

Joop

_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

----- Original Message -----

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Joop" <jvdwege@xs4all.nl> Cc: users@ovirt.org Sent: Thursday, August 6, 2015 7:05:38 PM Subject: Re: [ovirt-users] [ATN] LDAP Users please read

----- Original Message -----

...

From: "Joop" <jvdwege@xs4all.nl> To: users@ovirt.org Sent: Thursday, August 6, 2015 4:28:00 PM Subject: Re: [ovirt-users] [ATN] LDAP Users please read

Hi Alon,

I'll take the bait :-)

Good!

...

I have just installed the extension and the examples are there. I also installed the migration tool. Now it comes. We use Samba4 as our AD provider and have succesfully connected Foreman-1.8 to it using the cert that I got from the server. The same cert doesn't work with the migration tool. So either I'm confused or .. The first possibility is most likely. I always trip over certs and terminology. Error I got: [root@mgmt01 ~]# ovirt-engine-kerbldap-migration-tool --debug --domain ad.nieuwland.nl --cacert ad02.pem [INFO ] tool: ovirt-engine-kerbldap-migration-1.0.2 (ovirt-engine-kerbldap-migration-1.0.2-1.el6ev) [INFO ] Connecting to database [INFO ] Sanity checks [INFO ] Loading options [INFO ] Using ldap URI: ldap://ad01.ad.nieuwland.nl:389 [ERROR ] Conversion failed: {'info': "TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.", 'desc': 'Connect error'}

And now...

Interesting.

Can you please attach the ad02.pem certificate, and paste the output of the following command?

$ openssl s_client -connect ad01.ad.nieuwland.nl:636 -showcerts < /dev/null

There is no leak of sensitive information, it will enable me to determine what is wrong,.

Hi Joop, I am curios what went wrong, when you find time please send me the above information. Thanks! Alon

----- Original Message -----

From: "Jason Keltz" <jas@cse.yorku.ca> To: users@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... 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.

...

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

I enabled my engine installation to authenticate with my IPA server like this: 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...

----- Original Message -----

From: "Jason Keltz" <jas@cse.yorku.ca> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: users@ovirt.org Sent: Friday, August 7, 2015 4:12:40 PM Subject: Re: [ovirt-users] [ATN] LDAP Users please read

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

Good, but you could have first added the new one and only after you have all working delete the legacy one :) Not important right now.

# 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".

Correct this is new in 3.6, in 3.5 you should follow the documentation of 1.0[1] [1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob...

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:

there is no standard method to get CA certificate. we provided some information at[1] under: "3. [Optional] Obtaining LDAP CA certificate." """ FreeIPA Copy /etc/ipa/ca.crt to your oVirt machine into /tmp. """ [1] https://github.com/machacekondra/ovirt-engine-kerbldap-migration

# ovirt-engine-kerbldap-migration-tool --domain EECS.YORKU.CA --cacert /tmp/cacert.p12

PKCS#12 file should never leave your IPA machine :)

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").

thanks! will fix. can you please add --debug and --log=/tmp/debug.log and send os the debug.log? probably we cannot resolve dns srvrecord correctly. $ dig +noall +answer srv _ldap._tcp.EECS.YORKU.CA should return a set of LDAP servers for your domain, if you do not have srvrecord we can workaround this by specifying a specific ldap server using --ldapserver parameter.

Of course the domain does actually exist. I can login to engine with my domain login.

yes, true, the question is what wrong in our conversion program :)

Jason.