Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

sa with Great Plains SOX compliance. Expand / Collapse
Author
Message
Posted Wednesday, February 7, 2007 8:07 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, February 10, 2007 6:12 PM
Points: 1, Visits: 1

Forgive my question if it has already been answered elsewhere. Would appreciate links to the forums that help.

I'm a SQL Server novice, but i'm learning (used to Oracle), and I've been asked to get SOX compliant with Great Plains from Microsoft (know even less about Great Plains). I'm sure many of you know that pain.

I am told GP only allows access with the sa login. Is there a way to find out the box IP and/or windows login of the person logging into SQL Server with sa? Is there any 3rd party software that might provide that information?

Would appreciate any help or suggestions. Thanks.

Post #343313
Posted Friday, February 9, 2007 6:54 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Sunday, June 22, 2014 6:53 PM
Points: 967, Visits: 388

You can find out the hosname (usually) of a connection by running the sproc [master].[dbo].[sp_who2]

It will list the login name, SPID, Hostname, and a bunch of other useful things.  If the application connects to the SQL server using SQL authentication, then no, you will not know their windows login.  I don't believe that the windows login name is exposed to the connection in any way that would allow it to be learned from SQL server.  I'm not 100% positive, however.

I do believe that GP requires that the sa account be used to perfom certain administration tasks, but the users connect with SQL server user names.  At least that's how the last GP system I used was working.

jg

 

Post #343743
Posted Friday, February 9, 2007 10:25 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 11:26 PM
Points: 3,214, Visits: 2,336
Working with "Great Pains" ... another great MS purchase absorbing the competition ... my sympathies to you since I remember the pre and post purchase days ...



Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #343869
Posted Saturday, February 10, 2007 4:53 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: 2 days ago @ 6:27 AM
Points: 82, Visits: 176

Can confirm that Jeff is right in saying

"I do believe that GP requires that the sa account be used to perfom certain administration tasks, but the users connect with SQL server user names"

One question the Auditors like to ask is if they are a user in GP doesn't that mean they have DB access rights. Answer is that  their  password is encrypted in the DB so users cannot just us ODBC to access the database directly

With reagrds to sa it may be possible to set up a user in GP and then give them admin right in SQL to be able to do the restricted tasks. Its one of the down sides of GP - you cannot just give these permisssions to users but one way of getting SOX Compliance. The way we are getting round the issue at present is to only aloww one or two DBAs to have access to the pasword and then changing the password on a regular basis.

 

Hope this helps

Jim




Post #344028
Posted Sunday, February 11, 2007 12:53 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, June 6, 2009 11:47 PM
Points: 48, Visits: 52

Hi - If I understand your question you are trying to find out if you can identify who is using the 'sa' account and from where.

There is a solution out there but I can't post this on this thread since it could be considered advertising. Please contact me (hroggero001@hotmail.com) and I can provide you with the company name/product that achieves what you are looking for.

The solution will allow you to:

> Block the use of 'sa' from any machine outside of the database server itself and the GP box

> Log all attempts to use the 'sa' account from anywhere along with the IP address

> Use 2-factor authentication (extreme case) if you want to know who is actually using 'sa' and from which IP/MAC address

> Ensure that 'sa' is only usable by GP and not Query Analyzer

Regards,

Herve



Herve Roggero
hroggero@pynlogic.com
MCDBA, MCSE, MCSD
SQL Server Database Proxy/Firewall and Auditing
Post #344055
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse