[Freeipa-users] Unable to resolve AD users from IPA client

Jakub Hrozek jhrozek at redhat.com
Mon Oct 17 11:51:41 UTC 2016 

On Mon, Oct 17, 2016 at 01:27:40PM +0200, Jan Karásek wrote:
> Hi, 
> please can you help me with troubleshooting IPA clients in IPA - AD trust scenario ? We have two IPA servers and couple of clients running on RHEl 6 and 7. IPA is running on RHEL 7.2. 
> AD servers are in domains example.cz, cen.example.cz. Test users sits in cen.example.cz. IPA is subdomain of AD - vs.example.cz. 
> Trust is set as one-way trust. User's POSIX attributes are stored in AD. 
> 
> ipa idrange-find 
> ---------------- 
> 3 ranges matched 
> ---------------- 
> Range name: CEN.EXAMPLE.CZ 
> First Posix ID of the range: 98800000 
> Number of IDs in the range: 200000 
> Domain SID of the trusted domain: S-1-5-21-527237240-1482476501-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: EXAMPLE.CZ_id_range 
> First Posix ID of the range: 68800000 
> Number of IDs in the range: 200000 
> Domain SID of the trusted domain: S-1-5-21-73586283-1958367476-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: VS.EXAMPLE.CZ_id_range 
> First Posix ID of the range: 930000000 
> Number of IDs in the range: 200000 
> First RID of the corresponding RID range: 1000 
> First RID of the secondary RID range: 100000000 
> Range type: local domain range 
> ---------------------------- 
> Number of entries returned 3 
> ---------------------------- 
> 
> I have no problem to resolve AD users from both IPA server: 
> 
> IPA Server: 
> root#:id tst99654 at cen.example.cz 
> uid=20019(tst99654 at cen.example.cz) gid=5001(csunix) groups=5001(csunix),930000008(final_test_group) - this is correct 
> 
> but from IPA client: 
> root#:id tst99654 at cen.example.cz 
> id: tst99654 at cen.example.cz: no such user 
> 
> ==> sssd_vs.example.cz.log <== 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=tst99654] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_req_set_domain] (0x0400): Changing request domain from [vs.example.cz] to [cen.example.cz] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=tst99654))][cn=Default Trust View,cn=views,cn=accounts,dc=vs,dc=example,dc=cz]. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such object(32), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) 
> 
> All IPA clients have the same result - No such user. On the other hand kerberos works fine - I can do kinit with AD users both on IPA servers and clients. All IPA clients use the same DNS server as IPA servers. 
> 
> 
> On IPA server, I can see that it is able to find test user in AD. Log is captured during IPA client request for id: 
> 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=tst99654)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=cen,dc=example,dc=cz]. 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=tst99654,OU=CSUsers,DC=cen,DC=example,DC=cz]. 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://DomainDnsZones.cen.example.cz/DC=DomainDnsZones,DC=cen,DC=example,DC=cz 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] [sdap_save_user] (0x0400): Save user 
> ... 
> 
> 
> I can provide full log from IPA server, but its quite long. Could you point me what else I could try ? 

the most typical cause is that the IPA client cannot resolve all the
POSIX information from the server.

Check if all the groups are resolvable by ID:
   getent group 5001 
   getent group 930000008
alternatively, tail /var/log/sssd/sssd_nss.log on the IPA *server* and
watch if all requests that come from the DS UID (typically the dirsrv
user, see getent passwd dirsrv) are resolvable on the server.

More information about the Freeipa-users mailing list