Data Loss Prevention

 View Only
Expand all | Collapse all

Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

  • 1.  Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 12, 2018 11:34 AM

    Hi All,

    There is an environment of Symantec DLP 15.0 wherein the Enforce Server is installed on RHEL 7.4. It has been running successfully for a while after upgradation. However due to some issue this machine was rebooted and then subsequently, it fails at systemctl status systemd-logind.service with Failed to Login Service failure.

    Assuming this to be an issue with the machine, various steps were attempted after reading articles such as https://unix.stackexchange.com/questions/321038/cannot-login-failed-to-start-login-service. However the machine was not able to be run successfully.

    So, a new machine with RHEL 7.4 was setup (VM) and Enforce Server was installed on it using the EnforceReinstallationResources(config and keystore folders) method and here an issue was encountered "Failed to encrypt the password file" which was resolved using https://www.symantec.com/connect/articles/symantec-enforce-recovery-reinstall tips. 

    Running the Enforce Server, was able to access the Login Screen for DLP. The AD Integration was not showing so tried installing the relevant packages krb5 etc and then rebooted the machine.

    So unfortunately, this new machine got stuck at the login as well and shows "Failed to Login Service Failure".

    Is this an issue with RHEL 7.4 ? 

    Kind regards



  • 2.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 12, 2018 02:56 PM

    Hi here,

    If you check the link below, it only mentions RHEL 7.1, 7.2 & 7.3 as supported OS, although 7.4 is mentioned as a Linux system that can be scanned.

    https://symwisedownload.symantec.com//resources/sites/SYMWISE/content/live/DOCUMENTATION/10000/DOC10602/en_US/Symantec_DLP_15.0_System_Requirements_Guide.pdf?__gda__=1542194492_df55afeea181cc59acd19146e2de5010

     

    However, DLP 15.1 lists Oracle Linux 7.3 & 7.4 as supported for Enforce Server:

    https://symwisedownload.symantec.com//resources/sites/SYMWISE/content/live/DOCUMENTATION/10000/DOC10602/en_US/Symantec_DLP_15.1_System_Requirements_Guide.pdf?__gda__=1542194492_60ae8e5a03a815788a89f23402e47dcb

     

    So it could be a compatibility issue you're facing. Check out both those documents as confirmation.

    Thanks!



  • 3.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 13, 2018 03:32 AM

    Hi Muhammed,

     

    Have you checked that all services are running on your linux box?

     

    RHEL 7.4 should be fine running Enforce. Is your database instance performing as it should?

     

    Have you also checked the logs for anything suspect. I would start with the Tomcat logs.

     

    Thanks



  • 4.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 13, 2018 04:12 AM

    Hi Alan,

    The issue is that the Enforce Machine (RHEL 7.4) gets stuck on Failed to Login Service Failure after reboot. So we aren't able to get the Enforce Machine to get back up successfully. Otherwise when the machine is up and running, the Enforce works fine all the services are up and DLP is running alright.

    We attempted to restore the Enforce on another RHEL 7.4 machine and then after reboot this issue occurs as well. However somehow it has managed to come back up now after reboot with Enforce console being successfully accessed and overall DLP running alright, however untill it has been identified what exactly the issue is either with RHEL 7.4 or DLP since this is continuously occuring after reboot then we will now try to restore the Enforce on RHEL 7.3 Machine.

    Kind regards

    Muhammad Ahmad Gul



  • 5.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 13, 2018 05:47 AM

    Ah right now this makes sense!

     

    I have experienced the same issue. When you boot up the server you get prompted to select which Kernel you want to boot from. If your system has done an update this usually happens.

     

    Reboot your server and select a different kernel to boot from other than the top, you should find this allows you to log in.

     

    If you need me to send a screenshot of my instance on boot feel free to ask and I'll help you more.

     

    Thanks



  • 6.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 13, 2018 06:21 AM

    Well, actually no update was performed on the machine. And the other kernels were also tested and same issue is occuring. Failed to Login Service Failure.



  • 7.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 14, 2018 05:18 AM

    We have now moved the DLP Enforce to RHEL 7.2 and its working fine after reboot. The issue with RHEL 7.4 was not able to be identified. 



  • 8.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 14, 2018 05:40 AM

    Might still be some sort of incompatibility with 7.4.



  • 9.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 14, 2018 06:47 AM

    Seems like it, however in DLP 15.1 they now mention that RHEL 7.1 through 7.5 is supported.

    So not clear right now what the problem was with RHEL 7.4. 

     



  • 10.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)
    Best Answer

    Posted Nov 15, 2018 02:55 AM

    Check the links I sent through...RHEL 7.4 isn't shown as listed for DLP 15, but it is for DLP 15.1, which is why I said in the beginning I suspected it might be a compatibility issue.

    Sometimes you might get an application to work on a newer OS, but there are subtle differences. Whilst it may work now, there would be no guarantee it would work later, and no guarantee Symantec would offer you any form of support except to say you need to upgrade.

    Thanks!



  • 11.  RE: Symantec DLP 15.0 on RHEL 7.4 (Stuck at Login after Reboot)

    Posted Nov 16, 2018 07:30 AM

    Hi CraigEV,

    Yes, it seems to be the case. So will close this as this seems the most possible reason.