Re: [Freeipa-users] service account for ovirt

2015-11-23 Thread Martin Kosek 
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 = 
> 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
>

Re: [Freeipa-users] service account for ovirt

2015-11-20 Thread Rob Verduijn 
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,


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

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 = 
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 :
> On 11/18/2015 04:27 PM, Rob Verduijn wrote:
>>
>> 2015-11-18 15:51 GMT+01:00 Martin Kosek :
>>>
>>> On

Re: [Freeipa-users] service account for ovirt

2015-11-18 Thread Rob Verduijn 
2015-11-18 15:51 GMT+01:00 Martin Kosek :
> 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.

Cheers
Rob Verduijn

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

Re: [Freeipa-users] service account for ovirt

2015-11-18 Thread Martin Kosek 
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
> 

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

[Freeipa-users] service account for ovirt

2015-11-18 Thread Rob Verduijn 
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.

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

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