[Freeipa-devel] freeIPA and NIS
Dmitri Pal
dpal at redhat.com
Tue Aug 12 13:59:10 UTC 2008
Ahmed Kamal wrote:
> How would IPA know which accounts on AD to sync over to IPA? Do they
> need to share the same username ? anything else ?
They are matched by name.
> Also, does RHEIPA bundle DirectoryServer, or do I need to
> buy/install/configure that separately ?
IPA embeds DS. The IPA server = MIT Kerberos + DS + WebUI + Command Line
utilities.
All nicely glued together and tested.
>
> Thanks
>
> On Tue, Aug 12, 2008 at 4:15 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>
> Ahmed Kamal wrote:
>
> Thanks Dmitri for the very informative reply. I am planning on
> buying RHEIPA soon, I will probably use it in testing mode and
> let like 30 users play on it. After it has proved successful
> for us, is it possible to "link" the 30 user accounts from
> freeIPA to the same people's AD accounts (without deleting and
> re-creating all accounts) ? I hope the users would retain
> their UIDs so nothing breaks
>
>
> Yes. The user entries coming from AD will "take over" control of
> the already existing entries in IPA. So there will be no need to
> delete and re-create them.
>
>
> Thanks
>
>
> On Mon, Aug 11, 2008 at 5:26 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com> <mailto:dpal at redhat.com
> <mailto:dpal at redhat.com>>> wrote:
>
> Colin,
>
> Our plans for the AD integration are following:
> a) We will release an AD synch tool later this year (most
> likely
> November). Since the freeIPA versions and Red Hat Enterprise
> versions are a bit out of synch I can't say exactly which
> freeIPA
> version it would be but 1.x for sure. It will be 1.1 for
> RHEIPA.
> The feature will deliver:
> 1) If user account is created in AD it is synchronized to
> IPA.
> 2) If user account is created in IPA it is NOT
> synchronized to AD
> 3) The changes to an account once created in AD and
> synchronized
> to IPA are synchronized in both directions.
> 4) The passwords for accounts mentioned in 3) are also
> synchronized in both directions but require installation of the
> password filter component on every DC.
> b) In freeIPA v2 we plan to offer trust between IPA and AD.
> This
> will probably ease some pain but to what extent it is hard
> to say
> at the moment.
> Yes we use DNS for the name resolution and IPA v2 will be even
> more integrated with DNS. There will be an option to use an
> already existing DNS instead of the one that would come
> with IPA
> but zoning is the preferred method. One of the features of
> the v2
> is the capability of the clients to update their DNS
> information.
> The DNS back end will be integrated with IPA's DS and kerberos
> auth will be used to make sure the update is legitimate.
> c) Samba 4 and Penrose are other technologies that we seriously
> consider as solutions for the better AD integration down
> the road.
> It is unclear what shape and form this solution would take.
> It is
> unlikely that anything more than options a) and b) will be
> available soon. Tighter integration via Samba 4 is on our radar
> for v3 but may be Penrose based solution would come out earlier
> than that.
>
> From the use case you described it seems that Samba 4 will
> work
> fine for the Windows machines you have in your company. It most
> likely will be accepted as a domain (represented by Samba 4) by
> your parent company. IPA will be used for Linux/Unix
> machines and
> user accounts on those machines. There you will have an
> option of
> a) and b) and probably Penrose based solution. Having and
> integrated Samba 4 + IPA realm that can deal with both
> Windows and
> Linux/Unix might not be the best choice. We are working on such
> integration option but as I mentioned it is down the road in v3
> time frame.
>
> I hope I did not miss anything.
>
> Thank you
> Dmitri
>
>
> Colin Simpson wrote:
>
> On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote:
>
>
> -FreeIPA2 should be out fairly soon, is there a
> final
> word on how the Windows integration is going to
> look
> like (particularly if there's no AD) ?
>
> We are still working on this piece. The first step is
> going to be some limited syncing of users and
> passwords,
> later adding a more robust solution.
>
> If you have any specific needs please let us know. This
> can be very complex as some people want to only sync
> certain parts of their tree, only in one direction,
> etc.
> So the more requirements we gather the better the first
> release will be.
>
> thanks
>
> rob
>
>
> I'm interested in your AD integration plans.
>
> We are a heavy RH Linux users but our parent is a big
> AD user
> (and we
> use AD on the Windows side). Our present Linux
> directory is a
> hand built
> OpenLDAP/MIT Kerberos solution, pretty much what IPA was
> designed to
> replace. We have at present password syncing via a
> couple of
> tools.
> Maybe we're pretty typical.
>
> In the future (hopefully near future) we'd like to have
> a much
> more
> integrated solution. We are looking at either
> Enterprise IPA
> or Samba 4
> (saying that whenever that appears!)
>
> Features we'd look for:
>
> 1. True single sign on. If you say, log into a windows
> box and
> SSH into
> Linux you shouldn't be asked for a password and
> vice-versa if
> you say
> got to a Windows Sharepoint site in Firefox on Linux you
> should again
> not be asked for a password.
> Now I know this can be achieved already by a cross realm
> trust, but it's
> a bit of hassle to setup (IPA might help here by hiding
> some
> of the
> pain). One downside I have seen of this is that the
> Kerberos realm
> appears in the Windows drop down domains list on the login
> screen. We'd
> not really want Windows users logging into that for various
> reasons. Not
> sure if it's possible to hide a domain(realm) in
> windows from that
> dialog if it's trusted.
> Also with this approach telling windows AD that one
> user on a
> realm is
> equivalent to a user on another realm is a hassle to setup
> (again an IPA
> opportunity to ease the pain).
> And also, does the IPA's use of DNS to find directory
> servers
> interfere
> with AD's (i.e do they use the same mechanism/name spaces).
> I'd rather
> not maintain my Windows and Linux boxes in separate DNS
> zones
> just to
> keep various directory services happy (it makes DHCP with
> Dynamic DNS a
> non starter).
> 2. Support auto adding of Linux accounts when AD
> accounts are
> added
> would be nice, maybe based on a template of some kind, for
> things like
> automount points of home directories).
> Probably pulling in the Unix attributes from AD if that
> schema
> is loaded
> in AD, would be a nice feature.
> 3. Naturally, of course password syncing.
> 4. How will IPA support Samba servers? Just now we
> join Samba
> to AD and
> use a second krb5.conf file (with all the AD stuff in) that
> only samba
> uses (giving clean passwordless access to Samba shares
> for Windows
> users).
>
> My view of IPA vs potentially a Samba 4 solution would be:
>
> Samba 4
> =======
> No Cross Realm trust issues - As in it would issue krb
> tickets
> that were
> just tickets valid in AD.
>
> No separate management of a Linux directory. Having an AD
> account would
> automatically give you a Linux account.
> Can have windows systems authenticate safely to a Samba
> 4 server.
>
> IPA
> ===
> Better Linux targeting - Management of policies and
> patches.
>
> No hoops to jump through to support *ix features e.g
> automount maps
> Kerberos Service (host, NFS) keys etc.
> Easier client configuration
>
> Good vendor support and IPA is here now.
>
>
> Or is there no choice here and IPA will be able to pull
> in all
> Samba 4
> features.
> Have I missed anything or just given you job security
> for life...
>
> Thanks
> Colin
>
> This email and any files transmitted with it are
> confidential
> and are intended solely for the use of the individual or
> entity to whom they are addressed. If you are not the
> original recipient or the person responsible for delivering
> the email to the intended recipient, be advised that
> you have
> received this email in error, and that any use,
> dissemination,
> forwarding, printing, or copying of this email is strictly
> prohibited. If you received this email in error, please
> immediately notify the sender and delete the original.
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> <mailto:Freeipa-devel at redhat.com>
> <mailto:Freeipa-devel at redhat.com
> <mailto:Freeipa-devel at redhat.com>>
>
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
>
> -- Dmitri Pal
> Engineering Manager
> Red Hat Inc.
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com <mailto:Freeipa-devel at redhat.com>
> <mailto:Freeipa-devel at redhat.com
> <mailto:Freeipa-devel at redhat.com>>
>
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
>
>
> --
> Dmitri Pal
> Engineering Manager
> Red Hat Inc.
>
>
--
Dmitri Pal
Engineering Manager
Red Hat Inc.
More information about the Freeipa-devel
mailing list