I inherited a Linux server; the previous administrator is no longer with our company. I can log in to the server via SSH with my company-wide Microsoft Directory administration user, and it works perfectly. I have sudo privileges. But I can't figure out why. This is my nsswitch.conf:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the glibc-doc-reference' and info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

I would have expected to see myself with my user in the getent passwd command, but that's not the case:

myadminaccount@SERVER-NAME:~$ getent passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:101:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:110::/nonexistent:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
administrator:x:1000:1000:administrator,,,:/home/administrator:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
_rpc:x:106:65534::/run/rpcbind:/usr/sbin/nologin
mik:x:998:1001:OMD site mik:/omd/sites/mik:/bin/bash
Debian-exim:x:107:114::/var/spool/exim4:/usr/sbin/nologin
myadminaccount@SERVER-NAME:~$

The user seems to be known but the group not:

myadminaccount@SERVER-NAME:~$ ls -l | head -n4
insgesamt 384
-rw-r--r-- 1 myadminaccount 5001 11854  6. Feb 2023  update_2022-02-06.log
-rw-r--r-- 1 myadminaccount 5001 46374  7. Nov 2022  update_2022-11-07.log
-rw-r--r-- 1 myadminaccount 5001  8192  6. Mär 2023  update_2023-03-06.log
myadminaccount@SERVER-NAME:~$ ls -ln | head -n4
insgesamt 384
-rw-r--r-- 1 2173 5001 11854  6. Feb 2023  update_2022-02-06.log
-rw-r--r-- 1 2173 5001 46374  7. Nov 2022  update_2022-11-07.log
-rw-r--r-- 1 2173 5001  8192  6. Mär 2023  update_2023-03-06.log

At a minimum, the hostname of the Active Directory server, a password or key for the connection, and the information that my user has sudo privileges should be configured somewhere on the server. But where? And why isn't my username listed in getent passwd? Where should I read and look to find out more? The server is SMP Debian 5.10.226-1 (2024-10-03) x86_64.

I have a Debian 10 machine which uses PAM LDAP for authentication. In LDAP I have two users alice and bob which are both members of group mygroup. Everything has worked fine (so the configuration shouldn't be too far off) until I recently discovered some weirdness with my groups (not sure what happened): - ldapsearch reports user alice as a member of group mygroup (as it should). - getent group shows user alice as a member of group mygroup (as it should).

root@tux:~# getent group | grep mygroup
    mygroup:*:1210:alice,bob

- id does _not_ report alice to be a member of group mygroup:

root@tux:~# id alice
    uid=1200(alice) gid=1200(alice) groups=1200(alice)

- Surprisingly enough user bob is reported to be a member of mygroup:

root@tux:~# id bob
    uid=1201(bob) gid=1201(bob) groups=1210(mygroup),1201(bob)

So far I thought that both getent and id are getting their information from the Name Service Switch library (NSS). I'm confused and hoping for some hints how to troubleshoot.

I want to use basic tool available without installing anything to solve an IP into it's FQDN. I know the domain in which I can solve this IP. The command line or the tool should be available on any minimal debian or rhel based system which exclude : - /usr/bin/host - /usr/bin/nslookup - /usr/bin/dig I'm trying with getent but to no end for now. My resolvctl config looks like this: nameserver 127.0.0.53 search dom2.lan dom1.lan What I want is to get the FQDN of IP 10.1.1.1 in dom3.lan (not in resolvconf) without any package installed but the one on a Ubuntu server minimal image for example. getent hosts 10.1.1.1 does not return anything. host 10.1.1.1 dom3.lan return the hostname I want. So how can I achieve this without installing bind9-tools just with standard systemctl or basic linux package available in any linux distro that is less than 3 years old. Edit 1 : The solution I'm looking for need to be available to any user. I consider that python3 is available. Edit 2: I may be confused or dumb or may mis-explain what I mean. If I do the following nslookup request here's the result: Without domain appened: nslookup srv1 ;; Got SERVFAIL reply from 127.0.0.53 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find srv1: SERVFAIL With domain happen nslookup srv1.dom3.lan Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: srv1.dom3.lan Address: 10.1.1.1 Now I know my local DNS can solve dom3.lan. BUT I don't want to add it in my default search in /etc/resolf.conf because it's not my choice and the choice make sense in our context. BUT I'd like to be able to do reverse lookup like nslookup 10.1.1.1 and using a different search than the one set in /etc/resolv.conf. AND at the moment I realize that I don't even manage to do such a request from dig or host or nslookup while if I edit my /etc/resolv.conf without changing any other DNS settings it works. So my question is : is there a way to set a search for a reverse DNS lookup with any tool and if possible not an installed one. nslookup set q=A set domain=dom3.lan 10.1.1.1 no result with dig dig @127.0.0.53 +norecurse +domain=dom3.lan. -x 10.1.1.1 No result either. I'm not even sure this question makes sense but there's definitely strange stuff happening on my system. If changing my /etc/resolv.conf search works I feel like a tool like dig or nslookup should work as well.

We are using SSSD for authentication using LDAP. And I filter the user access using **simple_allow_groups** as follows: access_provider = simple simple_allow_groups = Computer Admins (**Note**: Computer Admins is a LDAP group) Is it possible to get a list of **ONLY** allowed users using **getent** or something else?? There is an option enumeration, but this lists **all** users from LDAP. I am only interested in the **allowed** users.

Getting the output of user identity with getent passwd. How can i change the output from

:John Doe

to

,jdoe

i got it with sed but it it removes u12345 but does give me jdoe

I'm used to joining windows 2008 r2 AD with Krb5.conf/ldap.conf/smb.conf and pam.d/authconfig_ac and being able to list users with

getent passwd

but after joining a centos 7 system I can logon fine, but I can't see users in AD who are able to logon. What do I need to look at to fix this? I'm just getting my feet wet on Centos 7 and used the join realm to join the domain.

I have an administration node running LDAP and a login node which uses LDAP on the other node to authorize users. Users are able to log into the login node successfully. When I run

passwd

, on the admin node I get all the users, both those from

/etc/passwd

and LDAP. However, on the login node the LDAP users are missing. Both machines are running CentOS 7.9.2009 and both have an identical

/etc/nsswitch.conf

. The only non-trivial differences between the two version of

/etc/sss/sssd.conf

is that on the admin node ldap_access_order = filter,expire is set, whereas on the login node the setting is ldap_access_order = expire but that seems to me irrelevant (the filter just contains a single non-root functional user which was only used when the system was set up). Where else should I be looking to work out what the difference is between the two systems?

With getent group xyz I get a list of users who are members of

with

either as a primary group **or** as secondary group. How do I get a list of just those users who have

as their primary group? My users are in LDAP, so I am not looking for solutions which involve parsing

/etc/group

.

I recently installed my EPSON L3150 printer's drivers and about the same time I started having weird (and random) DNS name resolution errors in some applications (ssh, nextcloud-client), that I can only fix by restarting the NetworkManager service: systemctl restart NetworkManager For example:

$ ssh example.mydomain
ssh: Could not resolve hostname example.mydomain: Name or service not known

Another example is getent, which returns nothing and exits with code 2:

$ getent hosts example.mydomain

$ echo $?
2

But nslookup works fine:

$ nslookup example.mydomain
...
Name:	example.mydomain
Address: 192.168.0.10

I narrowed it down to my nsswitch.conf file, which I blame my printer installer for changing it. I found a nsswitch.conf.bak lying besides a nsswitch.conf, created at the same time that I installed the printer drivers using dnf install epson/*.rpm. The file had this change in the hosts line:

-hosts:      files dns myhostname
+hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

So the question is, why does the "new" configuration fail so randomly? How can I prevent it? I don't think just restoring the original file would be a solution since the new file seems to be auto-generated, it says so right at the top: > Generated by authselect on Sat Feb 12 18:53:06 2022 Uninstalling the driver would also not be a solution. **EDIT**: The culprit seems to be systemd-resolved. My network config is managed by NetworkManager and I setup two DNSs:

$ nmcli con show my-lan
...
ipv4.dns 192.168.0.1 8.8.8.8

It seems that whenever my computer wakes up from sleep, NetworkManager falls back to the second DNS:

$ systemd-resolve --status
...
Link 2 (enp39s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 192.168.0.1 8.8.8.8
        DNS Domain: mydomain

Thus causing systemd-resolve example.mydomain to fail (because 8.8.8.8 can't resolve my domain): > query: resolve call failed: 'example.mydomain' not found I guess it's a bug in NetworkManager?

I want to get list of users - both human and machine who have access to the unix server. OS is:

NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"

I tried

/etc/passwd

and

passwd

- but both these lists are incomplete. A number of users that have a folder in /home are not present in output of either of the above two commands. I ran

for a username that had a folder but not present in the output of these commands and I got a valid output, proving that that user exists. So, how do I get a list of "all" users of the server.
PS: I do have sudo access. Output of

~> grep passwd /etc/nsswitch.conf
passwd:     files sss

EDIT1: I did some digging and turns out this server uses IPA. I ran

user-find

. It listed 2K users, which I believe is the exhaustive list of users that are created via IPA but not necessarily all of them have access to this particular server. More Background:
Most human users login via either SSH or id + password.
This server is not maintined by any IT/Server team; the business users own the server. People without deep knowledge of servers and systems maintain create users on it. I recently got sudo access and need to 'clean up' the server a little bit - delete users who no longer should have access, identify data that can be archived etc., create proper unix groups to segregate access to data.

With my current setup, I have a dnsmasq instance operating on my home server (Void Linux) and 3 GNU/Linux devices that use it as default dns (1 Manjaro, 1 Arch, 1 Linux Mint 20.1). Due to seemingly unrelated issues, I was testing the mdns name resolution with getent, and I noticed, both by looking at dnsmasq logs and running strace getent, that getent would automatically append the .station Top Level Domain if the domain wasn't already specified. getent hosts home-server results in

dnsmasq: query[AAAA] home-server.station from 192.168.0.6
dnsmasq: forwarded home-server.station to 9.9.9.9
dnsmasq: query[AAAA] home-server.station from 192.168.0.6
dnsmasq: forwarded home-server.station to 9.9.9.9
dnsmasq: query[AAAA] home-server.station from 192.168.0.6
dnsmasq: forwarded home-server.station to 9.9.9.9
dnsmasq: forwarded home-server.station to 95.216.24.230
dnsmasq: forwarded home-server.station to 89.233.43.71
dnsmasq: forwarded home-server.station to 78.46.244.143
dnsmasq: forwarded home-server.station to 146.255.56.98
dnsmasq: forwarded home-server.station to 78.46.244.143
dnsmasq: forwarded home-server.station to 146.255.56.98
dnsmasq: forwarded home-server.station to 78.46.244.143
dnsmasq: forwarded home-server.station to 146.255.56.98
dnsmasq: forwarded home-server.station to 45.90.57.121
dnsmasq: forwarded home-server.station to 80.67.169.40
dnsmasq: forwarded home-server.station to 104.244.78.231
dnsmasq: reply home-server.station is NXDOMAIN
dnsmasq: query[AAAA] home-server from 192.168.0.6

On the dnsmasq log and

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4
setsockopt(4, SOL_IP, IP_RECVERR, , 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.100")}, 16) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\2\17\1\0\0\1\0\0\0\0\0\0\vhome-server\7station"..., 37, MSG_NOSIGNAL, NULL, 0) = 3

Calling getent with strace. I wasn't able to find any information regarding the .station TLD. Does anyone know why does getent have this default behavior, and where does the .station come from? My /etc/nsswitch.conf hosts line on Manjaro

hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve dns mdns4 myhostname

On Mint

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

The output further down was retrieved by employing machinectl on a Ubuntu 20.04 host: * machinectl pull-tar https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-root.tar.xz focal * machinectl start focal * systemd-run --machine focal --pty /bin/bash You should be able to reproduce this as long as the cloud image for "focal" is available. Here's the output:

root@ubuntu:/# getent passwd|grep -P '^(nobody|root):'
root:x:0:0:root:/root:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
root:x:0:0:root:/root:/bin/sh
nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
root@ubuntu:/# cat /etc/passwd|grep -P '^(nobody|root):'
root:x:0:0:root:/root:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Curiously getent shadow doesn't show the same discrepancy:

root@ubuntu:/# getent shadow|grep -P '^(nobody|root):'
root:*:18697:0:99999:7:::
nobody:*:18697:0:99999:7:::
root@ubuntu:/# cat /etc/shadow|grep -P '^(nobody|root):'
root:*:18697:0:99999:7:::
nobody:*:18697:0:99999:7:::

Can someone please shed any light on what's happening here? Why is getent passwd producing two entries for root and nobody each?! Additionally, why does the shell for root differ for these entries?

On a specific machine with both local users and LDAP users, there is a user that is listed under getent group foo (let's say the user jdoe is listed), but when doing getent passwd jdoe I get no output. Attempting sudo su jdoe doesn't work either. Using the command members -t foo I found out the user is only listed as a secondary member of the group, although I'm not sure if that's relevant. Does anyone know how I can find out how this seemingly nonexistent user ended up in this user group? To clarify, the listed user is in no way related to a system user, and it doesn't seem to be listed anywhere under locally created users. Something that might be a possibility: is it possible this is being caused by someone who previously had a user account named jdoe, whose account since has been renamed or deleted? And if so, how can I find this out? This is my /etc/nsswitch.conf:

-none
passwd:         compat ldap systemd
group:          compat ldap systemd
shadow:         compat ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

It is pretty much the default configuration with LDAP included.

There is a term called ahostsv4 in the Linux documentation of man getent. What is the usage of it?

If I execute sudo getent shadow I see password hashes for all the local users who have them. For most of the LDAP accounts I only see * in the password field. However, for a few LDAP users, I see password hashes. I have verified that they don't have local accounts (i.e. no entry in /etc/passwd but getent passwd username returns a line). In fact, logged in as myself, my user entry is one of the ones with an *. There is a single LDAP server running OpenLDAP with a single group of accounts (one branch in the tree). The LDAP-client servers are running nscd and libnss-ldap. This is a portion of /etc/nsswitch.conf on the LDAP-client servers: passwd: files ldap group: files ldap shadow: files ldap LDAP is used to authenticate the user for login to the LDAP-client server in this case and at some point the authentication mechanism, PAM in this case, must check a hash of the password provided by the user at login against the stored hash which is contained in the LDAP database. Each user's LDAP account stores their password hash and has the objectClasses of posixAccount and shadowAccount (among other values and settings). Only system accounts have local entries in /etc/password and /etc/shadow. User accounts are all on LDAP (and only there). All users in LDAP have userPassword entries. What might cause this or how can I run down the cause of it? Why doesn't getent shadow return password hashes for all LDAP users?

# Question How is the following possible? $ getent group | grep docker $ getent group docker docker:x:600: Note that the first call doesn’t return anything while the second one does. grpck doesn’t report any issues. # Some Background This is on a CentOS 7.6 VM that I have inherited from someone else, so I’m not sure where its configuration could potentially differ from the CentOS defaults. As far as I can tell, the VM is connected to LDAP somehow (but I’m not too familiar with this …). Actually I wonder where this docker group is defined. At least it’s neither in /etc/group nor in /etc/gshadow. As requested in the comments: $ grep ^group /etc/nsswitch.conf group: files sss hesiod

In various shell scripts I often see two approaches for getting information from databases supported by *Name Service Switch* libraries like /etc/group, /etc/hosts or /etc/services. One is getent utility and other is grep or some other text processing tool. For example: root@fw-test:~# getent passwd root root:x:0:0:root:/root:/bin/bash root@fw-test:~# root@fw-test:~# grep root /etc/passwd root:x:0:0:root:/root:/bin/bash root@fw-test:~# ..or: root@fw-test:~# getent hosts www.blah.com 189.113.174.199 www.blah.com root@fw-test:~# root@fw-test:~# host www.blah.com www.blah.com has address 189.113.174.199 root@fw-test:~# Which of those two approaches above should be used in scripts? I mean is one of the solutions more elegant or standard than the other?

This is a follow-up to this question . I have a CentOS 7 machine which has joined a domain FOOBAR. It is possible to successfully get info about users stored in the AD via id user@FOOBAR.GLOBAL However, getent passwd and getent group do not show users and group defined in the AD. These are the relevant lines in /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss What needs to be added there?

Verbatim output from my terminal: $ getent hosts example.org 2001:500:88:200::10 example.org $ getent ahosts example.org 192.0.43.10 STREAM 43-10.any.icann.org 192.0.43.10 DGRAM 192.0.43.10 RAW I thought they were both (at the very least [ahosts](https://unix.stackexchange.com/questions/30318/what-is-in-the-output-of-getent-ahosts)) supposed to print both IPv4 and IPv6 addresses. Why are these printing different address types? $ uname -srvmpio Linux 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:17:36 UTC 2012 i686 i686 i386 GNU/Linux **Edit**: Looks like it might be related to this bug report .

I just got a user account on a server with its nsswitch pointing at ldap. Something is wrong with my home folder (I don't have one). Generally the home folders are mounted by automount/autofs and the automount maps are in ldap. In the bad old days of NIS it would have been as easy as ypcat auto.home | grep myusername to verify if the automount map had sane data. In Solaris they seem to have similar features built into getent. How can I query the automount maps in CentOS 6 type Linux? I do not have ldapsearch available, nor do I know what ldap server I'm using or how the catalog is structured. So I don't think manual ldap queries is much of an option.