ls command hangs after migration to sssd from VAS
by linuxlover.chaitanya from LinuxQuestions.org on (#6Q9DW)
Hello Members,
We recently migrated to SSSD from VAS (Vintela Authentication Services) which is now part of One Identity. Our version was old and was still VAS. The issue now we see is on NFS shares with folders owned by accounts which are disabled on AD. Or UID Numbers not associated with any account on AD because account was deleted. When we have such folders with user owner being deleted and UID Number is orphan, we cant "ls" on the entire share in which such folders exist. The "ls" command just hangs around. I believe the "ls" command is trying to associate the UID numbers to an account on AD but is not able to. This was not the case with VAS. This has cropped up recently.
We tried to change one configuration on sssd.conf which solves the issue but breaks the sssd entirely
Quote:
The above works but breaks the association of the UID Number and Account and authentication completely breaks.
Also, stopping sssd service also resolves the issue but then that is not the solution we are looking at.
Below is our sssd.conf file
Quote:
We recently migrated to SSSD from VAS (Vintela Authentication Services) which is now part of One Identity. Our version was old and was still VAS. The issue now we see is on NFS shares with folders owned by accounts which are disabled on AD. Or UID Numbers not associated with any account on AD because account was deleted. When we have such folders with user owner being deleted and UID Number is orphan, we cant "ls" on the entire share in which such folders exist. The "ls" command just hangs around. I believe the "ls" command is trying to associate the UID numbers to an account on AD but is not able to. This was not the case with VAS. This has cropped up recently.
We tried to change one configuration on sssd.conf which solves the issue but breaks the sssd entirely
Quote:
| ldap_id_mapping = True |
Also, stopping sssd service also resolves the issue but then that is not the solution we are looking at.
Below is our sssd.conf file
Quote:
[nss] filter_groups = root,adm filter_users = root,adm reconnection_retries = 3 [pam] reconnection_retries = 3 [sssd] domains = <our-domain-name> config_file_version = 2 services = nss, pam [domain/<our-domain-name] ad_domain = <our-domain-name> realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad auth_provider = ad default_shell = /bin/bash ldap_id_mapping = False - Changing this to True solves the issue but breaks a lot of other things use_fully_qualified_names = False override_homedir = /home/%u enumerate = False ad_gpo_access_control = permissive ldap_schema = rfc2307bis ignore_group_members = False ldap_group_nesting_level = 2 ldap_use_tokengroups = False case_sensitive = Preserving debug_level = 5 |