[Freeipa-devel] freeIPA and NIS

[Colin Simpson]

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.