[Freeipa-users] One way trusts

[Alexander Bokovoy]

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.

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

-- 
/ Alexander Bokovoy