[Freeipa-users] UPN suffixes in AD trust

[Sumit Bose]

On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote:
> On 06/24/2015 06:45 PM, Sumit Bose wrote:
> > On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote:
> >> Hi everybody,
> >> I established a bidirectional trust between an IPA server (version 4.1.0 on
> >> CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local.
> >> Everything is working fine, and I'm able to authenticate and logon on a linux
> >> host joined to IPA server using AD credentials (username at mydomain.local).
> >> But active directory is configured with two more UPN suffixes (otherdomain.com
> >> and sub.otherdomain.com), and I cannot logon with credentials using alternative
> >> UPN (example: john.doe at otherdomain.com).
> >>
> >> How can I make this possible? Another trust (ipa trust-add) with the same AD?
> >> Manual configuration of krb5 and/or sssd?
> > 
> > Have you tried to login to an IPA client or the server? Please try with
> > an IPA server first. If this does not work it would be nice if you can
> > send the SSSD log files from the IPA server which are generated during
> > the logon attempt. Please call 'sss_cache -E' before to invalidate all
> > cached entries so that the logs will contain all needed calls to AD.
> > 
> > Using UPN suffixes were added to the AD provider some time ago and the
> > code is available in the IPA provider as well, but I guess no one has
> > actually tried this before.
> > 
> > bye,
> > Sumit
> 
> First of all let me say that i feel like I'm missing some config somewhere..
> Changes tried in krb5.conf to support UPN suffixes didn't helped.
> I can only access the server vi ssh so I've attached the logs for a successful
> login for account1 at mydomain.local and an unsuccessful login for
> account2 at otherdomain.com done via ssh.
> 
> Bye and thanks for your help
> 

It looks like the request is not properly propagated to sub-domains (the
trusted AD domain) but only send to the IPA domain.

Would it be possible for you to run a test build of SSSD which might fix
this? If yes, which version of SSSD are you currently using? Then I can
prepare a test build with the patch on top of this version.

bye,
Sumit