NAS 4.03 minimum permissions in SQL Server

We are trying to determine minimum permissions needed to run NAS to keep our SOX auditors happy.
The only reliable combination we have found is NAV SUPER permissions and dbo rights to the database. If we don't give dbo rights, it has problems reading Navision tables.
The NAV license is loaded in the SQL Server.

Is there a lesser set of rights that work for NAS?

Comments

  • The users just need public role. Get in contact with a partner to setup your db correctly.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • I don't think that works for NAS
  • Are you sure it's not something with the code that is creating this issue? No NAV client, including NAS, should ever need to be DBO.
    There are no bugs - only undocumented features.
  • Our dbas have locked down permissions in SQL Server
    Should I be looking at an approle account?
  • Define "locked down". NAV only requires the minimum permissions of membership in the "Public" roles both at server and database level. It requires no additional permissions on the SQL end.

    What error is NAS reporting?
    There are no bugs - only undocumented features.
  • And best use the Standard Security Model and not the Enhanced one.

    The dbowner is only needed if you need to change/insert tables like when importing objects.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • What is the exact error the NAS reports? I'm think one possibility is that the NAS process is trying to insert a non-blank value into an auto-increment field. And that's why it only works as DBO.
    There are no bugs - only undocumented features.
  • davmac1
    edited 2011-12-15
    Inbetween other tasks, I have been checking the code, and it is doing a transferfields to an archive table where the primary key is autoincrement. Probably the result of copy and paste.
    When I archive, I typically add a separate key field for the archive table.

    I will ask the provider to look at changing it. (We have internal rules on who can change what.)
  • Hi
    We had a similiar problem caused by table inserts in tables containing autoincrement values in pk. The problem arised if the value for the autoincrement part was not zero. In this case SQL server executed "Set Identity_Insert", but this was only possible in the context of a dbo or higher.
    Solution was to eliminate the C/AL code causing the autoincrement value to be <> 0 or dont use autoincrement.

    Also look here: viewtopic.php?f=23&t=14145

    Hope this helps
    Thomas