I've been using SSSD 1.9 for a while now, and it works great. I'm setting up a Fedora 19 laptop which came with a newer version of SSSD, 1.11.3-1.
I configured it much like I configure the installs of 1.9, using the ad provider for everything, and using msktutil to handle joining to my AD domain.
When I attempted to login, I got access denied, so I increased the logging, restarted SSSD, and tried again. In the log, everything's looking good, until I get to sdap_save_user.
[sdap_save_user] (0x0400) : Save user
[sdap_save_user] (0x0040) : SID (redacted, but it is the correct SID for my account) does not belong to any known domain
[sdap_save_users] (0x0040) : Failed to store user 0. Ignoring.
My AD environment is a forest, and my Fedora laptop is joined to a child domain. SSSD is only configured for the child domain as well, I haven't tried multiple domain setups. So, SSSD should only know about the single domain.
In sssd.conf, I do have ad_domain set to the FQDN.
I'm sure this is probably something simple. Or it's related to the changes made in 1.11.2 for sdap_save_user: try to determine domain by SID.
The domain portion of my SID is correct as well, and running psgetsid sidvalue for both my account and the domain SID returns the correct information.
It finds my GC via DNS, and correctly uses the two local servers as the primary GC servers, with 32 backup servers. I'm sure that my laptop can't actually connect to all 34 domain controllers, due to firewalls. DNS contains the _gc entries for the remote GC servers, but has no current way to resolve the hosts.
I'm currently assuming that the lack of connection to the other GC's cause it to fail to find out which domain the domain portion of my account's SID belongs to.
Any help in pointing me towards a resolution would be appreciated.