While I understand the expectations, it's not that easy for anyone there to help you without knowing context, without seeing logs, without seeing configuration files.
We (as SSSD team) have written down some documents that may help you and I sincerely would like to suggest people to take a look at those documents at the first thing. So, if you're having an issue, please, go through: https://docs.pagure.org/SSSD.sssd/users/index.html.
In our "User facing documentation" we have material about:
- Integrating with a Windows server using the AD provider
- Integrating with a Windows server using the LDAP provider
- Frequently Asked Questions
- Debugging and troubleshooting SSSD
- Troubleshooting SUDO
- Migrating from pam_krb5 to sssd
- How to file a useful SSSD bug report
All of those should be useful to, at least, give us or meaningful information that we would be able to start helping you!
Also, keep in mind that we do not spend our entire day checking #sssd. We still have to fix the bugs we have, come up with new cool stuff and whatnot. It means that just dropping a message on #sssd may not be the best way to get a quick answer (although sometimes it may work!).
So, please, do not be afraid of file an issue on https://pagure.io/SSSD/sssd/issues, following the instructions provided here. File the issue, provide us as much info as possible and drop us a ping on IRC in case we don't reply to your bug report quickly enough.
Last but not least, please, do not be this person:
21:27 -!- person [---] has joined #sssd
21:27 <person> Does there exist software worse than SSSD?
21:27 <person> I really don't think so
21:27 -!- person [---] has left #sssd 
Although I can understand how gratifying is to telling us how bad our software is (mind that I also do not think it's great), we'd like to hear from the user what makes it so bad and then, hopefully, be able to improve it somehow. But for doing this, we need meaningful bug reports, patience from our users to wait till the issue is fixed and to deal with us with some back and forth of testing packages and, mainly, understanding that we may have been busy with a bunch of different issues (which, please, does not mean that your issue is not important to us ... it is, we just need enough time to get to it!).