Re: [Freeipa-users] mod_auth_krb issues with AD trust
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
Re: [Freeipa-users] mod_auth_krb issues with AD trust
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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-users] mod_auth_krb issues with AD trust
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
Re: [Freeipa-users] mod_auth_krb issues with AD trust
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. -- / Alexander Bokovoy -- 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
[Freeipa-users] mod_auth_krb issues with AD trust
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. 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. John -- 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
