We are looking to lock down our universal forwarders on Windows servers. Our plan is for all the necessary configs to be pulled down from a deployment server.
In light of that, is there any reason why we would need the local user (admin) created when the forwarder is installed? What functions would that be used for? Could we rename it or disable it to prevent it from being used? Also, is there a way to prevent remote CLI functions from being able to be run? What is the 8089 port used for on a forwarder?
Thanks for the response. Point 2 is what my question was mainly around, the forwarder's internal credentials. From initial testing it looks like the forwarder starts up just fine with no users in the SPLUNK_HOME/etc/passwd file. If I'm handling my initial installs and mass upgrades with a deployment tool like SCCM and I am managing my forwarder configurations via deployment server, are there any critical CLI functions I would be losing out on by not having any users internal to the forwarder?
Even if we changed the user name from admin and the password, we'd have to rotate the password (to meet internal standards). If there isn't any functionality we are missing out on, it seems easier to just disable it entirely.
The only time I leverage CLI on a forwarder is troubleshooting. I agree that if you've become very comfortable with deployment server and have a method in mind to manage potential changes to the deploymentclient.conf file, there's very little need for CLI or the management port. All that said, I do not know of a way to completely disable the CLI functions. You can check with support for confirmation. Restricting access to the forwarder installation from non-admin's with login capabilities is an option.