Skip navigation
3212 Views 7 Replies Latest reply: May 17, 2012 6:53 AM by Jason Creech RSS
Nitin Gopinathan Level 1 11 posts since
Apr 19, 2012
Currently Being Moderated

May 14, 2012 7:15 AM

Policy Compliance - SQL Controls fail to evalute

Hi,

 

I have been running quite a few scans to check whether my SQL Server 2000 controls work as expected. However, there is no data related to SQL Server being displayed in any of the reports. No graphs, no data, nothing. I am not able to figure out the problem despite repeated changes to the policy and scan profiles. The machine being scanned is tunning SQL Server 2000 on a Windows 2003 Server machine. Screenshot below shows the output I get from every scan.

 

EDIT : When testing for the same values using manually created controls, things seem to be running fine. The inbuilt controls are failing without any error message. Is this a known issue?

 

sql_policy.JPG

 

Regards,

Nitin Gopinathan

  • Jason Creech Level 3 124 posts since
    May 28, 2010

    Hi Nitin,

     

    This looks like a setup issue.

     

    It may be that you have a good Windows authentication record but not a MSSQL Authentication record. 

     

    The policy above appears to have both Windows OS and Windows MSSQL controls. You would need to have two authentication records for scanning the target Windows systems for this policy to provide both the OS and DB level configuration content.

     

    You mention that manually created controls (User Defined Controls or UDC I am assume?) are reporting okay.  Since UDCs are only available for Windows or UNIX authentication and not database technologies, it may be that you have not setup a MSSQL authentication record but do have Windows authencation records setup.

     

    When a Windows system is scanned, the Windows authencation record is used for that technology type to gather OS values.  If it has a MSSQL database installed, you will need an MSSQL auth record as well even if the database is configured for Windows or Mixed Mode authentication.  MSSQL Auth records also have an OS level configuration option for some of the OS level database checks as well.

     

    Let me know if this helps,

     

    Jason Creech

    Qualys

      • Jason Creech Level 3 124 posts since
        May 28, 2010

        Hi Nitin,

         

        Your JPG didn't come through for some reason.

         

        But, to answer your question, the appropriate authentication records to use will depend on the policy data you want and how your MSSQL databases are configured.

         

        If your MSSQL databases are configured for Windows Auth or Mixed mode, then you can use Windows option in the MSSQL auth record since the account will have rights to authenticate into the database to get confgurations values.

         

        But, if the MSSQL databases are configured for database authencation only, you must use database option in the MSSQL record.

         

        If your policy includes OS level controls listed under the Windows Server or AD technology types AND MSSQL technology controls, you will need both a Windows Authencation record AND an MSSQL Authentication record.

         

        If you are using the appropriate auth records and still getting failures, make sure the account you are using has appropriate admin rights. 

         

        In the HELP>>Resources>>Tips and Techniques areas, you will find the Trusted Scanning Guide for MSSQL, This guide has the information you will need to setup the MSSQL authentication.

         

        Best Regards,

         

        Jason Creech, Qualys

          • Jason Creech Level 3 124 posts since
            May 28, 2010

            Hi Nitin,

             

            At this point, since it is difficult to ascertain where the issue might be with the limited information we can share in this forum, we should setup a support case for tracking purposes.  Support can rule out the usual configuration/setup issues and ascertain if the problem is a bug or if there was a step missed in the configuration of the MSSQL scans, policy creation, and/or reporting. 

             

            Also, if support is unable to resolve the issue, I could conduct a WebEx to take a look as well.  There are several areas where the setup or process could be off, that is usually the issue though, occasionally, there may be an issue engineering might need to address. 

             

            Contact support@Qualys.com and describe the issue you are seeing and the steps you have taken to resolve as well as your contact information and company name.  Support can get you a case number for tracking and, if necessary, a debug scan could be used to identify where the issue may lie.

             

            I am curious that after you scan the MSSQL system, does the scan even see the IP addresses, give a message about insufficient privileges or auth failed? Not in the report but in the compliance scan information view? 

             

            Below, you can see an example of compliance scan results from my test MSSQL system with two DB instances and the MSSQL authentication was successful, which means user/name password was correct.  And, I did not receive an "insufficient privileges" error message which means my account had appropriate access to gather the data. You can see another IP where my scan credentials did not have sufficient access to scan that IP so it threw the error message "insufficient privileges".

             

            Compliance Scan Results.jpg

             

            Let me know if you have an issues creating the support case.

             

            Best regards, Jason Creech

              • Jason Creech Level 3 124 posts since
                May 28, 2010

                Hi Nitin,

                 

                Thank you for the information.  I think contacting support is still the best option as they can work directly with you to figure out the issue.  Failed authentication usually means one of two things on the database scanning.

                1. Most simply Username/Password are incorrect which I doubt based on your responses.
                2. More likely, the database is not configured to allow the auth type being used (I.e., database is not configured for mixed mode or Windows auth and a Windows credential is being used.) or some variation of this.

                 

                 

                But, without having access to the system, I am guessing a bit.

                 

                Please update the post if support is able to resolve the issues for you.

                Best regards,

                Jason Creech

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 6 points