Thanks Sumit.

On Mon, Feb 15, 2021, at 20:53, Sumit Bose wrote:
On Mon, Feb 15, 2021 at 01:36:09PM +1100, Lachlan Simpson wrote:

> [root@idm ~]# id z3530577@adtest.company.com
> uid=13530577(z3530577@adtest.company.com) gid=5000(company@test.linux.company.com) groups=5000(company@test.linux.company.com)
> [root@idm ~]# getent passwd z3530577@adtest.company.com
z3530577@adtest.company.com:*:13530577:5000:Rajkumar Theeban:/home/adtest.company.com/z3530577:/bin/bash

> [root@idm ~]# id z3530577@ad.company.com
> id: ‘z3530577@ad.company.com’: no such user
> [root@idm ~]# id z3530577@ad.company.com
> id: ‘z3530577@ad.company.com’: no such user


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.


This was exactly the problem apparently. I increased the ID range to 5,000,000 (we are in a testing environment before deployment) and it worked. Thank you very much.

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?

We have POSIX attributes set in AD, and all users get GID 5000. We will leave that in place and override their other group memberships. Their UID should be the same as their login id but with the leading z replaced with a 1. We will most likely keep that system.

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?

This has me confused. All three of those attributes exist, but the sAMAccountName should match z[0-9]{7}, the userPrincipleName is z[0-9]{7}@company.com and the mail is different again, although there are proxies for z[0-9]{7}@company.com and z[0-9]{7}@ad.company.com

I'm fairly certain there's a large amount of technical debt built up in that AD.

I have noticed in the logs that even when logging in with a fully qualified login name  - ie, one that includes the domain in the login - that sssd is still searching the other domains (implicit files, etc).

Cheers
L.