It's very possible. I'm giving KDE a look now on RHEL7. I've never used it too long due to stability issues on RHEL, maybe it will be better now.

Hi James,

Although it's possible to install the two desktop environments side-by-side, I wouldn't recommend to do that.
In case you are running RHEL Server, better install the basic system without a GUI and add the KDE DE later.
Sadashiva already provided the instructions how you can do it. Please note that this is just "my two cents". :)

Regards,
Christian

Rahul, for RHEL server (think data center, not for desktop use), I'd highly recommend you not install a graphical interface at all. Just use Command Line Interface (CLI). There are numerous reasons which boil down to having to perform less security mitigations for a RHEL server instance. Now if you're using a RHEL workstation or RHEL desktop (and not RHEL server), then a graphical interface would be more appropriate.

Can you use GNOME/KDE etc with RHEL Server? the answer is yes. However, if you're installing RHEL server to fulfill some server role especially in a data center, then you'll have to take additional security mitigations for the additional vulnerabilities inherited with a Server with GUI installation. You can CERTAINLY mitigate the issues, but it will involve much more work.

Those who are not used to command-line methods will often install RHEL Server with GUI on strictly server systems because they are used to it. You, your company/organization inherits additional risk that certainly can be mitigated, however, at a larger workload.

My customers do not use Server with GUI for RHEL Server. If they need GNOME/KDE, they restrict it to RHEL Workstation or RHEL Desktop.

Do as you deem best, but know what you are accepting as a result, and be aware of the additional cost in terms of time/effort and sustainability and security. I'd personally recommend against the use of a GUI with RHEL Server and restrict the use of GNOME/KDE to only RHEL Workstation or RHEL Desktop. Others will have a passionate view otherwise, but the cost/time of security mitigations are not worth it for RHEL Server. (Those that do like it for server use, need to mitigate the additional security issues of a graphical environment).

Here's some info on performing security mitigations for server builds: SCAP Workbench getting started at https://www.open-scap.org/getting-started/. This link gives you a basic how-to guide to use the SCAP security benchmarks and profiles (there are various security postures to select from based on your company or organizational security requirements, if in doubt, ask them). The methods use either a graphical or command line approach. Both methods will allow you to view what [known] security vulnerabilities are present and in many cases what actions to take to resolve them.

Consider reading the Red Hat Discussion are STIG discussions here and here, both of which are lengthy and have "rabbit trails" yet have some very worthwhile information. There is a common misconception that STIG requirements only relate to government-like entities. The short answer is, that is not true. Banking entities and other groups use STIG requirements as well! Routinely!! My Technical Account Manager (TAM) at Red Hat and other contacts I have at Red Hat have told me that non-government entities routinely use STIG requirements for their baseline. Another misconception, some will have a disdain for STIG issues (it actually can be a royal pain) and falsely think one must take =all= mitigations, =however=, you do not (you do not) have to inherit every STIG mitigation, nor should you. Document the mitigations you don't take and be prepared to explain why to whomever cares the most about security for your company (whoever the security responsible person is). There are STIG mitigations that are (in some cases just flat broken and have a bugzilla, like this yum.conf gpg check, for example), but there are many that are ... "sane" or at least feasible. I'll spare the expense of further explanation to the STIG Red Hat discussions, and not tie it up here.

Additionally, here is Red Hat's documentation on SCAP Workbench use.

We generally don't even bother installing KDE on RHEL workstations unless a customer specifically asks for it, then we do. Is KDE bad? No. Is GNOME bad? No. The real issue is configuring whichever one you select for your customers in a way that is easily repeatable and sustainable for function and use in your company. I don't personally care for KDE but forced myself to use it just to be able to support customers that do use it. There are some things that we got to work slightly better with KDE than GNOME (some highly unique high end graphical), and in some cases we ditched both KDE and GNOME and suffered the EPEL (google RHEL EPEL) use of "Mate" or "Cinnamon" and instead of using GDM we went to "lightdm"for a few highly unusual needed situations on RHEL workstations when justified (a very-very-non-merry chase of making either ATI/NVIDIA work with very non-typical unique software). More about RHEL EPEL from Red Hat.

Wish you well