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

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

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:

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

Freeipa-users mailing list

Reply via email to