Re: [ovirt-users] oVirt 3.5 and FreeIpa

From: "Jorick Astrego" <j.astrego(a)netbulae.eu&gt; To: users(a)ovirt.org Sent: Thursday, January 22, 2015 2:09:18 PM Subject: Re: [ovirt-users] oVirt 3.5 and FreeIpa On 01/22/2015 12:59 PM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Jorick Astrego" <j.astrego@ netbulae.eu > >> To: users@ ovirt.org >> Sent: Thursday, January 22, 2015 1:41:40 PM >> Subject: Re: [ovirt-users] oVirt 3.5 and FreeIpa >> >> >> On 10/31/2014 02:47 PM, Marcelo Donato wrote: >> >> >> >> >> Below the solution. Resolved By "Alon Bar-Lev" < alonbl@ redhat.com > >> >> >> 1. install ovirt-engine-extension-aaa- ldap, it is available in >> ovirt-3.5-snapshots repository. >> >> 2. create /etc/ovirt-engine/extensions. d/din.intranet-authz. properties >> >> ovirt.engine.extension.name = din-intranet-authz >> ovirt.engine.extension. bindings.method = jbossmodule >> ovirt.engine.extension. binding.jbossmodule.module = >> org.ovirt.engine-extensions. aaa.ldap >> ovirt.engine.extension. binding.jbossmodule.class = >> org.ovirt.engineextensions. aaa.ldap.AuthzExtension >> ovirt.engine.extension. provides = org.ovirt.engine.api. >> extensions.aaa.Authz >> config.profile.file.1 = /etc/ovirt-engine/aaa/din. intranet.properties >> >> 3. create /etc/ovirt-engine/extensions. d/din.intranet-authn. properties >> >> ovirt.engine.extension.name = din-intranet-authn >> ovirt.engine.extension. bindings.method = jbossmodule >> ovirt.engine.extension. binding.jbossmodule.module = >> org.ovirt.engine-extensions. aaa.ldap >> ovirt.engine.extension. binding.jbossmodule.class = >> org.ovirt.engineextensions. aaa.ldap.AuthnExtension >> ovirt.engine.extension. provides = org.ovirt.engine.api. >> extensions.aaa.Authn >> ovirt.engine.aaa.authn.profile.name = din.intranet >> ovirt.engine.aaa.authn.authz. plugin = din-intranet-authz >> config.profile.file.1 = /etc/ovirt-engine/aaa/din. intranet.properties >> >> 4. create /etc/ovirt-engine/aaa/din. intranet.properties >> >> include = <ipa.properties> >> >> vars.user = uid=admin,cn=users,cn= accounts,dc=din,dc=intranet >> vars.password = 123456 >> vars.server = ipa1.din.intranet >> >> pool.default.serverset.single. server = ${global:vars.server} >> pool.default.auth.simple. bindDN = ${global:vars.user} >> pool.default.auth.simple. password = ${global:vars.password} >> >> 5. restart engine. >> >> >> Thanks a lot Alon. >> >> >> >> Thanks for this, saved me some time! >> >> Just a couple of addtions, please hash the password with SSHA (I really >> hate >> plain text admin passwords...) >> I tried putting an {SSHA} encoded password in " vars.password =" , but it >> fails to authenticate while plain text works fine. > I am unsure I understand. > using hash to store password hint at server side makes sense. > but using hash to store password at client side does not makes sens, this > means that if I get the server database I can authenticate to any user > without knowing his password. > > Also, please note that the user you specify within configuration should not > have any special privilege but to query public objects within ldap. I don't like storing plain text in textfiles, so I try to avoid it. Even if it is a read only user there are no "public" objects that I like to expose to anyone. I can query groups, group members, e-mail addresses, krbPasswordExpiration, krbLastPwdChange etc. with this user. So that's why I try to have the bind user password hashed in the properties file.

>> For people with multiple ipa replica's I you guess you need to use: >> >> Round robin configuration: vars.server1 = ipa1.din.intranet >> vars.server2 = ipa2.din.intranet pool.default.serverset.type = >> round-robin >> pool.default.serverset.round-robin.1.server = ${global:vars.server1} >> pool.default.serverset.round-robin.2.server = ${global:vars.server2} >> >> instead of >> >> vars.server = ipa1.din.intranet pool.default.serverset.single.server = >> ${global:vars.server} >> But I still have to test that as our second replica is down at the moment. > Correct, there are multiple policies for you to choose from. > >> Also can we get rid of the internal admin or better just disable internal >> authenticationt without problems? As we have ipa we don't want local login >> enabled, but in emergency situations we might need to turn it on quickly. > Yes, you can disable the internal by creating > /etc/ovirt-engine/engine.conf.d/50-disable-internal.conf > --- > ENGINE_EXTENSION_ENABLED_builtin-authn-internal = false > --- > > Hmmm.... we have a bug in this case... will fix, so let's just disable the > authz for now. > --- > ENGINE_EXTENSION_ENABLED_internal = false > --- > > Regards, > Alon thanks! that will work. Met vriendelijke groet, With kind regards, Jorick Astrego Netbulae Virtualization Experts Tel: 053 20 30 270 info(a)netbulae.eu Staalsteden 4-3A KvK 08198180 Fax: 053 20 30 271 www.netbulae.eu 7547 TA Enschede BTW NL821234584B01 _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users