I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster.
Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot.
Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains.
Hi,
On Thu, Feb 3, 2022 at 12:19 AM Bill Conn Bill.Conn@usd.edu wrote:
I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster.
Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot.
What exact SSSD version 1.16.5 based machines have?
Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains.
I tried both of these versions on centos 7.
Name : sssd Arch : x86_64 Version : 1.16.5 Release : 10.el7_9.10
Name : sssd Arch : x86_64 Version : 1.16.5 Release : 10.el7_9.11
And they both showed no users for other domains in the forest.
Bill,
Same situation here. In our case, it's an overarching global AD domain with 4 regional child domains. One child domain cannot discover the other domains. In specifics, these are the bad sssd versions:
OL7: 1.16.5-10*.0.1*.el7_9.11
RHEL7: 1.16.5-10.el7_9.11
We had to roll back to version 1.16.4 or older and all was good.
It was with interest we read this bugzilla that seems relevant: https://bugzilla.redhat.com/show_bug.cgi?id=2032867
However we downloaded this test RPM and tried it on this child domain. It didn't help.
Curiously, other child domains can discover all expected domains.
Spike
On Wed, Feb 2, 2022 at 5:19 PM Bill Conn Bill.Conn@usd.edu wrote:
I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster.
Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot.
Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hello Spike,
Thanks for the info and links. It looks like rolling back sssd and it's associated packages to 1.16.4 might be my best bet until a working update is rolled out. I also took a look at the test rpms on the bugzilla ticket and they didn't work for me either.
Bill
Any updates on this AD domain under-discovery?
We have SRs open with our OS vendors, but developers on this mailing list seem far more knowledgeable about the minute details of 'sssd domain auto-discovery' than the first level of the support queue of our OS vendors.
sssd-*-1.16.5-10.0.1.el7_9.12.x86_64 RPMs do not fix the problem. The problem is very easily reproducible; we have a test box with it exhibiting this under-discovery.
Spike White
On Thu, Feb 3, 2022 at 11:43 AM Bill Conn bill.conn@usd.edu wrote:
Hello Spike,
Thanks for the info and links. It looks like rolling back sssd and it's associated packages to 1.16.4 might be my best bet until a working update is rolled out. I also took a look at the test rpms on the bugzilla ticket and they didn't work for me either.
Bill _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hey Spike,
We have old images of our affected HPC nodes and I tried a couple different older images on the nodes and then updating things other than sssd and I was running into inconsistency issues where it would sometimes return results from other domains in the forest and sometimes not. Clearing the cache seemed to remove the ability to look those users up and I wasn't sure if it was related to the head node or some other interaction issue. In the interests of moving forward on the problem I was having I sidestepped it by creating duplicate accounts for those users in our AD Domain and having them use those credentials. It might create some potential headaches in the future if we want to 'merge' their current temp account with their real account at a different campus, but that will have to be after the cent7 sssd packages get fixed. And now, at least they can get on and use the resources.
Bill
Hi Bill, Can you try this patch from same bug https://bugzilla.redhat.com/show_bug.cgi?id=2032867" https://bugzilla.redhat.com/attachment.cgi?id=1866000
Regards, Ashok
On Wed, Mar 30, 2022 at 5:32 AM Bill Conn bill.conn@usd.edu wrote:
Hey Spike,
We have old images of our affected HPC nodes and I tried a couple different older images on the nodes and then updating things other than sssd and I was running into inconsistency issues where it would sometimes return results from other domains in the forest and sometimes not. Clearing the cache seemed to remove the ability to look those users up and I wasn't sure if it was related to the head node or some other interaction issue. In the interests of moving forward on the problem I was having I sidestepped it by creating duplicate accounts for those users in our AD Domain and having them use those credentials. It might create some potential headaches in the future if we want to 'merge' their current temp account with their real account at a different campus, but that will have to be after the cent7 sssd packages get fixed. And now, at least they can get on and use the resources.
Bill _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
Ashok Kumar -
Bill Conn -
Bill Conn
-
Spike White