On la, 03 loka 2020, Ronald Wimmer via FreeIPA-users wrote:
On 03.10.20 09:53, Alexander Bokovoy via FreeIPA-users wrote:
>On la, 03 loka 2020, Ronald Wimmer via FreeIPA-users wrote:
>>On 02.10.20 16:03, Simo Sorce via FreeIPA-users wrote:
>>>On Fri, 2020-10-02 at 12:27 +0200, Ronald Wimmer via FreeIPA-users
>>>wrote:
>>>>How could I possibly find the POSIX ids of all mapped Active Directory
>>>>users?
>>>>
>>>>I do neither see them in LDAP nor do I find them with IPA user find.
>>>They are in AD, query AD please.
>>>
>>>The only other option is to use a command like: id <username>, but that
>>>requires knowledge of each AD username you care for.
>>>
>>>Keep in mind IPA is not a caching LDAP server, that's not its role, its
>>>role is to provide the means to establish a point of trust between the
>>>two worlds, so that AD clients can use services hosted in the IPA
>>>domain servers.
>>
>>Before reading your answer I always thought that IPA holds a
>>unique UID for each user. I was not aware that they could be found
>>in AD. But where in AD? What do I need to query for? When I take a
>>look at my user in AD i cannot find the UID attribute anywhere.
>
>Look at 'ipa idrange-find' output, see types of ID ranges connected with
>your AD domains. Most likely you'd see there
>
> Range name: WIN2016.TEST_id_range
> First Posix ID of the range: 1768400000
> Number of IDs in the range: 200000
> First RID of the corresponding RID range: 0
> Domain SID of the trusted domain:
>S-1-5-21-3410309376-2751302362-2141305124
> Range type: Active Directory domain range
>
> E.g. range type is 'Active Directory domain range'
>
>which means that AD users and groups don't have explicitly assigned
>UID/GID attributes but instead do have their UID/GID values
>automatically generated by SSSD based on the security identifiers of the
>AD user and its group memberships.
>
>For such case a relative identifier of the security identifier (RID
>value of SID) is taken and added to the 'first RID of the RID range' and
>then added on top of 'first POSIX ID of the range'. So, for user with
>RID 500 (Administrator in AD domain) it would be 1768400000+0+500, e.g.
>1768400500, which is what I see when I do 'id
>administrator(a)win2016.test':
>
>$ id administrator(a)win2016.test
>uid=1768400500(administrator(a)win2016.test)
>gid=1768400500(administrator(a)win2016.test)
>groups=1768400500(administrator(a)win2016.test),1768400519(enterprise
>admins(a)win2016.test),1768400518(schema
>admins(a)win2016.test),1768400513(domain
>users(a)win2016.test),1768400520(group policy creator
>owners(a)win2016.test),1768400512(domain admins(a)win2016.test)
>
>There are few more factors that affect this, most importantly, an ID
>override for the AD user can change which UID or GID is assigned to the
>AD user/group. A 'Default Trust View' ID view applies globally. If there
>is a custom ID view applied to a specific IPA client, it might also
>contain an ID override that would be applied on top of that procedure.
>
>There are other ID range types which disable automatic generation of IDs
>for AD users/groups. These assume that AD LDAP contains explicit UID/GID
>numbers assigned to the users/groups but on top of that ID view
>overrides still apply.
>
>As a result, as Simo said, the best tool is 'id <username>', because
>there is no a single place to store this information and how it looks
>like depends heavily where you are querying for it. I.e. context
>matters.
Thank you for the clarification. Maybe I should try another approach
for the problem I need to solve.
Let me outline the scenario:
We are planning to use auditd to log which user does what on an IPA
client. The auditd logs go to Splunk. The problem is that we do only
see the uidNumbers of the AD users and not their usernames. The Splunk
guys proposed to create some kind of lookup table for the AD users.
Maybe auditd can be configured in a way that the AD users' usernames
will be logged too?
There are two ways:
- use enriched log_format option of auditd.conf
- use 'ausearch --interpret' when parsing/searching auditd logs
From auditd.conf(5):
log_format
The log format describes how the information should be stored on disk.
There are 2 options: raw and enriched. If set to RAW, the audit records
will be stored in a format exactly as the kernel sends it. The ENRICHED
option will resolve all uid, gid, syscall, architecture, and socket
address information before writing the event to disk. This aids in
making sense of events created on one system but reported/analized on
another system. The NOLOG option is now deprecated. If you were setting
this format, now you should set the write_logs option to no.
From ausearch(8):
-i, --interpret
Interpret numeric entities into text. For example, uid
is converted to account name. If the audit logs are
unenriched, the conversion is done using the current
resources of the machine where the search is being run. If
you have re‐ named the accounts, or don't have the same
accounts on your machine, you could get misleading
results. If the logs are enriched, it uses the
supplemental data to do the conversion. This allows
accurate log reporting even when run on
a different machine than the original logs came from.
I would suggest using 'ausearch --interpret', if possible, because
resolving user/group names would potentially be time consuming and may
lead to losing log entries at worst case.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland