On Sat, Dec 12, 2015 at 01:34:53PM +0100, Stefano Cortese wrote:
>
>
> This is expected because if either the principal or the user name is
> known to SSSD the localauth plugin will take control because by default
> the added modules are registered first (see [plugins] section of man
> krb5.c
Sumit Bose wrote:
On Tue, Dec 08, 2015 at 02:33:40PM +0100, Stefano Cortese wrote:
Hi Sumit
yes it works commenting out theĀ line 'enable_only = sssd' and making
the file immutable , namely the .k5login file is read and enforced.
But respect to the solution emptying completely the
On Tue, Dec 08, 2015 at 02:30:54PM +0100, Stefano Cortese wrote:
>Jakub Hrozek wrote:
>
> On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
>
>
> So the questions are:
> - is there another cleaner way to exclude the localauth sssd plugin
> (considering that the configurati
On Tue, Dec 08, 2015 at 02:33:40PM +0100, Stefano Cortese wrote:
> Hi Sumit
> yes it works commenting out theĀ line 'enable_only = sssd' and making
> the file immutable , namely the .k5login file is read and enforced.
> But respect to the solution emptying completely the snippet, it is lost
> the p
Simo Sorce wrote:
I am attempting to log from a local machine as "userA" using the
credentials of a "service principal" defined in IPA to a remote machine
as "userB"
The userB principal is resolvable on the remote host via "getent passwd
userB" because it is a user principal.
Also
Sumit Bose wrote:
On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
So the questions are:
- is there another cleaner way to exclude the localauth sssd plugin
(considering that the configuration snippet is recreated at every sssd
restart)?
Sumit Bose wrote:
On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
So the questions are:
- is there another cleaner way to exclude the localauth sssd plugin
(considering that the configuration snippet is recreated at every sssd
restart)?
Jakub Hrozek wrote:
On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
So the questions are:
- is there another cleaner way to exclude the localauth sssd plugin
(considering that the configuration snippet is recreated at every sssd
restart)?
On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
> >> So the questions are:
> >> - is there another cleaner way to exclude the localauth sssd plugin
> >> (considering that the configuration snippet is recreated at every sssd
> >> restart)?
> >
> >Can you test if this hack would help
On Mon, 2015-12-07 at 18:04 +0100, Stefano Cortese wrote:
> > > So the questions are:
> > > - is there another cleaner way to exclude the localauth sssd plugin
> > > (considering that the configuration snippet is recreated at every sssd
> > > restart)?
> >
> > Can you test if this hack would help:
On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote:
> >> So the questions are:
> >> - is there another cleaner way to exclude the localauth sssd plugin
> >> (considering that the configuration snippet is recreated at every sssd
> >> restart)?
> >
> >Can you test if this hack would help
> So the questions are:
> - is there another cleaner way to exclude the localauth sssd plugin
> (considering that the configuration snippet is recreated at every sssd
> restart)?
Can you test if this hack would help:
# service sssd stop
# rm /var/lib/sss/pubconf/krb5.include.d/localauth_p
On Sat, Dec 05, 2015 at 06:44:45PM +0100, Stefano Cortese wrote:
> Hello,
> we have a number of ipa 3.0 clients that have been upgraded from Scientific
> Linux 6.6 to 6.7 and after the upgrade both the .k5login authorization and
> auth_to_local_names mappings don't work anymore as before.
> The env
13 matches
Mail list logo