I have an issue where i've established the AD trust and am able to lookup my own account and about 30 others, but all others fail. I've compared AD attributes across accounts and can't find anything that is notably different. I've seen messages about making sure that groups can resolve, but I don't think that's what's happening. I have a user account that only has one group membership and that group resolves, but the account still is not returned on a lookup. The only common thread I can find with the accounts that succeed is that they are older accounts - they were created a long time ago - more recently created accounts fail. Where can I look to see what might be happening?
On Wed, Jul 11, 2018 at 08:36:43PM -0000, Mike Conner via FreeIPA-users wrote:
I have an issue where i've established the AD trust and am able to lookup my own account and about 30 others, but all others fail. I've compared AD attributes across accounts and can't find anything that is notably different. I've seen messages about making sure that groups can resolve, but I don't think that's what's happening. I have a user account that only has one group membership and that group resolves, but the account still is not returned on a lookup. The only common thread I can find with the accounts that succeed is that they are older accounts - they were created a long time ago - more recently created accounts fail. Where can I look to see what might be happening?
Are the users resolvable on the IPA server at least or do the lookups fail on both the server an the client?
On Wed, Jul 11, 2018 at 09:07:41PM -0000, Mike Conner via FreeIPA-users wrote:
No, the lookups fail on both the server and the client.
Can you post logs of a failing lookup on the server? You would add debug_level to the [nss] and [domain] section in sssd.conf and run the lookup..
sssd_nss.log during attempted lookup of slymedia@grinnell.edu account: https://pastebin.com/gLFnhZ9s
On Wed, Jul 11, 2018 at 09:42:14PM -0000, Mike Conner via FreeIPA-users wrote:
sssd_nss.log during attempted lookup of slymedia@grinnell.edu account: https://pastebin.com/gLFnhZ9s
This is somewhat helpful, at least this snippet: (Wed Jul 11 16:33:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #230: Object [slymedia@grinnell.edu] was not found in cache (Wed Jul 11 16:33:22 2018) [sssd[nss]] [cache_req_search_ncache_add_to_domain] (0x0400): CR #230: Adding [slymedia@grinnell.edu] to negative cache (Wed Jul 11 16:33
Shows the user was not found. The next step are the domain logs.
Aha! This (from the domain log) shed some light: (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x0400): Processing user slymedia@grinnell.edu (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x1000): Mapping user [slymedia@grinnell.edu] objectSID [S-1-5-21-71189414-1642862984-1097818727-518801] to unix ID (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_idmap_sid_to_unix] (0x0040): Object SID [S-1-5-21-71189414-1642862984-1097818727-518801] has a RID that is larger than the ldap_idmap_range_size. See the "ID MAPPING" section of sssd-ad(5) for an explanation of how to resolve this issue. (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-71189414-1642862984-1097818727-518801] to a UNIX ID (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user] (0x0020): Failed to save user [slymedia@grinnell.edu] (Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring.
So it looks as though I have an incorrect ID Range for these AD accounts. I increased the number of IDs in the range for the AD domain and - low and behold, the accounts are now resolving.
Thank you for your help!
freeipa-users@lists.fedorahosted.org
-
Jakub Hrozek -
Mike Conner