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 <[email protected]>: >> On 11/18/2015 04:27 PM, Rob Verduijn wrote: >>> >>> 2015-11-18 15:51 GMT+01:00 Martin Kosek <[email protected]>: >>>> >>>> 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
