[SSSD-users] Re: logins fail after socket activated responders implemented.
SSSD team, Just checking in on this post. Any thoughts why the socket based responders would be crashing? Is there any additional info I could provide that would be useful? Thank you as always! -- lawrence On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney wrote: > ... I did notice this after a login attempt: > > [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- > > sssd-autofs.socket loaded active listening SSSD AutoFS Service > responder socket > sssd-kcm.socket loaded active listening SSSD Kerberos Cache > Manager responder socket > sssd-nss.socket loaded active running SSSD NSS Service > responder socket > sssd-pac.socket loaded active listening SSSD PAC Service > responder socket > sssd-pam-priv.socket loaded failed failedSSSD PAM Service > responder private socket > sssd-pam.socket loaded inactive dead SSSD PAM Service > responder socket > sssd-secrets.socket loaded active listening SSSD Secrets > Service responder socket > sssd-ssh.socket loaded active listening SSSD SSH Service > responder socket > sssd-sudo.socket loaded active listening SSSD Sudo Service > responder socket > > Both PAM responders were running/active/listening prior to the auth > attempt following a fresh reboot. > > /var/log/secure also contains: > > pam_sss(sshd:auth): Request to sssd failed. Bad address > Failed password for msteele from 192.168.2.1 port 53357 ssh2 > > > -- lawrence > > > On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney > wrote: > >> SSSD team, >> A curious issue after walking through the implementation of the socket >> activated responders. >> >> System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers. >> >> Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) >> worked when specifying the responders in the SSSD.conf file. >> >> [root@darkvixen241 ~]# id msteele >> uid=1727401116(msteele) gid=1727401151(primary_unix_g) >> groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain >> users) >> >> >> [root@darkvixen241 ~]# sssctl user-checks msteele >> user: msteele >> action: acct >> service: system-auth >> >> SSSD nss user lookup result: >> - user name: msteele >> - user id: 1727401116 >> - group id: 1727401151 >> - gecos: Ming Steele >> - home directory: /home/dvc.darkvixen.com/msteele >> - shell: /bin/bash >> >> SSSD InfoPipe user lookup result: >> - name: msteele >> - uidNumber: 1727401116 >> - gidNumber: 1727400513 >> - gecos: Ming Steele >> - homeDirectory: /home/msteele >> - loginShell: /bin/bash >> >> testing pam_acct_mgmt >> >> pam_acct_mgmt: Success >> >> PAM Environment: >> - no env - >> >> >> After implementing the desired socket activated responders I cannot login >> as users via SSH, but can su as them from a root session. User resolution >> and sssctl still work. >> >> [root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- >> sssd-autofs.socket loaded active listening SSSD AutoFS >> Service responder socket >> sssd-kcm.socket loaded active listening SSSD Kerberos >> Cache Manager responder socket >> sssd-nss.socket loaded active running SSSD NSS Service >> responder socket >> sssd-pac.socket loaded active listening SSSD PAC Service >> responder socket >> sssd-pam-priv.socket loaded active listening SSSD PAM Service >> responder private socket >> sssd-pam.socket loaded active listening SSSD PAM Service >> responder socket >> sssd-secrets.socket loaded active listening SSSD Secrets >> Service responder socket >> sssd-ssh.socket loaded active listening SSSD SSH Service >> responder socket >> sssd-sudo.socket loaded active listening SSSD Sudo Service >> responder socket >> >> [root@darkvixen241 ~]# id msteele >> uid=1727401116(msteele) gid=1727401151(primary_unix_g) >> groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain >> users) >> >> [root@darkvixen241 ~]# sssctl user-checks msteele >> user: msteele >> action: acct >> service: system-auth >> >> SSSD nss user lookup result: >> - user name: msteele >> - user id: 1727401116 >> - group id: 1727401151 >> - gecos: Ming Steele >> - home directory: /home/dvc.darkvixen.com/msteele >> - shell: /bin/bash >> >> SSSD InfoPipe user lookup result: >> - name: msteele >> - uidNumber: 1727401116 >> - gidNumber: 1727400513 >> - gecos: Ming Steel
[SSSD-users] Re: Group disappears from users / no group name gets resolved
Hi Sumit, Thank you for getting back to me. > Now it would be important to know if the group is defined in the same > domain your client is joined to or if it is coming form a different > domain. > > In the latter case (group is coming from a different domain) the cache > attributes 'isPosix: FALSE' and 'gidNumber: 0' are expected because SSSD > will filter out those groups because they are not valid in the domain > the client is joined to. My guess is that using the group as primary > group for some users might use a code path that skips the filter so that > it is added to the cache as proper group first but later on another > lookup uses the filter and removes the gidNumber and sets isPosix to > FALSE. To solve this you should switch the scope of the group to > 'Global' or 'Universal'. > > In the former case (group is from the domain the client is joined to) it > would be good to know if you are using UIDs and GIDs stored in AD or if > you use SSSD's id-mapping scheme (ldap_id_mapping = False / True > respectively). > > bye, > Sumit The group we are using is defined in the same domain and for the most part it does in fact return the correct GIDs for the group. We have set ldap_id_mapping to false as we are using POSIX attributes on our AD users and groups. I noticed that whenever the backend fills the cache with the wrong data, any updates do not actually modify the cache entry, we get this: [sdap_save_group] (0x0400): Storing info for group gr...@domain.com [sysdb_store_group] (0x1000): The group record of gr...@domain.com did not change, only updated the timestamp cache But occasionally, seemingly out of chance it does modify the entry, fixing the problem and setting the group to isPosix: TRUE when we get this: [sdap_save_group] (0x0400): Storing info for group gr...@domain.com [sysdb_set_entry_attr] (0x0200): Entry [name=gr...@domain.com,cn=groups,cn=domain.com,cn=sysdb] has set [cache, ts_cache] attrs. Not sure if any of that means anything towards the issue, just trying to give as much information as I can! Do let me know if there is anything more you need, Thanks, Jamal ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: Group disappears from users / no group name gets resolved
On Fri, Nov 15, 2019 at 10:58:17AM -, Jamal Mahmoud wrote: > Hi Sumit, > > Thank you for getting back to me. > > > Now it would be important to know if the group is defined in the same > > domain your client is joined to or if it is coming form a different > > domain. > > > > In the latter case (group is coming from a different domain) the cache > > attributes 'isPosix: FALSE' and 'gidNumber: 0' are expected because SSSD > > will filter out those groups because they are not valid in the domain > > the client is joined to. My guess is that using the group as primary > > group for some users might use a code path that skips the filter so that > > it is added to the cache as proper group first but later on another > > lookup uses the filter and removes the gidNumber and sets isPosix to > > FALSE. To solve this you should switch the scope of the group to > > 'Global' or 'Universal'. > > > > In the former case (group is from the domain the client is joined to) it > > would be good to know if you are using UIDs and GIDs stored in AD or if > > you use SSSD's id-mapping scheme (ldap_id_mapping = False / True > > respectively). > > > > bye, > > Sumit > > The group we are using is defined in the same domain and for the most part it > does in fact return the correct GIDs for the group. We have set > ldap_id_mapping to false as we are using POSIX attributes on our AD users and > groups. Ok, do you know if the LDAP attributes uidNumber and gidNumber are replicated to the Global Catalog in your environment? By default they are not. You can check this manually as well with ldapsearch on the Global Catalog port 3268: ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b 'DC=your,DC=ad,DC=domain' samAccountName=groupname If gidNumber is missing in the Global Catalog object please try if setting ad_enable_gc = False in the [domain/...] section of sssd.conf makes the group lookup more reliable. bye, Sumit > > I noticed that whenever the backend fills the cache with the wrong data, any > updates do not actually modify the cache entry, we get this: > > [sdap_save_group] (0x0400): Storing info for group gr...@domain.com > [sysdb_store_group] (0x1000): The group record of gr...@domain.com did not > change, only updated the timestamp cache > > But occasionally, seemingly out of chance it does modify the entry, fixing > the problem and setting the group to isPosix: TRUE when we get this: > > [sdap_save_group] (0x0400): Storing info for group gr...@domain.com > [sysdb_set_entry_attr] (0x0200): Entry > [name=gr...@domain.com,cn=groups,cn=domain.com,cn=sysdb] has set [cache, > ts_cache] attrs. > > Not sure if any of that means anything towards the issue, just trying to give > as much information as I can! > > Do let me know if there is anything more you need, > Thanks, > Jamal > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: Group disappears from users / no group name gets resolved
> On Fri, Nov 15, 2019 at 10:58:17AM -, Jamal Mahmoud wrote: > > Ok, do you know if the LDAP attributes uidNumber and gidNumber are > replicated to the Global Catalog in your environment? By default they > are not. > > You can check this manually as well with ldapsearch on the Global > Catalog port 3268: > > ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b > 'DC=your,DC=ad,DC=domain' samAccountName=groupname > > If gidNumber is missing in the Global Catalog object please try if > setting > > ad_enable_gc = False > > in the [domain/...] section of sssd.conf makes the group lookup more > reliable. > > bye, > Sumit Hi Sumit, I'm just after checking and you are correct! the ldap search through the Global Catalog does not return any POSIX attributes, we're going to apply this patch and see if the errors stop occurring. If this is the solution I owe you a drink (or 5). Thanks, Jamal ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
I use both. Triple-S-D is easier. On 2019-11-14 19:20, Spike White wrote: > All, > > S-S-S-D does not seem to roll off the tongue. When I say that, > co-workers think I'm discussing solid-state drives (SSD). When I call > it triple-S-D, someone invariably corrects me. > > Which is correct? Are both pronunciations correct? > > Spike > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
We, developers, always use S-S-S-D. I have never heard anyone saying Triple-S-D :-) On 11/15/19 1:49 PM, Jim Burwell wrote: I use both. Triple-S-D is easier. On 2019-11-14 19:20, Spike White wrote: All, S-S-S-D does not seem to roll off the tongue. When I say that, co-workers think I'm discussing solid-state drives (SSD). When I call it triple-S-D, someone invariably corrects me. Which is correct? Are both pronunciations correct? Spike ___ sssd-users mailing list --sssd-users@lists.fedorahosted.org To unsubscribe send an email tosssd-users-le...@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.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: Group disappears from users / no group name gets resolved
On 2019-11-15 04:25, Jamal Mahmoud wrote: >> On Fri, Nov 15, 2019 at 10:58:17AM -, Jamal Mahmoud wrote: >> >> Ok, do you know if the LDAP attributes uidNumber and gidNumber are >> replicated to the Global Catalog in your environment? By default they >> are not. >> >> You can check this manually as well with ldapsearch on the Global >> Catalog port 3268: >> >> ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b >> 'DC=your,DC=ad,DC=domain' samAccountName=groupname >> >> If gidNumber is missing in the Global Catalog object please try if >> setting >> >> ad_enable_gc = False >> >> in the [domain/...] section of sssd.conf makes the group lookup more >> reliable. >> >> bye, >> Sumit > Hi Sumit, > > I'm just after checking and you are correct! the ldap search through the > Global Catalog does not return any POSIX attributes, we're going to apply > this patch and see if the errors stop occurring. If this is the solution I > owe you a drink (or 5). > > Thanks, > Jamal Yep. The docs say that all those POSIX attributes should be marked as being part of the GC, which they aren't by default. You need to use the AD schema too to do that IIRC. I've also encountered issues with groups going missing, and in fact I'm working such an issue now. In our case, all the POSIX stuff is replicated to the GC. What happens is that the user's groups are fine for a long time (8-10 hours), then either a single group vanishes, OR all but their login group vanishes. The only thing that brings it back immediately is stopping SSSD, removing /var/lib/sssd/db/*, and restarting it. Then the groups will be back for that semi-random period. I had another case of this issue a few weeks ago. But in this case it turned out to be that there was an automated process on the AD that was removing users from groups, then adding them back shortly after. It seems that SSSD would sometimes catch it at the right time, and remove the user from the group, or sometimes bug out and remove all the users group except the user entry's gidNumber group (primary login group). This appears to me to be some sort of bug with SSSD where once it removes a group in the cache, it doesn't restore it when the user comes back. Perhaps negative caching (intended, or not)? - Jim ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users]Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
S-S-S-D here. On Fri, Nov 15, 2019, at 7:57 AM, Pavel Březina wrote: > We, developers, always use S-S-S-D. I have never heard anyone saying > Triple-S-D :-) > > On 11/15/19 1:49 PM, Jim Burwell wrote: > > I use both. Triple-S-D is easier. > > > > > > On 2019-11-14 19:20, Spike White wrote: > >> All, > >> > >> S-S-S-D does not seem to roll off the tongue. When I say that, > >> co-workers think I'm discussing solid-state drives (SSD). When I call > >> it triple-S-D, someone invariably corrects me. > >> > >> Which is correct? Are both pronunciations correct? > >> > >> Spike > >> > >> ___ > >> sssd-users mailing list --sssd-users@lists.fedorahosted.org > >> To unsubscribe send an email tosssd-users-le...@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.org > > > > > > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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.org > > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
... admittedly I use triple-s-d myself :-) -- lawrence On Fri, Nov 15, 2019, 8:27 AM James Cassell wrote: > > S-S-S-D here. > > > On Fri, Nov 15, 2019, at 7:57 AM, Pavel Březina wrote: > > We, developers, always use S-S-S-D. I have never heard anyone saying > > Triple-S-D :-) > > > > On 11/15/19 1:49 PM, Jim Burwell wrote: > > > I use both. Triple-S-D is easier. > > > > > > > > > On 2019-11-14 19:20, Spike White wrote: > > >> All, > > >> > > >> S-S-S-D does not seem to roll off the tongue. When I say that, > > >> co-workers think I'm discussing solid-state drives (SSD). When I > call > > >> it triple-S-D, someone invariably corrects me. > > >> > > >> Which is correct? Are both pronunciations correct? > > >> > > >> Spike > > >> > > >> ___ > > >> sssd-users mailing list --sssd-users@lists.fedorahosted.org > > >> To unsubscribe send an email > tosssd-users-le...@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.org > > > > > > > > > > > > ___ > > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > > To unsubscribe send an email to > sssd-users-le...@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.org > > > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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.org > > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: Group disappears from users / no group name gets resolved
On Fri, Nov 15, 2019 at 04:57:27AM -0800, Jim Burwell wrote: > On 2019-11-15 04:25, Jamal Mahmoud wrote: > >> On Fri, Nov 15, 2019 at 10:58:17AM -, Jamal Mahmoud wrote: > >> > >> Ok, do you know if the LDAP attributes uidNumber and gidNumber are > >> replicated to the Global Catalog in your environment? By default they > >> are not. > >> > >> You can check this manually as well with ldapsearch on the Global > >> Catalog port 3268: > >> > >> ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b > >> 'DC=your,DC=ad,DC=domain' samAccountName=groupname > >> > >> If gidNumber is missing in the Global Catalog object please try if > >> setting > >> > >> ad_enable_gc = False > >> > >> in the [domain/...] section of sssd.conf makes the group lookup more > >> reliable. > >> > >> bye, > >> Sumit > > Hi Sumit, > > > > I'm just after checking and you are correct! the ldap search through the > > Global Catalog does not return any POSIX attributes, we're going to apply > > this patch and see if the errors stop occurring. If this is the solution I > > owe you a drink (or 5). > > > > Thanks, > > Jamal > > > Yep. The docs say that all those POSIX attributes should be marked as > being part of the GC, which they aren't by default. You need to use the > AD schema too to do that IIRC. > > I've also encountered issues with groups going missing, and in fact I'm > working such an issue now. In our case, all the POSIX stuff is > replicated to the GC. What happens is that the user's groups are fine > for a long time (8-10 hours), then either a single group vanishes, OR > all but their login group vanishes. The only thing that brings it back Hi, are the group from the domain the client is joined to or from a different domain in the forest? > immediately is stopping SSSD, removing /var/lib/sssd/db/*, and > restarting it. Then the groups will be back for that semi-random period. > > I had another case of this issue a few weeks ago. But in this case it > turned out to be that there was an automated process on the AD that was > removing users from groups, then adding them back shortly after. It Are the groups being removed as well during this process and then added back with the same name? Can you share your sssd.conf? bye, Sumit > seems that SSSD would sometimes catch it at the right time, and remove > the user from the group, or sometimes bug out and remove all the users > group except the user entry's gidNumber group (primary login group). > > This appears to me to be some sort of bug with SSSD where once it > removes a group in the cache, it doesn't restore it when the user comes > back. Perhaps negative caching (intended, or not)? > > > - Jim > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: Group disappears from users / no group name gets resolved
On 2019-11-15 06:10, Sumit Bose wrote:
> On Fri, Nov 15, 2019 at 04:57:27AM -0800, Jim Burwell wrote:
>> On 2019-11-15 04:25, Jamal Mahmoud wrote:
On Fri, Nov 15, 2019 at 10:58:17AM -, Jamal Mahmoud wrote:
Ok, do you know if the LDAP attributes uidNumber and gidNumber are
replicated to the Global Catalog in your environment? By default they
are not.
You can check this manually as well with ldapsearch on the Global
Catalog port 3268:
ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b
'DC=your,DC=ad,DC=domain' samAccountName=groupname
If gidNumber is missing in the Global Catalog object please try if
setting
ad_enable_gc = False
in the [domain/...] section of sssd.conf makes the group lookup more
reliable.
bye,
Sumit
>>> Hi Sumit,
>>>
>>> I'm just after checking and you are correct! the ldap search through the
>>> Global Catalog does not return any POSIX attributes, we're going to apply
>>> this patch and see if the errors stop occurring. If this is the solution I
>>> owe you a drink (or 5).
>>>
>>> Thanks,
>>> Jamal
>>
>> Yep. The docs say that all those POSIX attributes should be marked as
>> being part of the GC, which they aren't by default. You need to use the
>> AD schema too to do that IIRC.
>>
>> I've also encountered issues with groups going missing, and in fact I'm
>> working such an issue now. In our case, all the POSIX stuff is
>> replicated to the GC. What happens is that the user's groups are fine
>> for a long time (8-10 hours), then either a single group vanishes, OR
>> all but their login group vanishes. The only thing that brings it back
> Hi,
>
> are the group from the domain the client is joined to or from a
> different domain in the forest?
Same domain.
>
>> immediately is stopping SSSD, removing /var/lib/sssd/db/*, and
>> restarting it. Then the groups will be back for that semi-random period.
>>
>> I had another case of this issue a few weeks ago. But in this case it
>> turned out to be that there was an automated process on the AD that was
>> removing users from groups, then adding them back shortly after. It
> Are the groups being removed as well during this process and then added
> back with the same name?
I'm not positive about that. I presumed that the groups themselves were
being left in place and users were just being removed from the group
then re-added by an automated process. But I'll inquire as to whether
this was a case. I have doubts because the groups exist with the proper
gidNumber, which I don't believe these automated process handles.
>
> Can you share your sssd.conf?
#
# sssd.conf for SSSD versions which have the AD provider module
# (preferred method)
#
[sssd]
config_file_version = 2
domains = {{ krb5_realm }}
services = nss, pam, pac
# remove PAC if it causes slow/failed login
#services = nss, pam
# uncomment for heavy debugging
# debug_level = 0x37F0
[nss]
# in case home dir isn't defined in AD/ldap unixHomeDirectory
fallback_homedir = /h/%u
[pam]
# debugging
#pam_verbosity = 5
# custom messages
pam_account_expired_message = Account Expired
pam_account_locked_message = Account Locked
# domain section
[domain/{{ krb5_realm }}]
# uncomment for heavy debugging
# debug_level = 0x37F0
#ad_gpo_access_control = permissive
# disabled, causes issues w/ some OSes
ad_gpo_access_control = disabled
# Use AD provider
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
ldap_id_mapping = False
cache_credentials = True
ldap_schema = ad
# Search base
ldap_search_base = dc=widgetco,dc=com
# Speed up search with narrowed user search base if required
#ldap_user_search_base = OU=Users,OU=Corp,DC=widgetco,DC=com
ldap_user_object_class = user
# Speed up search if required. See sssd-ldap man page for how to
# specify complex search bases with multiple bases, etc.
# ldap_group_search_base = ou=users,dc=widgetco,dc=com
ldap_group_object_class = group
# Use AD unix attributes instead of generating UID/GID, etc
ldap_id_mapping = False
# where AD keeps these attributes
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
# expire policies
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = True
# specify only if needed (DNS SRV records used otherwise)
#ad_server = dcwidgetcoprim.widgetco.com
# Let DHCP client handle this
dyndns_update = false
# This greatly improves login speed, but getent group groupname
won't show
# group members (but group lookups for the OS still work). It is
basically
# required for complex AD group schemas, or AD environments with LOTS of
# groups. It may be possible to turn it
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
Security Services here. On Thu, Nov 14, 2019 at 8:24 PM Spike White wrote: > All, > > S-S-S-D does not seem to roll off the tongue. When I say that, co-workers > think I'm discussing solid-state drives (SSD). When I call it triple-S-D, > someone invariably corrects me. > > Which is correct? Are both pronunciations correct? > > Spike > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
[SSSD-users] Re: how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
On Fri, Nov 15, 2019 at 7:57 AM Pavel Březina wrote: > > We, developers, always use S-S-S-D. I have never heard anyone saying > Triple-S-D :-) The "correct" pronunciation is "Ess Ess Ess Dee". It's just the initials. That said, some people use "Triple Ess Dee" and that's fine too. (I've also been known to jokingly refer to it as the "snake daemon" because it looks like it's hissing.) ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
