; >> > > > In all cases on both system pam_unix comes before pam_sss. For
> > >> example
> > >> > > in
> > >> > > > Fedora system-auth it is:
> > >> > >
> > >> > > On recent Fedora system
ess=1 default=ignore] pam_sss.so use_first_pass
> > > >
> > > > I tried reversing the lines and get a pam error about user not know
> (it
> > > is
> > > > an AD user which works fine on fedora).
> > > >
> > > > Also, it lo
m_pkcs11.so is used in smartcard-auth on Fedora.
> > Don't know if this is relevant or not.
> >
> > Steve
> >
> >
> > On Thu, Sep 28, 2017 at 11:40 AM, Sumit Bose via FreeIPA-users <
> > freeipa-users@lists.fedorahosted.org> wrote:
> >
> &
ike pam_pkcs11.so is used in smartcard-auth on Fedora.
Don't know if this is relevant or not.
Steve
On Thu, Sep 28, 2017 at 11:40 AM, Sumit Bose via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
> On Thu, Sep 28, 2017 at 11:29:27AM -0400, Steve Weeks via FreeIPA-users
>
We have smartcards (PIV) working just fine on Fedora 25 with FreeIPA client
version 4.4.4 (SSSD 1.14.2). However on Ubuntu 16.04, FreeIPA client
4.3.1, SSSD 1.13.4 the smartcard seems to be ignored.
The smartcard is readable using pkcs11-tools and pkcs15-tools on both
systems.
On both systems
We are running FreeIPA 4.4 on Centos 7 and trying to use radius
authentication.
Using radtest and radclient work fine and we can authenticate a user.
The radius proxy and secret are set to match the values from radclient.
The user has the radius check box checked and the other two fields set to
wrote:
> On Mon, Aug 14, 2017 at 11:05:23AM -0400, Steve Weeks via FreeIPA-users
> wrote:
> > This is what I get in sssd_pam.log:
> >
> > [pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][
> > ad.example.com]
> > [pam_reply] (0x0200): pam_reply c
oko...@redhat.com>
wrote:
> On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:
>
>> So we just got lucky with the fedora 25 systems?
>>
>> If we move the Linux system to host.ipa.example.com and leave the Windows
>> stuff as ad.example.com we should be fine?
choose ad.example.com
> and example.com. This is known to not work. If this is not your
> configuration then why did you choose it to obfuscate? Details matter.
>
>
>
>
>> On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy <aboko...@redhat.com>
>> wrote:
>>
>> On m
the user should be able to login.
Any idea what to try next or what logs to look at?
On Sat, Aug 12, 2017 at 7:37 AM, Lukas Slebodnik <lsleb...@redhat.com>
wrote:
> On (11/08/17 14:17), Steve Weeks via FreeIPA-users wrote:
> >We are running FreeIPA 4.4
> >
> >I just upgra
We are running FreeIPA 4.4
I just upgraded a system from fedora 25 to fedora 26 using dnf.
The first problem is that the mkhomedir option is lost. I've reinstated it
with:
authconfig --enablemkhomedir --update
The second problem is that AD users still can't login. This is a server
system
I can use 'id ad_user@ad_domain' command to see what groups an ad_user is a
member of.
Is there a way from the Linux command line to see who are the member of
some_ad_group@ad_domain are?
Thanks,
Steve
___
FreeIPA-users mailing list --
We are running FreeIPA 4.4. Even though sudo is listed as one of the
services in the HBAC rule, it seems like only the Sudo rules are what
really controls sudo. Sudo ignores what is in the HBAC rules.
Is this expected behavior? It doesn't really which way it really works, we
are more concerned
We want to let AD admins install new linux FreeIPA clients using their AD
credentials. It looks like if fails using kinit in the script. If you run
kinit 'AD\ad_admin' you get the same error.
Is it feasible to do what we want? Does it make sense? We already have a
system for managing the
14 matches
Mail list logo
