I’ve got a prototype setup for cross-realm operations. I don’t know if that’s 
useful for you or not. I don’t have control over “my” AD, and I’m managing this 
during our CIO’s migration from one AD realm to another (so duplicate users 
having distinct DNs and Kerberos principals are the norm, rather than the 
exception). I have three upstreams: FreeIPA, and Corporate AD A and B.

My non-FreeIPA users setup is in two stages, meaning two separate OpenLDAP 
servers. I couldn’t squash them down onto one server, but you might be smarter 
than me:

1] A “remapping” metadirectory server, which combines all of the foreign users 
from all three upstreams into one DIT (although each upstream gets its own OU). 
This server’s job is to make sure that a single LDAP query can return results 
from any of the upstream servers. It stores nothing locally and masks out most 
of the upstream info. LDAP binds are passed thru to upstream.
2] A “translucent proxy” server, which does no remapping, but lets me 
add/override attributes. Also have RFC2307 group stored here.

FWIW, I don’t have a trust between any AD and FreeIPA. The metadirectory server 
binds as me against AD (via a keytab and k5start). You can get pretty far 
without a trust, and without the ability to create groups on the AD side.

My goal is to set myself up to take advantage of “views” when they make it into 
FreeIPA. The real objective, though, is to propagate the cross realm 
functionality enjoyed for the last four years with my ldap/padl setup into a 
freeipa/sssd environment. Long term, I want FreeIPA to internalize my sketchy 
prototype setup and manage uid/uidNumber/gidNumber/loginShell/homeDirectory 
overrides for my linux domain in some sensible and convenient way.

I’m trying to implement the “umich_schema” (man idmapd.conf) to enable cross 
realm NFS, eventually, if I ever get a trust. Ideally, this could also be used 
by sssd to map GSSAuthName to username, particularly if a person has more than 
one GSSAuthName.

Dumb and persistent sometimes trumps smart. ☺

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Daniel Shown
Sent: Monday, August 11, 2014 3:04 PM
To: Alexander Bokovoy
Cc: freeipa-users
Subject: Re: [Freeipa-users] about AD trusts and passthrough authentication

Right, that's what I've got at this point. I just wanted to make sure I wasn't 
missing something. Unfortunately, that architecture won't work for me (mostly 
for political reasons instead of technical ones). I guess I'll be digging into 
pass through auth to see if I can get that working.


Daniel Shown,
Linux Systems Administrator
Advanced Technology Group
Information Technology Services<http://www.slu.edu/its>
at Saint Louis University<http://www.slu.edu/>.

"The aim of education
is the knowledge,
not of facts,
but of values."
— William S. Burroughs

"I’m supposed to be
a scientific person
but  I use intuition
more than logic
in making basic
— Seymour R. Cray

[Image removed by sender.]

On Mon, Aug 11, 2014 at 3:08 PM, Alexander Bokovoy 
<aboko...@redhat.com<mailto:aboko...@redhat.com>> wrote:
On Mon, 11 Aug 2014, Daniel Shown wrote:
I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I
be able to map AD users in an AD trust to to corresponding FreeIPA users?
i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber,
gidnumber, home, etc.?
Users from a trusted forest are treated as separate users. They have
their own identities and get IDs from either Active Directory (if POSIX
compatibility is enabled at AD) or from special ID range allocated for
them in IPA.

You can include these users (and groups, it doesn't matter what is what)
into special type of groups in IPA, called "external" groups. These
groups, in turn, can be members of existing POSIX groups from IPA. If
done so, your AD users will become members of appropriate POSIX groups
from IPA by means of nested membership.

These POSIX groups then can be used to apply SUDO or HBAC rules against
AD users.

/ Alexander Bokovoy

This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to