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.

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?

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.

There is a fix for this that works -  it's a very old Apache module
called mod_map_user, but it seems to only work on older versions of
Apache and I was hoping to avoid having to get that custom.

John



On 5/26/16 12:20 PM, Alexander Bokovoy wrote:
> On Thu, 26 May 2016, John Meyers wrote:
>> All,
>>
>> I have two-way trust established between IPA.DOMAIN.COM and
>> AD.DOMAIN.COM.  The users are sync'ed via a replication agreement and
>> password sync so u...@ipa.domain.com is the same person as
>> u...@ad.domain.com.
> Trust doesn't use synchronization. Your AD users are not IPA users and
> will never be with trust.
>
>> With "KrbLocalUserMapping On" in the Apache config, everything works
>> great for users in the IPA domain.  The realm is properly stripped off
>> and the end applications work very well with IPA.
>>
>> However, if a user from the AD domain authenticates, mod_auth_krb does
>> not strip off the realm and returns "krb5_aname_to_localname() failed:
>> Supplied data not handled by this plugin", passing the untouched string
>> to the end application which promptly chokes on it.  I tried adding
>> AD.DOMAIN.COM to "KrbAuthRealms" in the Apache configuration.  That
>> didn't do it.  Then I tried adding "auth_to_local =
>> RULE:[1:$1@$0](^.*@AD\.DOMAIN\.COM)s/@.*//"  to /etc/krb5.conf under the
>> IPA realm.  That STILL didn't do it and that is about the end of my
>> knowledge on kerberos realm mapping and stripping.
>>
>> Any help would be appreciated.
> SSSD on RHEL 7.x and Fedora 22+ provides a localauth plugin to Kerberos
> that allows to map Kerberos principal to a user known by SSSD.
> Effectively, u...@ad.domain.com principal would be mapped to
> u...@ad.domain.com by SSSD localauth plugin automatically and
> aname_to_localname() should succeed.
>
> mmod_auth_krb5 should work just fine with this setup if you remove
> 'KrbLocalUserMapping On" and would add all allowed realms to
> KrbAuthRealms.



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

Reply via email to