Thanks! For the use case where IPA, and not AD, is the authoritative source it's actually working out very well if we can solve this last issue. With regard to the work in 4.4, from what I've read about it, I am not 100% sure it will work. In this case the "alternate principal" is a cross-domain one. I'm not expecting IPA to issue a ticket for it. What I'm looking for is what AD can do -- if you authenticate with a principal from a trusted domain AND you find a match for that principal as an "alternate" for a user on the IPA domain, from a directory perspective don't treat that a foreign user (e.g. assign a posix UID from the foreign domain's range, apply external group mappings) but rather accept the foreign principal as the local IPA domain user itself and apply the UID, group membership, etc as if the user authenticated with a local IPA principal.
John On 5/26/16 1:28 PM, Alexander Bokovoy wrote: > On Thu, 26 May 2016, John Meyers wrote: >> Alexander, >> >> I use both trust AND synchronization. Our IPA is authoritative. We add >> the "ntUser" objectclass and related attributes and 389ds automatically >> creates a corresponding AD account and password changes are likewise >> propagated. This is necessary since FreeIPA can not act as a Global >> Catalog. It works fantastically. > Interesting use of winsync. :) > >> On the AD side, we use the "altSecurityIdentities" attribute to tell AD >> that u...@ipa.domain.com is the same person as u...@ad.domain.com. I >> guess there isn't a similar mapping on the IPA side such that when I >> authenticate from u...@ad.actifio.com IPA will would recognize it as an >> alias of a local domain user? > We have some code in 4.4 that will support aliases for Kerberos > principals more clearly. > >> I did try your suggestion. Removing KrbLocalUserMapping does indeed >> clear up the aname_to_localname() issue, however, now REMOTE_USER gets >> the fully qualified realm string for all users, including the native IPA >> domain users, and the downstream applications that consume it break as >> they just expect a username. > Well, what about using mod_rewrite to reassemble REMOTE_USER? If > REMOTE_USER is set by mod_auth_kerb, use mod_rewrite's RewriteRule > [E=NEW_REMOTE_USER:%1] and RewriteCond before that to drop the suffix. > > This implies you have ability to redefine variable looked up by the > applications from REMOTE_USER to NEW_REMOTE_USER. > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project