[Freeipa-users] mod_auth_krb issues with AD trust

[John Meyers]

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 user at IPA.DOMAIN.COM is the same person as user at AD.DOMAIN.COM.  I
>> guess there isn't a similar mapping on the IPA side such that when I
>> authenticate from user at 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.
>