Hey Sumit, I'll get you the logs next week...however, we only have them for debug=9. The guy I was working with just left for the weekend. We have quite the collection.
What we're seeing for lookups by email is pretty consistently 500ms to 1s where lookups by account takes ~20ms once cached. Initial lookups for uncached ids are comparable. Is there any way to tell sssd not to break apart the address and use it as given? There are likely other areas that are likely less than optimally configured as well since this was a learning experience when we switched over to sssd. =G= ________________________________________ From: Sumit Bose <[email protected]> Sent: Friday, September 15, 2017 4:14 PM To: [email protected] Subject: [SSSD-users] Re: sssd email login performance EXTERNAL On Fri, Sep 15, 2017 at 06:00:55PM +0000, Galen Johnson wrote: > ?Bump. I can't tell if this made it to the list since I don't see my own > postings... > > > =G= > > > ________________________________ > From: Galen Johnson > Sent: Wednesday, September 13, 2017 9:12 AM > To: [email protected] > Subject: sssd email login performance > > > Hey, > > > We're looking into why our servers are suddenly less performant with > authentications than they used to be. We have SSSD set up to allow Can you specify how fast is was before and after? > users to login with their email address. However, the email addresses > are from various domains. It appears that sssd still attempts to > break apart the address and refer to the @user.domain. Is there a way SSSD has to break the name apart to figure out if the domain part belongs to a know or unknown domain. If the domain is unknown SSSD assumes that the name is an email address. In the other case it assumes a user name first and falls back to an email address is a matching user wasn't found. > to prevent sssd from attempting to lookup the user for a domain it > doesn't manage? I've looked through the man pages and had hoped that > setting "subdomain_provider = none" would help but it appears not to > be the case. We're still looking through the logs. Based on how > ldap/ad would normally handle this id ([email protected]), it's > typically expected behavior but it'd be nice to override this if > possible and just defer to the sssd domain. Can you send SSSD's pam and domain logs with debug_level=10 (see https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for details). Feel free to send them to me directly if you do not want to share them on a public list. > > > I hope that made sense. > > > thanks > > > =G= > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
