On Mon, Feb 15, 2021 at 01:36:09PM +1100, Lachlan Simpson wrote: > Hi, > > I'm having trouble getting results with IPA and SSSD, so I'm starting from > first principles. > > Running on RHEL 8.3, I have an IPA server (idm) and a test client (idm-test), > with one way trusts to the company AD - both their adtest.company.com and > production ad.company.com > > I can't get id or ssh working on idm-test, so I went back to the IPA server > to see if I can get id resolution there. This is what I'm seeing in > /var/log/sssd/sssd_test.linux.company.com.log: > > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] > (0x0020): Failed to save user [[email protected]] > > > Here are the longer details > > ipaserver = FreeIPA 4.8.7, SSSD 2.3.0 > domain = test.linux.company.com > trusts = adtest.company.com, ad.company.com > > [root@idm ~]# sssctl domain-list > implicit_files > test.linux.company.com > adtest.company.com > ad.company.com > > [root@idm ~]# sssctl domain-status adtest.company.com > Online status: Online > ... > [root@idm ~]# sssctl domain-status ad.company.com > Online status: Online > ... > > chronyd is set up against ntp.company.com > > [root@idm ~]# id [email protected] > uid=13530577([email protected]) > gid=5000([email protected]) > groups=5000([email protected]) > [root@idm ~]# getent passwd [email protected] > [email protected]:*:13530577:5000:Rajkumar > Theeban:/home/adtest.company.com/z3530577:/bin/bash > > [root@idm ~]# id [email protected] > id: ‘[email protected]’: no such user > [root@idm ~]# id [email protected] > id: ‘[email protected]’: no such user > > > As you can see, the user in ad.company.com can't be found. > > Here is the log file /var/log/sssd/sssd_test.linux.company.com.log with more > context /var/log/sssd/sssd_test.linux.company.com.log > > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sss_domain_get_state] > (0x1000): Domain ad.company.com is Active > (2021-02-15 10:43:17): [be[test.linux.company.com]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(|([email protected] > )([email protected])(userPrincipalName=z3530577\\@[email protected]))(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=ad,dc=unsw,dc=edu,dc= > au]. > (2021-02-15 10:43:17): [be[test.linux.company.com]] > [sdap_get_generic_ext_add_references] (0x1000): Additional References: > ldap://ad.company.com/CN=Configuration,DC=a > d,DC=unsw,DC=edu,DC=au > (2021-02-15 10:43:17): [be[test.linux.company.com]] > [generic_ext_search_handler] (0x4000): Ref: > ldap://ad.company.com/CN=Configuration,DC=ad,DC=unsw,DC=edu,DC=au > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sss_domain_get_state] > (0x1000): Domain ad.company.com is Active > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] > (0x0400): Processing user [email protected] > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] > (0x1000): Mapping user [[email protected]] objectSID > [S-1-5-21-1140405718-358989843-3445714 > 273-3730445] to unix ID
Hi, from reading the logs I would say that it looks like your RIDs (last part of the SID) can become quite large (3730445). By default only id-ranges to to 200000 are created. Please check with e.g. 'ipa idrange-find' the size of the id-range related to you AD domain. If it is only 200000 there are two way to solve it. For production environments I would always recommend to add a second id-range for the AD domain covering the missing RIDs. The reason is that SSSD on the client does not try to modify existing id-ranges because it might changes the id-mapping for active users or groups on the systems. But if there are no conflicts with existing id-ranges SSSD can add new ones. If you are in a testing environment with only few clients you can also change the existing id-range of the AD domain by increasing the size. But new you have to restart SSSD on all IPA servers and client and remove the existing cache to properly read and apply the modified id-range. If you have the sssd-tools package installed you can call 'sssctl cache-remove' on each host to do this. But what puzzles me a bit is the output of the 'id' command. Here it looks like the UIDs and GIDs are taken from value stored in AD. What behavior are you expecting, automatic creation of UIDs and GIDs or reading them from AD? Is the primary GID 5000 stored in AD or are you using an id-override? Finally, the logs indicate that the user was not found by the sAMAccountName 'z3530577' but via email or user principal name. Does the user has a different sAMAccountName? bye, Sumit > (2021-02-15 10:43:17): [be[test.linux.company.com]] [sdap_save_user] > (0x0020): Failed to save user [[email protected]] > (2021-02-15 10:43:17): [be[test.linux.company.com]] > [sysdb_search_user_by_upn] (0x0400): No entry with upn > [[email protected]] found. > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
