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

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

From: "Joop" <jvdwege(a)xs4all.nl&gt; To: users(a)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 :-)

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

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

engine# engine-manage-domains add --domain=EECS.YORKU.CA --provider=ipa --user=ovirtadmin

----- Original Message ----- > From: "Jason Keltz" <jas(a)cse.yorku.ca&gt; > To: users(a)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=b... > 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=b...

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.

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