[Freeipa-users] Re: AD-Trust users not known
Hello Jakub, with my first tries i'v had following entries in /etc/sss/sssd.conf on server side: [sssd] services = nss, sudo, pam, ssh default_domain_suffix = example.com full_name_format = %1$s domains = ipa.example.com debug_level = 10 With writing my first mail, i've disabled 'default_domain_suffix' and 'full_name_format', with no success on ipa-member. In the meanwhile, i did some test's on ipa-member: ipa-member> systemctl restart sssd ipa-member> sss_cache -E ipa-member> systemctl restart sssd ipa-member> id usern...@example.com uid=299801104(usern...@example.com) gid=299801104(usern...@example.com) Gruppen=299801104(usern...@example.com),299800513(domänen-benut...@example.com),299801109(mitarbei...@example.com),55688(ad_us...@example.com) So it work's as expected. Now i've enabled 'default_domain_suffix' and 'full_name_format' on server's sssd.conf, restart sssd and run sss_cache. It's still working. I'm not sure, if 'sss_cache' does some magical things. I will setup an other ipa client and test behavior on it. Thanks, Michael Am 18.08.2017 um 12:07 schrieb Jakub Hrozek via FreeIPA-users: > On Fri, Aug 18, 2017 at 12:00:45PM +0200, Michael Gusek via FreeIPA-users > wrote: >> Hi, >> >> for testing i've installed an FreeIPA-Server with a trust to an >> AD-Server. On IdM i can resolve AD-users with 'id usern...@example.com', >> on IdM member client not. >> >> AD-Domain is Server 2012R2 as 'example.com' >> IdM is latest CentOS 7 with ipa-server-4.4.0-14.el7.centos.7.x86_64 as >> 'ipa.example.com' >> IdM member client is latest CentOS 7 with >> sssd-client-1.14.0-43.el7_3.18.x86_64 >> >> Here an example on an Centos 7 client: >> ipa-member> id usern...@example.com >> id: 'usern...@example.com': no such user >> >> Logmessages, with log_level=10, shows: >> ipa-member> tail -f /var/log/sssd/sssd_ipa.example.com.log | grep s2n >> (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_send] (0x0400): Executing extended operation >> (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 13 >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: >> Success(0), (null). >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_send] (0x0400): Executing extended operation >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 14 >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such >> object(32), (null). >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed. >> (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] >> [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed. >> >> Running on IdM: >> ipa-server> id usern...@example.com >> uid=299801104(username) gid=299801104(username) >> Gruppen=299801104(username),299800513(domänen-benutzer),299801109(mitarbeiter),55688(ad_users) > The s2n operation triggers, through a DS plugin on the IPA side, a > lookup through the SSSD NSS interface. So, tailing the sssd_nss logs > on the server would be a good start to make sure all the NSS operations > succeed. > > By the way, the name resolution of the users from the trusted domain > does not include the domain name, just the username. How is that? Are > you sure you're not using some hacks like full_name_format = $1 on the > server side? > >> Any help is welcome. >> >> Michael >> >> - /etc/sssd.conf on ipa-member - >> [domain/ipa.example.com] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = ipa.example.com >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipa-server.ipa.example.com >> chpass_provider = ipa >> dyndns_update = True >> ipa_server = _srv_, ipa-server.ipa.example.com >> dyndns_iface = eth0 >> ldap_tls_cacert = /etc/ipa/ca.crt >> debug_level = 10 >> >> [sssd] >> debug_level = 10 >> services = nss, sudo, pam, ssh >> domains = ipa.example.com >> >> [nss] >> debug_level = 10 >> homedir_substring = /home >> >> [pam] >> debug_level = 10 >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> debug_level = 10 >> >> [ifp] >> >> - /etc/sssd.conf on ipa-server - >> [domain/ipa.example.com] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = ipa.example.com >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = ipa-server.ipa.example.com >> chpass_provider = ipa >> ipa_server = ipa-server.ipa.example.com >> chpass_provider = ipa >> ipa_server_mode = True >> ldap_tls_cacert = /etc/ipa/ca.crt >> subdomain_homedir = /home/%u >> shell_fallback = /bin/bash >> debug_level = 10 >> >> [sssd] >> services = nss, sudo, pam, ssh >> domains = ipa.example.com >> >>
[Freeipa-users] Re: AD-Trust users not known
On Fri, Aug 18, 2017 at 12:00:45PM +0200, Michael Gusek via FreeIPA-users wrote: > Hi, > > for testing i've installed an FreeIPA-Server with a trust to an > AD-Server. On IdM i can resolve AD-users with 'id usern...@example.com', > on IdM member client not. > > AD-Domain is Server 2012R2 as 'example.com' > IdM is latest CentOS 7 with ipa-server-4.4.0-14.el7.centos.7.x86_64 as > 'ipa.example.com' > IdM member client is latest CentOS 7 with > sssd-client-1.14.0-43.el7_3.18.x86_64 > > Here an example on an Centos 7 client: > ipa-member> id usern...@example.com > id: 'usern...@example.com': no such user > > Logmessages, with log_level=10, shows: > ipa-member> tail -f /var/log/sssd/sssd_ipa.example.com.log | grep s2n > (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Fri Aug 18 11:38:08 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 13 > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: > Success(0), (null). > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 14 > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such > object(32), (null). > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed. > (Fri Aug 18 11:38:09 2017) [sssd[be[ipa.example.com]]] > [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed. > > Running on IdM: > ipa-server> id usern...@example.com > uid=299801104(username) gid=299801104(username) > Gruppen=299801104(username),299800513(domänen-benutzer),299801109(mitarbeiter),55688(ad_users) The s2n operation triggers, through a DS plugin on the IPA side, a lookup through the SSSD NSS interface. So, tailing the sssd_nss logs on the server would be a good start to make sure all the NSS operations succeed. By the way, the name resolution of the users from the trusted domain does not include the domain name, just the username. How is that? Are you sure you're not using some hacks like full_name_format = $1 on the server side? > > Any help is welcome. > > Michael > > - /etc/sssd.conf on ipa-member - > [domain/ipa.example.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa-server.ipa.example.com > chpass_provider = ipa > dyndns_update = True > ipa_server = _srv_, ipa-server.ipa.example.com > dyndns_iface = eth0 > ldap_tls_cacert = /etc/ipa/ca.crt > debug_level = 10 > > [sssd] > debug_level = 10 > services = nss, sudo, pam, ssh > domains = ipa.example.com > > [nss] > debug_level = 10 > homedir_substring = /home > > [pam] > debug_level = 10 > > [sudo] > > [autofs] > > [ssh] > > [pac] > debug_level = 10 > > [ifp] > > - /etc/sssd.conf on ipa-server - > [domain/ipa.example.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa-server.ipa.example.com > chpass_provider = ipa > ipa_server = ipa-server.ipa.example.com > chpass_provider = ipa > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > subdomain_homedir = /home/%u > shell_fallback = /bin/bash > debug_level = 10 > > [sssd] > services = nss, sudo, pam, ssh > domains = ipa.example.com > > [nss] > memcache_timeout = 600 > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > - complete log messages for 'id usern...@example.com' on ipa-member > - > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] > [sysdb_search_user_by_upn] (0x0400): No entry with upn > [usern...@example.com] found. > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] > [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending > request > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [dp_req_done] > (0x0400): DP Request [Account #5]: Request handler finished [0]: Erfolg > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] [_dp_req_recv] > (0x0400): DP Request [Account #5]: Receiving request data. > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] > [dp_req_reply_list_success] (0x0400): DP Request [Account #5]: Finished. > Success. > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] > [dp_req_reply_std] (0x1000): DP Request [Account #5]: Returning > [Success]: 0,0,Success > (Fri Aug 18 11:54:05 2017) [sssd[be[ipa.example.com]]] > [dp_table_value_destructor] (0x0400): Removing >
