[Freeipa-users] IPA, Samba and AD

Mon Sep 23 07:54:23 UTC 2013

Suppose we would "bite the bullet" and *move* IPA to another domain. This
would be a subdomain (IPA.MYCOMP.EDU). I have to install 2 new IPA servers.
No problems there. However, I have to migrate the data. That is a real
problem, I think. For HBAC rules, SUDO rules, etc we can do this manually.
However Users and DNS is quit a lot *and* we want to migrate the user
passwords.

For DNS we could use zone transfers

But for user passwords?

Is there IPA export import type of functionality (in RHEL64) that can
provide this?

Met vriendelijke groeten,
*
Fred van Zwieten
*
*Enterprise Open Source Services*
*
Consultant*
*(woensdags afwezig)*

*VX Company IT Services B.V.*
*T* (035) 539 09 50 mobiel (06) 41 68 28 48
*F* (035) 539 09 08
*E* fvzwieten at vxcompany.com
*I*  www.vxcompany.com

Seeing, contrary to popular wisdom, isn’t believing. It’s where belief
stops, because it isn’t needed any more.. (Terry Pratchett)

On Sun, Sep 22, 2013 at 10:37 PM, Simo Sorce <simo at redhat.com> wrote:

> On Sun, 2013-09-22 at 18:09 +0200, Fred van Zwieten wrote:
> > Well, as explained in this thread, the problem here is that we have an
> > IPA domain named "MYCOMP.EDU" _and_ an AD domain named "MYCOMP.EDU" as
> > well. Both have there own DNS servers. It's beyond the scope of this
> > mail to explain why we have named them exactly the same, and we do
> > wish we didn't, but this is the current situation. Migrating any of
> > these to another domain name would be the best solution but would
> > involve quite a lot of work.
> >
> >
> > So now we have a bunch of SAMBA services running on RHEL6.4 boxes that
> > are IPA-clients and we would like to give the AD users access to them.
> > How to proceed? We cannot use an IPA - AD trust, because both domains
> > have the same name. We also cannot make the SAMBA services member of
> > the AD domain, because the server itself is an IPA-member and
> > krb5.conf already points to the IPA servers for domain MYCOMP.EDU..
> > Also /etc/resolv points to the DNS services of IPA.
>
> > See my problem? If not, read the whole mail thread..
> >
> I haven't read all the thread way back, but what you *could* do is to
> configure Samba in a completely independent way for the rest of the
> machine.
>
> Join just the samba file server to the Ad domain but use net rpc join
> and configure samba with security = domain not security = ads, basically
> treat the AD domain as a legacy NT4 domain.
> It will allow you to use only NTLM, no kerberos.
>
> The main issue will be how to provide users to the system.
>
> If you can map the AD domain SIDs in a different ID range you could run
> both the normal sssd and add on top winbindd configured with idmap rid
> to map the Ad domain SIDs in a range that do not conflict and use fully
> qualified names for users so you have no chance of conflict with the
> native IPA users.
>
> It *might* work, but you'd have to try to know and you need to fully
> understand the nsswitch interactions as well as winbindd configuration
> nuissances to pull it off. It will be a fragile setup, in any case.
> >
> >
> > It get's even more complicated. The AD "MYCOMP.EDU" domain has a trust
> > with an AD "OTHERCOMP.EDU" and users in "OTHERCOMP.EDU" must access
> > resource in "MYCOMP.EDU". There is a trust between the AD domain
> > "MYCOMP.EDU" and the AD domain "OTHERCOMP.EDU". This works. We have
> > some shares on a NetApp filer who is member of the AD domain
> > "MYCOMP.EDU" and people from "OTHERCOMP.EDU" can successfully access
> > those shares (given correct group membership offcourse).
> >
> >
> > Now, we would like to have peoply in the AD domains "OTHERCOMP.EDU"
> > and "MYCOMP.EDU" to access shares served by SAMBA services on RHEL64
> > machines that are IPA clients in the IPA domain "MYCOMP.EDU".
> >
> >
> > As all out RHEL servers are IPA clients by default we also want the
> > servers running SAMBA to stay IPA-clients for system level central
> > administration of users, groups, sudo policies, hbac, etc.
> >
> >
> > Now, how to proceed:
> >
> >
> > I see 2 possible solutions (besides byting the bullet and name change
> > one of the MYCOMP domains):
>
> Byting the bullet will be by far the easiest I think, although
> *changing* here really means installing a new domain and slowly phasing
> off the old one.
> >
> > Solution 1:
> > Create an intermediary domain. This gives the following trust
> > relationships:
> >
> >
> > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--trusts--
> > AD(MYCOMP-INTERMEDIARY.EDU) <--trusts-- IPA(MYCOMP.EDU). I don't like
> > this one and I am not even sure it solves my problem. Another problem
> > involves adding to (virtual) Windows boxes to maintain this domain.
>
> We do not have yet full support for transitive trusts, so it will not
> work with any released buts, although we *are* getting close.
>
> >
> > Solution 2:
> > Make a SAMBA only domain. Make one of the SAMBA servers a PDC and one
> > BDC. Make a NT-4 style trust to the AD domain MYCOMP.EDU. NT-4 style
> > to have no Kerberos involvement as that is used for IPA. Also no DNS
> > clashes as NT-4 style doesn't use DNS SRV records.
>
> I do not recall how good the old NT domain stuff is wrt trusts, but it
> is certainly a possibility, you have the same Winbindd issues as above
> plus having to manage to add the necessary samba objectlasses in the IPA
> tree manually when needed for the local users, or you'll have to keep a
> separate database, if you do not care exporting samba share tfor IPA
> users, you may just not create anything beyond a few admin users locally
> on the samba boxes and rely entirely on winbindd to provide trusted
> domain users. However at this point you can as well use the solution I
> proposed you above.
>
> > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--nt-4-trusts--
> > NT4(MYCOMP-SAMBA)
> >
> >
> >
> > Now, giving correct group memberships and all, users in OTHERCOMP.EDU
> > should be able to access shares in MYCOMP-SAMBA.
> >
> >
> > Correct?
> >
> Once you get through a correctly working trust you should be able to
> deal with this relatively easily, yes.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130923/dfa8e2c5/attachment.htm>