[Freeipa-users] One way trusts

[Alexander Bokovoy]

On Wed, 15 Jan 2014, Petr Spacek wrote:
>On 15.1.2014 06:49, Alexander Bokovoy wrote:
>>On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
>>>
>>>>Both AD integration solutions we have (synchronization and
>>>>cross-forest domain trusts) assume having higher level access
>>>>privileges at the time integration is set up.
>>>
>>>My problem here is that I'm too ignorable. :) There's over 15000 users
>>>in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
>>>is being absorbed into the next level up the chain (Forest Service AD
>>>is going to become a part of the overall USDA AD). Then I'm an even
>>>smaller fish, relatively speaking.
>>>
>>>>I'm unaware of other
>>>>mechanisms that would give you the same flexibility and level of
>>>>privilege separation between the AD and IPA domains.
>>>
>>>?? The current solution using the LDAP interface to AD (and a
>>>metadirectory to merge "external users") provides privilege separation
>>>and the flexibility to add external users. I don't need more; I just
>>>need it to be less clunky. It weakens security, of course, as my AD
>>>password is stored in various plaintext configuration files for each
>>>application needing binding credentials to search for users in AD. I
>>>also have an index to which files contain my password, as it forms a
>>>"password-change-checklist" which I need to run thru every 60 days.
>>You got me confused on this. You cannot run FreeIPA in such mode because
>>FreeIPA is not a client-only solution, it is server and client solution.
>>If you want to stay with an approach where AD is the data source, IPA
>>server part will not be usable to you and what left is SSSD on the
>>client side.
>>
>>SSSD is capable to work as an AD client.
>>
>>However, if you want all your Linux machines to be enrolled to IPA, they
>>cannot be enrolled to AD at the same time, this will not work.
>
>Alexander and Jakub, would it be possible to enroll a machine as IPA 
>client and then manually add AD domain do SSSD configuration?
>
>I guess that this configuration theoretically allows to use one set 
>of users ("external" users) from IPA and also use another set of 
>users ("internal" users) from AD at the same time. The obvious 
>disadvantage is that you have to carefully type username at DOMAIN.
>
>This naturally does 'separation' of external and internal users 
>because AD would know nothing about IPA users and the other way 
>around.
>
>Could it work? I'm just theorizing ... :-)
You can setup SSSD to use multiple sources and you can setup krb5.conf
to serve multiple realms. What you cannot do is to mix and match within
the same DNS namespace over multiple Kerberos realms without being
prepared to things not working now and then.

Suppose you have example.com DNS namespace and four machines:
dc.example.com, win.example.com, lnx.example.com, and ipa.example.com.
They are AD DC, Windows machine, Linux server, and IPA master.

dc.example.com would host Active Directory and own example.com DNS
namespace, including DNS server which hosts example.com zone. Kerberos
realm for AD will be EXAMPLE.COM

ipa.example.com would host IPA master: LDAP server, KDC for IPA realm,
DNS server for example.com with IPA entries. You'd need to define
different Kerberos realm name since you'll need to have different
configurations in krb5.conf on your lnx.example.com. Let's say, it is
IPA-EXAMPLE.COM.

win.example.com is enrolled to AD. It consults dc.example.com for DNS
and Kerberos on logon. It will attempt to get Kerberos tickets to any
service in .example.com through Active Directory domain controller
dc.example.com.

lnx.example.com is enrolled to IPA. You can either manually set up
configuration to point to ipa.example.com everywhere where needed
(through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point
/etc/resolv.conf to ipa.example.com and assume that split-brain DNS will
work when communicating with win.example.com.

lnx.example.com could be configured to have a second domain in
/etc/sssd/sssd.conf that points to dc.example.com. You need to create a
computer object for lnx.example.com in AD, you need to fetch service
key for host/lnx.example.com at EXAMPLE.COM from AD, and later
maintain it refresh over time but it is possible.

The very same is needed for IPA side. I think we already had discussion
on this list how to setup SSSD with two different domains pointing to
different Kerberos realms last week but in that case there were
non-overlapping DNS namespaces for both Kerberos realms.

Now, when an SSH client (PuTTY) on win.example.com will want to connect
to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket
to service host/lnx.example.com at EXAMPLE.COM based on own AD credentials.
One will be able to login with this ticket to lnx.example.com but
nothing from IPA side will apply here: sudo and HBAC rules don't know
anything about these users and authentication source.

In such situation what I question is the need for IPA deployment at all.
If all users will be coming from AD and they are not visible to IPA and
not using IPA features, why to spend time with FreeIPA at all?

-- 
/ Alexander Bokovoy