Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a Red Hat Enterprise Linux file server (Samba) running on a network governed by a Windows Domain Controller.
When I run my security scan tool, It finds that there is a 'guest' account with an active log-in shell. I need to disable this account's access.
I need to kill a networked guest account.
This guest account is NOT a local account on the Linux server so it's not listed in passwd/shadow. This prevents the normal usermod -L, or passwd -l, methods of disabling/locking an account. chsh results in an error saying use ypchsh but ypchsh can't see the domain (not sure why).
The only "guest" account in Active Directory (AD) is disabled. I even renamed it to guestX and did a gpudate (no affect).
When I su - guest (using root) it logs me on as 'guest' and displays the message, "Found Windows ADS User: guest"
I tried to create a local 'guest' account (useradd) and then disable it but of course my system won't allow this because it already sees a guest account.
I tried userdel guest but it's not a local account so this fails as well.
How are your systems using AD? Are you using pam_ldap? if so how are you binding? This could be your anonymous bind account to query the DC from pam_ldap.
I was unaware there may be an anonymous bind account used by pam. If that's the case then I probably don't want to disable it. Do you have any idea how I could at least disable the accounts default shell? The scan tool is not flagging the fact that I have a guest account, it's complaining because the account has it's shell set to /bin/bash.
The other system accounts are all set to /sbin/nologin.
ypchsh command says that it can't change the shell because my "domain name is not set."
I typed: ypdomainname
System response: <none>
I typed: sysctl -w kernel.domainname=mydomain
SYStem response: kernel.domainname = mydomain
I typed: ypdomainname
System response: mydomain
Now when I run ypchsh it balks with a new complaint: Can't find the master ypserver: Internal NIS error
in the /etc/samba/smb.conf file:
changing the default login won't work because we need the other users to default to bash.
Instlling IDMU and then adding the following line to the global section of smb.conf sounds like it is the best solution if you have many systems to update: "winbind nss info = rfc2307"
I was about to do just that (Install IMDU and add "winbind nss info = rfc2307" to smb.conf file) when I saw another post where someone suggested the fix below.
***** UPDATE *****
SOLVED!
getent passwd guest >> passwd
The 'useradd' command fails because the system sees that the guest account already exists but the 'getent' command gets the job done.
The 'getent' command is safer than attempting to manually add 'guest' to the local passwd file. The 'getent' command ensures that you get the correct user and group Ids and it also saw that my guest account had been renamed guestX in active directory. I changed the name to guestX (in Active Directory) in a vain attempt to make the guest account appear not to exist but samba already had a mapped it in its own db, therefore this had no affect. The 'getent' command saw the Active directory name (guestX) and samba name (guest mapped to system account 'nobody') and made the proper entry in the local passwd file.
Now that the 'getent' command has pulled all the correct settings into the passwd file, I have total control using the normal methods. I can now lock the account or in my case, simply change the login shell to /sbin/noligin. This made my vulnerability scanner (& me) happy!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.