On 2012-09-18, at 4:03 PM, Jakub Hrozek wrote: > On Tue, Sep 18, 2012 at 02:38:13PM -0400, Michael Mercier wrote: >> >> On 2012-09-18, at 4:03 AM, Jakub Hrozek wrote: >> >>> On Mon, Sep 17, 2012 at 11:17:47AM -0400, Dmitri Pal wrote: >>>>> [root@ipaserver2 ~]ifdown eth0 # NOTE: ipaserver2 is 172.16.112.8 >>>>> >>>>> [root@ipaclient ~]# SSSD_KRB5_LOCATOR_DEBUG=1 kinit mike >>>>> [sssd_krb5_locator] sssd_krb5_locator_init called >>>>> [sssd_krb5_locator] Found [172.16.112.8] in >>>>> [/var/lib/sss/pubconf/kdcinfo.MPLS.LOCAL]. >>>>> [sssd_krb5_locator] sssd_realm[MPLS.LOCAL] requested realm[MPLS.LOCAL] >>>>> family[0] socktype[2] locate_service[1] >>>>> [sssd_krb5_locator] addr[172.16.112.8:88] family[2] socktype[2] >>>>> [sssd_krb5_locator] [172.16.112.8] used >>>>> [sssd_krb5_locator] sssd_krb5_locator_close called >>>>> [sssd_krb5_locator] sssd_krb5_locator_init called >>>>> [sssd_krb5_locator] Found [172.16.112.8] in >>>>> [/var/lib/sss/pubconf/kdcinfo.MPLS.LOCAL]. >>>>> [sssd_krb5_locator] sssd_realm[MPLS.LOCAL] requested realm[MPLS.LOCAL] >>>>> family[0] socktype[1] locate_service[1] >>>>> [sssd_krb5_locator] addr[172.16.112.8:88] family[2] socktype[1] >>>>> [sssd_krb5_locator] [172.16.112.8] used >>>>> [sssd_krb5_locator] sssd_krb5_locator_close called >>>>> kinit: Cannot contact any KDC for realm 'MPLS.LOCAL' while getting >>>>> initial credentials >>>> >>>> Jakub, does this make sense to you? >>>> >>> >>> As stated elsewhere in this thread, bare kinit does not contact the SSSD >>> at all. You want to go through the PAM stack (with "su - mike" or "ssh >>> mike@ipaclient") in order to contact the SSSD so that the SSSD refreshes >>> the file. >>> >>> Does using "su - mike" refresh the file? >> >> When performing an 'su - mike' I will occasionally see a short delay (~2 >> seconds) when bringing the interfaces up and down on the servers. >> >> e.g. >> >> [root@ipaclient sssd]# su - mike > > ^^ Sorry, but can you re-run the test again and either su from another > non-root user or ssh into the client for instance? The reason is that > performing su as root would not contact the SSSD at all either. The > default PAM configuration for su includes "pam_rootok.so" which just > returns PAM_SUCCESS if the user who performs su has UID=0.
Hello, [mike@ipaclient ~]$ su - eric Password: # NOTE: no delay [eric@ipaclient ~]$ exit logout [root@ipaserver ~]ifdown eth0 [mike@ipaclient ~]$ su - eric Password: # NOTE: there is a delay here, ~5 seconds [eric@ipaclient ~]$ exit logout [root@ipaserver ~]ifup eth0 [root@ipaserver2 ~]ifdown eth0 [mike@ipaclient ~]$ su - eric Password: # NOTE: no delay [eric@ipaclient ~]$exit logout [root@ipaserver ~]ifdown eth0 [root@ipaserver2 ~]ifup eth0 [mike@ipaclient ~]$ su - eric Password: # NOTE: no delay [eric@ipaclient ~]$ exit logout There does not appear to be any problems when doing an su -. An addition note is that the ipaclient system had been sitting idle all night. Right before starting this test, I had to unlock the workstation. Thanks, Mike > > I kinda expect the result to be the same (at least for user who is not > recently cached) because the case of IPA we need to establish a GSSAPI > encrypted connection anyway so we'd talk to the KDC only to perform > initgroups. _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
