> I'm not completely sure which release notes are you referring to, but
> this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
> changelog:
>
> * Fri Sep 2 2016 Jakub Hrozek - 1.14.0-32
> - Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
On Mon, Nov 07, 2016 at 08:28:45AM +0100, Troels Hansen wrote:
> Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this
> shiny new release that should fix a lot of the problems and current quirks we
> have, so I went through the release notes on SSSD in RHEL 7.3 and can't
Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this
shiny new release that should fix a lot of the problems and current quirks we
have, so I went through the release notes on SSSD in RHEL 7.3 and can't see any
patched being added since end September, and in particular a
On Mon, Sep 05, 2016 at 09:02:04AM +0200, Troels Hansen wrote:
>
>
> - On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhro...@redhat.com wrote:
> >> >We were debugging this yesterday with Troels and the logs said it's:
> >> >https://fedorahosted.org/sssd/ticket/3127
> >> >
> >> Fixed version
- On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhro...@redhat.com wrote:
>> >We were debugging this yesterday with Troels and the logs said it's:
>> >https://fedorahosted.org/sssd/ticket/3127
>> >
>> Fixed version is in 1.14 copr
>
> Thank you, btw another affected user confirmed that the
On Fri, Sep 02, 2016 at 09:27:57AM +0200, Lukas Slebodnik wrote:
> On (26/08/16 07:54), Jakub Hrozek wrote:
> >On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> >> On (25/08/16 11:30), Troels Hansen wrote:
> >> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>
On (26/08/16 07:54), Jakub Hrozek wrote:
>On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
>> On (25/08/16 11:30), Troels Hansen wrote:
>> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>> >getting a version 1.14.1, clean cache DB (complaing about cache being
On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> On (25/08/16 11:30), Troels Hansen wrote:
> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
> >getting a version 1.14.1, clean cache DB (complaing about cache being
> >old version),
> Upgrade to 1.14.1 should
On (25/08/16 11:30), Troels Hansen wrote:
>Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>getting a version 1.14.1, clean cache DB (complaing about cache being
>old version),
Upgrade to 1.14.1 should not require puring sssd cache.
If you are able to reproduce then please
On Thu, Aug 25, 2016 at 11:30:52AM +0200, Troels Hansen wrote:
> Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a
> version 1.14.1, clean cache DB (complaing about cache being old version), I
> can getent users, but log log in for no obvious reason (system error in
Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a
version 1.14.1, clean cache DB (complaing about cache being old version), I can
getent users, but log log in for no obvious reason (system error in secure.log).
Downgrading to official RHEL 7.2 SSSD-1.13 restores
On (25/08/16 10:05), Troels Hansen wrote:
>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>
>https://fedorahosted.org/sssd/ticket/2919
>
Meanwhile, you can test upstream version
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
LS
--
Manage your subscription
yes.
On Thu, Aug 25, 2016 at 10:05:36AM +0200, Troels Hansen wrote:
> Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>
> https://fedorahosted.org/sssd/ticket/2919
>
> Am I correct?
>
> - On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:
>
> >
Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
https://fedorahosted.org/sssd/ticket/2919
Am I correct?
- On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:
> Hmm, sometimes the man page actually helps
>
> It seems setting
Hmm, sometimes the man page actually helps
It seems setting "default_domain_suffix" to allow users to log in, without the
domain part changes use_fully_qualified_names default to true, without the
option of setting it false.
So, we have two options:
- Have users always use their full
On Thu, Aug 25, 2016 at 08:42:28AM +0200, Troels Hansen wrote:
> Yes and no
>
> Have tried setting it to both true and false, but doesn't make a huge
> difference.
>
> Current result with "use_fully_qualified_names = false"
>
> LDAP search from sssd_sudo.log shows SSSD finding a sudo
Yes and no
Have tried setting it to both true and false, but doesn't make a huge
difference.
Current result with "use_fully_qualified_names = false"
LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
Running RHEL 7.2:
ipa-client-4.2.0-15.el7_2.18
sssd-ipa-1.13.0-40.el7_2.12.x86_64
ipa-server-4.2.0-15.el7_2.18.x86_64
I have a sudo rule where I try to give sudo access based on a AD group.
# groups drext...@net.dr.dk
drext...@net.dr.dk : drext...@net.dr.dk ...
18 matches
Mail list logo