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

On Fri, Jan 10, 2014 at 1:12 AM, Sumit Bose sbose@redhat.com wrote:

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

---

sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

On Fri, Jan 10, 2014 at 01:57:07AM -0800, Chris Gray wrote:

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

Can you install the ldb-tools package and check if the cache contains the ID mapping object for the domain?

yum -y install ldb-tools ldbsearch -H /var/lib/sss/db/cache_$yourdomain.ldb \ objectclass=id_mapping

Do the domain SIDs (stored in objectSID) attribute match the SID of the user, except for the part after the last dash (the RID) ?

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Hello, all this to inform you all of the solution to the problem I encountered.

It of course follows what is often said on this list, don't add ldap parameters unless you really know what you're doing.

I had an ldap_search_base that was set to an OU, and SSSD needed access to a lower level of the AD structure than was allowed by my search base setting.

I of course thought setting that would optimize the queries to AD, as all the accounts were below the OU I had specified. I was incorrect.

Sumit from RedHat helped me out and suggested removing the search base.

Thanks! Chris

On Fri, Jan 10, 2014 at 3:06 AM, Chris Gray fathed@gmail.com wrote:

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@redhat.com 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

---

sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

-- Intelligence is a matter of opinion.