Data Loss Prevention

Hello

I am running DLP 11.5 and under settings>general I enabled AD Authentication. Now I get the j_security_check error when I try to login after rebooting. The user account jpadmin was in an admin role on the Enforce server and that is also my domain admin account, Im starting to think there was a typo in the KRB5.ini path I entered?

Is there any way to revert back to the old configuration since I am unable to login and correct it? Or a way to edit the file manually to correct it?

I have read the post below but admit I rebooted and didnt restart the service and test before I did. https://www-secure.symantec.com/connect/forums/symantec-vontu-dlp-ad-authentication-users-problem-help

Thanks for your help

You should be able to login using the defaul Administrator account and password, since this is not an AD account.

Yayuca is correct, the normal Administrator account shoudl still be enabled and allwo you back in to verify settings. If you have multiple domains configured as well, you need to be sure to choose the correct domain in the drop down box.

If you want to verify that your krb5 file is configured properly, you can reference (I'm looking at an 11.1 Admin Guide) page 103 of the Admin Guide to test the connection. This will confirm/deny if your krb5 is configured properly. If you have teh Admin Guide for 11.5 search in the PDF for: "Verifying the Active Directory connection".

Hi DLP Scanner,

I had faced same error before couple of months, In this you might getting enforce login console but after providing login+password , you are getting above error.

I had researched on this issue an got some valuable outcome. When you provide your login and password are stored on Oracle DB and they are checked and authenticated through enforce to oracle.

As if ther is connectivity issue between oracle and enforce server's services then above error will displays.

1) You can restart the oracle/enforce services as per Symantec DLP Admin guide

2)If still persist the error, restart both servers.

Thaks ShawnM

I added the following to the krb5.ini

[libdefaults]

default_tkt_enctypes = rc4-hmac

default_tgs_enctypes = rc4-hmac

permitted_enctypes = rc4-hmac

And I finally get a ticket. So the KDC setup for this user is complete per the documentation.

However I still get the error in the log

java.lang.RuntimeException: java.lang.RuntimeException: Default KDC not set

And I still hang at the J_security_check. I tried rebooting the DB waiting until it started and then rebooting the Enforce server but still hang at the error. Here are the logs after reboot below:

20 Apr 2012 11:58:53,859- Thread: 10 INFO [com.vontu.manager] Enforce Server started. The enforce server was started.

20 Apr 2012 11:58:53,875- Thread: 10 INFO [com.vontu.manager.ProtectServlet] (MANAGER.2) The Manager is now running

20 Apr 2012 11:58:53,953- Starting Coyote HTTP/1.1 on http-443

20 Apr 2012 11:58:53,968- Server startup in 7765 ms

20 Apr 2012 11:59:53,812- Thread: 12 INFO [com.vontu.manager.system.keystore.KeystoreRotationTask] (MANAGER.805) Checking if cryptographic keys require rotation

20 Apr 2012 12:03:53,890- Thread: 13 INFO [com.vontu.manager.license.ManagerLicenseTools] (MANAGER.400) License validation succeeded.

20 Apr 2012 12:03:53,890- Thread: 13 SEVERE [com.vontu.manager] License has expired. One or more of your product licenses has expired.  Some system feature may be disabled.  Check the status of your licenses on the system settings page.

20 Apr 2012 14:16:04,521- Thread: 14 INFO [com.vontu.enforce.authentication.kerberos.KerberosAuthenticationService] System property java.security.krb5.realm=globeandmail.net

20 Apr 2012 14:16:04,521- Thread: 14 SEVERE [com.vontu.enforce.authentication.kerberos.KerberosAuthenticationService] Default KDC not set

20 Apr 2012 14:16:04,537- Thread: 14 SEVERE [com.vontu.enforce.authentication.AuthenticationServiceFactory] Unable to initialize the EnforceAuthenicationService

Cause:

java.lang.RuntimeException: Default KDC not set

java.lang.RuntimeException: Default KDC not set

                at com.vontu.enforce.authentication.kerberos.KerberosAuthenticationService.<init>(KerberosAuthenticationService.java:39)

                at com.vontu.enforce.authentication.AuthenticationServiceFactory.getService(AuthenticationServiceFactory.java:22)

                at com.vontu.enforce.authentication.realm.ProtectJAASRealm.createAuthenticationService(ProtectJAASRealm.java:82)

                at com.vontu.enforce.authentication.realm.ProtectJAASRealm.getAuthenticationService(ProtectJAASRealm.java:74)

                at com.vontu.enforce.authentication.realm.ProtectJAASRealm.authenticate(ProtectJAASRealm.java:29)

                at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:259)

                at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:454)

                at com.vontu.manager.security.VontuFormAuthenticatorValve.invoke(VontuFormAuthenticatorValve.java:64)

                at com.vontu.manager.security.ClientCertificateLoginValve.invoke(ClientCertificateLoginValve.java:81)

                at com.vontu.manager.security.SpcSsoValve.invoke(SpcSsoValve.java:106)

                at com.vontu.manager.security.IpCatcherValve.invoke(IpCatcherValve.java:73)

                at com.vontu.manager.security.CharacterEncodingValve.invoke(CharacterEncodingValve.java:42)

                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)

                at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:581)

                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)

                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)

                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)

                at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)

                at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)

                at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)

                at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)

                at java.lang.Thread.run(Thread.java:619)

20 Apr 2012 14:16:04,537- An exception or error occurred in the container during the request processing

java.lang.RuntimeException: java.lang.RuntimeException: Default KDC not set

FYI I cannot log into the DLP server as Administrator ever since I made the AD change. I get the same J_security_check error. Any ideas? Thanks for your help. 

Hi kishorilal

Yes we once resolved a j_security_check issue by restarting the Vontu services a month ago, when it was not using AD authentication. The password i used for the Enforce account and the AD account were the same so it shouldnt be different on those 2 sources. Ill have another read through on that section though do you have a page number? thanks again

You may want to check that the TNS listener is running on your oracle server.

From the logs here, it looks like there is still something happening with the authentication service starting and having an issue. I would go to P101 of the Admin Guide, and walk through the steps again to ensure everything is correct. Keep in mind, some pieces of the krb5 file need to be UPPERCASE as mentioned in the guide. From the last line "Default KDC not set" it sounds like you are missing the default realm (aka domain) in the [libdefaults] section of the file, I would start there.

The other note I will make, is that I've randomly seen this error occur when something happens with the TLS listeners (as someone noted below), and other times I've seen it happen for no known reason and so restarting the servers is my course of action which has solved the problem. Many times if you change configuration files, the services or system services need to be restarted to fucntion properly. A full system restart is generally most effective as it will ensure all necessary services are completely restarted.

Thanks ShawnM

Ive tested my DB connection is good and the KRB seems to be fine with Kinit tests. I see now I made 2 errors when I configured the AD authentication in the Enforce server; I set the domain in lowercase letters and did not put a KDC server in the appropriate boxes. We had a vendor setup the system and I didnt take the time to read the documentation which was foolish as I see now it was a big deal. Im going to see if I can reset the administrator password to login locally and correct the mistake as there seems to be no other way to fix it. Otherwise it will need to be set up all over again. 

Please verify also if you have enough free space available on the partition with the Oracle DB. When we get j_security_check after we try to authenticate into the interface, we realise that we have only a few MB free on the partition with Oracle DB... and we solved this problem by archiving and deleting the old logs.

Kishorilal,I tried your solutions but it seems that none of them is really working

1) I restarted the oracle/enforce services as per Symantec DLP Admin guide

2)I restarted both of my servers.

...but all came down to the same error.

Is there any other way to get through this?

http://www.bloggypedia.com/

I just got hit by the "j_security_check" issue.  I couldn't log on as Administrator, Oracle was fine...

My issue was that a file /vontu/protect/config/jaas.config had been deleted.  (Shame on me, I missed the errror in the logs and had to call support.)