Thanks Jakub. I'm sure. I've ssh'd directly into the servers with an account
that has no key. I'm still thinking something is configured differently with
the new AD DCs...I just have to convince them that it's on their end :-/.
=G=
From: Jakub Hrozek
Also, yes, setting ldap_sasl_authid does help, but it's bit awkward as right
now I am using general sssd.conf for all machines.
Having to include ldap_sasl_authid parameter means the configuration file is
different for every machine :-(
Ondrej
-Original Message-
From: Ondrej Valousek
Hi,
No, these are different forests, but a two way trust is established between
these two.
Ondrej
-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, August 06, 2018 9:36 AM
To: End-user discussions about the System Security Services Daemon
Subject:
Are mydomain and mydomain2 coming from a different forest?
with id_provider=ad sssd should work fine with domains from the same forest and
it should pick the right principal. If it doesn’t and setting ldap_sasl_authid
to shortname$@realm, then there must be a bug in the principal selection
SSSD does not update any attributes on its own. Are you sure the users are not
logging in with e.g. ssh public key which would bypass AD DCs during
authentication completely?
> On 3 Aug 2018, at 17:15, Galen Johnson wrote:
>
> Hey,
>
> I'm wondering if SSSD might not be updating some of the
This sounds like a bug. We should never update DNS with loopback addresses and
I’m sure we at least had checks in place to prevent this. Can you file a
ticket, please?
> On 3 Aug 2018, at 08:06, Kosseck, Adam MR wrote:
>
> UNOFFICIAL
>
> A number of DHCP linux workstation hosts in our
