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
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
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.
> 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
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 environment is linux only with no AD/Samba
Essentially we are using
