[Freeipa-users] service account for ovirt

Mon Nov 23 08:02:27 UTC 2015

On 11/20/2015 08:16 PM, Rob Verduijn wrote:
> Hello,
> 
> I've tested the solution you suggested it doesnt work
> I think ovirt-engine looks for the other users in the same context as
> the bind user, it will ofcourse find not many there,

Ah, I see. oVirt apparently expects the users to be only in the users container
and not in the system user container. I am thinking this might be something
that can be improved, as it would be much easier to do with system user, on the
first look.

> I can't get the seconf option with the keytab to work.
> So I'm stuck with the full blown user account for this.

Can you show some error log, why ipa-getkeytab on a service failed? It should
just work, if you add appropriate service with service-add and then ask for the
keytab with power account.

> Here's what I did :
> 
> The ovirt os is centos 6 x86_64
> All the latest patches have been applied.
> It can be a member of the freeipa domain but this is not required for
> the ovirt-freeipa authentication to work.
> personally I think its nice to have the ovirt machine under freeipa
> supervision as wel.
> 
> the freeipa os is centos7 x*6_64
> All the latest patches have been applied.
> 
> The ovirt environment is configured, up and running.
> 
> There are two ways of single sign on for ovirt.
> see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html
> 
> This howto is for the first option
> you require a search account in the freeipa domain.
> add a user account to the freeipa domain
> login with that account so it asks you to set a new password for it
> then reset the experation date for the password to somewhere in the
> far future with the procedure below
> 
> #
> # Add the search account for ovirt to the freeipa domain.
> #
> # executed these commands on the freeipa server as root.
> #
> 
> # first set the variables
> export SUFFIX='dc=example,dc=com'
> export OVIRT_SERVER=ovirt.example.com
> export FREEIPA_DOMAIN=EXAMPLE.COM
> export USERNAME=ovirt
> export YOUR_PASSWORD='top_secret_random_very_long_password'
> 
> # create an ldif file
> cat > resetexperation.ldif << EOF
> dn: uid=$USERNAME,cn=users,cn=accounts,$SUFFIX
> changetype: modify
> replace: krbpasswordexpiration
> krbpasswordexpiration: 20380119031407Z
> EOF
> 
> # apply the ldif file
> # the password requested is the directory admin password, this is NOT
> the same account as the freeipa admin
> ldapmodify -x -D "cn=directory manager" -W -vv -f resetexperation.ldif
> 
> # for the second option also :
> # add the service for http to freeipa
> kinit admin
> ipa service-add HTTP/$OVIRT_SERVER@$FREEIPA_DOMAIN
> 
> #
> # The following commands are executed as root on the ovirt-engine machine.
> # This is the example that allows single sign on from the portal to the vm's
> # Assuming the forementioned bindaccount exists in the freeipa domain
> #
> 
> #
> # first install the required package :
> #
> 
> yum install -y ovirt-engine-extension-aaa-ldap
> 
> #
> # create the ovirt configuration files
> # examples can be found here :
> # /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/.
> #
> 
> mkdir /etc/ovirt-engine/aaa
> mkdir /etc/ovirt-engine/extenstions.d
> 
> #
> # set the vars again ( exports do not work between vm's)
> #
> 
> export SUFFIX='dc=example,dc=com'
> export YOUR_PASSWORD='top_secret_random_very_long_password'
> export FREEIPA_SERVER=freeipa.example.com
> export PROFILE_NAME=profile1
> 
> #
> # create the config files
> #
> cat > /etc/ovirt-engine/aaa/$PROFILE_NAME.properties << EOF
> include = <ipa.properties>
> vars.server = $FREEIPA_SERVER
> vars.user = uid=ovirt,cn=users,cn=accounts,$SUFFIX
> vars.password = $YOUR_PASSWORD
> pool.default.serverset.single.server = \${global:vars.server}
> pool.default.auth.simple.bindDN = \${global:vars.user}
> pool.default.auth.simple.password = \${global:vars.password}
> EOF
> 
> cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authz.properties << EOF
> ovirt.engine.extension.name = $PROFILE_NAME-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 = ../aaa/$PROFILE_NAME.properties
> EOF
> 
> cat > /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties << EOF
> ovirt.engine.extension.name = $PROFILE_NAME-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 = $PROFILE_NAME
> ovirt.engine.aaa.authn.authz.plugin = $PROFILE_NAME-authz
> config.profile.file.1 = ../aaa/$PROFILE_NAME.properties
> EOF
> 
> #
> # change owner and permissions of the profile file
> #
> chown ovirt:ovirt /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties
> chmod 400 /etc/ovirt-engine/extensions.d/$PROFILE_NAME-authn.properties
> 
> #
> #  restart the ovirt engine
> #
> service ovirt-engine restart
> 
> #
> #  done you can now add freeipa users to the rhevm portal in the users menu
> #  after the users have been added you can assign permissions for them
> on the vm's
> #
> 
> 
> Cheers
> Rob Verduijn
> 
> 2015-11-18 20:34 GMT+01:00 Martin Kosek <mkosek at redhat.com>:
>> On 11/18/2015 04:27 PM, Rob Verduijn wrote:
>>>
>>> 2015-11-18 15:51 GMT+01:00 Martin Kosek <mkosek at redhat.com>:
>>>>
>>>> On 11/18/2015 08:23 AM, Rob Verduijn wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I've read a lot regarding service accounts on this mailinglist in the
>>>>> past.
>>>>> But it's rather unclear to me what is the current preffered method to
>>>>> create a service account for a service running on a different machine.
>>>>>
>>>>> In this case it would be  a service account for ovirt so that freeipa
>>>>> users can authenticate in the ovirt portal using their freeipa
>>>>> credentials.
>>>>
>>>>
>>>> It sounds like that you do not want system user account, but you are OK
>>>> with
>>>> service account so that you can get a keytab for your oVirt instance. In
>>>> that
>>>> case, simple
>>>>
>>>> $ ipa service-add HTTP/frontend.ovirt.test
>>>> and
>>>> $ ipa-getkeytab ...
>>>> should be enough, right?
>>>>
>>>> Maybe I just do not understand the use case.
>>>>
>>>>> I could ofcourse create an account and then apply a ldf to set its
>>>>> password expiration to the next millennium to make sure the password
>>>>> does not expire.
>>>>>
>>>>> Anybody who has a good suggestion on how to deal with this ?
>>>>>
>>>>> Cheers
>>>>> Rob Verduijn
>>>>>
>>>>
>>>
>>>
>>>
>>> Hello,
>>>
>>> I think some more context should clear this up a bit.
>>>
>>> according to the rhev administrator guide: (ovirt referes to rhev manuals
>>> a lot)
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-Directory_Users.html
>>>
>>> It talks about two options as a single sign on solution.
>>>
>>> On have the single sign on work for the portal, but then it won't work
>>> for the vm's.
>>> ( something about not being able to pass a password since the portal
>>> won't have one to pass )
>>>
>>> Or have the single sign on work for the vm's but than you have to sign
>>> in to the portal so it can pass on your credentials to the vm's.
>>>
>>>   I guess there is some interesting technical challenge to deal with to
>>> merge those two cases.
>>>
>>> The first option requires privileges to browse the freeipa directory
>>> to look for user accounts.
>>> I do not know if that can be solved with something as simple as a
>>> keytab and a pricipal.
>>>
>>> My current working solution is an account with a very long password
>>> experation time in the freeipa directory
>>> ( a random 32 character/number password is being used for this )
>>>
>>> However something tells me that there is a more elegant solution.
>>> And I was wondering if anyone knows one.
>>
>>
>> Reading the HowTo, I think using normal FreeIPA POSIX user with password
>> policy, uid, home and all the rings and bells may be an over kill. You could
>> replica what is done with sudo system user for binding to LDAP for example:
>>
>> # ldapmodify -D "cn=Directory Manager" -x -W
>> dn: uid=ovirt,cn=sysaccounts,cn=etc,$SUFFIX
>> changetype: add
>> objectclass: account
>> objectclass: simplesecurityobject
>> uid: sudo
>> userPassword: $YOUR_PASSWORD
>> passwordExpirationTime: 20380119031407Z
>> nsIdleTimeout: 0
>>
>> and use that as oVirt BIND user. As for keytab, you just would not use
>> kadmin, but rather add the service object with "service-add" and get the
>> keytab with "ipa-getkeytab".
>>
>> Other than that, the HowTo was mostly about oVirt side of configuration.
>>
>> If you succeed, it would nice to record your steps specific to FreeIPA in a
>> HowTo article on FreeIPA :-)
>>
>> http://www.freeipa.org/page/HowTos
>> http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki
>>
>> Martin