Re: [ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

- Original Message -
 From: Alon Bar-Lev alo...@redhat.com
 To: Joop jvdw...@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 jvdw...@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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

- Original Message -
 From: Jason Keltz j...@cse.yorku.ca
 To: Alon Bar-Lev alo...@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;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0

 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.
 
 
 
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ATN] LDAP Users please read

[Jason Keltz]

On 08/06/2015 01:50 PM, Alon Bar-Lev wrote:


- Original Message -

From: Jason Keltz j...@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;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

Re: [ovirt-users] [ATN] LDAP Users please read

[Ondra Machacek]

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


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

Re: [ovirt-users] [ATN] LDAP Users please read

[Daniel Helgenberger]

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;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0

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?

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

Should I migrate to the new provider?

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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

- Original Message -
 From: Daniel Helgenberger daniel.helgenber...@m-box.de
 To: Alon Bar-Lev alo...@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;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0
 
 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
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

- Original Message -
 From: Jason Keltz j...@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;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

Re: [ovirt-users] [ATN] LDAP Users please read

[Jason Keltz]

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?


Thanks!

Jason.


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

Re: [ovirt-users] [ATN] LDAP Users please read

[Joop]

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

And now...

Joop

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

Re: [ovirt-users] [ATN] LDAP Users please read

[Donny Davis]

AAA ldap has been working great for me for quite some time now. Good work
Alon
On Aug 4, 2015 3:56 AM, Alon Bar-Lev alo...@redhat.com 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
 [3]
 https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

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

Re: [ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

- Original Message -
 From: Joop jvdw...@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,.

Thanks!
Alon
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ATN] LDAP Users please read

[Alon Bar-Lev]

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
[3] https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users