[Idea] Update users inventory on linux domain computers

[szelga]

Your idea

in my experience, users inventory for Linux computers joined into AD domain behaves quite different, than for Windows ones.

for instance, provided that long AD domain name is domain.company.name, short (workgroup name) is COMPANY, and username is domain.username, Windows agents provide output like this for <USERS> tag:

    <USERS>
      <DOMAIN>COMPANY</DOMAIN>
      <LOGIN>domain.username</LOGIN>
    </USERS>

whereas Linux agents provide output like this:

   <USERS>
      <LOGIN>domain.username@domain.company.n</LOGIN>
   </USERS>

(note it being truncated to 32 characters).

for Windows machines GLPI matches agent's output with LDAP users w/o any hassle, which is not the case for Linux machines. the most important (at least, in my experience) is contact field in GLPI (not sure how it's filled up).

Windows computer:

Linux computer:

(I have GLPI 9.4 in air-gapped network, so that could partially be a me problem.)

I have the basic idea what to do with _getLoggedUsers (fills up the <USERS> tag, as far as I understand):

# getting process IDs
$ who --users | awk '{print $6}'
4597
15509
17307
32150
49920
# getting UIDs
$ ps -o user:128 -p 4597,15509,17307,32150,49920 | tail -n +2 | sort | uniq
991227614
991226519
# getting full name(s)
$ id -un 991227614 991226519
domain.username@domain.company.name
another.bloody.user@domain.company.name

and then split the username and (if SAMBA is installed, and smb.conf is configured properly, it should be extracted via testparm -sl --parameter-name=workgroup command) substitute domain name for workgroup name (as Windows agents seem to do).

(sorry, I'm not skilled at Perl at all, I can provide a patch, but it would take time.)

not sure what could be done about _getLastUser.

[szelga]

UPD: re-checked with a username, where full length is under 32 characters, and, it appears, the last stage (with workgroup) is unnecessary, the User field in GLPI is being filled up automatically. other than that, my workaround with PIDs is valid.

[g-bougard]

Thank you for the new discussion.

(I have GLPI 9.4 in air-gapped network, so that could partially be a me problem.)

Of course this can be a problem. Essentially for you as a lot of security hole has been fixed since then. I hope for you it is well closed from internet.

This can also be a problem for user matching in GLPI but in the case of linux computers I think we should be close to the current behavior. Anyway, I strongly advise you to also use a GLPI v11 test instance to verify your goal can still be achieved in current best GLPI context - and maybe this will motivate you to migrate your server ;-).

[szelga]

to be clear, my main qualm is that the User field doesn't fill up properly, when full username is over 32 characters long (which is often the case in our organization). I'm not sure whether this field is based on <USERS> or <LASTLOGGEDUSER> tag.

[g-bougard]

Of course, the goal is to discover the correct connected user and for that these fields must report what GLPI knows from your AD. <LASTLOGGEDUSER/> is more a legacy field - and may be used in 9.4, I won't dig this to tell you if it is, that version is no more supported. I still can tell we tried of course to keep the user matching mechanism in GLPI as consistent as possible over time. But my guess is latest versions better use </USERS/>.

So in glpi-agent, I still have to deal with these 2 fields.

[szelga]

thanks. I'm gonna provide a patch with my workaround (wouldn't hurt anyway) and work on updating our GLPI instance.

[szelga]

UPD: imported XML, in which I manually edited <USERS> to provide a correct username, the User field filled up correctly even in GLPI 9.4.

[szelga]

as for updating, it's physically isolated from the Internet, which makes it difficult to update (probably gotta delete some unused plugins before that). I'm gonna do it eventually, after I deal with more pressing matters.

[g-bougard]

My first concern is to know if in your context we have better tools than standard ones.

Checking quickly your SSSD configuration documentation link, I first saw we may use realm discover command to check if the system is connected to an AD. I'm not a SSSD expert so can you confirm ? I'm working on Fedora so the command is available, but I'm not connected to an AD so it gives:

[guillaume@rog glpi-agent]$ realm discover
realm: No default realm discovered
[guillaume@rog glpi-agent]$ echo $?
1

So it probably can be used to enable a dedicated module or handle dedicated calls for more accurate data. Then the question is which tools can we use: sssd tools ? DBus calls ?
Get logged users from process PID still may be a good solution as it may be more portable.

[szelga]

$ loginctl list-sessions -o json
[{"session":"5","uid":991227614,"user":"domain.username@domain.company.name","seat":"seat0","tty":"tty7"},{"session":"c1","uid":102,"user":"fly-dm","seat":"seat0","tty":"tty7"}]
$ loginctl list-users -o json
[{"uid":102,"user":"fly-dm","linger":false},{"uid":991227614,"user":"domain.username@domain.company.name","linger":false}]

(sorry for the belated reply, was away from my work PC for a while, and am gonna be like that for a week or so more.)

fly-dm is AstraLinux's service account, gotta filter it out on the GLPI side, I reckon.

[g-bougard]

Hello @szelga

can you test this path, eventually fixing command ?

diff --git a/lib/GLPI/Agent/Task/Inventory/Generic/Users.pm b/lib/GLPI/Agent/Task/Inventory/Generic/Users.pm
index 24d0c8ee1..b250f75d8 100644
--- a/lib/GLPI/Agent/Task/Inventory/Generic/Users.pm
+++ b/lib/GLPI/Agent/Task/Inventory/Generic/Users.pm
@@ -6,6 +6,7 @@ use warnings;
 use parent 'GLPI::Agent::Task::Inventory::Module';
 
 use English qw(-no_match_vars);
+use UNIVERSAL::require;
 
 use GLPI::Agent::Tools;
 
@@ -133,6 +134,36 @@ sub _getLoggedUsers {
         @_
     );
 
+    # Use loginctl if available as more accurate than who when users has more than
+    # 32 chars in length. This can happen when computer is connected to an AD
+    if (canRun("loginctl")) {
+        my $json_content = getAllLines(
+            command => "loginctl --json=short list-users",
+            @_
+        );
+        unless (empty($json_content)) {
+            Cpanel::JSON::XS->require();
+            Cpanel::JSON::XS->import("decode_json");
+            my $json;
+            eval {
+                $json = decode_json($json_content);
+            };
+            if (ref($json) eq "ARRAY") {
+                my @users;
+                my %seen;
+                foreach my $logged (@{$json}) {
+                    next if empty($logged->{user});
+                    # Only keep users with uid >= 1000, others are root or system
+                    # users and may be "logged" as service
+                    next unless $logged->{uid} && $logged->{uid} >= 1000;
+                    next if $seen{$logged->{user}}++;
+                    push @users, { LOGIN => $logged->{user} };
+                }
+                return @users;
+            }
+        }
+    }
+
     my @lines = getAllLines(%params)
         or return;
 

I'm using here loginctl --json=short list-users command syntax as this is the one which works on my own Fedora system. -o json fails to produce json output on mine. If this option is not reliable against systems, we will have to better parse loginctl list-users. So does --json=short option works on your system ?

On my system, my user also has an active field. I don't see it in your output. I assume you modified your output for privacy purpose, so I wan to be sure you didn't remove an "active" field by mistake. Then can you confirm "active" field is not used on your side ?

About "fly-dm", in my patch, I assume all users with uid lower than 1000 to be system users - this includes "root" user. The "1000" number is the default on Fedora as seen into /etc/logins.def:

$ grep UID_MIN /etc/login.defs 
UID_MIN                  1000
SYS_UID_MIN               201
SUB_UID_MIN		   524288

Can you also share the version reported by loginctl ? Here is mine:

$ loginctl --version | grep systemd
systemd 257 (257.10-1.fc42)

This will help to take a decision if we can use it or not. Even I'm starting to think such command is not reliable as systemd changes a lot other time. I suspect your systemd is a little older and they changed the comportment of -o option in a more recent version.

Then about _getLastUser, I still don't see a correct/simple way to guess with 100% accuracy. We may decide to find the real user if last command returns a username with a 32 chars length. This should be enough until somebody will setup 2 users - or more... - with the same 32 first chars. Systemd provides userdbctl --no-legend command to list users so we probably can have a 32-chars string match. But I'm scarred to use it on an AD... It may be huge.

[szelga]

thanks for the patch. I'm gonna check your patch next week, when I have access to AD environment.

as for versions, for systemd versions 245 (245.4-4ubuntu3.24) and 255 (255.4-1ubuntu8.12), --json option is unrecognized. for those versions, --output json works. according to systemd changelog, that options was added in version 257: https://github.com/systemd/systemd/blob/8ea31c2307dda52cbbcd19dbe39f3cfdd7a3b8a5/NEWS#L2880

[szelga]

@g-bougard Tested the patch, works fine, but I had to substitute --json=short with --output json on my system (obviously).

[szelga]

#1080