Centrify Direct Control and centrify-sshd not permitting root to issue shell commands?
10-30-2018 04:46 PM
Hi Centrify Community,
I'm using a product called Thycotic SecretServer. It makes an ssh connectiong to a Linux host to perform a password reset. This normally works. Enter Centrify. On our Centrified hosts, we see a series of log lines in messages when SecretServer attempts to connect as root (using password authtentication) and reset the root password.
Does this mean Centrify is blocking root from issuing shell commands?
Oct 30 15:44:06 FAKEHOSTNAME adclient: INFO AUDIT_TRAIL|Centrify Suite|Centrify sshd|1.0|100|SSHD granted|5|user=root pid=24643 utc=1540939446412 status=GRANTED service=ssh-connection tty=(no tty) authMechanism=password client=188.8.131.52 sshRights=shell command=(none)
10-30-2018 05:14 PM
Welcome to Centrify!
We are sorry to hear about SecretServer! (Just kidding, we respect our competitors)
The audit trail message you're seeing there is expected. This is the log generated by our client to document "Individual access attempts" - as you can see, the user was allowed to log in. In this particular entry, the user was allowed to log in.
I'd recomment that you look into the logs to see of any other reason why this is not working.
Remember, if you are a commercial customer, we are a support case away (this is for non-SLA, volunteer help).
PS: In the future, always provide the OS, Centrify version (adinfo -v) and operating mode (zone or auto zone) - (adinfo --zone), to provide you with better assistance.
10-31-2018 09:31 AM
@Robertson thanks for your reply.
SUSE Linux Enterprise Server 11 (x86_64)
Operating mode is 'zone' (I think).
The part of the log line that I'm asking about is sshRights=shell command=(none).
Why is 'command=(none)'? This is a root login and it should be able to issue shell commmands. This does not happen on hosts that use OpenSSH that installs with the OS. Hosts that use Centrify's SSH installation have this issue.
I have a support case open- it's been open over 3 days. The engineer cannot answer that question. Can you assist them perhaps? Case 181025-194765.
10-31-2018 11:06 AM
Good question. This is related the format of Centrify Audit Trail.
Our format accomodates multiple access or privilege elevation methods. So when you read:
This means that you are requesting normal access rights (the default shell) with no commands.
Centrify provides suport for multiple shells, including a restricted shell and can also limit what commands can be run. The output would be different if you are dealing with a different shell, a remote command or something like SCP.
This is to aid organizations during investigative efforts.
Finally, some notes:
You are running a version of the product (5.1.3) that has been out of core support for almost two years.
I highly-encourage you to upgrade to a supported version.
To set the expectation clearly, I can't interject in support cases.
10-31-2018 12:02 PM
Sorry to be dense.
Does 'This means that you are requesting normal access rights (the default shell) with no commands.' mean that root can issue no commands in that shell?
Or, no commands are being passed when logging onto that shell?
11-08-2018 02:26 PM
The review trail message you're seeing there is normal. This is the log produced by our customer to archive "Singular access endeavors" - as should be obvious, the client was permitted to sign in. In this specific section, the client was permitted to sign in.
I'd recomment that you investigate the logs to see of whatever other motivation behind why this isn't working.
Keep in mind, on the off chance that you are a business client, we are a help case away (this is for non-SLA, volunteer help).