Endpoint Protection

Always had this issue,


Windows Server 2008 R2
All machines on a domain.
Delegation model in place for SQL access

SQL 2005 server, service pack 3
Dedicated instance installed.
SQL account has Sysadmin rights to the instance works fine.

Windows firewall is turned off for all profiles.

McAfee, Sophos and Sanctuary setup and using the instance without an issue.
SQL server changed to mixed authentication mode.
SA account activated but I do not want to use it.

SEPM installation starts on a server called SEP, enter advanced mode.
Follow guide, get to the part about creating a database.

Select windows authentication mode.
Continually get the error about not being able to connect to the database.
DNS is fine, forward and reverse works.
Enter SQL authentication mode, connects to the database instance without an issue.

Go back to windows auth mode, check the service account password has no special chars in it, found in a one liner in the installation guide hidden away somewhere.
Makes no odds, still can't connect to instance with Windows Authentication turned on.
Check tomcat installation error log @ C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\logs

Find this:

Java.sql.SQLException: Login failed for user ''. The user is not associated with a trusted SQL Server connection.

SEPM Installation program is not parsing any username through when it tries to authenticate against the SQL Server.
All I can see in the DC server's event logs is the attempted logon from a NULL SID. Useless.
This looks to me like an absolutely major bug, how has this managed to come across from SEP 10 and now into SEP 11 and has not been addressed?
I found something identical when installing SEP 10 which meant I purely couldn't get Windows Authentication to work against SQL 2005.

The ONLY way I can get this damn product to install is via SQL authentication, what is going on?

Hi,

Have you checked the article below:

"Login failed for user 'username'. The user is not associated with a trusted SQL Server connection" in install_log.err while installing Symantec Endpoint Protection Manager (SEPM) on Microsoft SQL 2005

http://service1.symantec.com/support/ent-security.nsf/docid/2008111401380948


Checklist for installing Symantec Endpoint Protection Manager with SQL Server 2005

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/8ed22363812c4c8388257456004df257?OpenDocument

Aniket

Hi Aniket, thanks for your reply.
The first article is not the problem I am experiencing, I appreciate you are trying to be helpful but you are missing the point of what I have written.
The error I am seeing does read "

"Login failed for user 'username'. The user is not associated with a trusted SQL Server connection"

However, the problem is not the SQL server or the username or any operating mode, the problem seems to me to be the SEPM installer failing to behave correctly.

If you read my descirption above, I said that the error I am facing is that there is NO username parsed in the tomcat logs when the installation tries to authenticate against the domain. The username is simply '' (as in nothing). This is backed up by the fact that the DC shows a NULL SID attempting to logon in the security logs.

The problem in the first article you've put describes the wrong operating mode for the SQL server and the sa account being disabled, I stated also above that the SQL server was in mixed mode and the SA account WAS active. This works without a problem, however I do not want to use a clear text SQL authentication login to make the product work. It claims to use Windows Authentication, as in domain based kerberos, but it fails to send a username to the DC.

I followed the checklist in the second article you pasted originally, don't forget I said that I CAN get SEPM installed with SQL authentication, just not Windows authentication.
I could be wrong but it appears what I've found here is quite a severe bug, that I've experienced before in SEPM 10 and has now been carried forward into SEP 11. I reported a feature of the install broken in the same way about a year ago now and it was admitted this was a bug in the software, the exact same bug that I'm now experiencing in SEP 11.

My question is WHY is there no domain username being parsed from the installer to the SQL server / DC when attempting to hit the database.
This alone makes it IMPOSSIBLE to authenticate with Windows Kerberos Authentication as it hits the DC with a NULL SID every single time

Could someone with a bit more in depth knowledge of what I am reffering to please comment?
Thanks

Paul

This issue was supposed to be resolved in MR4Mp2 ( 11.0.4202.75 ) and latest version is 11.0.5002.33
Are you installing the latest version ? 

I will check...

Ok I have checked.

I am using 11.0.5002.333 as you stated.

This bug is certainly not fixed I can assure you.
I think the prevention of using Windows Authentication and forcing the admin to select cleartext SA authentication really needs to be sorted out pretty fast no?
Perhaps this needs elevating to the correct people, unless I am doing something hideously wrong of course and then feel free to tell me.

P

 Long back I had this issue with one of my customers..I installed it on my test environment using Windows Authentication it worked fine I used the same settings on customer's env.. it dint work..

Well the user account with which you are trying to install ..does that Use account show up in the Studio ?
Make sure you are entering
domain\user or computer\user

 I'm not sure what you mean by "does the user account show up in the Studio".
You mean the SQL management studio for 2005?

The user account is specified as having Sys Admin rights on the instance so it can do anything it wants.
Yes I am using domain\user, I have a huge background in Active Directory and have been using Microsoft products for over 20 years.
The same model of delegation I have used for the 3 other products installed on the instance like I've mentioned.

Back to the point, I have checked all name resolution like I said, other products are using the instance with Windows Authentication just fine.
I repeat that I managed to get the product installed with cleartext SA authentication so there is nothing wrong with the domain / SQL server or any supporting components.

Please assume from this point onwards that I am technically very adept within these technology areas and also try to keep in mind that if I say the SQL server infrastructure is working for 3 other products, I will know how to set up Security Logins to make it operate.



The most important part as I have mentioned is the fact the tomcat logs show NO USERNAME being parsed through and the associated domain controller showing a NULL SID attetmpting to authenticate. As far as I am concerned this is the be all and end all of the problem that I am facing.

I have tried to do some fault finding, I noticed the installation guide said there can be no special characters in the service account password so I removed these.
Same problem.
I removed all special characters (non alpha numeric) from the service account name so it was plain text.
Same problem.
I cloned the service account and gave it the same rights, complex plain text password etc ( I used Password12345 so it was complex yet no invalid characters).
Same problem. I simply can not make it work.

The only other choice I can see is lowering the number of password characters and complexity the domain is insisting on, perhaps add fine grain password policy. It still wouldn't explain the null sid being parsed from the installer however.

It would be very useful to know from a deep technical point of view if there are any obvious restraints on the password/username such as length/complexity that are not mentioned in the install guide, because anything i do from this point onwards is guess work.

I would suggest opening a case with Symantec in that case..

You might have this enabled however you can double check if you have these roles enabled for the account.
 "dbcreator" role
 "securityadmin" roles

If you have the "SysAdmin" role for an SQL login you instantly have all rights on the SQL instance... there is no need to specify anything else...
I guess I need to open a case, but I don't know how. I'm supposed to be going for an interview for a job using SEP  in 2 days time, what am I supposed to say in its defence?
"Yeah I can really recommend this product, first try to install it resulted in a critical bug which meant I had to use unsecured SQL logins."

Pfft :(

I find this unbelievable that no one else has run into this problem or it has been addressed yet!
Surely all enterprise solutions will use Windows Authentication on a remote SQL instance? :(

Dime

OK I've just been on the telephone for the best part of 30 minutes and now I am more than slightly angry.

I got through to someone who said I couldn't talk to anyone technical about the problem because I was using the latest trial version. She then told me I would be put through a technical pre-sales person, to which I expressed concern as I explained I needed to talk  to someone deeply techincal about this. She refused and put me through to what was a non technical line where I was not allowed to ask any technical questions, which didn't matter because the line was closed anyway and I was instantly cut off.

What sort of business is this company running?
I've found what I consider a show stopping bug and I'm trying my hardest in my own damn time to contact Symantec for help and it's impossible.
I had the same issues in SEP 10 to which I got an admission that it was a bug in the software, I pickup the same problem in SEP 11.
I'm calling on behalf of one of the largest technical consultant companies in the world, we're currently using SEP 10 to manage thousands of endpoints.
This apparently doesn't matter?

Firstly the technical support is impossible to contact, then I can't get put through to someone technical then I get an answer-phone message after a refusal then cut off? Can someone suggest or put me in contact with a developer / technical support person from Symantec before I get seriously miffed and start looking at another another provider such as Sophos / Lumension etc? One that I can actually get installed in a normal secure fashion without incident? :(

Any help gratefully received at this point, I'm at a total loss of how I'm meant to proceed.

Please note I am a very experienced consultant with numerous SQL implementations with applications. But I am getting the same error with SEPM. I am also having the same frustrations with getting a straight answer for support.

SQL Server 2005 SP3
Windows 2008 R2 (6.1)
Symantec Version 11.0.6100.645
Java Version:1.6.0_14

tomcat install_log.err = java.sql.SQLException: Login failed for user ''. The user is not associated with a trusted SQL Server connection.