[Freeipa-users] One way trusts

[Petr Spacek]

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 ... :-)

Petr^2 Spacek

>> If I might try to repeat the problem back to you to see if I got it
>> right...the factor which requires access to the corporate AD is setting
>> up a Kerberos cross realm trust. This is required so that machines in
>> IPA can connect directly to AD for authentication. This in turn is
>> necessary so that identities in the AD Kerberos Realm are correctly and
>> consistently identified as being sourced from AD. And of course, this
>> requirement is necessary for services in AD to recognize users and
>> groups in AD.
>>
>> Let me ask what is probably a series of dumb questions: What do I lose
>> if my FreeIPA server is set up as one of the 10 machines I can join to
>> the network as a regular user, and all the machines in IPA connect
>> directly to IPA? Could FreeIPA (current or future) be configured to
>> relay the credentials to AD either via Kerberos or using AD's LDAP
>> interface (binding as itself because it's joined to the AD domain)?  If
>> AD accepts the provided credentials can FreeIPA issue the user a ticket
>> in the FreeIPA realm? Would this look to AD like a bunch of users are
>> logging into the FreeIPA server machine?
> FreeIPA as a server provides own Kerberos realm. AD as a server provides
> its own Kerberos realm. In addition,  FreeIPA cannot be made a part of
> AD forest due to implementation limitations which are not solved yet. We
> choose to go with cross-realm trust in which FreeIPA and AD belong to
> different forests and trust each other through cross-forest domain trust
> in AD speak.
>
> One of implementation details of Kerberos in Active Directory is the
> fact that it assumes Kerberos realm is governing DNS namespace. At one
> DNS namespace level there could be only one Kerberos realm. If you have
> example.com DNS namespace under AD control, no machine in .example.com
> can belong to another Kerberos realm -- AD will not issue tickets for
> services in that realm even though it would trust it. .ipa.example.com
> can be used along with .example.com but there is no way to have
> foo.example.com in AD and bar.example.com in IPA and communicate over
> Kerberos.
>
> What you are talking about is living in AD namespace (both Kerberos and
> DNS) and yet somehow have FreeIPA working with AD users. This is not
> possible.
>
> If you want to use Linux clients in AD environments you can use SSSD on
> Linux directly connected to AD, without FreeIPA. This way, of course,
> you will not get any of FreeIPA benefits like access controls through
> HBAC rules and sudo rules.
>
> Dmitri had a talk last week outlining AD integration options we have:
> http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf
> http://www.youtube.com/watch?v=cS6EJ1L7fRI
>
>> I know this arrangement would sacrifice access to any of the AD
>> services by AD-users-on-the-IPA network. That's fine. If it's
>> technically feasible, tho, it gives me one server that can authenticate
>> both "corporate users" and "external users", and a central
>> administration point for the external network. It also plainly
>> differentiates between corporate users logged in on the corporate
>> network, and corporate users logged in on the "external network". I'd
>> consider that a good thing. Finally, if this is possible, it seems to
>> me that this stands a chance of reducing the number of places my
>> password is stored in plaintext.
> I wish it could be so simple...