[Freeipa-interest] RE: NIS Migration and IPA

Manny Vellon mvellon at centeris.com
Mon Nov 26 18:20:25 UTC 2007 

Some comments on the two approaches:
 
1) Synchronization. If this solution incorporates synchronization of passwords, then this approach is gradual in transition to IPA, but one that is not accompanied by a gradual improvement in security. The issue with NIS is that it communicates password hashes "in the clear" (the hashes, not the passwords). A client can do a "ypcat" and grab the passwd file then employ dictionary attacks on it. If you're synchronizing your IPA data with the NIS server (and include passwords in the synchronization), you're effectively compromising the value of the IPA directory. Although the move from NIS is gradual, the improvement in security is nil until the last NIS server is turned off and all the passwords are changed in IPA.
 
2) Virtual directory. The difficulty in migrating from NIS to another directory is not the difficulty of migrating the actual NIS data. Once you have changed all the clients to talk to IPA instead of to the NIS server, you're 99% of the way there; write an import utility to move the data into IPA and get it over with.
 
The biggest pain in NIS migration is something that Karl's mail touched on briefly: dealing with conflicting id's on different NIS servers.  Associating a user account with different UIDs and GIDs depending on what computer he's logged into requires some thought.
 
In Centeris Likewise Identity, we do this with the concept of "cells". Centrify calls these "Zones" whereas Quest refers to "Unix Personalities".  The basic idea in all three products is the same: the client computer is associated with a particular cell. In our case, we do this based on the location of the computer object (established when the computer is "joined" to Active Directory/Keberos). A cell contains name<->ID mapping that's relevant for the computers associated with the cell. In a sense, we allow users to have different sets of attribute values depending on context.  When we migrate a NIS server int Microsoft AD, we create a cell for it and import its account information into that cell. We then take all the client machines that spoke to that server and we join them to the appropriate organizational unit in the AD hierarchy that corresponds to our cell.  The client software "finds" its cell information in AD and uses it to perform name<-->ID mapping.  There is a lot of magic involved in order to deal with orphaned objects (e.g. when you delete a user, you have to delete its information in all cells). It's also important to consider caching and indexing issues (we make heavy use of Global Catalog searches) in order to get good performance (especially when you do something like "ls -l").
 
Free IPA could try to do something smarter here. If the additional data could be attached to the user (and group) objects then this would avoid the need for the separate cell data and would avoid the orphaned object problem. Multi-valued attributes might help here, but I can foresee problems with them. When mapping an ID to a name in a particular cell, you want to be able to search for (uidNumber=500), for example, but ONLY for data in the relevant cell. A standard LDAP search on a multivalued uidNumber would match an object if ANY of its values was 500.  Another approach might be to allow user objects to contain other objects (the Microsoft schemas don't let you do this). The per-cell data could be contained by the user object but would be deleted en-masse with the user.
 
 
 
________________________________

From: freeipa-interest-bounces at redhat.com on behalf of freeipa-interest-request at redhat.com
Sent: Mon 11/26/2007 9:00 AM
To: freeipa-interest at redhat.com
Subject: Freeipa-interest Digest, Vol 5, Issue 5



Send Freeipa-interest mailing list submissions to
        freeipa-interest at redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.redhat.com/mailman/listinfo/freeipa-interest
or, via email, send a message with subject or body 'help' to
        freeipa-interest-request at redhat.com

You can reach the person managing the list at
        freeipa-interest-owner at redhat.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Freeipa-interest digest..."


Today's Topics:

   1. NIS migration and IPA (Karl Wirth)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Nov 2007 11:18:25 -0500
From: Karl Wirth <kwirth at redhat.com>
Subject: [Freeipa-interest] NIS migration and IPA
To: freeipa-interest at redhat.com, freeipa-devel at redhat.com
Message-ID: <474AF1D1.6090104 at redhat.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

A few of us discussed how, with freeIPA, to make NIS migration as easy
as possible for organizations.  Here are the ideas we came up with:

/Problem Statement from Organizations' Perspective:/  For compliance,
organizations need to have one userid for their users and that userid
must have a strong password policy.  Today, many organizations have
multiple NIS domains and often a user will have different (and
potentially conflicting) userids in the different domains.  The same
problem is true for user groups, machines, and machine groups.   NIS is
EOLd by Sun and is also not seen as compliant given the strength and
method of its password encryption.  Organizations generally are looking
to reconcile their uids and guids and move to an LDAP server. 
Hopefully, IPA can be a good solution for them.

/Problem statement from IPA perspective.   /If someone just tries to
deploy IPA into a heavy NIS environment, it may get adoption in some new
areas of deployment, but it will be hampered in adoption by the fact
that it is difficult for organizations to migrate off of NIS onto IPA. 
Therefore, whatever we can do to ease the pain of migration will help.

/Pain of Migration/:   What has to happen to accomplish a migration? 
The following are not necessarily in order:
(i).  Data has to be dumped from different NIS domains and moved into
IPA.  If it is dumped slowly over time then some kind of data
synchronization is necessary.
(ii).  Clients need to point at IPA not NIS.
(iii).  NIS data has to be reconciled/mapped so the user has only one userid
(iv).  User must end up using just one password with their one userid
(v).  Legacy clients that can only talk NIS need to continue being supported
Note.  All of this happens on production often mission critical servers
so the migration has to be slow, sure, and not big bang or risky in any
way.

/Requirement regardless of approach:    /We need to satisfy (v) above by
having a NIS server front end IPA

/Option A.  Synch/
- Using some kind of migration tool, organization maps data in a NIS
domain to the IPA userID
- Organization dumps a NIS domain and moves data into a tree in IPA's
Directory and sets up mapping from that tree to the IPA userID
- IPA has a synch capability that keeps that NIS domain and IPA's data
in synch
- Slowly organization points clients from the NIS domain to hit IPA via
LDAP instead of the NIS server via NIS.
- Slowly organization removes data from the tree in IPA and just uses
the authoritative IPA userid
- Repeat for next NIS domain
- Pros:  Slow migration.  Leaves NIS server up while IPA is being tried
out.  Gives quick fall back if something goes wrong.
- Cons: Data synchronization

/Option B.  Virtual/
- Using some kind of migration tool, organization maps data in a NIS
domain to the IPA userID
- IPA has a virtual directory capability that enables it to query the
existing NIS domain
- Slowly organization points clients from the NIS domain to hit IPA via
LDAP instead of the NIS server via NIS.  IPA is proxying their LDAP
request out to the NIS server and proxying the response back.
- Once all the clients are migrated, organization dumps NIS data and
puts it into tree of IPA LDAP.
- Slowly organization removes data from the tree in IPA and just uses
the authoritative IPA userid
- Repeat for next NIS domain
- Pros: No synchronization
- Cons: The night the NIS server is taken down, there is risk as the NIS
server must be taken down and the data migrated in one step.

Are the above two options correct?
Which is better for organizations?
Are there other options that I missed?

Regards,
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.redhat.com/archives/freeipa-interest/attachments/20071126/02bec79b/attachment.html

------------------------------

_______________________________________________
Freeipa-interest mailing list
Freeipa-interest at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-interest

End of Freeipa-interest Digest, Vol 5, Issue 5
**********************************************


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 9798 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-interest/attachments/20071126/3aa68d04/attachment.bin>

More information about the Freeipa-interest mailing list