[Freeipa-users] UPN suffixes in AD trust

Thu Jul 9 10:49:07 UTC 2015

On Thu, Jul 09, 2015 at 12:36:53PM +0200, Giorgio Biacchi wrote:
> On 06/29/2015 03:11 PM, Sumit Bose wrote:
> > On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote:
> >> On 06/29/2015 10:30 AM, Sumit Bose wrote:
> >>> On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote:
> >>>> On 06/26/2015 08:06 PM, Sumit Bose wrote:
> >>>>> On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 06/26/2015 02:38 PM, Sumit Bose wrote:
> >>>>>>> On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote:
> >>>>>>>> On 06/25/2015 05:44 PM, Sumit Bose wrote:
> >>>>>>>>> On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>> On 06/25/2015 02:10 PM, Sumit Bose wrote:
> >>>>>>>>>>> On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote:
> >>>>>>>>>>>> On 06/25/2015 12:56 PM, Sumit Bose wrote:
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>> I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for
> >>>>>>>>>>>> any test.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Here's the packages version for sssd:
> >>>>>>>>>>>>
> >>>>>>>>>>>> sssd-common-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-krb5-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> python-sssdconfig-1.12.2-58.el7_1.6.noarch
> >>>>>>>>>>>> sssd-krb5-common-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-ipa-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-libwbclient-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-ad-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-ldap-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-common-pac-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-proxy-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>> sssd-client-1.12.2-58.el7_1.6.x86_64
> >>>>>>>>>>>
> >>>>>>>>>>> Please try the packages at
> >>>>>>>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 .
> >>>>>>>>>>>
> >>>>>>>>>>> bye,
> >>>>>>>>>>> Sumit
> >>>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>> I've installed the new RPMs, now if I run on the server:
> >>>>>>>>>>
> >>>>>>>>>> id account1 at mydomain.local
> >>>>>>>>>> id account2 at otherdomain.com
> >>>>>>>>>> id account2 at sub.otherdomain.com
> >>>>>>>>>>
> >>>>>>>>>> all the users are found but I'm still unable to log in via ssh with the accounts
> >>>>>>>>>> @otherdomain.com and @sub.otherdomain.com.
> >>>>>>>>>>
> >>>>>>>>>> In attachment the logs for unsuccessful login for user account2 at otherdomain.com.
> >>>>>>>>>
> >>>>>>>>> Bother, I forgot to add the fix to the pam responder as well, please try
> >>>>>>>>> new packages from
> >>>>>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 .
> >>>>>>>>>
> >>>>>>>>> bye,
> >>>>>>>>> Sumit
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>> I've updated all the packages but still no login.
> >>>>>>>>
> >>>>>>>> Logs follows.
> >>>>>>>
> >>>>>>> I found another issue in the logs which should be fixed by the build
> >>>>>>> from http://koji.fedoraproject.org/koji/taskinfo?taskID=10217756 .
> >>>>>>>
> >>>>>>> Please send the sssd_pam log file as well it might contain more details
> >>>>>>> about what goes wrong during authentication.
> >>>>>>>
> >>>>>>> bye,
> >>>>>>> Sumit
> >>>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>> packages update, sssd and kerberos services restarted, cache flushed but still
> >>>>>> no login on the IPA server.
> >>>>>>
> >>>>>> As before, logs attached. I've also included the logs generated by the restart
> >>>>>> of sssd service because there were no logs in sssd_pam.log when trying to
> >>>>>> authenticate.
> >>>>>>
> >>>>>> Debug level is set to 6 in the sections:
> >>>>>>
> >>>>>> [domain/ipa.mydomain.local]
> >>>>>> [sssd]
> >>>>>> [nss]
> >>>>>> [pam]
> >>>>>>
> >>>>>> of /etc/sssd/sssd.conf, please tell me if this is enough or if I have to
> >>>>>> increase it.
> >>>>>>
> >>>>>
> >>>>> so far it is sufficient. I have another build for you to try at
> >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=10219343
> >>>>>
> >>>>> Thank you for your patience.
> >>>>
> >>>> Thanks for your help!!
> >>>>
> >>>> Still no successful login.. Logs attached
> >>>
> >>> Please increase the debug level at least for the domain log to 9 and
> >>> attach the krb5_child log as well.
> >>>
> >>
> >> Debug level increased and logs attached..
> >>
> >> I'm sending this email again because I forgot to reply to the list...
> > 
> > Unfortunately the IPA KDC cannot redirect the Kerberos request to the
> > AD realm because of https://fedorahosted.org/freeipa/ticket/3559. I'll
> > try to figure out if this can be bypassed by tuning sssd.conf and
> > krb5.conf. Please allow 2 days for setting up a suitable environment and
> > testing different configurations.
> 
> Hi,
> I saw new activity on https://fedorahosted.org/freeipa/ticket/3559 but I also
> saw that we're far away from 4.2.1 milestone.
> 
> The deploy of freeIPA is a core part for the switch of a traditional dual boot
> pc lab into a VDI based on RHEV that we planned for september. I don't want to
> put rush on this, but I need to understand if it can be done on not to choose
> how to proceed. Is there any chance to have something working (patched
> version/alpha version) in our scenario with those extra UPNs in time to allow us
> to do the switch? If not we have to postpone the deployment during Christmas
> holidays.

Sorry for the delay. So far I didn't found a reliable way to make it
work with the existing code. So it looks fixing #3559 is needed. I will
have a closer look next week to see what is missing for #3559 and what
effort it would be to solve it.

bye,
Sumit

> 
> Thanks for your kind attention
> -- 
> gb
> 
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34