Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Brian LaMere]

>
> Brian,
> for non user/group/host objects you fully own and control you can use
> whatever directory structure you want as long as you do not put them
> under the cn=accounts subtree and keep them generally away from any IPA
> controlled subtree.
>
>
ah - well if that's the case, then I asked my initial question very poorly,
as that's ultimately what I was trying to find out.  If I can do things
outside of that area then I it will do what I need; I was just concerned
that the "completely flat DIT" might object to a tree next to it in the same
389-DS.  Having kerberized systems would improve more workflow issues around
here than I can even comprehend, and there are other features of the IPA I
am very interested in as well that will help solve other issues...once I get
around to having enough time to get to those tasks.

Apologies, as mentioned I'm quite ldap-rusty.

Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Simo Sorce]

On Thu, 2 Sep 2010 16:26:26 -0700
Brian LaMere  wrote:

> >
> > 389 access control is pretty powerful and flexible.  There's
> > usually a way to do what you want to do without having to resort to
> > using subtrees (as in AD).
> >
> > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Access_Control.html
> >
> >
> aye - I already have everything on that side of the house working
> perfectly, in exactly the way I want it.  However, part of how I have
> that is based on ACIs attached to specific ou units.  So if it could
> probably be made to work without resorting to ACIs for individual
> OUs, then...ok.  I want PMs to be able to make people that are
> customers, but not people who are People (that sounds horrible, but
> you know what I mean...heh).  That's just one of example of many,
> including batch processes that make changes to specific ou units
> reserved for the activities of those processes.
> 
> Perhaps I'll just install FreeIPA and see, then.

Brian,
for non user/group/host objects you fully own and control you can use
whatever directory structure you want as long as you do not put them
under the cn=accounts subtree and keep them generally away from any IPA
controlled subtree.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Brian LaMere]

>
> 389 access control is pretty powerful and flexible.  There's usually a way
> to do what you want to do without having to resort to using subtrees (as in
> AD).
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Access_Control.html
>
>
aye - I already have everything on that side of the house working perfectly,
in exactly the way I want it.  However, part of how I have that is based on
ACIs attached to specific ou units.  So if it could probably be made to work
without resorting to ACIs for individual OUs, then...ok.  I want PMs to be
able to make people that are customers, but not people who are People (that
sounds horrible, but you know what I mean...heh).  That's just one of
example of many, including batch processes that make changes to specific ou
units reserved for the activities of those processes.

Perhaps I'll just install FreeIPA and see, then.

Brian
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Rich Megginson]

Brian LaMere wrote:


The ACIs are defined inside the underlaying Directory Server. See
details and syntax are here
http://directory.fedoraproject.org/wiki/Howto:AccessControl
The ACIs as you see can be group based. One does not need a
hierarchical
"ou" user structure in the DS for ACIs  - just groups. So all the
users
live in one container without any hierarchy.  All the hierarchy can be
accomplished by creating a combination of nested groups. Groups
live in
another container but on the same level. This is what we mean by "flat
tree".


well, problem is that I want project managers to be able to create 
customers within ou=customers...how does a flat DIT allow 
otherwise unprivileged users the ability to create entries?  Note that 
most of my directory won't be people or groups, but objects that 
define things that tools then access for monitoring, 
extending/expanding services, etc.  I could always create aci's that 
allow particular groups to create entries with only a certain set of 
attributeTypes and objectclasses, but in some cases those customers 
should show up as valid users on a machine; "id customername" should 
respond with stuff.  If the answer is that I'm not creative enough to 
imagine how to restrict based on something other than ACIs on an ou, 
then I suppose that's the answer ;)  If that's the case then I'll just 
have to find the time to do an install, load my schema, and test to 
see if everything I want to happen can be made to happen, and 
everything I don't want to happen can be made to not happen.
389 access control is pretty powerful and flexible.  There's usually a 
way to do what you want to do without having to resort to using subtrees 
(as in AD).

http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Access_Control.html


Thanks,
Brian LaMere


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Brian LaMere]

>
> The ACIs are defined inside the underlaying Directory Server. See
> details and syntax are here
> http://directory.fedoraproject.org/wiki/Howto:AccessControl
> The ACIs as you see can be group based. One does not need a hierarchical
> "ou" user structure in the DS for ACIs  - just groups. So all the users
> live in one container without any hierarchy.  All the hierarchy can be
> accomplished by creating a combination of nested groups. Groups live in
> another container but on the same level. This is what we mean by "flat
> tree".
>
>
well, problem is that I want project managers to be able to create customers
within ou=customers...how does a flat DIT allow otherwise unprivileged users
the ability to create entries?  Note that most of my directory won't be
people or groups, but objects that define things that tools then access for
monitoring, extending/expanding services, etc.  I could always create aci's
that allow particular groups to create entries with only a certain set of
attributeTypes and objectclasses, but in some cases those customers should
show up as valid users on a machine; "id customername" should respond with
stuff.  If the answer is that I'm not creative enough to imagine how to
restrict based on something other than ACIs on an ou, then I suppose that's
the answer ;)  If that's the case then I'll just have to find the time to do
an install, load my schema, and test to see if everything I want to happen
can be made to happen, and everything I don't want to happen can be made to
not happen.

Thanks,
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Dmitri Pal]

Brian LaMere wrote:
> On Tue, Aug 24, 2010 at 6:16 PM, Rob Crittenden  > wrote:
>
> Brian LaMere wrote:
>
> Yes, if not easier. It is just 389-ds under the hood, we have
> some simple management tools that create the agreements for
> you. Since we use our own CA SSL is easy as well.
>
>
> if I already have certs for the servers that would be running the IPA,
> would it be easy enough to use those?  I ask because my gold images
> come out of the box already trusting my ldap servers, which means
> using someone else's CA can potentially be a concern.  That's not a
> show-stopper, because I can work around that anyway.

I think you can use the certs that you already have.
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
http://www.freeipa.org/page/Administrators_Guide#Managing_Certificates_and_Certificate_Authorities

If you need more details you need to wait a bit for Rob to get back from
leave.

>  
>
> Depending on your configuration the data migration should be
> relatively straightforward but know that the IPA DIT is completely
> flat. All users are in one container, groups in another, etc. 
>
>
> I have to admit that while I'm very good at some things, I was only
> "ok" with ldap way back long long ago when I did anything with it.  I
> just created a custom schema with a couple hundred attributeTypes and
> a couple dozen objectclasses so that I can manage a lot of different
> things within ldap (single point of pluggable info to allow an
> object-oriented framework, independent of what tools are used).  So
> when I read your "the IPA DIT is completely flat" statement I got a
> bit worried.  Much of what I am doing will be far more difficult if I
> can't give texture to things, and my understanding is that a
> "completely flat DIT" is very difficult to create good aci's against.
>
> I know that the obvious answer is to just install it, and look and see
> if it does what I want anyway ;)  But without spending time to do
> that...if I leave the users/groups in their current flat places, could
> I add texture to the DIT elsewhere (aci's are almost vital for what
> I'm doing; I want to expose methods, which means I can't just "trust"
> tools or hosts) without causing problems for FreeIPA?
>
> It's a lazy bred not out of laziness of not wanting to just experiment
> and test myself, but out of having a high workload; I'd like to use
> FreeIPA, and am just wondering if the above question has an obvious
> answer that doesn't even need to be tested.
>
The ACIs are defined inside the underlaying Directory Server. See
details and syntax are here
http://directory.fedoraproject.org/wiki/Howto:AccessControl
The ACIs as you see can be group based. One does not need a hierarchical
"ou" user structure in the DS for ACIs  - just groups. So all the users
live in one container without any hierarchy.  All the hierarchy can be
accomplished by creating a combination of nested groups. Groups live in
another container but on the same level. This is what we mean by "flat
tree".


> Thanks,
> Brian LaMere
> 
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Brian LaMere]

On Tue, Aug 24, 2010 at 6:16 PM, Rob Crittenden  wrote:

> Brian LaMere wrote:
>
>> Yes, if not easier. It is just 389-ds under the hood, we have some simple
>> management tools that create the agreements for you. Since we use our own CA
>> SSL is easy as well.
>
>
if I already have certs for the servers that would be running the IPA, would
it be easy enough to use those?  I ask because my gold images come out of
the box already trusting my ldap servers, which means using someone else's
CA can potentially be a concern.  That's not a show-stopper, because I can
work around that anyway.


> Depending on your configuration the data migration should be relatively
> straightforward but know that the IPA DIT is completely flat. All users are
> in one container, groups in another, etc.


I have to admit that while I'm very good at some things, I was only "ok"
with ldap way back long long ago when I did anything with it.  I just
created a custom schema with a couple hundred attributeTypes and a couple
dozen objectclasses so that I can manage a lot of different things within
ldap (single point of pluggable info to allow an object-oriented framework,
independent of what tools are used).  So when I read your "the IPA DIT is
completely flat" statement I got a bit worried.  Much of what I am doing
will be far more difficult if I can't give texture to things, and my
understanding is that a "completely flat DIT" is very difficult to create
good aci's against.

I know that the obvious answer is to just install it, and look and see if it
does what I want anyway ;)  But without spending time to do that...if I
leave the users/groups in their current flat places, could I add texture to
the DIT elsewhere (aci's are almost vital for what I'm doing; I want to
expose methods, which means I can't just "trust" tools or hosts) without
causing problems for FreeIPA?

It's a lazy bred not out of laziness of not wanting to just experiment and
test myself, but out of having a high workload; I'd like to use FreeIPA, and
am just wondering if the above question has an obvious answer that doesn't
even need to be tested.

Thanks,
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds to free-ipa transition; transparent?

[Rob Crittenden]

Brian LaMere wrote:

I have a multimaster 389-ds installation, and am considering migrating
to ipa-server.

http://freeipa.org/page/IPAv2_alpha2#Migration  seems to be pretty clear
that I'm out of luck, and that I need to do a completely clean install.
  Am I reading that correctly?


That's right. We have to configure a whole slew of services to work in 
concert so using an existing install would be extremely difficult at 
best, even if the DIT was the same.



Secondly, is multi-master on ipa as easy as it was for 389-ds?


Yes, if not easier. It is just 389-ds under the hood, we have some 
simple management tools that create the agreements for you. Since we use 
our own CA SSL is easy as well.


What I would recommend is to set up a test IPA instance to get a feel 
for how the data is stored, see how migrating users and groups would 
work, etc. If you want to get really fancy you can add a master or two 
to the mix.


Depending on your configuration the data migration should be relatively 
straightforward but know that the IPA DIT is completely flat. All users 
are in one container, groups in another, etc. Once the migration is done 
there is a simple form to set up user kerberos keys, then you should be 
off to the races. The basic idea is that you authenticate using your 
migrated LDAP password and this will automatically generate a kerberos 
key for the user.


regards

rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] 389-ds to free-ipa transition; transparent?

[Brian LaMere]

I have a multimaster 389-ds installation, and am considering migrating to
ipa-server.

http://freeipa.org/page/IPAv2_alpha2#Migration  seems to be pretty clear
that I'm out of luck, and that I need to do a completely clean install.  Am
I reading that correctly?

Secondly, is multi-master on ipa as easy as it was for 389-ds?

thanks,
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users