On Fri, Jan 10, 2014 at 01:03:35AM -0800, Chris Gray wrote: > Hello all, > > 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. I guess you are using id_provider=ldap. If yes, this issue is already know, see https://fedorahosted.org/sssd/ticket/2172 and https://fedorahosted.org/sssd/ticket/2175 and patches are currently reviewed on the list. Since you are using AD I would suggest to try the AD ID provider with 1.11. HTH bye, Sumit > > 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. > > Thanks, > Chris > _______________________________________________ > sssd-users mailing list > sssd-users(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

All of my providers are AD; ID, access, auth and chgpass. I use the AD provider for all 4 settings in 1.9 as well, seems to work fine. I have my ldap_id_mapping set to true. So, neither of those existing issues fit my setup, but thanks for the effort! Chris

I'll install the ldb-tools tomorrow (I went home) and try that out. The SID and the RID are correct, verified visually and used a windows utility to search the domain based on the SID to verify it was correct and returning the correct account from AD (psgetsid.exe). I'm also working on converting the SID and RID to reverse hex so I can use ldapsearch on the linux machine to triple verify, but I haven't completed that yet. The computers with SSSD version 1.9 correctly show the RID as the last digits of the unix UID. My default domain group is Domain Users as well, which always has a RID of 0513, and that correctly shows as the last 4 digits unix GID on the computers with 1.9. Reading those bug reports more may had lead to a solution. ldap_idmap_default_domain_sid (string) Specify the domain SID of the default domain. This will guarantee that this domain will always be assigned to slice zero in the ID map, bypassing the murmurhash algorithm described above. Default: not set ldap_idmap_default_domain (string) Specify the name of the default domain. Default: not set

I'll try those out tomorrow as well. I'm not sure they'll work since I got them from version 1.9 docs. I don't have them set on the computers I have that use SSSD 1.9, and they don't exhibit the problem. Thanks again, Chris

_______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

I'll check with my security team, and hopefully be able to send them to you tomorrow. I might do so from my work email account, but I'll mention my gmail address on there as well. I assume you'll want a copy the configuration files, so I'll send those with the logs if I'm able. Unfortunately gmail didn't notify me of your response (or I missed it), while I was sending that one. Thanks again! Chris On Fri, Jan 10, 2014 at 3:01 AM, Sumit Bose <sbose(a)redhat.com&gt; wrote: > On Fri, Jan 10, 2014 at 02:32:48AM -0800, Chris Gray wrote: > > I'll install the ldb-tools tomorrow (I went home) and try that out. > > > > The SID and the RID are correct, verified visually and used a windows > > utility to search the domain based on the SID to verify it was correct > and > > returning the correct account from AD (psgetsid.exe). I'm also working > on > > converting the SID and RID to reverse hex so I can use ldapsearch on the > > linux machine to triple verify, but I haven't completed that yet. > > > > The computers with SSSD version 1.9 correctly show the RID as the last > > digits of the unix UID. My default domain group is Domain Users as well, > > which always has a RID of 0513, and that correctly shows as the last 4 > > digits unix GID on the computers with 1.9. > > > > Reading those bug reports more may had lead to a solution. > > > > ldap_idmap_default_domain_sid (string) > > Specify the domain SID of the default domain. This will > > guarantee that this domain will always be assigned to > slice > > zero in the ID map, bypassing the murmurhash algorithm > > described above. > > > > Default: not set > > > > ldap_idmap_default_domain (string) > > Specify the name of the default domain. > > > > Default: not set > > > > Please note that those options have a special purpose and should not be > needed in your setup. Nevertheless they might lead to a working > solution by hiding the original issue. With those two option a domain is > pre-created in the idmapping code. If the SID matches the domain SID of > your user the user will get a POSIX ID and you won't see the errors you > posted earlier. But in general the AD provider is able to auto-detect all > domain in your forest and create the needed idmapping entries > automatically. I assume that there is an issue to detect of domain and > its domain SID or to create the needed idmapping entries. This is why I > asekd for the full logs. > > bye, > Sumit > > > > > > > I'll try those out tomorrow as well. I'm not sure they'll work since I > > got them from version 1.9 docs. I don't have them set on the computers > > I have that use SSSD 1.9, and they don't exhibit the problem. > > > > > > Thanks again, > > > > Chris > > > _______________________________________________ > > sssd-users mailing list > > sssd-users(a)lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users > > _______________________________________________ > sssd-users mailing list > sssd-users(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users > -- Intelligence is a matter of opinion.